RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта

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

    image

    Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.

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

    Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки?

    В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.

    Метод RICE Score


    Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?

    Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.

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

    • Reach — это охват
    • Impact — влияние
    • Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
    • Effort — трудозатраты

    Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.

    image

    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: Как это работает?


    Рассчитайте оценку для каждой фичи или идеи, согласно формуле:

    image

    • Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
    • Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
    • Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.

    image

    В 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:

    image

    Оценка в Hygger по RICE


    Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.

    image

    Все фичи также можно увидеть в таблице:

    image

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

    image

    Push работает так:

    • создается задача по реализации фичи на доске разработке — на Канбан или Спринт доске внутри Hygger (да-да, Hygger поддерживает Kanban и Scrum). В будущем мы добавим интеграцию с Jira и с другими трэкерами задачи, так как прекрасно понимаем, что многие команды используют для разработки Jira и уйти с нее на что-то другое — анрил
    • задача на бэклог-доске и задача на доске разработки линкуются между собой
    • когда задача на доске разработке будет полностью выполнена, задача на бэклог-доске также будет перенесена в done-колонку.

    Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.

    Оценка в Hygger по ICE


    Такой же алгоритм и в случае с выбором модели оценки ICE.

    Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.

    image

    Удобная таблица также визуализирует все ваши фичи:

    image

    Другие способы приоритизации в Hygger


    Приоритизация Value & Effort (aka Lean Prioritization)


    Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и

    Ценность:

    • Value — это то, какой вклад приносит конкретная фича.
    • Effort — это усилия, необходимые для реализации фичи.

    Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).

    В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):

    image

    • Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
    • Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
    • Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
    • Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.

    Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.

    Hygger

    74,00

    Hygger

    Поделиться публикацией
    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое