Как приоритизировать фичи в продукте: RICE, ICE и Weighted Scoring

ICE подходит для быстрой первичной сортировки гипотез, RICE — для сопоставимых фич с измеримым охватом, а Weighted Scoring — для решений, где нужно явно учесть стратегию, клиентскую ценность, риск и другие критерии. Выбирать метод следует по типу решения и качеству данных. До расчёта зафиксируйте единицы, горизонт, шкалы и полный состав работ, а после него примените обязательные ограничения, зависимости, доступную мощность и лимит незавершённой работы. Первое место в таблице — аргумент для обсуждения, а не автоматическая команда к разработке.

Какие вопросы решают три метода

Все три подхода превращают суждения в числа, но оптимизируют разные вещи. Поэтому один backlog может получить три разных порядка без арифметической ошибки.

Метод	Формула в этой статье	На какой вопрос отвечает	Когда особенно полезен	Главный риск
ICE	(Impact + Confidence + Ease) / 3	Какую из сопоставимых гипотез разумнее проверить раньше?	Нужен быстрый фильтр, данных мало, эксперименты обратимы	Субъективные шкалы и завышенная Ease
RICE	Reach × Impact × Confidence / Effort	Где ожидаемый эффект на единицу труда выше?	Есть единый горизонт, измеримый Reach и полный Effort	Несопоставимые единицы и слабый учёт стратегии, риска, зависимостей
Weighted Scoring	Σ(вес × нормированный балл)	Какая инициатива лучше соответствует выбранной системе предпочтений?	Решение многокритериальное: стратегия, клиенты, риск, реализуемость	Политическая настройка критериев, шкал и весов

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

ICE возник в процессе приоритизации growth-экспериментов. Практика GrowthHackers использует среднее трёх оценок от 1 до 10 и рассматривает ICE как относительный, «минимально достаточный» ориентир. В продуктовых шаблонах встречается и произведение Impact × Confidence × Ease. Эти варианты не взаимозаменяемы: среднее позволяет сильному фактору компенсировать слабый, а произведение сильнее наказывает за низкую оценку. Формулу нужно записать рядом с таблицей и не менять внутри цикла.

Weighted Scoring — частный практический вариант многокритериального анализа решений, или MCDA. Его сила — в настраиваемых критериях, а цена этой гибкости — необходимость обосновать шкалы и веса. Руководство Government Analysis Function по MCDA подчёркивает компенсаторный характер взвешенной суммы: хороший результат по одному критерию способен перекрыть плохой по другому. Для запретов и обязательных требований поэтому нужны отдельные пороги.

Сначала сделайте входы сопоставимыми

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

Перед оценкой составьте короткий контракт данных.

Поле контракта	Что зафиксировать	Что ломается без правила
Цель решения	Одна метрика или набор стратегических целей	Impact означает разное для разных участников
Состав кандидатов	Один тип, сегмент, стадия готовности и размер результата	Маленькие задачи выигрывают за счёт искусственного дробления
Горизонт	Например, следующий квартал	Reach за месяц сравнивается с годовым, срочность скрывается
Единица Reach	Уникальные аккаунты, пользователи, транзакции или события	Большой аккаунт и частое событие незаметно смешиваются
Impact	Эффект на один reached-объект или общий эффект гипотезы; шкала и якоря	Одинаковое слово маскирует разные величины
Confidence	Какие доказательства дают высокий, средний и низкий уровень	Энтузиазм превращается в «90% уверенности»
Effort и критерии готовности (Definition of Done)	Работа продакта, дизайнера, аналитика, разработчиков, тестировщиков и специалиста по безопасности, миграция и выпуск	В знаменатель попадает только время программиста
Evidence	Источник, дата, владелец, диапазон	Нельзя обновить прогноз и проверить автора оценки
Версия модели	Формула, рубрики, веса, дата среза	Старые и новые scores выглядят сопоставимыми

Не суммируйте сырые баллы разных команд. RICE с Reach в аккаунтах за квартал нельзя напрямую сравнить с RICE в событиях за месяц. ICE одной команды, где Ease 10 означает «до одного дня», не равен ICE другой, где это «до месяца». Даже одинаковый итоговый score не доказывает одинаковую ценность.

Как выбрать метод: decision matrix

Выбор зависит не от зрелости команды вообще, а от конкретного пула кандидатов и решения, которое предстоит принять.

Ситуация	Какие данные есть	Что сравниваем	Подход	Что остаётся вне формулы
Еженедельный discovery или growth	Гипотезы, интервью, прошлые тесты; Reach ещё неточен	Небольшие обратимые эксперименты одной цели	ICE	Риск для бренда, запреты, доступные слоты экспериментов
Квартальный backlog зрелого продукта	Аналитика по аккаунтам или пользователям, прогноз эффекта, общая оценка труда	Фичи одной метрики и горизонта	RICE	Стратегические ставки, dependencies, обязательства
Enterprise-релиз	Метрики плюс договорные, операционные и risk-данные	Фичи одного релиза	Weighted Scoring	Непреодолимые gates, capacity и последовательность
Портфель нескольких продуктов	Масштабы Reach и экономики различаются	Инвестиционные инициативы одного уровня	Weighted Scoring с общими value functions	Бюджет, компетенции, взаимоисключения и синергия
Compliance, security-инцидент, договорный срок	Есть обязательность и дата	Must-do работа	Gate или expedite-класс до рейтинга	Сам факт обязательного выполнения
Платформа и технический долг	Прямой Reach слаб, но измеримы инциденты, lead time и блокировки	Enablers внутри технического портфеля	Weighted Scoring или отдельная доля capacity	Граф зависимостей и минимальный уровень надёжности

ICE не обязан быть постоянной заменой RICE. Он может отсеять слабые сырые идеи, чтобы команда не тратила аналитику на сотню строк. RICE не обязан ранжировать весь портфель компании. Он хорошо работает внутри однородного набора. Weighted Scoring не делает решение «объективнее» только за счёт четырёх знаков после запятой: результат отражает выбранные предпочтения.

Как перевести один backlog из одного метода в другой

Переносить нужно факты и доказательства, а не итоговые scores. Рабочий порядок такой:

1. Заморозьте карточку исходных фактов: цель, Reach, наблюдения пользователей, коммерческие обязательства, риски, полный Effort, зависимости и даты.
2. Определите один пул кандидатов и один временной горизонт.
3. Создайте отдельные рубрики для каждой модели до просмотра рейтинга.
4. Переоцените все строки одним снимком. Не конвертируйте только понравившуюся фичу.
5. Сравните не только места, но и вклад факторов: что именно подняло или опустило кандидата.
6. Проверьте спорные inputs диапазонами, затем примените gates, dependencies, capacity и WIP.

Связь между полями выглядит так:

Смысл	RICE	ICE	Weighted Scoring	Правило переноса
Охват	Отдельный Reach за период	Отдельного поля нет	Может быть критерием после нормирования	Хранить сырое число; не прятать автоматически в Impact
Эффект	Impact на один reached-объект	Общий потенциал гипотезы по локальной рубрике	Customer value или иной критерий с value function	Перечитать evidence и оценить заново
Доверие к прогнозу	Confidence 100/80/50%	Confidence 1–10	Диапазон, evidence grade или отдельный критерий	Общую рубрику можно связать, но смысл явно описать
Стоимость	Effort в знаменателе	Ease направлена вверх	Delivery ease или cost после нормирования	Использовать один полный scope; задать интервалы Ease заранее
Стратегия и риск	Нет отдельных факторов	Нет отдельных факторов	Отдельные критерии	Не подмешивать скрыто в Impact; запреты вынести в gate

Механическое правило Confidence 80% = 8 допустимо только как заранее утверждённая рубрика. Оно не следует из названия метода. Так же нельзя объявить Ease обратной величиной Effort без границ: 1 / Effort резко усиливает разницу между маленькими задачами и может поощрять бесконечные quick wins.

Один B2B SaaS backlog в трёх моделях

Команда планирует квартал B2B SaaS — облачного сервиса для компаний. Reach — число уникальных активных аккаунтов, которые получат эффект за квартал. Effort — человеко-месяцы (person-month) всех ролей до готовности к рабочему запуску, включая тестирование и выпуск. Это адаптация канонического RICE без смены единицы внутри таблицы.

Исходный evidence pack дал такие оценки:

Фича	Reach	RICE Impact	Confidence	Effort, person-month	ICE: I / C / E	Weighted: стратегия / клиент / риск / лёгкость, 1–5
Массовый импорт	180	1	100%	1	6 / 10 / 10	4 / 4 / 2 / 5
SSO/SAML, единый корпоративный вход	120	2	80%	2	8 / 8 / 6	5 / 4 / 4 / 3
Журнал аудита	70	3	100%	1,5	10 / 10 / 8	4 / 3 / 5 / 4
ИИ-сводка обращений	220	2	50%	3	9 / 5 / 2	3 / 5 / 1 / 1
Очередь заданий и идемпотентные повторы	250	0,5	80%	2,5	7 / 8 / 4	4 / 3 / 5 / 2

Для ICE команда закрепила формулу GrowthHackers — среднее трёх факторов. Ease связали с тем же полным Effort: до 1 person-month — 10, 1,5 — 8, 2 — 6, 2,5 — 4, от 3 — 2. Impact ICE — не растянутая шкала RICE, а ожидаемый общий сдвиг одной целевой метрики. Confidence привязан к общей evidence rubric.

Для Weighted Scoring оценки 1–5 переведены в шкалу 0–100:

Нормированный балл = (оценка − 1) / 4 × 100.

Веса определены до расчёта: соответствие стратегии — 30%, клиентская ценность — 25%, снижение риска или выполнение обязательств — 25%, лёгкость доставки — 20%. Сумма весов равна 100%.

Проверяемая арифметика

Для массового импорта:

• RICE: 180 × 1 × 1 / 1 = 180;
• ICE: (6 + 10 + 10) / 3 = 8,67;
• Weighted: 75×0,30 + 75×0,25 + 25×0,25 + 100×0,20 = 67,5.

Для SSO/SAML:

• RICE: 120 × 2 × 0,8 / 2 = 96;
• ICE: (8 + 8 + 6) / 3 = 7,33;
• Weighted: 100×0,30 + 75×0,25 + 75×0,25 + 50×0,20 = 77,5.

Итоги для всех пяти строк:

Фича	RICE	Место RICE	ICE	Место ICE	Weighted	Место Weighted
Массовый импорт	180,00	1	8,67	2	67,5	3
SSO/SAML, единый корпоративный вход	96,00	3	7,33	3	77,5	1
Журнал аудита	140,00	2	9,33	1	75,0	2
ИИ-сводка обращений	73,33	4	5,33	5	40,0	5
Очередь заданий и идемпотентные повторы	40,00	5	6,33	4	65,0	4

Остальные строки считаются так:

• журнал аудита: RICE 70×3×1/1,5 = 140; ICE (10+10+8)/3 = 9,33; Weighted 75×0,30 + 50×0,25 + 100×0,25 + 75×0,20 = 75;
• ИИ-сводка: RICE 220×2×0,5/3 = 73,33; ICE (9+5+2)/3 = 5,33; Weighted 50×0,30 + 100×0,25 + 0×0,25 + 0×0,20 = 40;
• очередь и повторы: RICE 250×0,5×0,8/2,5 = 40; ICE (7+8+4)/3 = 6,33; Weighted 75×0,30 + 50×0,25 + 100×0,25 + 25×0,20 = 65.

Почему порядок изменился

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

ICE поставил журнал аудита первым. Отдельного Reach в формуле нет, а Impact, Confidence и Ease высоки. Массовый импорт остался рядом благодаря простоте. ИИ-сводка упала на последнее место: сильная идея пока слабо подтверждена и дорога для проверки.

Weighted Scoring выбрал SSO/SAML за сильное соответствие enterprise-стратегии и снижение договорного риска. Платформенная очередь обогнала ИИ-сводку благодаря надёжности и разблокировке будущих работ. Это не доказательство превосходства Weighted Scoring: модель отвечает на другую функцию полезности, заданную весами.

Расхождение полезно разбирать вопросом «какое допущение изменило место?». Если лидер RICE проигрывает Weighted Scoring, проверьте стратегию и риск. Если лидер ICE проигрывает RICE, проверьте реальный Reach. Если техническая работа всегда внизу, не выдумывайте ей охват — создайте подходящий технический портфель.

Как проверить чувствительность и неопределённость

Confidence не заменяет анализ неопределённости. Одно число скрывает разные причины сомнений: неизвестный охват, слабую причинную связь, изменчивый scope или внешнюю зависимость. Для верхней части списка считайте хотя бы три согласованных сценария — pessimistic, base и optimistic.

Для ИИ-сводки диапазон RICE может выглядеть так:

Сценарий	Reach	Impact	Confidence	Effort	RICE
Pessimistic	160	1	50%	4	160×1×0,5/4 = 20
Base	220	2	50%	3	220×2×0,5/3 = 73,33
Optimistic	280	2	80%	2,5	280×2×0,8/2,5 = 179,2

Диапазон от 20 до 179,2 пересекает почти весь рейтинг. Спорить о базовом месте №4 бессмысленно. Полезнее провести дешёвый discovery: проверить качество сводок на выборке, измерить долю подходящих обращений и уточнить стоимость эксплуатации.

Для Weighted Scoring проверяйте веса и спорные оценки. В базовом сценарии SSO набрал 77,5, аудит — 75. Если уменьшить вес стратегии с 30 до 20% и увеличить вес риска с 25 до 35%, SSO получит 75, а аудит — 77,5. Лидер меняется от сдвига на 10 процентных пунктов. Значит, оба кандидата устойчиво сильны, но выбор между ними зависит от предпочтений владельца решения.

Для ICE полезен простой однофакторный тест чувствительности. Если Impact журнала аудита не 10, а 8, его score станет (8+10+8)/3 = 8,67 — столько же, сколько у массового импорта. Ничья показывает потребность в правиле разрешения равенства или дополнительных доказательствах, а не необходимость округлить таблицу до сотых.

Правительственное руководство по MCDA рекомендует проверять, сохраняется ли предпочтительный вариант при изменении спорных оценок и весов. Для roadmap важна также устойчивость попадания выше границы capacity: фича может оставаться второй или третьей, но выпадать из исполнимого набора в половине сценариев.

Почему рейтинг ещё не roadmap

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

Gates и обязательные работы

Compliance, критическая security-уязвимость, инцидент и твёрдое договорное обязательство нельзя безопасно представить слабым весом. В компенсаторной модели коммерческая привлекательность может перекрыть провал по безопасности. Поэтому сначала применяют gate:

• pass — кандидат допускается к ранжированию;
• must — работа обязательна к сроку и резервирует capacity;
• blocked — не пройдена архитектурная, legal или data-зависимость;
• reject — риск или несоответствие стратегии неприемлемы.

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

Dependencies и технический долг

Зависимость меняет последовательность, а не внутреннюю ценность. Не завышайте задним числом Impact платформенной задачи, чтобы протолкнуть её наверх. Сохраните исходный score и отдельные поля blocks и blocked by.

Технический долг лучше сравнивать внутри технического портфеля по снижению частоты и масштаба инцидентов, экономии операционного времени, ускорению lead time и разблокировке фич. Другой вариант — заранее резервировать долю capacity. Иначе прямой Reach системно вытеснит работу, без которой delivery постепенно остановится.

Capacity и WIP

Capacity — доступный объём труда за период. WIP (work in progress) — число одновременно незавершённых инициатив. Пусть у команды 4,5 человеко-месяца на квартал и WIP limit равен двум инициативам. Журнал аудита обязателен к compliance-дате и занимает 1,5 человеко-месяца. Очередь с идемпотентными повторами занимает 2,5 и блокирует безопасный массовый импорт.

Исполнимый выбор — начать журнал аудита и платформенную очередь: вместе 4 человеко-месяца и два WIP-слота. Массовый импорт остаётся следующим после обязательной зависимости, хотя он первый по RICE. Оставшиеся 0,5 человеко-месяца нельзя назвать готовой ИИ-фичей; после освобождения слота их можно оформить как отдельный discovery-эксперимент с собственным результатом.

Это портфельная задача: первые N строк не всегда образуют лучший набор. Нужно учитывать разные компетенции, общий компонент, взаимоисключения и пользу, которая появляется только у комбинации работ.

Как защищаться от bias и gaming

Формула не устраняет политику. Она делает места, где политика проникает в решение, более заметными.

Манипуляция или ошибка	Как меняет рейтинг	Защита
Reach равен всей базе	Завышает RICE	Формула eligibility × exposure, одна единица и период
В Effort только разработка	Поднимает сложную фичу	Общий Definition of Done и оценки исполнителей
Confidence равен энтузиазму автора	Маскирует отсутствие данных	Evidence rubric, ссылки, дата и независимый review
Инициативу раздробили на «снеки»	Уменьшает Effort и повышает Ease	Сравнивать минимально полезные результаты, задать effort floor
Один эффект назван Reach, revenue и growth	Троекратно учитывает выгоду	Карта причинности и проверка корреляции критериев
Веса меняют после раскрытия результата	Подгоняет Weighted Scoring	Утвердить веса до performance scoring, хранить версию
Обновляют только любимые строки	Новый score сравнивается со старыми данными	Единый срез пула и дата свежести каждой строки
Округление создаёт ложную точность	Маскирует неопределённость	Диапазоны, rank bands и не более разумного числа знаков

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

Как провести сессию приоритизации

Скоринг-сессия нужна не для коллективного голосования за любимые идеи. Её задача — обнаружить разный смысл входов и принять видимый trade-off.

1. Разошлите pre-read: цель, кандидаты одного уровня, raw data, рубрики, известные зависимости и missing data.
2. В начале подтвердите владельца решения, горизонт, capacity и обязательные gates.
3. Попросите участников независимо оценить только те поля, в которых они компетентны. Это уменьшает anchoring на мнении руководителя.
4. Сначала обсуждайте размах оценок и доказательства, а не среднее. Если один инженер ставит Ease 8, а другой 3, вероятно, у них разный scope.
5. Для Weighted Scoring согласуйте value functions и веса до раскрытия общего результата. Вес — ценность полного перехода от худшего допустимого уровня к лучшему, а не абстрактная важность названия критерия.
6. Рассчитайте рейтинг и сделайте sense check: какой фактор дал каждому лидеру преимущество?
7. Проведите sensitivity test для близких мест и слабых данных.
8. Наложите dependencies, capacity, skills и WIP. Зафиксируйте выбранный набор и вытесненные работы.
9. Сохраните неснятое разногласие и дату, когда решение пересматривается.

В GrowthHackers growth process ICE работает вместе с общей целью, ограниченным числом номинаций, межфункциональной встречей, тестом и разбором результата. Без этого цикла спорные баллы не калибруются.

Гибридный двухступенчатый процесс

Комбинировать методы полезно последовательно, но не складывать их результаты в «супербалл».

Ступень отбора. Раз в неделю применяйте ICE к сырым гипотезам одной цели. Требуйте минимальный evidence pack и отмечайте неизвестные данные. Задача этапа — выбрать несколько кандидатов для исследования, прототипа или дешёвого теста, а не обещать квартальный roadmap.

Ступень обязательства. Перед планированием пересчитайте финалистов. Если у них один продуктовый результат, общий горизонт и измеримый Reach, используйте RICE. Если решение включает стратегию, enterprise-обязательства, риск и платформенные эффекты, примените Weighted Scoring с нормированными критериями. Затем отдельно наложите gates, dependencies, capacity и WIP.

RICE score не стоит добавлять как ещё один критерий Weighted Scoring, если таблица уже содержит охват, клиентскую ценность и лёгкость. Одни и те же эффекты будут учтены дважды. Переносите исходные данные или используйте RICE только как диагностический вид.

Когда пересчитывать и как документировать override

Универсального календаря нет. Частота должна соответствовать скорости появления новых данных и стоимости пересчёта.

Модель	Регулярный ритм	Событийный пересчёт
ICE	Еженедельный growth/discovery review	Новый тест, интервью, прототип или изменение scope
RICE	Перед sprint/quarter planning для верхнего пула	Новая аналитика, существенное изменение Reach или Effort, новая зависимость
Weighted Scoring	Оценки вариантов — перед планированием; критерии и веса — на стратегический цикл	Смена стратегии, обязательств, допустимого риска или функции ценности

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

Override допустим, если decision owner видит причину, но исходные данные переписывать нельзя. В журнале сохраните:

• дату и владельца решения;
• версию модели, исходный score и место;
• принятое действие: now, next, research, blocked, reject;
• категорию причины: gate, deadline, dependency, capacity, strategic bet;
• доказательство или ограничение;
• вытесненную работу и цену отказа от неё;
• дату истечения или повторного review;
• ожидаемый результат, по которому решение проверят.

Пример записи: «Журнал аудита, RICE №2, выбран первым до 30 ноября из-за подтверждённого compliance-срока; вытесняет SSO из текущего квартала; владелец — VP Product; пересмотр — после прохождения аудита». Если исключения повторяются по одной причине, модели не хватает критерия, отдельного портфеля или явного gate.

Вывод

ICE, RICE и Weighted Scoring полезны на разных этапах. ICE быстро сортирует обратимые гипотезы. RICE дисциплинирует сравнение охвата, эффекта, уверенности и полного труда. Weighted Scoring позволяет выразить несколько стратегических предпочтений и увидеть компромиссы.

Качественная приоритизация начинается раньше формулы: с одного класса решений, горизонта, единиц, рубрик и доказательств. После расчёта проверьте диапазоны и причины расхождения рейтингов, затем постройте допустимый план по gates, dependencies, capacity и WIP. Так score останется проверяемой моделью решения, а override — прозрачным управленческим выбором.