Каждый менеджер продукта рано или поздно сталкивается с вопросом приоритизации при планировании стратегии и роадмапа продукта. Всегда ли просто и быстро можно решить над чем работать в первую очередь?
Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.
Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.
Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки?
В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.
Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?
Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.
RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.
Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.
Влияние показывает какой вклад приносит эта фича продукту.
Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:
Исходя из ваших текущих целей у вас будут свои метрики.
Это фичи, которые помогают нам получить новых пользователей во время онбординга. Но не стоит забывать о том, что большинство пользователей «отпадают» на второй день.
Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.
Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.
На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.
К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.
Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.
Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.
Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.
Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
ICE Scoring иногда подвергается критике за его субъективность:
Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.
С чего начать?
Во-первых, у вас должны уже быть собранными необходимые фичи и идеи продукта на вашей Kanban-доске. Используя Hygger, вы можете структурировать их с помощью горизонтальных колонок Swimlanes, а также применяя Labels. Вы также можете настроить процесс работы с фичами с помощью Columns. К примеру, можно создать следующий рабочий процесс:
В меню Hygger вы найдете варианты моделей для оценки и приоритизации фичей, в том числе, RICE и ICE:
Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.
Все фичи также можно увидеть в таблице:
Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.
Push работает так:
Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.
Такой же алгоритм и в случае с выбором модели оценки ICE.
Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.
Удобная таблица также визуализирует все ваши фичи:
Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и
Ценность:
Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.
Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.
Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.
Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки?
В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.
Метод RICE Score
Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?
Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.
RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:
- Reach — это охват
- Impact — влияние
- Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
- Effort — трудозатраты
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Reach (Охват)
Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.
Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.
Impact (Влияние)
Влияние показывает какой вклад приносит эта фича продукту.
Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:
1. Улучшают trial-to-paid конверсию (metric movers)
Исходя из ваших текущих целей у вас будут свои метрики.
2. Помогают привлечь новых пользователей
Это фичи, которые помогают нам получить новых пользователей во время онбординга. Но не стоит забывать о том, что большинство пользователей «отпадают» на второй день.
Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.
3. Помогают сохранить текущих пользователей
Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.
4. Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.
К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.
Confidence (Уверенность в оценке)
Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.
Effort (Трудозатраты)
Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.
Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.
Метод оценки ICE
Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.
ICE Scoring: Как это работает?
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
- Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
- Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
- Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
- Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?
- Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?
- Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?
Недостатки ICE
ICE Scoring иногда подвергается критике за его субъективность:
- одна и та же фича может оцениваться по-разному одним и тем же лицом в разное время. Это может повлиять на окончательный список приоритетов.
- если разные люди оценивают фичи — все они будут оценивать ее по-разному.
- члены команды, которые хотят, чтобы их фичи были приоритетными, могут манипулировать результатами, чтобы получить аппрув.
Как использовать RICE и ICE Scoring?
Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.
С чего начать?
Во-первых, у вас должны уже быть собранными необходимые фичи и идеи продукта на вашей Kanban-доске. Используя Hygger, вы можете структурировать их с помощью горизонтальных колонок Swimlanes, а также применяя Labels. Вы также можете настроить процесс работы с фичами с помощью Columns. К примеру, можно создать следующий рабочий процесс:
- Backlog — здесь вы собираете все идеи и фичи
- Next Up — сюда вы перемещаете фичи, над которыми хотите работать в ближайшее время
- Specification — тут вы собираете требования и пишите спеки на фичи
- Development — фичи находятся в разработке, и здесь вы можете отслеживать их текущий статус
- Done — фичи были успешно залиты на прод и теперь доступны вашим пользователям.
В меню Hygger вы найдете варианты моделей для оценки и приоритизации фичей, в том числе, RICE и ICE:
Оценка в Hygger по RICE
Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.
Все фичи также можно увидеть в таблице:
Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.
Push работает так:
- создается задача по реализации фичи на доске разработке — на Канбан или Спринт доске внутри Hygger (да-да, Hygger поддерживает Kanban и Scrum). В будущем мы добавим интеграцию с Jira и с другими трэкерами задачи, так как прекрасно понимаем, что многие команды используют для разработки Jira и уйти с нее на что-то другое — анрил
- задача на бэклог-доске и задача на доске разработки линкуются между собой
- когда задача на доске разработке будет полностью выполнена, задача на бэклог-доске также будет перенесена в done-колонку.
Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.
Оценка в Hygger по ICE
Такой же алгоритм и в случае с выбором модели оценки ICE.
Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.
Удобная таблица также визуализирует все ваши фичи:
Другие способы приоритизации в Hygger
Приоритизация Value & Effort (aka Lean Prioritization)
Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и
Ценность:
- Value — это то, какой вклад приносит конкретная фича.
- Effort — это усилия, необходимые для реализации фичи.
Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
- Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
- Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
- Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
- Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.
Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.
