Метод RICE появился как развитие более простой техники ICE, о которой мы уже рассказывали. Главное отличие — добавление параметра Reach (охват), то есть количества пользователей, которых затрагивает задача. Второе отличие — использование Effort (трудозатраты) вместо Ease (легкость). И этот параметр измеряется не в абстрактных баллах, а в реальных человеко-часах или человеко-днях, что делает оценки более конкретными.
В статье расскажем, как работает методика RICE, покажем примеры расчетов и разберем важные нюансы этого метода.
Как устроен метод RICE
RICE — аббревиатура от четырех английских слов: Reach (охват), Impact (влияние), Confidence (уверенность) и Effort (усилия). Формула RICE выглядит так:
RICE = (R × I × C) / E
Задачи с самым высоким итоговым баллом делают в первую очередь — это и есть приоритизация по RICE.
Разберем подробнее каждый параметр.
Reach (охват) — количество людей, которых затронет изменение за определенный период (обычно месяц или квартал). Если вы улучшаете функцию, которой пользуются 5000 человек в месяц — пишите 5000. Охват измеряется в абсолютных числах, а не в баллах.
Impact (влияние) — оценка того, насколько сильно задача повлияет на каждого пользователя, который с ней столкнется. Здесь используется фиксированная шкала: 3 — огромное влияние, 2 — сильное, 1 — среднее, 0.5 — небольшое, 0.25 — минимальное. Например, исправление критического бага, блокирующего работу — это 3, а косметическое улучшение интерфейса — 0.5.
Confidence (уверенность) — показывает, насколько вы уверены в своих оценках охвата и влияния. Выражается в процентах: 100% — у вас есть точные данные, 80% — есть косвенные подтверждения, 50% — в основном интуиция. При расчетах процент превращается в десятичную дробь (100% = 1.0, 80% = 0.8, 50% = 0.5). Если уверенность ниже 50%, возможно, стоит сначала провести исследование.
Effort (трудозатраты) — оценка ресурсов, необходимых для реализации. Измеряется в человеко-месяцах, человеко-неделях или человеко-днях — выберите единицу, которая удобна для вашей команды. В отличие от остальных параметров, Effort находится в знаменателе: чем больше усилий требуется, тем ниже итоговый балл.
Метод RICE разработала команда Intercom (сервиса для общения с клиентами). Они искали способ приоритизировать огромный бэклог продуктовых улучшений и поняли, что другие методы сортировки не учитывают масштаб задач. Одно дело улучшить функцию, которой пользуются 1000 человек, а другое — функцию для 100 000 человек, даже если влияние одинаковое. Приоритизация RICE занимает больше времени, чем ICE, но дает более объективные результаты.
Примеры использования
Давайте посмотрим, как работает методология приоритизации RICE на конкретных задачах.
Пример 1. SaaS-продукт для управления проектами
Допустим, вы развиваете облачный сервис для управления проектами. Накопилось несколько идей по улучшению продукта, но ресурсы ограничены, и нужно выбрать, что делать в следующем квартале. Цель изменений: увеличить удержание пользователей и снизить отток.
Предположим, у сервиса примерно 10 000 активных пользователей в месяц. Применим RICE-оценку для каждой задачи.
Reach (охват) оцениваем, исходя из того, сколько пользователей столкнется с улучшением. Баг с потерей данных затрагивает примерно 30% пользователей в месяц, то есть 3000 человек. Мобильное приложение могут использовать около 60% аудитории (6000), но не сразу. Темная тема интересна примерно 40% (4000).
Impact ставим по стандартной шкале. Баг с потерей данных — критическая проблема, пользователи из-за нее уходят, это 3. Шаблоны проектов сильно упрощают старт работы — 2. Темная тема приятна, но не критична — 0.5.
Confidence зависит от наличия данных. По багу есть жалобы в поддержке и метрики — 100%. По шаблонам проводили интервью с пользователями — 80%. По темной теме только общие предположения — 50%.
Effort оцениваем в человеко-неделях. Исправление бага займет 1 неделю. Шаблоны проектов — 3 недели. Мобильное приложение — 12 недель. Темная тема — 2 недели.
Для оценки задач удобно использовать электронные таблицы:
Теперь перенесем результаты обратно в планировщик задач. Добавьте итоговый балл RICE в квадратных скобках перед названием задачи. Чтобы сортировка работала правильно, добавьте нули перед числами для выравнивания (0500, 0600, 0700 и так далее). После этого отсортируйте список в обратном алфавитном порядке (от Я к А), и получите приоритизированный бэклог.
Пример 2. Маркетинг для образовательной платформы
Вы управляете маркетингом образовательной онлайн-платформы. У вас 50 000 зарегистрированных пользователей, но только 10% из них активны. Нужно выбрать маркетинговые инициативы на следующий квартал. Цель: увеличить количество активных пользователей.
Применим RICE-фреймворк:
Reach: email-рассылка затронет 45 000 неактивных пользователей. Вебинар привлечет примерно 500 человек (исходя из опыта прошлых мероприятий). Реферальная программа — около 3000 активных пользователей могут пригласить друзей. Таргет — примерно 20 000 показов целевой аудитории.
Impact: бесплатный вводный курс может сильно повлиять на вовлеченность новичков (2). Email-рассылка со скидкой имеет среднее влияние (1). Геймификация дает небольшой, но стабильный эффект (0.5).
Confidence: по email-маркетингу есть данные предыдущих кампаний (80%). По реферальной программе — опыт конкурентов (60%). По геймификации — только гипотезы (50%).
Effort: вебинар потребует 1 человеко-неделю на организацию. Реферальная программа — 4 человеко-недели на разработку. Бесплатный курс — 6 человеко-недель на создание контента.
Составим таблицу:
Тонкости и нюансы
Система RICE кажется более точной и объективной, чем ICE, но и у нее есть свои подводные камни. Разберем нюансы, которые помогут применять метод эффективно.
1. Сразу определите базовый период для Reach. Охват всегда привязан к временному периоду: месяц, квартал, год. Команда должна договориться об этом заранее, иначе получатся несопоставимые оценки. Например, если одна задача оценивает охват за месяц (5000 пользователей), а другая за год (60 000), то вторая выиграет, хотя на самом деле охваты одинаковые.
2. Охват редко бывает 100%. Частая ошибка — указывать в Reach общее количество пользователей продукта. На самом деле нужно оценивать, сколько человек реально столкнется с изменением за выбранный период. Если вы улучшаете экран настроек, который посещают 3% пользователей раз в месяц, Reach — это именно те самые 3%, а не вся пользовательская база.
3. Договоритесь о шкале Impact. В модели RICE используется стандартная шкала (3, 2, 1, 0.5, 0.25), которая заметно снижает субъективность. Однако споры все равно иногда возникают: один человек может считать улучшение «сильным» (2), другой «средним» (1). Разница — в два раза в итоговом балле.
Поэтому заранее пропишите критерии для каждого значения в контексте вашего проекта. Например:
| Значение | Критерий | Пример |
|---|---|---|
|
3 Massive |
Решает критическую проблему или открывает новую возможность | Исправление бага, блокирующего оплату |
|
2 High |
Существенно улучшает опыт использования | Добавление функции сохраненных фильтров поиска |
|
1 Medium |
Заметное, но не критичное улучшение | Улучшение скорости загрузки страницы на 20% |
|
0.5 Low |
Небольшое улучшение комфорта | Добавление анимаций переходов |
|
0.25 Minimal |
Косметические изменения | Изменение оттенка цвета кнопки |
4. Confidence ниже 50% — сигнал к исследованию. Если уверенность в оценках меньше 50%, возможно, стоит не приоритизировать задачи, а провести исследование. Быстрое интервью с пользователями, анализ поведения в аналитике, изучение конкурентов — все это может поднять Confidence до разумного уровня.
RICE-оценка гипотез с низким Confidence часто означает, что команда движется наугад. Иногда лучше потратить неделю на исследование, чем месяц на разработку функции, которая никому не нужна.
5. Effort должен учитывать всю команду. Распространенная ошибка — считать время только профильных специалистов, например, разработчиков. На самом деле Effort включает работу всех, кто участвует в создании продукта: дизайнеров, тестировщиков, маркетологов, технических писателей, менеджеров и т. д. Если задача требует 2 недели работы разработчика и 1 неделю дизайнера — это 3 человеко-недели, а не 2.
6. RICE не заменяет здравый смысл. Иногда задача с меньшим баллом должна быть сделана раньше по стратегическим причинам: она разблокирует другие задачи, закрывает технический долг или критична для конкретного сегмента клиентов. Приоритизация бэклога по RICE — это инструмент принятия решений, а не диктатор.
7. Обновляйте оценки после запуска. После реализации задачи сверьте реальные показатели с оценками. Сколько пользователей реально воспользовались функцией? Сколько времени ушло на разработку? Благодаря такой калибровке ваши оценки со временем станут более точными.
