Как приоритизировать список требований с использованием RICE и ICE
После того как продукт перейдет в модели жизненного цикла на этап выхода на рынок, команде стоит задуматься о смене подхода к приоритизации функций (фич) на более сложный, который учитывает больше критериев и ориентируется в том числе на мнение пользователей.
В этом случае для приоритизации можно начать использовать подход ICE или близкий к нему по сути подход RICE.
Автор — Максим Якубович, партнер Product Lab
Из статьи вы узнаете:
- что такое RICE и ICE;
- как отранжировать функции или требования к продукту по RICE и как это сделать с помощью ICE;
- какие есть нюансы при оценке каждого из факторов, используемых в подходе RICE;
- чем RICE отличается от ICE
Что такое ICE и RICE
ICE и RICE (Impact, Confidence, Ease и Reach, Impact, Confidence, Effort) — два инструмента для принятия решений о приоритетах функций при разработке продукта.
В классификации инструментов приоритизации функций ICE и RICE относятся к сложным инструментам, в которых результат зависит от расчета нескольких параметров, и к внешним инструментам приоритизации, в которых результат оценки зависит от мнения внешних по отношению к команде людей.
При оценке факторов по ICE и RICE можно использовать мнения не только участников команды, но и пользователей продукта или других заинтересованных сторон.
Например, при оценке охвата менеджер продукта может использовать опрос реальных пользователей, чтобы узнать у них, насколько им интересна данная функция в продукте.
Приоритизация в ICE основана на трех критериях: Impact (влияние), Confidence (уверенность) и Ease (простота).
Для каждой функции продукта оцениваются три критерия.
- Impact (влияние)
Насколько сильно эта функция повлияет на достижение бизнес-целей? Например, на увеличение конверсии или доходов.
Оценивается по шкале от 1 до 10.
- Confidence (уверенность)
Насколько уверена команда в том, что функция действительно окажет положительное влияние? Оценка делается на основании анализа данных, результатов тестов и/или экспертного мнения.
Оценивается по шкале от 1 до 10.
- Ease (простота)
Насколько просто и быстро можно реализовать данную функцию с точки зрения ресурсов и времени?
Оценивается по шкале от 1 до 10, где 10 — самый простой вариант.
В подходе RICE для ранжирования функций используется четыре критерия, три из которых очень похожи на критерии, используемые в ICE.
- Reach (охват)
Количество пользователей за определенный период, которым будет интересна данная функция.
Например, если функцией воспользуются 1000 пользователей в месяц, то оценка охвата будет равна 1000.
● Impact (влияние)
Степень влияния функции на пользователей и достижение бизнес-целей.
Для влияния обычно используется шкала от 0,25 до 3, где 0,25 — минимальное влияние, а 3 — максимальное.
● Confidence (уверенность)
Оценивается уровень уверенности в прогнозах охвата, влияния и усилий. Оценка выражается в процентах от 0 до 100%.
● Effort (усилия)
Оценка объема работ, необходимого для реализации функции.
Оценивается в человеко-часах или человеко-днях.
Как видим, в ICE и RICE два критерия полностью совпадают — Impact и Confidence, а один немного отличается. В ICE оценивают Easy, а в RICE — Effort. На самом деле и то и другое относится к оценке сложности задач, но при оценке Easy чем проще реализовать функцию, тем выше будет балл, а при оценке Effort чем больше усилий нужно, тем выше будет оценка.
Инструмент ICE
1. История возникновения подхода ICE
Подход ICE был впервые предложен Шоном Эллисом, предпринимателем и маркетологом, известным как автор подхода Growth Hacking. Эллис работал с такими компаниями, как Dropbox и LogMeIn, где тестирование гипотез и приоритизация стали ключевыми факторами роста. Создавая метод ICE, он стремился упростить процесс принятия решений о внедрении новых функций, сделав его доступным для разных команд независимо от уровня экспертизы.
2. Как проводить оценку по ICE
Оценка по критериям Impact, Confidence и Ease в ICE-подходе может потребовать как внутренней экспертизы команды, так и обратной связи от пользователей. Далее вы увидите, как обычно проводится оценка по каждому из критериев.
- Impact (влияние)
Насколько сильно эта функция повлияет на достижение продуктовой метрики? Например, команда может оценивать влияние на конверсию или на удержание пользователей. Оценивается по шкале от 1 до 10.
Привлечение пользователей здесь бывает полезным, так как их мнения и предпочтения помогают точнее понять, какую ценность они видят в каждой функции. Можно использовать опросы, интервью или A/B-тестирование для получения данных о восприятии и пользе функций.
- Confidence (уверенность)
Оценивается степень уверенности команды в том, что предполагаемое влияние будет достигнуто. На оценку влияют данные из прошлых тестов, экспериментов, экспертиза членов команды и любые релевантные исследования. Оценка 10 ставится, если есть проверенные данные или успешные примеры внедрения аналогичных функций. Если уверенность низкая, ставится 5 и ниже.
Пользователи могут участвовать в тестировании прототипов, чтобы дать команде данные для повышения уверенности в оценке. Эти данные можно использовать для коррекции Confidence по мере работы.
- Ease (простота)
Оценивается, насколько просто внедрить функцию с точки зрения ресурсов, трудозатрат и временных затрат. Если функция требует минимальных ресурсов и реализуется легко, она получает высокий балл (до 10). Для сложных в реализации функций ставится 5 или ниже.
Привлечение пользователей к оценке Ease не обязательно, так как этот критерий больше зависит от технической и ресурсной готовности команды.
Для расчета балла по ICE используется формула
ICE = Impact × Confidence × Ease
3. Пример расчета ICE для функций мобильного приложения банка
Предположим, что необходимо расставить приоритеты для пяти возможных функций для мобильного приложения банка.
В результате приоритизации выяснилось, что функция «Чат-бот для поддержки пользователей» имеет самый высокий ICE Score, значит, ее нужно делать в первую очередь.
4. Плюсы и минусы подхода ICE
Плюсы ICE:
- Простота: система оценки позволяет быстро приоритизировать идеи, не требуя сложных расчетов.
- Гибкость: ICE может использоваться для различных задач, включая оценку продуктовых функций, маркетинговых инициатив и гипотез для роста.
- Фокус на главном: помогает командам сфокусироваться на тех функциях, которые дают наибольший эффект при минимальных затратах.
Минусы ICE:
- Субъективность: оценка по критериям часто зависит от субъективного мнения команды, особенно в отношении таких аспектов, как уверенность и влияние.
- Отсутствие глубокой аналитики: ICE трудно использовать на первых этапах создания продукта, когда команда еще не имеет пользователей и не ведет метрик.
Инструмент RICE
1. История создания RICE
Подход был сформирован в компании Intercom, которая занимается разработкой программного обеспечения для общения с пользователями. Прежде чем прийти к RICE, продакт-менеджеры Intercom столкнулись с проблемой субъективности и непрозрачности при принятии решений о том, на создании каких функций сосредоточиться в первую очередь. Для устранения этой проблемы они искали способ создать простую и прозрачную систему приоритизации, позволяющую оценивать функции по нескольким ключевым критериям, влияющим на успешность продукта.
Как проводить оценку по RICE
Давайте разберем на примере, как может быть сделана оценка по RICE.
Допустим, ваша команда разрабатывает мобильное приложение для управления личными финансами. Менеджер продукта сформулировал гипотезы о возможных новых функциях, которые могут привлечь больше пользователей к приложению.
Можно выделить следующие шаги для получения оценки по RICE:
- сформулируйте гипотезы о новых функциях;
- проведите оценку по каждому из факторов;
- рассчитайте RICE Score для каждой гипотезы;
- ранжируйте гипотезы по полученным баллам.
Шаг 1: Cформулируйте гипотезы
Менеджер продукта сформулировал следующие гипотезы о новых функциях:
Гипотеза A: пользователи будут более удовлетворены, если приложение будет автоматически анализировать их расходы и давать советы по оптимизации, что увеличит их удержание.
Гипотеза B: подключение к банкам для автоматического импорта транзакций облегчит пользователям ведение учета, увеличит количество активных пользователей.
Гипотеза C: введение целей сбережений поможет пользователям лучше управлять своими финансами, что увеличит время, проводимое в приложении.
Гипотеза D: персонализированные уведомления о необычных транзакциях повысят доверие к приложению и помогут вовремя реагировать на подозрительные операции.
Шаг 2: сделайте оценку по каждому из факторов
Менеджер продукта собрал команду разработки, сотрудников отдела продаж и маркетологов, получил от них данные для оценки, обсудил с участниками полученные данные и внес баллы оценки по каждому фактору в таблицу.
Предположим, участники оценили факторы для каждой гипотезы следующим образом.
Шаг 3: рассчитайте RICE Score
Для расчета RICE Score используем формулу
RICE Score = Reach × Impact × Confidence / Effort
Менеджер продукта сделал расчеты RICE-оценки для каждой гипотезы:
- Гипотеза A: RICE Score = (5000 × 3 × 0,8) / 3 = 4000.
- Гипотеза B: RICE Score = (3000 × 3 × 0,7) / 6 = 1050.
- Гипотеза C: RICE Score = (4000 × 2 × 0,6) / 4 = 1200.
- Гипотеза D: RICE Score = (2000 × 3 × 0,5) / 2 = 1500.
Итоговое значение расчетов приведено в колонке RICE Score.
Шаг 4: ранжируйте гипотезы
В итоге ранжирования на основе RICE гипотезы получили следующие приоритеты:
- Гипотеза A — приоритет номер 1
- Гипотеза D — приоритет номер 2
- Гипотеза C — приоритет номер 3
- Гипотеза B — приоритет номер 4
Теперь у менеджера продукта есть уникальные значения оценки каждой функции, а у команды разработки — понимание, в какой очередности они будут реализовывать функции.
Однако, несмотря на простоту самого расчета, у менеджеров продукта остается много вопросов по поводу того, как именно оценивать каждый из факторов.
Давайте разберемся с некоторыми нюансами оценки каждого фактора.
Оценка Reach (охвата)
При оценке Reach (охвата) у менеджера продукта возникает вопрос о том, на основании чего можно сделать прогноз количества пользователей, для которых эта функция может оказаться полезной.
Существует несколько вариантов для оценки Reach.
- Анализ текущих данных
Можно взять за основу данные по охвату для похожих функций, которые уже используются в продукте.
- Пользовательские опросы
Можно провести опрос пользователей о том, насколько вероятно то, что они будут использовать новую функцию.
- Сегментация пользователей
Этот метод предполагает, что новая функция может показаться интересной не всем пользователям, а какому-то их сегменту. Чтобы оценить охват, нужно определить, какие сегменты пользователей могут быть заинтересованы в новой функции (например, новички, активные пользователи).
- A/B-тестирование
Чтобы оценить охват с помощью этого подхода, нужно провести A/B-тест пилотной версии функции на небольших выборках пользователей.
- Экспертные оценки
Для прогнозирования охвата нужно привлечь команду разработки или внешних экспертов.
Оценка Impact (влияния)
При оценке влияния у менеджера продукта возникает вопрос: нужно оценивать влияние всех функций на одну и ту же продуктовую метрику или влияние функций на разные продуктовые метрики?
Здесь уместна следующая рекомендация: если продуктовая команда уже выбрала одну метрику, которую собирается растить в ближайшее время, то при оценке Impact есть смысл определять влияние всех функций именно на эту метрику. Это позволяет более объективно сравнивать влияние различных функций.
Примеры ключевых метрик:
● привлечение пользователей: количество новых пользователей;
● удержание пользователей: процент активных пользователей;
● монетизация: средний доход на пользователя (ARPU);
● вовлеченность: время, проведенное в приложении, количество действий;
● конверсия: процент пользователей, выполняющих целевое действие (например, регистрация, покупка).
Допустим, основная метрика, над которой работает команда, — удержание пользователей (ретеншен). При оценке Impact нужно определить, насколько каждая функция улучшит эту метрику. При этом перед оценкой вы можете договориться с участниками о следующих уровнях влияния:
● более чем 10% к ретеншен — влияние на 3 балла;
● от +7 до 10% к ретеншен — влияние на 2 балла;
● от +4 до +7% к ретеншен — влияние на 1 балл;
● от +1 до +4% к ретеншен — влияние на 0,5 балла;
● менее 1% к ретеншен — влияние на 0,25 балла.
Такой подход обеспечит объективное сравнение функций по одному критерию.
Но могут быть ситуации, когда команда работает одновременно над несколькими метриками. В этом случае можно оценивать влияние каждой функции на разные метрики продукта.
Итак, рекомендации по выбору подхода для оценки Impact следующие.
- Определите главную метрику. Если у продукта четко определена текущая основная метрика (например, увеличение ретеншен), оценивайте Impact по этой ключевой метрике. Это особенно актуально для продуктов на начальных стадиях жизненного цикла, где фокус на одной метрике более важен.
- Используйте несколько метрик в сложных продуктах. Если продукт зрелый и вы работаете над ростом нескольких метрик (например, удержание и выручка), оценивайте влияние каждой функции на свою метрику. Например, одна функция может влиять на увеличение выручки, а вторая — на рост удержания пользователей.
Оценка Confidence (уверенности)
Confidence (уверенность) в модели RICE показывает, насколько команда уверена в точности своих оценок по Reach, Impact и Effort.
Для оценки Confidence обычно используют процентные или оценочные шкалы.
Процентная шкала — один из наиболее распространенных подходов. Он позволяет выражать уверенность в процентах, где 100% соответствует полной уверенности.
Но некоторые продакт-менеджеры выбирают более простую оценочную шкалу, которая предполагает использование словесных оценок для уверенности.
Например, можно использовать следующие градации для оценки уверенности:
100% — высокая уверенность;
80% — средняя уверенность;
50% — низкая уверенность.
Оценка усилий (Effort)
Оценка Effort (усилий) в модели RICE показывает, сколько ресурсов потребуется для реализации функции. Для оценки Effort по каждой функции обычно используют человеко-часы, человеко-дни или человеко-месяцы.
Выбор единицы измерения усилий зависит от масштабности и сложности функций. При этом оценка всех функций делается с помощью одной единицы измерения, например в человеко-днях.
Какие методы можно использовать для оценки усилий?
Чаще всего используются следующие методы:
○ Экспертная оценка
В основе оценки лежит мнение экспертов или членов команды.
○ Метод аналогов
Используются данные о фактически затраченном времени на похожие задачи в прошлом.
○ Покерное планирование
Используется групповая оценка с использованием покерных карт.
Плюсы и минусы подхода RICE по отношению к ICE
Подход RICE достаточно часто используется менеджерами продукта. Рассмотрим плюсы и минусы этого подхода.
Плюсы RICE по отношению к ICE
В RICE используется дополнительный критерий — охват (Reach): он позволяет учесть, сколько людей будет пользоваться функцией, а это помогает эффективнее распределять ресурсы.
Минусы RICE по сравнению с ICE
1. RICE требует больше данных для расчета.
2. В ICE все критерии оцениваются по 10-балльной шкале, это значит, что они имеют одинаковое влияние на итоговую оценку приоритета.
В RICE полученное значение по критерию охват может сильно влиять на итоговую оценку, особенно это может проявляться в ситуациях, когда у продукта небольшое количество пользователей. Если охват по одной функции оценивается в 100 пользователей, а по второй — в 5, то первая функция по этому фактору получит в итоговом расчете в 20 раз больший балл. При этом разброс значений по влиянию не превышает 12 раз (максимальная разница между оценкой в 3 балла и оценкой в 0,25 балла по этому фактору), а по фактору уверенности при использовании оценочной шкалы максимальная разница в баллах не превышает 2 (разница между уверенностью в 100 и 50% составляет всего лишь 2).
Некоторые рекомендации по применению RICE:
- Регулярно пересматривайте оценки охвата (Reach), влияния (Impact), уверенности (Confidence) и усилий (Effort) для тех функций, по которым вы получаете новые данные, чтобы они основывались на актуальных данных и пользовательских исследованиях.
- Сочетайте RICE с другими методами приоритизации, такими как MoSCoW [8] или Kano, для того чтобы сэкономить время и по RICE приоритизировать только те функции, которые попали в группу Must по MoSCoW.
- Включите регулярные пересмотры RICE-оценок в процессе планирования спринтов или итераций, чтобы адаптироваться к изменениям в приоритетах и данных.
- Обучите команду использованию RICE, чтобы обеспечить единое понимание процесса и повышения качества оценок.
Выводы
Инструменты ICE и RICE достаточно популярны у продакт-менеджеров, которые используют их не только для приоритизации функций, но и для оценки гипотез.
Некоторые рекомендации по использованию этих инструментов:
- Приоритизируйте на основе данных.
Сбор и анализ данных, таких как пользовательская аналитика, результаты тестов и интервью, помогут повысить точность оценки Impact и Reach. - Вовлекайте пользователей и команду.
Для более точной оценки привлекайте пользователей и межфункциональные команды. Обратная связь от пользователей помогает точнее оценить Impact и Reach, а мнение команды — Confidence и Effort. - Регулярно пересматривайте оценки.
Оценки могут изменяться по мере получения новых данных и прохождения продукта через разные этапы. Периодически пересматривайте приоритеты, чтобы оставаться актуальными в условиях изменяющихся требований и возможностей.
Как приоритизировать список требований с использованием RICE и ICE сделать это правильно?
Приглашаем на курс «Полное погружение в продакт-менеджмент», где вы на практике не только освоите RICE и ICE, но и научитесь:
- Запускать продукты и управлять ими
- Улучшать метрики существующих продуктов
- Использовать Искусственный Интеллект для управления продуктами
- А также освоите 50+ инструментов и фреймворков из мира продакт-менеджмента
По ссылке ниже вы можете узнать подробную программу курса и зарегистрироваться.
Оставить комментарий