Как приоритизировать задачи в продукте
Приоритизация — секретный ингредиент?
Согласно определению из Википедии : «Приоритизация — понятие, показывающее важность, первенство. Например, приоритет действий определяет порядок их выполнения во времени»
Из определения становится понятно, что основная цель приоритизации — понять, «что важнее чего».
Казалось бы, что сложного? Выбрал те задачи для реализации, что повысят метрики компании, а остальные убрал поглубже в бэклог до “лучших” времен. Звучит действительно просто, когда у тебя немного задач.
Но что делать когда задач больше?
Представим себе обычную ситуацию продакт менеджера Петра, которая происходит раз в квартал:
Петр выходит из переговорки держа под мышкой свой ноутбук. Облегченный выдох, настроение приподнятое. Только что у Петра закончилось многочасовое совещание с командой по генерации идей и задач на следующий квартал. По началу конечно шло тухло, но вскоре у команды случилось прозрение и идеи полились рекой. “Мы обречены на успех” — подумал Петр, придя на свое место. Теперь осталось только выбрать с чего же начать победоносное шествие. И тут уже энтузиазм заметно падает перед списком:
1) A/B тест лендинга 1 и лендинга 2
2) Дизайн дашборда
3) Интеграция CRM для отдела продаж
4) Добавить базу знаний для пользователей
……..
27) Welcome бонус при регистрации пользователя
Что же первое взять в работу? А второе? Ну дальше? Почему не наоборот?
Разумеется, реализовать их все вряд ли получится. Все упирается либо во время, либо в деньги. Но как правильно оценивать и отсеивать фичи?
Существует различные подходы к оценки той или иной задачи. Ниже разберем основные из них.
Быстрая приоритизация. “А не фигню ли я делаю?”
Данный метод представляет собой “народное” мнение команды. Во многих случаях это особенно полезно, когда “фичи” затрагивают несколько категорий. Одна фича для отдела саппорта, другая для отдела продаж, третья для маркетинга и т.д
В этом подходе мы используем метод Poker Planning
Сам процесс по шагам выглядит так:
- Продакт- менеджер с командой обсуждают пользу каждой фичи и ставят свою оценку от 1 до 3. Где 3 “супер полезно”, а 1 “минимально”. Записывается среднее значение в таблицу.
- Тоже самое повторяем с оценкой затрат. Важно: затраты нужно обсуждать не с коллегой на кухне, а непосредственно с теми кто выполняет задачу.
- Получаем соотношение польза/затраты и видим, что 1 и 3 задача лидируют- значит, их можно взять в ближайший спринт.
RICE
Данный подход был разработан в компании Intercom. После тестов ребята остановили на 4 важных факторах:
- Reach (охват) — скольким пользователям мы улучшим жизнь?
Охват измеряется количеством людей / событий за период времени.
- Impact (эффект) — насколько мы улучшим жизнь нашим пользователям?
Воздействие трудно измерить довольно точно. Поэтому для удобства можно сделать следующие варианты: 3 для “сильного воздействия”, 2 для “высокого”, 1 “для среднего”, 0,5 “для низкого” и 0,25 для “минимального”.
- Confidence (уверенность) — насколько мы уверены, что вообще можем что-то улучшить?
Здесь есть 3 градации уверенности:
100% — высокая
80% — средняя
50% — низкая
- Effort (усилия) — сколько времени нам понадобится, чтобы реализовать задуманное?
В основном измеряется в “человеко-месяцах”. То есть объем работы, которую человек может выполнить за 1 месяц. Используем по возможности целые числа. Если 1 месяц, то значение 1,0. Если занимает меньше месяца, то значение 0,5.
Далее после того как умножим первые 3 параметра друг на друга и поделим на усилия, мы получаем итоговый счет. Чем выше счет тем важнее реализация той или иной задачи.
MoSCoW
Метод MoSCoW позволяет разделить все активности, «хотелки» и вновь прилетающие задачи на 4 категории, что намного эффективнее.
- Must — то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.
- Should — не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».
- Could — желательные требования, которые можно сделать, если останется время и будут ресурсы.
- Would — требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.
Отсюда как раз идет аббревиатура MoSCoW. Разберем данный подход на примере ремонта новой квартиры в новостройке:
- M — делаем электричество, трубопровод, клеим обои, кладем плитку или паркет. Устанавливаем туалет, ванну, делаем кухню и базово в спальню хотя бы просто кровать.
- S — покупаем мебель, шкафы, холодильник, микроволновку, стол, стулья, стиральную машину.
- C — установка посудомойки, дополнительные шкафы, кран с вытягивающимся шлангом,подсветка по периметру шкафов или на потолке.
- W — сервоприводы для ящиков, подсветка внутри шкафов, крутящаяся полка для углового шкафа, акустическая система, сетка на окнах от комаров, теплый пол, видеодомофон.
Плюсы: просто, быстро, понятно заказчику (если это не технический специалист).
Минусы: не сильно объективно, не учитывается техническая сложность и риски
ICE Scoring: Как это работает?
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
- Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
- Легкость реализации— это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
- Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1–10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
- Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?
- Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?
- Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?
Недостатки ICE
ICE Scoring иногда подвергается критике за его субъективность:
- одна и та же фича может оцениваться по-разному одним и тем же лицом в разное время. Это может повлиять на окончательный список приоритетов.
- если разные люди оценивают фичи — все они будут оценивать ее по-разному.
- члены команды, которые хотят, чтобы их фичи были приоритетными, могут манипулировать результатами, чтобы получить аппрув.
Резюме
Описанные в статье подходы к приоритизации не единственные, но почти все они базируются на одних и тех же принципах.
В заключении приведу краткий алгоритм приоритизации:
1. Найдите ТОП-3 ключевые метрики для конкретного сервиса.
2. Соберите гипотезы для прокачки этих метрик: из бэклога или вне его.
3. Если рынок новый — используйте качественные методы: спрашивайте у потенциальных юзеров, чем они сейчас пользуются.
4. Проведите быструю оценку и отбросьте «слабые» фичи.
5. Проведите детальную оценку оставшихся фичей.