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

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

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