Шаблоны откликов

— Как ты будешь принимать решение о необходимости этой фичи и её приоритете? Какие факты/данные/действия помогут тебе принять такое решение?

• Для начала я попытаюсь сформулировать проблему, вместо готового решения (часто так можно прийти к более выверенному решению), допустим мы видим, что шаблоны и правда кажутся наиболее оптимальным решением
• Сформулирую гипотезу или ряд гипотез по этому функционалу (например по шаблону “Мы хотим сделать Х, это позволит Y получить Z”)
  • Гипотеза 1: специалисты, использующие функционал будут чаще получать заказы потому что будут откликаться первыми
  • Гипотеза 2: специалисты будут отправлять больше откликов из-за упрощения флоу, увеличится общее число заказов у таких специалистов, у увеличится выручка от откликов, так как я вижу, что отклик платный
  • Вывод: скорее всего можно придумать ещё какие-то гипотезы, но уже видно, что скорее всего этот функционал влияет на ключевые метрики платформы
• Определю метрики, на которые потенциально влияет этот функционал
• Определю влияет ли функционал на фокусные метрики и цели бизнеса прямо или опосредованно (с помощью пирамиды метрик)
• Посчитаю возможный эффект в деньгах
• Мы уже знаем по качественным данным, что такое пожелание есть, мы можем подтвердить их количественно через платформу идей или по фиксированным фактам от поддержки и фронт-персонала
• Посмотрю сколько времени тратят специалисты на заполнение этого поля, как часто вставляют скопированный текст туда и насколько различны итоговые тексты между собой у каждого отдельного специалиста.
• Сформирую предварительное описание функционала или подготовлю wireframe, чтобы оценить затраты ресурсов на функционал
• Проскорю в сравнении с остальными задачами беклога, например по RICE (все данные, необходимые для этого, я уже получил)
• Текста много, но делается это сравнительно быстро

— Если фичу всё же решено делать, то как? Будешь ли ты её декомпозировать (если да, то на какие части), будет ли у неё несколько версий (если да, то каких)?

• Я думаю надо предложить специалисту сочинить себе шаблоны с использованием лучших практик (которые можно показывать в окне редактирования шаблона), чтобы был какой-то эффект конкуренции и клиентам не приходили однотипные шаблоны
• Элементы управления шаблонами расположить рядом с полем “Предложение клиенту” в соответствии с дизайн-системой и может быть ещё в профиле/настройках
• Декомпозицию по юз кейсам в формате UML обычно делаю, пусть будет:
  • UC1 - Создание шаблона
  • UC2 - Редактирование или удаление шаблона
  • UC3 - Вставка шаблона
  • В расширениях и дополнительных требованиях будут размещены дополнительные требования, альтернативные сценарии и критерии приёмки
• Версию можно сделать одну или две, например сначала позволять делать только один шаблон, а можно сразу несколько

— Ниже упрощённый скриншот формы для отклика. Попробуйте (любым способом) визуализировать первую версию.

https://lh7-us.googleusercontent.com/ItegyAFut_x_o8rhGkhkfujwrEDtjPrSaOlVFhbzTmuwIbTRpsG_04mCp9dsKJ1HPDEs-IhLxOGoQpHLlGFB2H1kKX9qEcE9pmmpi5F3u1mjjw62rNT6mURcSBtcLtOAO60_7d02hIJRi7K4n136qQ

По нажатию кнопки открывается редактор шаблона, можно в модальном окне. Если есть хоть один шаблон, то вместо кнопки можно отображать выпадающий список или контрол предусмотренный дизайн-системой