RICE и ICE: приоритизация гипотез с Reach из данных, а не из головы

Коротко

RICE и ICE — способы свести оценку инициативы к одному числу, чтобы сравнивать задачи, которые иначе сравнить трудно. RICE = Reach × Impact × Confidence / Effort, ICE складывается из Impact, Confidence и Ease.

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

Что такое RICE: формула и шкалы

RICE описал Шон Макбрайд в блоге Intercom: команде нужен был способ сравнивать проекты разного типа и не тянуть в работу то, что просто нравится самим. В формуле четыре оценки.

Reach — охват: сколько людей или событий инициатива затронет за выбранный период. Например, клиентов за квартал или операций за месяц. Автор прямо советует брать число из метрик продукта, а не придумывать.

Impact — влияние на одного затронутого человека. Точно измерить его заранее нельзя, поэтому шкала дискретная: 3 — огромное, 2 — высокое, 1 — среднее, 0,5 — низкое, 0,25 — минимальное. На что именно влияние, решает команда: в исходной статье это конверсия, у вас может быть активация или удержание.

Confidence — уверенность в оценках, в процентах: 100% — высокая, 80% — средняя, 50% — низкая. Всё, что ниже, автор называет выстрелом наугад. Этот множитель штрафует идеи, у которых охват и влияние взяты без опоры на данные.

Effort — трудозатраты всей команды, продукта, дизайна и разработки вместе, в человеко-месяцах. Целые числа, для совсем небольших задач — 0,5.

Результат читается как «влияние на единицу затраченного времени». Сам по себе он ничего не значит: 290 — это не пользователи и не рубли. Число имеет смысл только рядом с другими, посчитанными в тех же единицах и за тот же период.

Что такое ICE и чем он отличается от RICE

ICE связывают с Шоном Эллисом: метод вырос из практики команд роста, которым нужно было быстро упорядочить длинный список экспериментов, и описан в книге Эллиса и Моргана Брауна «Hacking Growth». Оценок три: Impact (влияние), Confidence (уверенность) и Ease (лёгкость реализации), каждая по шкале от 1 до 10.

Итог считают двумя способами. В одних командах три оценки усредняют, и счёт лежит между 1 и 10. В других перемножают, и он лежит между 1 и 1000. Это не одно и то же: произведение сильнее наказывает за одну низкую оценку, и порядок задач может отличаться. Договоритесь о способе до того, как начнёте сравнивать.

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

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

Откуда брать Reach: считаем на данных

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

Возьмём учебную базу «Маяк»: сервис, где пользователь регистрируется, создаёт рабочее пространство (workspace_created), затем первый отчёт (report_created) и приглашает коллег (invite_sent). В таблице users одна строка — один пользователь, в events — одно действие. Команда обсуждает пять инициатив, и у каждой свой шаг.

Сначала фиксируем единицу и период, одинаковые для всех: пользователи, зарегистрировавшиеся за июль 2026 года, и их действия в первые 14 дней после регистрации. Июль взят потому, что это полный месяц, и к закрытию выгрузки 30 августа у каждого его пользователя 14 дней уже прошли.

with cohort as (
  select user_id, signup_date
  from users
  where signup_date between date '2026-07-01' and date '2026-07-31'
),
steps as (
  select
    c.user_id,
    coalesce(bool_or(e.event_name = 'workspace_created'), false) as has_workspace,
    coalesce(bool_or(e.event_name = 'report_created'), false) as has_report,
    coalesce(bool_or(e.event_name = 'invite_sent'), false) as has_invite
  from cohort as c
  left join events as e
    on e.user_id = c.user_id
   and e.event_time < c.signup_date + interval '14 days'
  group by c.user_id
)
select
  count(*) as signups,
  count(*) filter (where not has_workspace) as no_workspace,
  count(*) filter (where has_workspace and not has_report) as workspace_no_report,
  count(*) filter (where has_report and not has_invite) as report_no_invite
from steps;

Reach для сегмента: канал и устройство

Три числа из первого запроса закрывают три инициативы. Подсказки на шаге создания рабочего пространства касаются тех, кто его не создал, — 725 человек. Шаблоны отчётов нужны тем, кто создал пространство и остановился перед пустым отчётом, — 339. Напоминание пригласить коллег увидят те, кто отчёт создал, а приглашение не отправил, — 460.

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

with cohort as (
  select user_id, signup_date, channel, device
  from users
  where signup_date between date '2026-07-01' and date '2026-07-31'
),
steps as (
  select
    c.user_id,
    c.channel,
    c.device,
    coalesce(bool_or(e.event_name = 'workspace_created'), false) as has_workspace,
    coalesce(bool_or(e.event_name = 'report_created'), false) as has_report
  from cohort as c
  left join events as e
    on e.user_id = c.user_id
   and e.event_time < c.signup_date + interval '14 days'
  group by c.user_id, c.channel, c.device
)
select
  count(*) filter (where channel = 'paid_search') as paid_signups,
  count(*) filter (where channel = 'paid_search' and not has_workspace) as paid_no_workspace,
  count(*) filter (
    where device = 'mobile' and has_workspace and not has_report
  ) as mobile_workspace_no_report
from steps;

Почему период и единица должны быть одинаковыми

Число из запроса привязано к месяцу. Тот же расчёт по июньской когорте даёт другие значения: без рабочего пространства остались 332 человека, а не 725. Регистраций в июне было в 1,6 раза меньше, но дело не только в этом — выросла и доля остановившихся на шаге, с 31,9% до 43,3%. Охват меняется и от размера аудитории, и от того, как ведёт себя воронка.

Если охват одной инициативы посчитан по июню, а другой по июлю, первая проиграет только из-за месяца. То же с единицей: «725 пользователей в месяц» и «2100 открытий экрана в месяц» в одном столбце не сравниваются, хотя формула молча перемножит оба. Август в расчёт не попал: у тех, кто зарегистрировался после 16 августа, к закрытию выгрузки 14 дней ещё не прошли, и «не дошедших до шага» среди них было бы больше просто из-за нехватки времени.

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

with cohort as (
  select user_id, signup_date
  from users
  where signup_date between date '2026-06-01' and date '2026-07-31'
),
steps as (
  select
    c.user_id,
    c.signup_date,
    coalesce(bool_or(e.event_name = 'workspace_created'), false) as has_workspace,
    coalesce(bool_or(e.event_name = 'report_created'), false) as has_report
  from cohort as c
  left join events as e
    on e.user_id = c.user_id
   and e.event_time < c.signup_date + interval '14 days'
  group by c.user_id, c.signup_date
)
select
  extract(month from signup_date) as signup_month,
  count(*) as signups,
  count(*) filter (where not has_workspace) as no_workspace,
  count(*) filter (where has_workspace and not has_report) as workspace_no_report
from steps
group by extract(month from signup_date)
order by signup_month;

Пример расчёта RICE для пяти инициатив

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

Арифметика по первой строке: 725 × 1 × 0,8 / 2 = 290. По второй: 339 × 2 × 0,8 / 1 = 542,4. Порядок по убыванию счёта: шаблоны отчётов, онбординг для платного поиска, подсказки на шаге пространства, напоминание о приглашении, мобильный редактор.

Обратите внимание на низ таблицы. У мобильного редактора самый высокий Impact, но самый маленький охват и самые большие трудозатраты, и формула ставит его последним. Напоминание о приглашении, наоборот, слабое по влиянию, зато дешёвое, и за счёт делителя 0,5 обходит редактор почти вдвое.

Как меняется порядок, если поправить одну оценку

Шкала Impact грубая: между «средним» и «высоким» разница вдвое, и спор о том, 1 это или 2, обычно ничем не заканчивается. Поэтому полезно проверить, что будет с порядком, если спорная оценка окажется на соседней ступени.

Поднимем Impact подсказок с 1 до 2. Счёт удваивается: 725 × 2 × 0,8 / 2 = 580, и инициатива с третьего места выходит на первое, обгоняя шаблоны отчётов с их 542,4. Одна ступень шкалы у одной строки поменяла лидера.

Менее заметный случай — второе и третье места. Между 309 и 290 разница около 6%. Достаточно поднять Confidence подсказок с 80% до 100%, и получится 362,5: строки меняются местами. Такие пары честнее считать равными и выбирать между ними по другим соображениям: зависимости, загрузка конкретных людей, связь с целью квартала.

Рабочее правило: различие в счёте имеет смысл, только если оно переживает сдвиг любой одной оценки на одну ступень. Шаблоны отчётов против мобильного редактора (542,4 и 128,8) это правило проходят. Первая тройка — нет.

Что покажет ICE на тех же инициативах

Переведём те же суждения в шкалу ICE. Оценки снова условные: Impact 3 превращается в 9, Impact 2 — в 7, средняя уверенность — в 7, низкая — в 4, задача на полмесяца получает лёгкость 9, а на три месяца — 2.

Шаблоны отчётов остаются первыми при любом способе. Дальше порядок расходится с RICE. По произведению мобильный редактор обходит напоминание о приглашении: 126 против 108, хотя в RICE было наоборот. По среднему он поднимается ещё выше и делит второе место с онбордингом для платного поиска — у обоих 6.

Причина одна: в ICE нет множителя, который знал бы, что редактор нужен 161 пользователю, а подсказки увидят 725. Если команда держит охват в голове, когда ставит Impact, результат будет ближе к RICE, но проверить это по таблице нельзя. Когда аудитории инициатив различаются в разы, как здесь, охват лучше считать отдельным столбцом.

RICE, ICE, MoSCoW и модель Кано: что выбрать

Рядом с RICE и ICE обычно называют ещё два метода, но они решают другие задачи. MoSCoW предложил Дай Клегг в 1994 году для проектов с жёстким сроком: требования делят на четыре группы — Must have, Should have, Could have и Won't have (в этот раз). Это договорённость с заказчиком о составе релиза, а не расчёт.

Модель Кано описана в статье Нориаки Кано с соавторами 1984 года. Она делит свойства продукта по тому, как они влияют на удовлетворённость: обязательные, отсутствие которых раздражает, а наличие не радует; линейные, где больше — лучше; привлекательные, которых никто не ждал; безразличные и нежелательные. Категорию определяют опросом: про каждое свойство задают парный вопрос — что вы почувствуете, если оно есть, и что, если его нет.

Методы не исключают друг друга. Кано помогает понять, что вообще стоит рассматривать, MoSCoW — зафиксировать состав релиза, RICE или ICE — упорядочить то, что осталось внутри одной группы.

Типичные ошибки в скоринге

Формула простая, поэтому ошибаются не в умножении, а в том, что в неё подставляют.

• Confidence 100% без данных. Высокая уверенность означает, что охват посчитан, а влияние подтверждено исследованием или прошлым тестом. Если есть только убеждённость автора, это 50%.
• Reach в разных единицах и за разные периоды. Пользователи у одной строки, сессии у другой, месяц и квартал вперемешку. Формула это не заметит.
• Эффект, заложенный в Reach. В охват пишут не «725 человек увидят подсказку», а «200 дополнительных активаций», и затем умножают ещё и на Impact.
• Impact как желание автора. Оценку ставит тот, кто идею принёс. Помогает правило: рядом с каждой оценкой выше 1 — ссылка на исследование, тест или хотя бы на базовую конверсию шага.
• Effort без команды. Трудозатраты оценивает продакт в одиночку, и они оказываются вдвое меньше реальных. Знаменатель должны давать те, кто будет делать.
• Подгонка под ответ. Оценки правят, пока любимая инициатива не окажется наверху. Проверка чувствительности из раздела выше делает такую подгонку заметной.
• Скоринг вместо стратегии. Счёт сравнивает инициативы внутри цели. Если одна строка про активацию, а другая про выручку с крупных клиентов, выбор между ними — вопрос о цели квартала, и решает его не формула.
• Порядок как закон. Автор RICE сам оговаривает, что счёт не жёсткое правило: зависимость между проектами или обязательство перед клиентом — законный повод взять задачу не по порядку. Важно, чтобы такое решение было видно.

Как связать скоринг с проверкой гипотезы после запуска

Оценка Impact — это спрятанный прогноз. Чтобы она чему-то учила, прогноз нужно записать явно до запуска. Для шаблонов отчётов он мог бы звучать так: в июльской когорте из 951 пользователя, создавшего рабочее пространство, отчёт за 14 дней создали 612, то есть 64,4%; мы ожидаем, что с шаблонами доля вырастет на 5 процентных пунктов. Пять пунктов здесь — условная цифра для примера; на аудитории июля это около 48 дополнительных пользователей с отчётом в месяц.

В такой записи есть всё, что нужно для проверки: метрика, знаменатель, окно, базовое значение и ожидаемый сдвиг. Это уже гипотеза в том виде, в каком её можно отдать в A/B-тест. Если тест невозможен, остаётся сравнение когорт до и после, но с поправкой на то, что состав каналов и сезон тоже меняются.

После запуска в ту же таблицу добавляют два столбца: фактический охват и фактический эффект. Охват часто расходится с прогнозом сильнее, чем кажется: подсказку увидели не все 725 человек, а только те, кто дошёл до нужного экрана. Через два-три квартала по этим столбцам видно, кто в команде систематически завышает Impact и какие типы инициатив дают меньше обещанного. С этого момента Confidence перестаёт быть ощущением: 80% получают идеи того типа, который раньше оправдывался.

Частые вопросы о RICE и ICE

Итог

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

Считать охват по шагам воронки и сегментам на базе продукта можно в Симуляторе SQL-аналитика: там та же учебная база «Маяк», на которой выполнены запросы из этой статьи.