Продакт и приоритизация: как оценить задачи проекта?

Иногда в команде появляются разногласия по продукту: какие сейчас задачи в приоритете. Чтобы между разработчиками и менеджерами не встала стена непонимания, продакт должен провести приоритизацию. А как сделать это правильно — читайте в статье.

Опытные продакты знают, что просто пальцем в небо не ткнёшь и среди всех горящих задач нужно выделить самые весомые. Миша Карпов, ex-Product Director Skyeng, через одно из исследований выяснил, что российские и зарубежные компании разбивают приоритизацию на два этапа: быстрая и медленная оценка.



Сначала — быстрая оценка, которая отсекает нерелевантные задачи. После этого продакт проводит медленную детальную оценку.

Быстрая оценка

Для быстрой оценки продакты вооружаются Agile-подходом, который учитывает пользу задачи и трудозатраты команды:

• Сначала продакт-менеджер и технические специалисты обсуждают, насколько полезна новая фича, например, польза фильтров в приложении «Метро». Команда голосует: показывают 1–3 пальца — и продакт записывает среднее значение. Так происходит со всеми фичами.
• Далее обсуждается, насколько сложно внедрить обновление. Как и с пользой результаты голосования записываются в колонку «Средняя оценка Затрат».
• Соотносим пользу и затраты. По таблице на рисунке выше видно, что Фича 2 и Фича 3 сильно лидируют — значит, два этих обновления стоит запустить в ближайшее время. По второму столбцу видим, что их просто сделать, а по первому, что эти фичи будут полезны для пользователей.

Трудозатраты обсуждаются с технической командой.

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

Вариантов оценки немало: например, у компании Intercom:

• в первом столбце пишется название фичей;
• во втором (Reach) — количество людей, которые могут столкнуться с этой фичей;
• в третьем (Impact) — уверенность в том, настолько обновление будет полезно пользователям;
• в четвёртом (Confidence) — вероятность, что фича «выстрелит»;
• в пятом (Effort) — затраты и сложность. После этого подсчитывается RICE score: между собой перемножаются Reach, Impact и Confidence и делятся на Effort.

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

Ещё один вариант быстрой оценки — «Иерархия метрик» на примере «ВКонтакте»:

• По верхнеуровневой метрике считают, как часто пользователи взаимодействуют с фичами.
• На следующем этапе используют сервисную метрику — время просмотра видео. Продакт обсуждает с командой, что влияет на время просмотра видео: длительность и количество. Эти показатели относятся к lvl 1.
• На уровне lvl 2 разбираем, что влияет на каждый показатель в частности. На длительность влияют процент досмотра и сама длительность видео. На проценты просмотра влияют качество контента и скорость загрузки видео.
• Раскладываем каждый пункт на уровни: получается слоёный пирог из основной метрики и уровней, которые на неё влияют. На этом этапе продакт думает, что могло бы улучшить показатели (например, добавить видео в HD). Но перед тем, как внедрить изменения, нужно понять, на какую метрику это повлияет. В этом случае HD-формат повлияет на качество видео. Продакт изучает своё дерево и находит уровень, на котором он разместил «Качество видео».

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

Чтобы измерить, насколько важно качество контента, продакт строит дерево, которое проверяют аналитики. После этого у разработчиков появляются задачи на полгода-год вперёд. Они поэтапно дорабатывают продукт.

На картинке ниже «Иерархия метрик» в формате excel для помесячного или поквартального анализа:

• в первом столбце указаны метрики, которые нужно поднять с помощью новых фичей;
• во втором столбце — ожидаемые оцифрованные показатели;
• в третьей колонке фичи, которые нужны;
• в четвертой колонке вес фичей (от одного до трёх).

С чем сталкивается продакт при работе с деревом?

• Бывает, что в таблице 15 фичей, а остальные 180 ждут своей очереди;
• Когда дерево составлено, идеи для фичей берут не только из таблицы, но и из бэклога, так как члены команды могут посоветовать что-то важное;
• «Вес» определяется по аналитике прошлых проектов и фичей;
• Если один проект влияет сразу на две метрики — его определяют в ту метрику, на которую он окажет больше влияния.

Медленная оценка

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

Нужно узнать, сколько денег принесёт квест и в каком приоритете должна стоять эта задача.

Составляем калькулятор с ответами на главные вопросы (жёлтым цветом в таблице выделены те пункты, в которых продакт сомневается):

• Сколько пользователей за 12 месяцев окажутся в этой точке принятия решения? Например, 100 000 человек.
• Сколько пользователей попробуют квест? Команда предполагает, что это могут быть 44 %.
• Сколько пользователей завершит весь квест? Возможно, 81 %.
• Насколько больше пользователей сделают вторую оплату после внедрения квест-уроков? Предположительно, повторных оплат станет на 4 % больше.
• Какую прибыль приносит вторая оплата? Команда точно знает, что 5000 рублей.
• Какую дополнительную прибыль получит компания за 12 месяцев от даты запуска? Считаем количество участников и умножаем на повторную оплату.

Почему числа, выделенные жёлтым, именно такие: 40 %, а не 60 % или 15 %?

Чтобы ответить, считаем вероятности для неизвестных коэффициентов (пункт 2 на картинке).

1. Рассматриваются пессимистичный, реалистичный и оптимистичный сценарии для тех, кто пробует WOW-уроки. Подставляем под каждый сценарий цифру, которая соответствует нашим ожиданиям.
2. В колонке «Вероятность сценария» определяем, какова вероятность, что сценарии произойдут, и считаем среднее значение. То же самое с остальными неизвестными.
3. Оцениваем стоимость разработки.
4. Считаем соотношение стоимости разработки и полученных денег (для стоимости разработки продакт уточняет у команды, сколько часов они потратили и умножает на их ставку).

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

Для сторонних людей может показаться, что продакт распыляется и при приоритизации тратит зря время.

Нужно посчитать, во сколько компании обойдётся ошибка продакта. Сумма может исчисляться миллионами.

Какой калькулятор для подсчёта данных использует Skyeng?

Это Google Doc, к которому подключаются данные (текущая стоимость, текущее LTV и т. д.). Информация попадает в ячейку документа, и затем все калькуляторы ссылаются на определённую ячейку. Расширенный калькулятор используется, когда нужно уточнить больше деталей.

Краткий алгоритм приоритизации

1. Найдите ТОП-3 ключевые метрики для конкретного сервиса.
2. Соберите гипотезы для прокачки этих метрик: из бэклога или вне его.
3. Если рынок новый — используйте качественные методы: спрашивайте у потенциальных юзеров, чем они сейчас пользуются.
4. Проведите быструю оценку и отбросьте «слабые» фичи.
5. Проведите детальную оценку оставшихся фичей.

Skyeng используют один быстрый и один медленный методы и заранее определяют сроки приоритизации. Например, для разработчиков на еженедельной планёрке команда обсуждает, сколько времени каждому понадобится на решение различных задач. Они предоставляют продакту оценку сроков, после чего он решает, браться ли за фичу. На приоритизации последней используют метрику ROI, чтобы показать соотношение денег, которые получит компания, и денег, которые будут потрачены на разработку. Бывает, что ROI может составить более 1000–3000 %, а разработка фичи займёт совсем немного времени.

Грамотной приоритизации!