Как идея становится фичей: пошаговая инструкция

Очень часто (на самом деле, постоянно) перед продакт-менеджером возникает потребность в том, чтобы его детище расширялось функционалом для своих пользователей. Как сделать так, чтобы эти фичи оказывались максимально а) востребованными б) быстрыми в разработке?

1. Сформулировать идею в формате мини-истории. Мы в EPICSTARS используем короткий шаблон, который стараемся заполнять под каждую идею:

  1. Какую проблему решает ваша идея
  2. В чем недостатки текущего решения?
  3. За счет какого действия/особенности она будет решена
  4. Варианты реализации идеи (не обязательный для стадии формулирования идеи пункт)

2. Первый уровень фильтрации. Определить глобальную востребованность этой фичи на текущем этапе развития продукта и то, на что она должна повлиять в продукте.

Я рассказывал ранее, что использую простой подход к определению того, на что влияет будущая фича: 1) лояльность и(или) активность пользователей; 2) деньги пользователей. Зная какие цели перед вами и вашим продуктом сейчас стоят, вы можете на начальном этапе отфильтровать те, которые уже не нужны.

Можно использовать скоринговый подход, описывал его в этом посте: http://t.me/ruspm/201

3. Второй этап фильтрации на уровне одноцелевых фич. На этом этапе нужно определить приоритет конкретной фичи по сравнению с аналогичными фичами, которые стоят в одной группе и преследуют одни цели.

Можно использовать классическую 10-бальную шкалу важности для каждой фичи, которая строится… сугубо на вашей субъективной оценке. Цель работы каждого продакта — раскачать свои навыки и интуицию так, чтобы эта оценка максимально совпадала с итоговым результатом.

4. Выбираем фичу. Исходя из а) этих оценок б) внутренного голоса (да-да) сделать выбор идеи, с которой дальше пойдет работа.

5. Начинаем созидать. Далее начинается кропотливая работа, вариации которой разнятся от продукта к продукту, от команды к команде. В нашем случае, мы расширяем описание сторис и ставим метрики, на которые ее реализация или изменение должны повлиять.

6. Далее эта сторис уходит на прототипирование. Обычно, проходит не более 3-х интераций, в результате которых становится понятна механика, по которой эта фича может работать.

Обычно, этот этап проходит в консультациях с а) фронтэнд-разработчиком и б) бэкэнд-разработчиком, которые оценивают варианты реализации, которые им же и придется кодить. Обычно, сторис подвтергается новому расширению описанию и в ее подтаске добавляется информация, связанная с особенностями технической реализации будущей фичи.

7. Получаем апрувы. На этом же этапе бэкэнд и фронтэнд дают свое «добро» на этот вариант реализации и апрувят его понимание.

8. Дизайн. Далее расширенная сторис вместе с прототипом уходит на графическую отрисовку. Нынче модно говорить с умным видом про дизайн-системы, но я считаю, что это те же самые дизайн шаблоны и сеты, поэтому мы просто собираем прототип на основе нашего текущего дизайна. В сторис добавляются макеты новой фичи.

9. Верстка. Далее снова зависит от текущего положения ролей в команде. У нас версткой макетов (и-за наличия единого стиля и готовых блоков интерфейса) в 80% случаев занимается фронтэнд-разработчик. В этом есть плюс когда команда не занимается креативом и не фигачит лендосы, где нужно изворачиваться и постоянно придумывать что-то новое. Макет верстается.

10. Включение в бэклог. Полдела сделано — теперь у нас есть готовая к разработке фича, сформулированная в сторис и содержащая ВСЮ необходимую и понятную для всех участников процесса/команды информацию, которую можно смело включать в бэклог, а потом и в спринт.

11. Разработка. Далее фича идет в разработку теми, кто включен тимлидом в этот процесс. У нас тимлид пишет отдельную техническую стори в которой описывает то, что написано в продуктовой стори на языке архитектуры, связей объектов и другой тарабарщине, которую не всегда нужно понимать ))

Обычно в процессе задействованы перечисленные выше фронт и бэкенд-разработчики (или целые команды), которые по традициям старой школы ведут разработку на тестовом сервере с приставкой DEV, о наличии которого знает только ваша команда.

12. Тестовый релиз. Когда фича готова, она идет в релиз на этом сервере, где по все тем же традициям ее работоспособность и соответствие требованиям тех/ сторис проверяет QA-инженер. Если что-то не так — фича переделывается. Рекомендую проверять фичи на дев-сервере на соответствие вашим ожиданиям и сторис, чтобы потом не переделывать их на проде.

13. О — ожидание. Ура, QA проверил и дал зеленый свет! Но фича ждет остальные фичи, которые были включены вами в спринт…

14. С днем рождения! День релиза на продакшен-сервере (который боевой с публичным продуктом и для пользователей) для продакт-менеджера как день рождения для ребенка, с той лишь разницей, что такие дни рождения можно устраивать каждый месяц!

15. Кое-что забыли. За день до релиза можно снять прошлые метрики, которые выставлены для фичи в качестве ключевых, чтобы было что с чем сравнивать.

16. Проверка. Обычно, в день релиза я как продакт иду и проверяю соответствие выкаченной фичи ее описанию из сторис и макетам. Если все ок — день рождения удался! Если нет — ох… лучше не думать об этом и именно поэтому читай п. №14.

17. Движение вперед. Фича работает, активность идет, метрики начали двигаться. В зависимости от фичи, к ее релизу можно привязать какие-либо маркетинговые активности (новость на сайте, рассылка, промо).

18. Пост-аналитика. Настало время считать цыплят, а именно правильно ли вы выбрали фичу и то, как она решает поставленные перед ней задачи. Снимаем метрики и делаем выводы о том, все ли вы правильно сделали. Нет — возвращайся к п.№1

You need an account to comment