RICE: как приоритизировать фичи по охвату, влиянию, уверенности и трудозатратам

RICE помогает сравнить фичи по формуле Reach × Impact × Confidence / Effort: сколько людей или событий затронет изменение за один период, насколько сильно оно повлияет на каждого, чем подтверждены оценки и сколько человеко-месяцев (person-month) потребуется всей команде. Чем выше балл, тем больше ожидаемое влияние на единицу труда. Результат служит аргументом для обсуждения; обязательства, безопасность, зависимости, мощность команды и лимит незавершённой работы применяют отдельно.

Как устроен RICE

Продуктовая команда Intercom разработала RICE для последовательного сравнения разных инициатив. В исходном описании метода четыре фактора объединены так:

RICE score = (Reach × Impact × Confidence) / Effort

Где:

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

Например, фича затронет 180 клиентских аккаунтов за квартал, даст высокое влияние 2, оценки подтверждены на 80%, а реализация потребует 2,5 person-month:

RICE = 180 × 2 × 0,8 / 2,5 = 115,2

Число 115,2 имеет смысл только рядом с другими строками той же таблицы. Оно не означает 115% возврата инвестиций (ROI), 115 клиентов выручки или 115 единиц абсолютной ценности. При смене Reach с «аккаунтов за квартал» на «пользователей за год» изменится масштаб всех результатов.

Перед расчётом зафиксируйте четыре условия:

• одну продуктовую или бизнес-цель;
• один горизонт Reach;
• одну единицу Reach;
• сопоставимый уровень работ: фичи, эксперименты или крупные инициативы с одинаковым критерием готовности (Definition of Done).

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

Reach: сколько людей или событий получат эффект и когда

Reach — главное отличие RICE от ICE. Параметр отвечает не просто на вопрос «много ли пользователей увидят фичу», а на более точный:

Сколько уникальных сущностей или событий реально испытают эффект этой инициативы за выбранный период?

Intercom приводит единицы «клиенты за квартал» и «транзакции за месяц». Выбор зависит от задачи:

Цель решения	Подходящая единица Reach	Пример
Улучшить активацию B2C	Новые пользователи за месяц	Пользователи, дошедшие до шага настройки
Снизить ошибки оплаты	Платёжные транзакции за месяц	Попытки оплаты, для которых сработает проверка
Повысить использование в B2B-продукте	Активные аккаунты за квартал	Организации, где администратор увидит функцию
Улучшить работу внутри аккаунта	Уникальные активные seats за квартал	Сотрудники клиентов, использующие сценарий
Ускорить обработку обращений	Тикеты за месяц	Обращения, которые попадут под автоматизацию

Сначала выберите единицу

В B2B (business-to-business, продукте для компаний) один крупный корпоративный аккаунт может иметь 5 000 пользователей, а небольшой клиент — пять. Если цель связана с продлением договоров, уместны аккаунты. Если оценивается ежедневный пользовательский сценарий, подходят уникальные активные пользователи или рабочие места. Если изменение применяется при каждой операции и повтор действительно создаёт новую пользу, допустимы транзакции или события.

Нельзя смешивать эти единицы в одной колонке. Строка «40 корпоративных аккаунтов» не сопоставима со строкой «12 000 кликов». Денежный вес клиентов тоже не стоит незаметно встраивать в Reach. Когда один стратегический аккаунт экономически важнее сотни бесплатных, вынесите сегмент, выручку или обязательство в отдельный критерий, стоимость задержки (Cost of Delay) либо обязательный фильтр.

Затем закрепите период

Период показывает скорость накопления эффекта. Фича с охватом 1 000 пользователей за месяц и фича с охватом 1 000 пользователей за год имеют одинаковое число, но разную срочность и отдачу на горизонте решения.

Для квартального планирования удобно считать Reach за следующий квартал. Все кандидаты получают одну дату начала и конца. Для постоянного сценария берут ожидаемый поток за этот интервал. Для разовой миграции считают существующих клиентов, которых она затронет один раз. Нельзя умножать разовый эффект на число месяцев как повторяющийся.

Считайте реально затронутых, а не всю базу

Рабочая формула Reach для воронки:

Reach = доступная аудитория × доля подходящих × вероятность контакта с изменением за период

Допустим, каждый месяц до нужного шага регистрации доходят 500 клиентов, 30% выбирают изменяемую опцию, а горизонт равен кварталу:

500 × 30% × 3 месяца = 450 клиентов за квартал

Это канонический тип расчёта Intercom. Подстановка всей зарегистрированной базы завысила бы охват: пользователи, не дошедшие до шага, эффекта не получат.

Проверьте ещё четыре свойства Reach:

• уникальность — один пользователь считается один раз или каждое событие отдельно;
• доступность (eligibility) — кому функция вообще доступна по тарифу, роли, платформе и стране;
• контакт с изменением (exposure) — кто встретится с ним в выбранный период;
• пересечение — не суммируются ли одни и те же люди в зависимых инициативах.

Записывайте рядом источник, дату и запрос: например, product analytics, event onboarding_started, 01.06–31.08.2026. Фраза «примерно половина клиентов» не позволяет перепроверить Reach.

Impact: насколько изменится результат для одного затронутого объекта

Reach отвечает за ширину эффекта, Impact — за его силу. В оригинальной модели Impact оценивает влияние на одного человека относительно выбранной цели.

Каноническая шкала Intercom:

Impact	Значение	Смысл
3	Massive	Очень большое влияние
2	High	Высокое влияние
1	Medium	Среднее влияние
0,5	Low	Низкое влияние
0,25	Minimal	Минимальное влияние

Эти числа являются множителями. Разница между 2 и 1 удваивает итоговый балл, поэтому словесные ярлыки нужно привязать к своей цели до оценки кандидатов.

Пример якорей для цели «повысить активацию новых B2B-аккаунтов»:

• 3 — фича способна закрыть большую часть основного барьера активации;
• 2 — устраняет важный повторяющийся барьер для подходящего аккаунта;
• 1 — заметно помогает пройти один этап;
• 0,5 — даёт небольшое улучшение без изменения основного сценария;
• 0,25 — локально улучшает удобство.

Допустимо адаптировать формулировки и целевую метрику под продукт. Если команда меняет сами значения, вводит шкалу 1–10 или отрицательный Impact, она получает производную модель RICE. Такие баллы нельзя сравнивать с канонической таблицей или с другой командой без пересчёта.

Отрицательный эффект безопасности, закона или репутации плохо помещается в положительную шкалу Impact. Для неприемлемого риска нужен запрет (veto) или обязательный фильтр (gate). Тогда высокий Reach другой инициативы не сможет математически «компенсировать» нарушение.

Confidence: насколько доказаны Reach, Impact и Effort

Confidence снижает рейтинг эффектной идеи, если прогноз держится на слабых основаниях. Канонические уровни Intercom:

Confidence	Уровень	Что должно лежать рядом с оценкой
100%	Высокий	Метрики Reach, релевантное исследование Impact и проверенная исполнителями оценка Effort
80%	Средний	Большая часть факторов подтверждена, но остаётся одно существенное допущение
50%	Низкий	Есть слабые сигналы, широкие диапазоны или перенос данных из другого сегмента
Ниже 50%	Moonshot	Гипотеза почти не подтверждена; сначала полезнее дешёвая проверка

Confidence — не настроение автора и не статистически рассчитанная вероятность успеха. Он отражает доказательность всего набора входных данных. Метрики охвата не дают 100%, если Impact основан на одном разговоре, а Effort назвал человек, который не будет выполнять работу.

Для каждой строки полезно хранить три мини-проверки:

• Reach: аналитика, CRM, выборка, период и правило расчёта;
• Impact: эксперимент, исследование, повторяющийся запрос или близкий внутренний запуск;
• Effort: оценка дизайна, разработки, контроля качества, безопасности, данных, выпуска и операций.

Если слаб только один фактор, общий Confidence всё равно должен это учитывать. Иначе множитель создаст ложную точность.

Effort: сколько person-month потребуется всей команде

В каноническом RICE Effort измеряется в person-month, или человеко-месяцах — объёме работы, который один человек выполняет за месяц. Складывается время всех ролей, необходимых для готового результата.

Например:

• исследование задачи и спецификация — 0,25 person-month;
• дизайн — 0,5;
• backend — 1;
• frontend — 0,5;
• контроль качества, проверка безопасности и выпуск — 0,75.

Итого: 3 person-month.

Три разработчика за один календарный месяц могут выполнить около трёх person-month работы, если задачи распараллеливаются без потерь. Календарный срок и person-month не взаимозаменяемы: зависимость от одного специалиста способна растянуть три person-month на три месяца.

Intercom советует сохранять оценку грубой: целые числа и 0,5 для работ заметно короче месяца. Десятые и сотые доли часто создают видимость точности, которой у ранней продуктовой оценки нет.

Ловушки смешанных единиц

Нельзя делить один Reach на 3 story points, другой — на 2 недели, третий — на 1 person-month. Итоговые scores будут иметь разные знаменатели.

Story points, или условные единицы размера работы, допустимы как локальная адаптация, если:

• одна команда оценивает все строки одной версией шкалы;
• величины отражают полный scope;
• score не сравнивают с другой командой и таблицами в person-month;
• модель помечена как адаптированная.

Человеко-дни можно механически перевести в person-month по одному принятому коэффициенту, например 20 рабочих дней на person-month. Сначала сложите работу всех ролей, затем делите: 40 человеко-дней / 20 = 2 person-month. Не смешивайте календарные и рабочие дни и не округляйте каждую роль отдельно.

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

Пример RICE на пяти фичах B2B SaaS

Команда планирует следующий квартал и сравнивает пять работ для B2B SaaS — облачного продукта для компаний. Reach — уникальные клиентские аккаунты за квартал. Impact привязан к цели «повысить успешное внедрение и удержание целевых аккаунтов». Confidence записан десятичной дробью, Effort — полный объём в человеко-месяцах.

Фича	Как получен Reach	Impact	Confidence	Effort	RICE
Чек-лист онбординга	800 новых × 75% увидят = 600	1	1,0	2	300
Массовый импорт CSV	240 подходящих × 75% используют сценарий = 180	2	0,8	2,5	115,2
Единая модель прав и событий	300 активных × 80% затронуты = 240	0,5	0,8	2	48
Экспорт журнала аудита	100 регулируемых × 70% потребность = 70	3	0,8	4	42
SAML SSO	60 корпоративных × 75% встретят требование = 45	2	0,8	3	24

Чек-лист онбординга

За квартал ожидается 800 новых аккаунтов. Аналитика прошлых когорт показывает, что 75% дойдут до этапа, где появится чек-лист:

Reach = 800 × 0,75 = 600 аккаунтов за квартал

Влияние на один аккаунт среднее: Impact = 1. Reach, UX-исследование и трудозатраты подтверждены завершённым похожим запуском: Confidence = 1. Полный Effort — 2 person-month:

RICE = 600 × 1 × 1 / 2 = 300

Массовый импорт CSV

Функция доступна 240 аккаунтам целевого тарифа, 75% из них ожидаемо столкнутся с переносом данных в квартале:

Reach = 240 × 0,75 = 180

Импорт снимает важный барьер, поэтому Impact = 2. Намерение клиентов подтверждено, но использование после релиза неизвестно: Confidence = 0,8. Оценка всех ролей — 2,5 person-month:

RICE = 180 × 2 × 0,8 / 2,5 = 115,2

Единая модель прав и событий

Платформенный слой напрямую меняет поведение авторизации и аудита для 80% из 300 активных аккаунтов:

Reach = 300 × 0,8 = 240

Изменение почти незаметно для отдельного клиента: Impact = 0,5. Архитектурный дизайн согласован, но миграция содержит неизвестные: Confidence = 0,8. Effort — 2 person-month:

RICE = 240 × 0,5 × 0,8 / 2 = 48

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

Экспорт журнала аудита

Из 100 регулируемых аккаунтов около 70 должны подготовить аудит или выгрузку в квартале:

Reach = 100 × 0,7 = 70

Для каждого затронутого аккаунта влияние очень велико: Impact = 3. Потребность подтверждена, но сложность экспорта и хранения уточняется: Confidence = 0,8. Effort — 4 person-month:

RICE = 70 × 3 × 0,8 / 4 = 42

SAML SSO

SAML SSO — единый вход (Single Sign-On) по стандарту Security Assertion Markup Language. Из 60 целевых корпоративных аккаунтов около 75% встретятся с таким требованием в квартале:

Reach = 60 × 0,75 = 45

Для такого аккаунта SSO сильно влияет на внедрение: Impact = 2. Система работы с клиентами (CRM) подтверждает спрос, но прогноз закрытия сделок и границы интеграций неполны: Confidence = 0,8. Effort — 3 person-month:

RICE = 45 × 2 × 0,8 / 3 = 24

Базовая сортировка выглядит так: онбординг, CSV-импорт, платформа, аудит, SSO. Квартальный план может иметь другой порядок из-за обязательств и зависимостей.

Как превратить рейтинг в выполнимый план

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

Примените gates и overrides

Ситуация	Как учитывать	Почему одного RICE мало
Критическая уязвимость	Security gate или expedite с владельцем и сроком	Малый Reach не отменяет тяжесть риска
Требование закона или аудита	Must-do до установленной даты	Нарушение нельзя компенсировать высокой ценностью другой фичи
Договорное enterprise-обязательство	Gate/override с клиентом, сроком и экономикой	Один аккаунт может иметь малый Reach и критическую цену задержки
Блокирующая зависимость	Поставить predecessor раньше зависимой работы	Score не кодирует порядок графа
Platform/enabler	Считать прямой эффект, зависимости и открываемые возможности	Косвенный Reach легко раздуть и посчитать дважды
Технический долг	Оценить частоту инцидентов, замедление delivery, риск и объём	Пользовательский Impact часто проявляется косвенно и позже горизонта
Стратегическая ставка	Выделить ограниченную capacity и decision memo	У нового направления может не быть исторических данных Reach

Override должен быть виден. Запишите инициатора, основание, дату, срок пересмотра и то, какую работу решение вытесняет. Так команда сохраняет прозрачность модели и не маскирует ручное решение завышенным Impact.

Для platform/enablers и техдолга есть три рабочих пути:

• посчитать прямой наблюдаемый Reach и Impact, если пользователи реально получают эффект в горизонте;
• пометить работу как dependency и включить раньше разблокируемой фичи;
• выделить отдельную capacity-корзину или использовать WSJF/Weighted Scoring, если важнее снижение риска, скорость будущей поставки и Cost of Delay.

Наложите capacity и WIP

Допустим, после поддержки, обязательных инцидентов и отпусков на квартал остаётся 8 person-month. Единая модель прав и событий нужна до корректного экспорта аудита, а экспорт закрывает обязательство в текущем квартале:

1. платформа — 2 person-month;
2. экспорт аудита — 4 person-month;
3. остаётся 2 person-month, куда помещается чек-лист онбординга.

CSV с RICE 115,2 не попадает в этот набор, хотя выше платформы и аудита. Причина видна: dependency, обязательный срок и ограниченная мощность.

Доступный Effort нельзя заполнить арифметически без проверки специализаций. Свободные два person-month backend не заменяют недостающий месяц security engineering. Календарь должен учитывать узкие места, последовательность и возможность параллельной работы.

После выбора состава задайте WIP — сколько крупных элементов может одновременно находиться в работе. Open Guide to Kanban связывает pull новой работы с доступной мощностью и указывает, что избыток Work in Progress увеличивает и делает менее предсказуемым время завершения. Для примера можно разрешить не более двух крупных фич одновременно, а следующую брать после освобождения слота.

Как работать с неопределённостью и диапазонами

Один RICE score скрывает погрешность. Особенно опасны десятые доли: 48 и 42 выглядят как уверенный порядок, хотя Reach и Effort обеих строк могут измениться вдвое.

Запишите для каждого фактора минимум, базовый и максимум, затем посчитайте крайние сценарии:

Фича	Диапазоны R / I / C / E	Пессимистичный RICE	Базовый	Оптимистичный RICE
Чек-лист онбординга	R 500–700; I 0,5–1; C 0,8–1; E 1,5–2,5	80	300	466,7
Массовый импорт CSV	R 130–230; I 1–2; C 0,5–0,8; E 2–3,5	18,6	115,2	184
Единая модель прав и событий	R 180–300; I 0,25–0,5; C 0,5–0,8; E 1,5–3	7,5	48	80
Экспорт журнала аудита	R 50–90; I 2–3; C 0,5–1; E 3–5	10	42	90
SAML SSO	R 30–60; I 1–3; C 0,5–0,8; E 2,5–4	3,75	24	57,6

Пессимистичный сценарий CSV:

130 × 1 × 0,5 / 3,5 = 18,6

Оптимистичный:

230 × 2 × 0,8 / 2 = 184

Интервалы CSV, платформы, аудита и SSO перекрываются. Защищать их точный порядок нельзя. Их лучше считать одним кластером, а следующий шаг выбрать по стоимости получения данных, gates и цене задержки.

Проверьте чувствительность по одному фактору

Для базового CSV score равен 115,2. Если менять только одно допущение:

• Reach падает с 180 до 130: 130 × 2 × 0,8 / 2,5 = 83,2;
• Impact падает с 2 до 1: 180 × 1 × 0,8 / 2,5 = 57,6;
• Effort растёт с 2,5 до 3,5: 180 × 2 × 0,8 / 3,5 = 82,3.

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

Диапазон не обязан использовать ложную комбинацию всех худших событий как прогноз. Его задача — показать возможную смену решения. Для более зрелой аналитики можно задать сценарии с согласованными допущениями или провести Monte Carlo, но исходные распределения всё равно придётся доказать.

Что делать, если данных нет

Не ставьте 0 вместо неизвестного Reach или Impact. Ноль означает доказанное отсутствие охвата или влияния и обнуляет произведение. Пустое знание должно выглядеть как N/A.

Для строки с missing data укажите:

• какой фактор неизвестен;
• почему его нельзя оценить;
• какой минимальный диапазон допустим;
• какое исследование даст ответ;
• владелец и дата пересмотра.

Пример: «Reach массового экспорта неизвестен: событие не отслеживается. За два дня добавить временный лог, за неделю собрать число уникальных аккаунтов, затем вернуть строку в scoring». Если потенциальный Impact высок, приоритетом становится дешёвое исследование, а не сама дорогая фича.

Confidence не должен легализовать полностью выдуманные цифры. Запись Reach 10 000, Confidence 50% всё равно может поднять фантазию выше проверенных инициатив. При отсутствии разумного диапазона используйте research gate и не ранжируйте строку.

Как RICE искажают и как это остановить

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

Манипуляция или ошибка	Как распознать	Защита
Reach равен всей базе	Нет eligibility и exposure	Формула воронки, запрос к данным, правило уникальности
Смешаны месяц и год	В колонке нет горизонта	Один период в шапке и отдельная колонка Horizon
Повторы названы уникальными людьми	Events заметно больше активной аудитории	Явно выбрать people/accounts/events и дедупликацию
Impact назначен после просмотра рейтинга	Якоря отсутствуют или меняются по строкам	Зафиксировать шкалу до scoring
Confidence выражает энтузиазм	Нет ссылок на Reach, Impact и Effort	Evidence pack и независимый review
Effort включает только код	Нет QA, security, rollout, миграции	Общий Definition of Done и оценка исполнителей
Фичу раздробили ради маленького знаменателя	Части сами не дают ценности	Считать минимально полезный инкремент с полным выпуском
Платформенный Reach посчитан вместе с зависимыми фичами	Одни аккаунты встречаются в нескольких строках	Не суммировать scores, отметить overlap и dependency
Пересчитывают только любимые идеи	Старые даты у остальных строк	Единая дата среза и регулярный batch refresh

Полезный контроль — слепая предварительная оценка факторов разными ролями. Продакт приносит Reach и Impact, исполнители — Effort, аналитик или researcher проверяет источники, security/legal выставляют gates. Разногласия обсуждают до сортировки.

Как калибровать RICE между людьми и командами

Сначала возьмите три-пять завершённых фич разного размера. Восстановите прогнозы и сравните их с фактом:

• прогнозный и фактический Reach за тот же период;
• ожидаемый и наблюдаемый сдвиг целевой метрики;
• Confidence до релиза и величина ошибки;
• оценочный и фактический Effort всех ролей.

Затем уточните якоря Impact и правила Confidence. Если команды стабильно завышают Reach в 1,7 раза, одного снижения всех Confidence недостаточно: нужно исправить модель exposure. Если QA и rollout постоянно добавляют 30% Effort, включите их в Definition of Done.

Для совместной таблицы храните:

• версию шкалы;
• владельца каждой оценки;
• ссылку на доказательства и дату;
• min/base/max;
• фактические значения после релиза;
• причину каждого override.

Scores разных команд сопоставимы только при одинаковых единицах Reach, горизонте, шкале Impact, Confidence policy и Effort unit. Иначе число служит локальным инструментом внутри команды.

Пересматривайте оценки при появлении существенных данных, изменении scope, переносе горизонта или перед очередным циклом планирования. Ежедневный пересчёт создаёт шум; квартальное число, которое не меняют после крупного эксперимента, устаревает.

RICE, ICE, Weighted Scoring и WSJF: что выбрать

Метод	Логика	Сильная сторона	Когда выбрать	Ограничение
RICE	Reach × Impact × Confidence / Effort	Явно учитывает охват и период	Есть сопоставимые продуктовые данные и несколько фич одной цели	Плохо кодирует стратегию, gates, зависимости и Cost of Delay
ICE	Impact, Confidence, Ease; формулу нужно зафиксировать	Быстрая первичная сортировка гипотез	Reach трудно оценить, нужен лёгкий discovery-фильтр	Нет отдельного охвата; шкалы и реализации субъективны
Weighted Scoring	Сумма нормированных критериев с весами	Критерии настраиваются под стратегию	Нужно совместить ценность, риск, сегмент, стратегию и другие измерения	Вывод чувствителен к шкалам и весам; требуется более строгая настройка
WSJF	Относительная Cost of Delay / относительная длительность	Учитывает цену времени, риск и открытие возможностей	Нужно определить последовательность работ в потоке	Требует осмысленных относительных оценок Cost of Delay и размера

ICE подходит для быстрой сортировки ранних экспериментов. Его Ease направлена вверх: чем легче, тем выше балл. В RICE Effort направлен вниз и стоит в знаменателе. Дополнительный Reach заставляет показать, сколько объектов получат эффект и за какое время. В практических реализациях ICE встречаются среднее и произведение, поэтому название метода без формулы недостаточно.

Weighted Scoring уместен, когда фиксированных четырёх факторов RICE мало. Например, стратегия требует отдельно учитывать enterprise revenue, соответствие рынку, риск, поддержку и бренд. Тогда критерии нормируют и взвешивают, избегая скрытого добавления этих смыслов в Reach или Impact.

SAFe описывает WSJF как относительную Cost of Delay, делённую на относительную длительность. В Cost of Delay входят пользовательская или бизнес-ценность, временная критичность, снижение риска и открытие возможностей. Поэтому WSJF лучше выражает срочное compliance-требование или enabler, который разблокирует будущие работы. RICE лучше показывает широкую фичу с измеримым охватом за квартал.

Команда может применять модели последовательно: сначала gates, затем RICE для сопоставимых продуктовых кандидатов, после этого capacity и WIP. Смешивать четыре формулы в один «супербалл» без ясной модели не нужно.

Когда RICE подходит

RICE полезен, если:

• есть несколько сопоставимых фич одной цели;
• можно оценить реальный Reach за общий месяц, квартал или год;
• Impact на один объект имеет понятные якоря;
• исполнители способны оценить полный Effort;
• команда хочет сделать допущения видимыми;
• score будет пересматриваться вместе с данными.

Особенно хорошо метод работает для зрелого продукта с аналитикой: улучшений воронки, функций self-service, сценариев поддержки, adoption и повторяемых транзакционных процессов.

Когда выбрать другой подход

RICE слабее подходит, если:

• продукт новый и Reach нельзя даже ограничить диапазоном;
• сравниваются разные стратегии, рынки или горизонты;
• основное решение определяется сроком закона, критической безопасностью или договором;
• ценность лежит в снижении системного риска и будущей скорости delivery;
• работы образуют сложный граф зависимостей;
• цена задержки важнее общего охвата;
• сравниваются инвестиции, для которых нужен денежный business case.

В этих случаях помогают discovery-эксперимент, scenario planning, Weighted Scoring, WSJF, Cost of Delay, финансовая модель или отдельный risk portfolio. RICE можно оставить как один из входов, если его Reach и Impact действительно измеримы.

Готовый шаблон RICE

Перед заполнением таблицы запишите шапку решения:

• цель: какой результат оптимизируем;
• кандидаты: фичи какого уровня сравниваем;
• Reach unit: уникальные пользователи, аккаунты, события или транзакции;
• период: точные даты;
• Impact anchors: значения 3 / 2 / 1 / 0,5 / 0,25 с локальными определениями;
• Confidence policy: какие доказательства дают 100%, 80%, 50% и research gate;
• Effort unit: person-month и полный Definition of Done;
• capacity/WIP: сколько person-month и одновременных работ доступно;
• gates: security, legal, compliance, contractual и dependencies.

Шаблон строк:

Поле	Что записать
Feature	Однозначное название минимально полезного инкремента
Goal/metric	Цель и ожидаемое изменение
Reach formula	Аудитория × eligibility × exposure
Reach min/base/max	Диапазон в выбранной единице
Period	Общие даты горизонта
Impact + rationale	3/2/1/0,5/0,25 и основание
Confidence	1 / 0,8 / 0,5 или research gate
Effort min/base/max	Person-month всех ролей
Evidence	Ссылки на аналитику, исследование и оценку
RICE min/base/max	Три результата формулы
Gate/dependency	Must, blocked, predecessor, none
Owner/review date	Ответственный и дата обновления
Decision	Now, next, later, research, reject
Override reason	Причина ручного изменения порядка и вытесненная работа

Если Reach находится в D2, Impact — E2, Confidence десятичной дробью — F2, Effort — G2, формула Google Sheets или Excel выглядит так:

=IFERROR((D2*E2*F2)/G2,"")

Для min/base/max создайте отдельные колонки. Не используйте IFERROR(...,0): ошибка или пустое поле не должны превращаться в доказанный нулевой приоритет.

Вывод

RICE делает сильным тот разговор о приоритетах, в котором команда может ответить: кого затронет фича, за какой период, насколько изменится результат для одного объекта, чем подтверждены прогнозы и сколько труда потребуется всем участникам. Reach и горизонт нужно определять раньше оценок Impact и Effort — именно они отличают RICE от быстрых моделей без охвата.

Рассчитайте score, покажите диапазоны, проверьте чувствительность и missing data. Затем отдельно примените security/compliance gates, зависимости, capacity и WIP. Получится объяснимый план: цифры показывают исходные допущения, а ручные решения остаются видимыми.