RICE

Общее #

• Назначение: количественная приоритизация инициатив/фичей для roadmap и backlog.
• Аудитория: PM, команды разработки, стейкхолдеры.
• Статус: устоявшийся (Intercom, 2016).
• Не путать с: MoSCoW (категориальная приоритизация), ICE и WSJF (другие формулы скоринга), матрицей Value×Effort (упрощённое визуальное сравнение), моделью Кано (классификация по ожиданиям пользователей).

RICE (Reach, Impact, Confidence, Effort — «охват, влияние, уверенность, трудозатраты») — фреймворк количественной приоритизации продуктовых инициатив. Каждая инициатива оценивается по четырём факторам, каждый фактор переводится в число, а формула сводит их в единый score, по которому инициативы можно сравнивать между собой. Название образовано инициалами факторов:

• Reach (охват) — сколько людей или событий затронет инициатива за период.
• Impact (влияние) — насколько сильно изменится целевая метрика у затронутого пользователя.
• Confidence (уверенность) — насколько достоверны оценки, на которых строится расчёт.
• Effort (трудозатраты) — сколько ресурсов потребует реализация.

Ключевой принцип RICE: каждый фактор — число, итог — score для сравнения. Вместо спора «мне кажется, эта фича важнее» команда вынуждена явно назвать охват, силу эффекта, степень уверенности в оценках и цену реализации. Разногласия из области мнений переходят в область проверяемых утверждений: цифру можно обсудить, уточнить по данным и пересчитать.

Происхождение #

Фреймворк появился в 2016 году в продуктовой компании Intercom и описан в статье How to Use RICE to Prioritize в блоге Intercom. Команда Intercom регулярно стояла перед задачей выбора из нескольких десятков идей, и её не устраивало, что приоритеты определялись субъективно: громкостью стейкхолдера, свежестью идеи или личными предпочтениями. Нужен был метод, который заставлял бы явно формулировать допущения и снижал влияние случайных факторов на решение.

RICE стал ответом: простая арифметическая формула, в которой одновременно учтены масштаб эффекта (Reach × Impact), достоверность допущений (Confidence) и стоимость реализации (Effort). Простота формулы — сознательное решение авторов: метод должен был работать на обычном продуктовом совещании, а не требовать отдельного аналитического контура.

Фреймворк быстро распространился в продуктовых командах и стал одним из стандартных инструментов приоритизации бэклога наряду с ICE, WSJF и матрицей Value×Effort.

Место в иерархии решений #

RICE не существует изолированно — он занимает строго определённое место в цепочке продуктовых решений:

1. North Star Metric и OKR задают направление и фокус: какие метрики и результаты считаются важными.
2. RICE ранжирует уже выровненные по стратегии инициативы: упорядочивает кандидатов внутри фокуса.
3. Roadmap и backlog получают приоритизированный список, готовый к планированию.

Поэтому формула RICE не заменяет стратегическое выравнивание: высокий score у инициативы вне стратегического фокуса означает лишь то, что она «эффективно ведёт не туда». RICE — инструмент ранжирования, а не выбора направления.

Формула RICE #

Итоговая оценка инициативы считается по формуле:

Score = (Reach × Impact × Confidence) / Effort

Числитель отражает ожидаемую ценность: сколько людей затронем (Reach), насколько сильно изменим их поведение (Impact) и насколько верим в эти оценки (Confidence). Знаменатель — цену этой ценности в трудозатратах. Инициатива с меньшим Effort при прочих равных получает более высокий score: быстрые выигрыши поощряются самой формулой.

Reach (охват) #

Reach — сколько людей или событий затронет инициатива за фиксированный период. В оригинальной методике Intercom период — квартал, а Reach измеряется в конкретных единицах: «столько-то клиентов столкнутся с изменением в квартал». Это всегда число за период, а не процент и не абстракция «все пользователи».

Примеры корректной формулировки Reach:

• «Онбординг-изменение затронет 500 новых пользователей в квартал» — если в квартал регистрируется 500 человек.
• «Интеграция нужна 300 активным командам, у которых есть соответствующий сценарий» — если опрос или аналитика показывают такой сегмент.

Типичные ошибки: завышенный охват «на всех пользователей» вместо реально затронутого сегмента; смешение периодов (Reach за месяц при Effort за квартал); использование процента вместо абсолютного числа — процент скрывает масштаб и делает разные инициативы несравнимыми.

Источник Reach — данные: продуктовая аналитика, воронки и конверсии, обращения в поддержку, опросы. Чем точнее данные, тем честнее расчёт.

Нюанс B2B-продуктов: охват можно считать в пользователях или в аккаунтах/командах, и выбор единицы меняет результат. Правило — считать в той единице, в которой измеряется метрика влияния: если эффект выражается в удержании команд, Reach тоже считается в командах, а не в отдельных пользователях. Смешение единиц внутри одного ранжирования — распространённая и незаметная ошибка, из-за которой крупные аккаунты с десятками пользователей искусственно перекашивают охват.

Impact (влияние) #

Impact — насколько сильно изменится целевая метрика у одного затронутого пользователя. Intercom предложила пятиуровневую шкалу:

Шкала привязана к заранее выбранной цели — метрике влияния (например, конверсия активации, удержание, adoption функции). Прежде чем оценивать Impact, команда фиксирует, какую метрику двигает данная группа инициатив; без этого «влияние» превращается во вкусовщину. Метрика влияния обычно выводится из North Star Metric или из этапа AARRR-воронки, на котором работает инициатива.

Ограничение шкалы: она не различает направления. Отрицательный эффект (фича ухудшает метрику) в ней не предусмотрен — такие инициативы в принципе не должны попадать в приоритизацию. Если команде нужна большая гранулярность, шкалу расширяют (например, до 5 или 10), но это усложняет калибровку: чем больше градаций, тем труднее договориться, чем «6» отличается от «7». Практика показывает, что пяти уровней достаточно — грубость шкалы осознанно компенсируется простотой согласия.

Важно понимать, что Impact в RICE — оценка эффекта на отдельного затронутого пользователя, а не на всю базу. Общий эффект как раз и получается произведением Reach × Impact: охват умножается на глубину изменения.

Confidence (уверенность) #

Confidence — насколько команда уверена в оценках Reach и Impact. В оригинальной методике — три уровня:

• 100% — есть количественные данные: эксперименты, аналитика по аналогичным фичам, проверенные воронки.
• 80% — есть качественные данные: интервью, опросы, количественные данные из смежных источников, обоснованные экстраполяции.
• 50% — гипотеза без доказательств: «кажется, что будет так».

Главная ценность фактора: Confidence «штрафует» гипотезы с непроверенными допущениями. Красивая идея без единого факта получает половину score автоматически — не потому что она плоха, а потому что не проверена. Это встроенная защита от HiPPO-эффекта (Highest Paid Person’s Opinion) и от ставки ресурсов на непроверенные амбиции.

Практическое следствие: если у команды есть дешёвый способ поднять Confidence (короткое исследование, прототип, анализ существующих данных), такой способ сам становится кандидатом в бэклог — он «окупается» повышением score целевой инициативы.

Effort (трудозатраты) #

Effort — какие ресурсы потребует реализация инициативы. В оригинале Intercom оценивает Effort в человеко-месяцах; минимальная единица — половина человеко-месяца (всё, что меньше, округляется до 0.5). Возможны и другие единицы — спринты, недели команды, — принципиально одно: единая единица измерения для всех инициатив в списке.

В формулу Effort входит делителем, поэтому он прямо торгуется против ценности: инициатива с впечатляющим числителем и огромным Effort может проиграть скромной, но дешёвой. Это отражает реальность ограниченных ресурсов лучше, чем методы, учитывающие только ценность.

Практическое правило: Effort оценивает команда разработки, а не PM; в оценку включаются не только разработка, но и дизайн, исследования и запуск. Инициативы, требующие участия нескольких ролей, обычно недооцениваются — это стоит компенсировать явно.

Почему формула устроена именно так #

Каждый элемент формулы отвечает за конкретный способ «сломать» приоритизацию без него:

• без Reach выигрывают идеи, приятные узкому кругу, включая саму команду;
• без Impact выигрывают «модные» идеи с непонятным эффектом;
• без Confidence выигрывают самые красиво рассказанные гипотезы;
• без Effort выигрывают гигантские ставки, съедающие квартал разработки.

Произведение в числителе и деление на Effort дают понятную экономическую интерпретацию: score — это «ожидаемая ценность в единицу трудозатрат». Именно поэтому итоговую оценку RICE часто описывают как отдачу на вложенные усилия.

Пример расчёта #

Рассмотрим RICE на условном примере: трекер задач для команд. Метрика влияния — конверсия активации новых пользователей. В бэклоге три инициативы-кандидата.

Инициатива A. Интерактивный онбординг. Аналитика показывает: в квартал регистрируется 500 новых пользователей, и воронка теряет их до первого созданного проекта. Reach = 500. Проблема подтверждена данными воронки и интервью (качественные данные), ожидаемый эффект умеренный: Impact = 1, Confidence = 80%. Разработка с дизайном — один человеко-месяц: Effort = 1.

Инициатива B. Мобильное приложение. Опросы показывают запрос на мобильный сценарий у части активных команд: Reach = 2000. Эффект высокий — меняет сам сценарий использования: Impact = 2. Но спрос оценён только опросом, реальную пользу не проверяли: Confidence = 50%. Оценка команды — два разработчика на полгода: Effort = 12.

Инициатива C. Интеграция с календарём. Календарный сценарий есть у 800 активных команд: Reach = 800. Эффект для затронутого пользователя невысокий: Impact = 0.5. Данные по сегменту — из продуктовой аналитики: Confidence = 80%. Effort = 2.

Расчёт и ранжирование #

Интерпретация результата:

• Онбординг выигрывает с отрывом — не потому, что это «самая важная» идея, а потому что он дёшев и опирается на подтверждённые данные. Быстрая проверенная победа бьёт амбициозную ставку.
• B и C практически неразличимы (167 против 160). Это не «победа» B, а сигнал: оценки в пределах погрешности метода, и решение должно приниматься обсуждением — стратегической значимостью, рисками, зависимостями, а не третьим знаком после запятой.
• Чувствительность к Confidence. Если бы спрос на мобильное приложение был проверен исследованием и Confidence выросло до 80%, score B стал бы ≈267. Дешёвое исследование, поднимающее уверенность, меняет финальное ранжирование — это типичный вывод RICE-сессии.

Результат расчёта — не приговор, а каркас для разговора: он показывает, где команда уверена, где гадает и что стоит проверить, прежде чем принимать решение.

Как проводить RICE-сессию #

Типовая RICE-сессия — встреча на 60–90 минут, к которой команда готовится заранее. Последовательность шагов ниже; для регулярного приоритизационного ритуала она повторяется каждый цикл планирования.

Шаг 0. Подготовка #

Качество сессии определяется до её начала. Фасилитатор заранее готовит список кандидатов, собирает доступные данные (воронки, сегменты, результаты исследований), договаривается с техлидом о предварительных оценках Effort и рассылает материалы участникам. Задача подготовки — чтобы на сессии обсуждались расхождения в оценках и их обоснования, а не «придумывание» цифр с нуля: экспромт на сессии почти гарантированно означает оценки «по ощущениям».

Шаг 1. Собрать кандидатов #

Свести в один список все инициативы-кандидаты из доступных источников: результатов Discovery, обращений в поддержку, запросов стейкхолдеров, собственной аналитики, технического долга. Каждая инициатива формулируется в едином формате «проблема → предлагаемое решение», чтобы список был сравнимым. Оптимальный размер списка для одной сессии — 5–10 инициатив; более длинные списки дробятся.

Шаг 2. Определить метрику влияния #

Зафиксировать, какую метрику двигают оцениваемые инициативы: компонент North Star Metric или конкретный этап AARRR-воронки. Без общей метрики влияния оценщики будут невольно мерить инициативы разными линейками. Если инициативы группируются вокруг разных метрик, честнее провести отдельные ранжирования по каждой группе.

Шаг 3. Оценить факторы — командно #

Каждый фактор оценивает тот, у кого лучшие данные:

• Reach — аналитик или PM по данным продуктовой аналитики.
• Impact — обсуждение PM, дизайнера и исследователя относительно метрики влияния.
• Confidence — по типу доказательств: количественные данные, качественные данные или гипотеза.
• Effort — техлид и команда разработки; в человеко-месяцах или спринтах.

Оценки заносятся в общую таблицу сразу с обоснованием каждой цифры: не «Impact = 2», а «Impact = 2, потому что интервью показывают, что без этого сценария команды отваливаются на второй неделе». Обоснования важнее самих чисел — они и есть предмет обсуждения.

Шаг 4. Посчитать score и ранжировать #

Score считается по формуле для каждой инициативы, список сортируется по убыванию. Расчёт прозрачен: любой участник может пересчитать и оспорить любое число.

Шаг 5. Sanity-check #

Проверить результат на здравый смысл:

• Близкие score (разница в пределах ~10–20%) считаются неразличимыми — их порядок определяет обсуждение, а не формула.
• Неожиданные аутсайдеры и победители разбираются явно: либо оценка ошибочна, либо команда узнала что-то новое о своих допущениях.
• Проверка на стратегию: попадают ли лидеры в текущий фокус (OKR, стратегические темы); инициатива с высоким score вне фокуса — предмет отдельного разговора, а не автоматическое «да».
• Зависимости и риски: формула их не знает; критические зависимости отмечаются поверх ранжирования.

Итог сессии — приоритизированный список с зафиксированными обоснованиями, который отправляется в roadmap и backlog.

Роли участников #

• Фасилитатор (обычно PM) — ведёт сессию, следит за форматом, фиксирует обоснования, не позволяя разговору превратиться в спор о вкусах.
• Аналитик — поставляет данные для Reach, готовит воронки и сегменты заранее.
• Техлид / разработка — отвечает за Effort, подсвечивает технические риски и зависимости.
• Дизайнер / исследователь — обосновывает Impact и Confidence находками исследований.
• Стейкхолдеры — участвуют в sanity-check и коммуникации решения; их присутствие на оценке снижает риск «а теперь решает самое громкое мнение» после сессии.

Антипаттерны сессии #

• Якорение: первая названная цифра становится «официальной». Защита — участники пишут оценки молча и одновременно, потом обсуждают расхождения.
• Защита «своих» идей: автор инициативы завышает Impact и Confidence. Защита — правило «оценку обосновывают данные, а не энтузиазм».
• Спор о точности: обсуждение 0.25 против 0.5 дольше, чем они того стоят. Точность метода не выше точности входных данных.
• Конфетти Confidence: все оценки получают «80% по ощущению». Защита — Confidence назначается только по типу доказательств.

Вариации RICE #

Оригинальная формула — не догма; на практике встречаются модификации, адаптирующие метод под контекст.

RICE с отдельным фактором риска (RICE++) #

Классическая слабость RICE: Confidence смешивает два разных вопроса — «насколько мы уверены в оценках эффекта» и «насколько рискованна реализация». Расширенные версии (часто под названием RICE++) выносят риск в отдельный множитель, например: Score = (Reach × Impact × Confidence) / (Effort × Risk), где Risk — коэффициент технической или рыночной неопределённости. Единого стандарта нет; суть вариации — разделять неуверенность в гипотезе и риск исполнения, потому что лечатся они по-разному: первую — исследованием, второй — декомпозицией и прототипированием.

Взвешенный RICE #

Некоторым командам нужен явный учёт стратегического выравнивания. Вариант: финальный приоритет = RICE score × стратегический вес (например, 0.5–1.5 по вкладу инициативы в текущие OKR). Альтернатива, ближе к оригиналу, — не взвешивать формулу, а проводить ранжирование отдельно внутри каждой стратегической темы: RICE отвечает на вопрос «что внутри темы делать первым», а порядок тем задаёт стратегия. Второй путь чище: он не прячет стратегические решения внутри арифметики.

RICE для bugfix и feature #

Сравнивать исправления багов и новые функциональности в одном списке некорректно: у них разная природа ценности и разная база для Reach. Практика — раздельные ранжирования. Для багов Reach — «сколько пользователей сталкиваются с проблемой за период» (частота обращений × тираж), Impact определяется серьёзностью (severity) проблемы: 3 — блокирует работу, данные или деньги; 2 — работа возможна, но требует серьёзного обходного пути; 1 — раздражает, но обходной путь есть. Отдельный список bugfix-приоритизации защищает обе категории от систематического проигрыша друг другу.

Родственные скоринговые формулы #

RICE — не единственная формула скоринга, и у него есть сознательные упрощения. ICE (Impact, Confidence, Ease) убирает Reach и заменяет человеко-месяцы на оценку простоты — быстрее, но грубее. WSJF из SAFe строится вокруг стоимости задержки (Cost of Delay) и учитывает срочность явно. Подробный разбор этих методов — в статье об ICE / WSJF; здесь важно, что выбор формулы — выбор того, какие аспекты решения считать явно.

RICE в регулярном процессе #

Однократный расчёт — малоценный артефакт; RICE раскрывается как регулярный ритуал приоритизации, встроенный в цикл планирования команды.

Ритм пересчёта #

Типовой ритм — раз в квартал (при планировании OKR) или раз в 4–6 недель (при сквозном бэклог-рефайнменте). Чаще — нецелесообразно: оценки не успевают обновиться, и сессия превращается в ритуал. Реже — опасно: список отрывается от реальности, и приоритеты устаревают раньше, чем пересчитываются. Вне ритма пересчёт запускается событием: существенное новое знание (исследование, метрика, релиз конкурента) — повод собрать список заново, а не ждать календаря.

Владение и артефакт #

Живой артефакт RICE — таблица (лист, доска) с колонками: инициатива, Reach, Impact, Confidence, Effort, score, обоснования, статус. Владелец артефакта — PM; технические оценки подтверждаются техлидом. Обоснования обязательны: таблица без них через квартал нечитаема — никто не помнит, почему Confidence было 80%, и пересчёт начинается с нуля. Артефакт хранится там же, где backlog и roadmap, и доступен всем участникам: прозрачность оценок — часть метода.

Обновление оценок #

События, запускающие пересмотр отдельных строк:

Правило гигиены: score пересчитывается вместе с изменением оценки, а не «по памяти» — иначе таблица накапливает расхождения между зафиксированными и фактически используемыми числами.

Связь с бэклогом #

Результат RICE — порядок инициатив, а не готовый бэклог. Между ранжированием и работой остаются два шага: декомпозиция инициатив верхнего уровня до эпиков и задач (приоритет наследуется) и уточнение Effort при декомпозиции — первый контакт с деталями почти всегда сдвигает оценку. Если после декомпозиции оценка выросла заметно, инициатива возвращается в таблицу RICE на пересчёт: изменение порядка на этом этапе — нормальная работа метода, а не сбой.

Частые вопросы применения #

Две инициативы с почти одинаковым score — что делать? #

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

Как оценивать техдолг и инфраструктуру? #

Через последствия для пользователя и бизнеса, а не через «правильность кода»: Reach — сколько пользователей страдает от медленной части продукта или инцидентов, Impact — эффект на удержание или конверсию. Если прямой связи с метрикой нет, работа с техдолгом — не кандидат RICE-ранжирования, а часть инженерного бюджета, который выделяется отдельно (типовая практика — фиксированная доля мощности команды). Попытка пропустить через RICE весь техдолг обычно дискредитирует метод: у инфраструктурной работы часто нет «охвата» в продуктовом смысле.

Нет данных для Reach — считать ли RICE? #

Считать можно, но результат будет декоративным: Reach «на глаз» умножает погрешность. Честнее либо признать Confidence = 50% и понимать, что score вдвое занижен, либо сначала дёшево закрыть пробел в данных (аналитика, опрос) и уже потом ранжировать. Само обнаружение «мы не знаем, скольких это касается» — один из полезных выводов RICE-сессии.

Инициатива обязательна (инцидент, регуляторное требование), но score низкий #

Обязательные работы не конкурируют в приоритизации — они выходят из списка. RICE ранжирует дискреционные инициативы, за которые команда действительно выбирается; страх и регуляторика попадают в план напрямую, минуя формулу. Смешение обязательного и дискреционного в одном ранжировании — способ «утопить» и то и другое.

Сравнение с другими методами приоритизации #

RICE — один из нескольких распространённых методов. Выбор между ними — выбор между точностью, скоростью и характером решения.

Когда выбирать RICE #

RICE уместен, когда одновременно выполняются условия: инициатив несколько и они сопоставимы по масштабу; есть данные хотя бы для Reach; решения повторяются (регулярный цикл планирования), поэтому вложения в оценку окупаются; команде нужен защищаемый от субъективности протокол выбора. Если хотя бы одно условие не выполняется, дешевле обойтись категориальным методом.

Комбинирование методов #

Методы не конкурируют, а работают на разных уровнях одного процесса:

• Kano подсказывает природу ценности инициативы — это улучшает оценку Impact.
• RICE ранжирует инициативы внутри стратегического фокуса.
• MoSCoW фиксирует объём конкретного релиза из уже приоритизированного списка.
• Матрица Value×Effort наглядно объясняет готовое ранжирование стейкхолдерам.

Попытка использовать все методы одновременно для одного списка — оверкилл; зрелая команда выбирает один основной скоринг для регулярного ритма и держит остальные как инструменты для специальных задач.

Плюсы #

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

Количественность и сравнимость #

Итог RICE — число. Инициативы разной природы (инфраструктура, рост, UX) попадают на одну шкалу «ценность на единицу усилий» и становятся сравнимыми. Числа можно сортировать, хранить, пересчитывать при изменении оценок и отслеживать, как менялись приоритеты между циклами планирования, — с категориями это работает хуже.

Учёт не только ценности #

Большинство быстрых методов учитывают только ценность. RICE одновременно принимает во внимание охват (Reach), силу эффекта (Impact), достоверность допущений (Confidence) и стоимость (Effort). Формула честно отвечает на четыре вопроса, которые обычно смешиваются в интуитивной оценке: скольких затронем, насколько сильно, насколько уверены и сколько это стоит.

Драйвер обсуждения #

Главная ценность RICE — не итоговое число, а разговор, который приходится вести, чтобы его получить. Формула вынуждает команду формулировать допущения явно, а расхождения в оценках участников указывают на самые важные точки незнания: если один участник ставит Confidence 50%, а другой 100%, это не конфликт, а обнаруженный пробел в данных, который стоит закрыть.

Снижение субъективности #

RICE не устраняет субъективность полностью — это невозможно, — но дисциплинирует её: мнение «мне кажется важным» переводится в проверяемые утверждения про охват, эффект и уверенность. Решение получает протокол: видно, какие оценки и допущения к нему привели, и новое мнение — это пересчёт, а не пересмотр настроений.

Быстрые победы поощряются структурно #

Деление на Effort систематически поднимает дешёвые инициативы с доказанным эффектом. Это противодействует системной ошибке планирования — недооценке накопительного эффекта множества небольших улучшений по сравнению с одной большой ставкой.

Минусы и риски #

Сильные стороны RICE оборачиваются рисками при некритичном применении; большинство проблем метода известны и лечатся процессом.

Иллюзия точности #

Самый большой риск RICE — воспринимать score как точную науку. Числа в формуле — оценки, часто экспертные; точность результата не выше точности входов. Score 400 против 390 не означает, что первая инициатива лучше: это одинаковые кандидаты. Защита — правило «близкие score неразличимы», диапазоны вместо точечных оценок и культура, в которой число открывает обсуждение, а не закрывает его. RICE — discussion tool, инструмент для разговора, и его главная ошибка — считать иначе.

Затратность для мелких задач #

Оценка четырёх факторов с обоснованиями — осязаемая стоимость. Для крупных инициатив она окупается, для потока мелких задач — нет: гонять через RICE каждую задачу спринта — значит тратить на приоритизацию больше, чем на работу. Правильный масштаб применения — инициативы уровня roadmap и крупные эпики; внутри спринта достаточно обычного планирования.

Confidence — самый манипулируемый параметр #

Формула не умеет проверять честность Confidence: завышенная уверенность удваивает score без каких-либо оснований. Участники, заинтересованные в «своей» инициативе, завышают Confidence; осторожные аналитики занижают — и методично проигрывают. Защита — протокол привязки Confidence к типу доказательств (данные / исследования / гипотеза) и фиксация источников рядом с оценкой.

Не учитывает стратегическое выравнивание #

RICE оценивает локальную эффективность инициативы, но не её вклад в стратегию: формула не знает про фокус года, обязательства перед клиентами, регуляторные требования или позиционирование. Инициатива с максимальным score может уводить продукт от заявленного направления. Поэтому RICE применяется после стратегического фильтра: North Star Metric и OKR задают фокус, RICE ранжирует уже выровненные инициативы — а не наоборот.

Effort оценить сложнее всего #

Оценка трудозатрат в начале работы — самая ошибка-ёмкая: индустрия десятилетиями недооценивает сроки, и RICE наследует эту проблему. Поскольку Effort стоит в знаменателе, его ошибка напрямую искажает score, а крупные стратегические инициативы систематически штрафуются за масштаб. Защита — оценка Effort диапазоном (и расчёт score для границ), декомпозиция больших инициатив до сопоставимых кусков и ретроспективная сверка оценок с фактом.

Игнорирование зависимостей и непрямых эффектов #

Формула считает каждую инициативу атомарной: не учитывает технические зависимости, синергии между фичами (когда две средние инициативы вместе дают больше двух сильных по отдельности) и эффекты типа «эта работа разблокирует следующие». Sanity-check и явная пометка зависимостей поверх ранжирования — обязательная часть применения метода.

Связанные материалы #

• Метод MoSCoW — категориальная приоритизация требований внутри релиза; дополняет RICE на уровне фиксации объёма.
• Roadmap — куда встраивается приоритизированный RICE список инициатив.
• North Star Metric — источник метрики влияния для оценки Impact.
• OKR — стратегический фильтр, поверх которого работает RICE-ранжирование.
• AARRR — воронка для выбора этапа и метрики влияния.
• Discovery-процесс — источник валидированных кандидатов и доказательств для Confidence.
• ICE / WSJF, модель Кано, матрица Value×Effort — альтернативные и дополняющие методы приоритизации.

Первоисточники #

• Intercom (2016). How to Use RICE to Prioritize. Intercom blog. — оригинальное описание фреймворка: факторы, шкалы, примеры.
• Cagan M. (2017). Inspired: How to Create Tech Products Customers Love. — приоритизация в продуктовых командах и роль PM в ней.
• Seiden J. (2019). Outcomes Over Output. — переход от «выпустить фичи» к результатам для пользователей; основа для выбора метрики влияния.
• ProductBoard. The Product Manager’s Guide to Prioritization. — обзор методов приоритизации и места RICE среди них.
• McBride S. (2019). RICE: Simple Prioritization for Everyone. ProductTalk. — практическое применение RICE за пределами Intercom.