Фильтры восприятия фич из Product Backlog

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

Я хорошо представляю, как тяжело выбирать фичи для разработки, когда ваш product backlog просто ломится от “вкусных” фич. Но нам, менеджерам проектов, приходится совершать этот выбор ежедневно. Потому что наша основная задача — дать пользователю value, как можно скорее и как можно больше. И мы не можем сидеть сложа руки. Наша задача — быстро принимать решения в условиях некоторой неопределенности.

[sendpulse-form id=”278″]

Вопрос звучит просто: какая фича самая важная для нас сейчас? Но если они почти все важные? Этот вопрос слабо помогает нам в принятии решения.

Рассмотрим набор фильтров, которые помогут глубже понять степень важности или степень влияния фичи на ваш продукт. А это понимание поможет принять правильное в данный момент и в данном месте решение.

Итак, поехали:

1. Стратегическая/тактическая

Фича соответствует нашей долговременной стратегии или нет. Пример тактической функции — поддержка нового стандарта GDRP, который должен быть внедрен до 25 мая 2018 года, иначе мы рискуем попасть на большой штраф.

2. Влияет на метрику/не влияет (долги, баги)

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

3. Улучшает UX/портит UX

Фича может улучшать UX и делать жизнь пользователя в вашем продукте лучше, а может, наоборот, усложнять его жизнь, но при этом повышать доход.

4. Нужна многим клиентам/нужна единицам

Сравните: фича, которая касается onboarding и которую увидят и прочувствуют абсолютно все новые пользователи, и фича, которая понадобится пользователям только на 7 день после регистрации. Например, экспорт в PDF time tracking отчета.

5. Нужна часто клиентам/нужна редко

Например Фича shortcuts или hot keys нужна часто тем пользователям, которые активно пользуются сервисом, в отличие от фичи «Смена типа внешнего вида», которая нужна только один раз, когда клиент импортирует свои данные.

6. Время и стоимость разработки: высокие/низкие

Тут все просто: нужно оценить трудозатраты на разработку фичи. Если есть функции с маленькими затратами, но с большим value, то их надо делать первыми. Мы их еще называем Quick Wins. Но нельзя забывать и про большие функции с большим value. Их желательно разбивать на более мелкие куски и делать постепенно. Ибо они могут дать хороший value вашему продукту.

7. Время и стоимость внедрения: высокие/низкие

Себестоимость фичи складывается не только из времени разработки. Для фичи надо написать документацию, снять и смонтировать видео, сделать рассылку, настроить ивенты в аналитике, сделать Dashboard в BI туле, провести вебинар и так далее.

8. Требует vip клиент/требует не платящий клиент

Если фичу просит vip клиент, логотип которого вы гордо показываете всем посетителям на лендинге, то не спешите говорить «нет».

9. Ожидаемая/нет

Если в вашем продукте не будет ожидаемой по модели Кано функции, то пользователь просто уйдет.

10. Желаемая/нет

Пример желаемой по Кано функции — объем доступной памяти на Dropbox. Чем больше памяти доступно пользователю, тем выше его удовлетворенность. Как правило, это линейные свойства продукта, то есть, чем этого больше, тем лучше. Другие примеры:

• больше расстояние между креслами в самолете
• больше разных кодеков поддерживает видео-плеер и т.д.

11. Восхищающая/нет

Если ваша фича является восхищающей по Кано, то она станет «пасхалкой» для пользователя. То есть, это всегда что-то неожиданное, то, чего пользователь совсем не ожидает от вашего продукта. Например, это может быть 2-х уровневое комментирование задач.

Если этой функции не будет в вашем продукте, ну и ладно — пользователи даже не заметят этого. Но, с другой стороны, пользователи могут быть настолько впечатлены функцией, что поделятся своим открытием с другими.

12. Есть у конкурентов/инновация

Если фича есть у конкурентов, это значит только то, что она есть у конкурентов. А вдруг ей никто не пользуется, и конкурент собирается ее скоро «выпилить»? Но иногда фича у конкурентов становится ожидаемой по Кано, и нам приходится ее повторять у себя. А лучше делать новые и классные фичи первыми!

13. Идея проработана/не проработана

Вы готовы отдавать фичу в разработку? Не спешите, убедитесь, что она детально изучена и описана так, что ее четко и ясно поймут ваши программисты и тестировщики. Степень детализации выбирать вам — вы как product manager лучше знаете ваших людей. Если понимаете друг друга с полуслова — отлично, можно не писать «Войну и мир». Работаете с банковским продуктом, у вас в команде есть свои бизнес-аналитики — прекрасно, пусть они моделируют фичу в UML хоть во всех 7 диаграммах.

14. Уверенность в том, что выстрелит: высокая/низкая

Оцените в процентах вероятность того, что фича действительно оправдает возложенные на нее ожидания.

15. Измерима/нет

Идеально, если все фичи измеримые. Это дает нам возможность численно оценить их вклад в успех продукта.

16. Проблема выявлена на UX

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

Конечно, наблюдение проблемы у 5 человек — это одно, а гипотеза на основе анализа поведения 1000000 пользователей — это другое. Тогда и не стоит это сравнивать, а надо формулировать гипотезы и проверять их asap.

17. Технический долг

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

Если такие долги не отдавать, то со временем могут «накапать» очень большие проценты и на рефакторинг кода может уйти намного больше времени, чем эти долги позволили выиграть на старте.

Lean Prioritization или как мы приоритезируем

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

Мы используем метод Lean Prioritization. Он легковесен и эффективен, поэтому мы им пользуемся практически каждый день.

Это метод, представляет собой 2×2 матрицу, которая помогает в принятии решений и определяет, что важно, что рискованно, и куда направлять свои усилия. Матрица активно применяется и для определения приоритетов в разработке продуктов.

Если не поддерживать бэклог постоянно, он быстро может стать свалкой для десятков, сотен и даже тысяч фич и багов.

Используя Lean Prioritization для работы с матрицей можно просто нарисовать большой знак плюс «+» на доске и задать значения «Value» и «Efforts» вдоль вертикальной и горизонтальной осей. Однако, многие согласятся, — эффективнее и удобнее будет использовать специальный онлайн инструмент, особенно, если у вас распределенная команда.

Мы называем такой инструмент Backlog Priority Chart, где, помимо параметров Value и Efforts, предлагаются 4 сегмента: Big Bets, Quick Wins, Time Sinks и Maybes, каждый из которых представляет собой степень приоритетности:

• Quick Wins — это идеи с действительно высоким проказателем value и низким efforts. Это как спелые плоды, которые низко висят и их пора срывать. Чем раньше вы разберетесь с ними, тем больше результата получите.
• Big Bets — это идеи с высокими value и efforts. Вы можете сделать их после Quick Wins. Они займут больше рабочего времени, чем Quick Wins, но принесут такой же профит. Старайтесь разбивать такие фичи на более мелкие.
• Maybes — эти фичи с более низким значение value для клиентов, но их легко реализовать. Они часто заполняют рабочее время, когда есть небольшой «простой» в работе или между более крупными фичами.
• Time Sinks — это идеи с низким value, но значительным показателем efforts. Несмотря на то, что они несут какую-то пользу для клиентов, такие фичи не должны быть приоритетными на данный момент времени.

Наверняка, список способов для определения приоритетности продуктовых фич может быть расширен. А по каким критериям вы оцениваете фичи? Возможно, у вас есть решение, которое может помочь другим?