RICE, ICE и WSJF: методы приоритизации задач и бэклога

Приоритет и приоритизация — не одно и то же

Приоритет High / Medium / Low — короткая отметка важности задачи. Она помогает быстро ориентироваться в очереди, но сама по себе не объясняет, почему две задачи получили одинаковую метку и какую из них стоит выполнить раньше.

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

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

RICE

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

• Reach — охват. Количество пользователей, клиентов или других единиц, которых затронет задача за выбранный период. Например, пользователей за квартал. Период и единица должны быть одинаковыми для сравниваемых задач.
• Impact — влияние. Ожидаемая сила эффекта на одного участника охвата относительно выбранной цели. Можно договориться об уровнях слабого, среднего и сильного влияния и назначить им числовые веса.
• Confidence — уверенность. Насколько оценки охвата и влияния подкреплены данными. В этой формуле используется доля: 80% записываются как 0.8, а 100% — как 1.
• Effort — трудозатраты. Объём работы всех необходимых участников. Его можно измерять, например, в человеко-неделях, последовательно используя одну единицу.

RICE = (Reach × Impact × Confidence) ÷ Effort

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

Задача «Упростить первый запуск» затронет 1 000 пользователей за квартал. Влияние оценили в 2, уверенность — в 80%, трудозатраты — в 3 человеко-недели. Получается (1000 × 2 × 0.8) ÷ 3 ≈ 533.3. Чем выше результат, тем выше место задачи при сортировке по этой модели.

Если уверенность хранится в процентах как число 80, перед умножением его нужно разделить на 100. Смешивать 80 и 0.8 в одном наборе оценок нельзя. Трудозатраты должны быть положительными: деление на ноль не даёт осмысленного балла.

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

ICE

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

• Impact — влияние. Насколько задача поможет достичь выбранной цели.
• Confidence — уверенность. Насколько команда доверяет ожидаемому эффекту на основании исследований, наблюдений или результатов экспериментов.
• Ease — простота реализации. Насколько легко выполнить задачу с учётом усилий и сложности. Высокое значение означает большую простоту.

ICE = Impact × Confidence × Ease

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

Для задачи «Добавить экспорт CSV» команда использует шкалу от 1 до 10 по каждому фактору: влияние — 9, уверенность — 9, простота — 6. Балл равен 9 × 9 × 6 = 486. Здесь Confidence — балл согласованной шкалы, а не процент из примера RICE.

ICE проще и быстрее применять, чем RICE, поскольку не нужно отдельно оценивать Reach, а трудность отражается одним фактором Ease. Это удобно для предварительного разбора идей, когда точных данных об охвате ещё нет. Ускорение оценки не устраняет субъективность: без общего понимания шкалы один участник поставит 9 там, где другой выберет 5.

Чтобы оценки были сопоставимыми, договоритесь, какие примеры соответствуют нижнему, среднему и верхнему уровню каждой шкалы. Не подставляйте трудозатраты напрямую вместо Ease: иначе более сложная задача получит больший множитель. Выбор между ICE и RICE зависит от доступных данных и цели обсуждения.

WSJF

Приоритизация по WSJF рассматривает стоимость задержки относительно размера работы. Модель помогает обсуждать, выполнение каких задач не стоит откладывать, когда очередь работ конкурирует за ограниченную пропускную способность команды.

WSJF = Cost of Delay ÷ Job Size

Cost of Delay — стоимость задержки. Это оценка потерь или упущенной ценности при откладывании работы. Её можно выразить через сумму относительных факторов:

• Пользовательская или бизнес-ценность — какой результат даст выполнение задачи.
• Критичность по времени — насколько ценность зависит от срока и что изменится при задержке.
• Снижение риска или открытие возможностей — какие риски уменьшит работа или какие последующие инициативы сделает возможными.

Job Size — размер работы. Относительная оценка объёма задачи. В знаменателе должно быть положительное значение. Небольшая работа при одинаковой стоимости задержки получает больший балл, поскольку позволяет раньше получить результат.

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

Для задачи «Добавить SSO» бизнес-ценность оценили в 9, критичность по времени — в 8, снижение риска и открытие возможностей — в 7. Cost of Delay составляет 9 + 8 + 7 = 24. При размере работы 5 балл равен 24 ÷ 5 = 4.8.

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

Один бэклог — три разных результата

Возьмём три задачи: «Упростить первый запуск», «Добавить экспорт CSV» и «Добавить SSO». Это учебный пример с условными оценками. Для каждой модели используем свои факторы и согласованные шкалы.

Ранжирование по RICE

Для первого запуска расчёт уже разобран выше. Для экспорта CSV берём охват 600, влияние 1.5, уверенность 90% и трудозатраты 1.8: (600 × 1.5 × 0.9) ÷ 1.8 = 450. Для SSO: (300 × 3 × 0.7) ÷ 4 = 157.5. Охват везде измеряется за один квартал, трудозатраты — в человеко-неделях.

1. Упростить первый запуск
2. Добавить экспорт CSV
3. Добавить SSO

Ранжирование по ICE

На шкалах от 1 до 10 первый запуск получает 8 × 8 × 5 = 320, экспорт CSV — 9 × 9 × 6 = 486, SSO — 9 × 7 × 4 = 252. В этой оценке экспорт сочетает высокое влияние и уверенность с большей простотой реализации.

1. Добавить экспорт CSV
2. Упростить первый запуск
3. Добавить SSO

Ранжирование по WSJF

Для первого запуска Cost of Delay равен 8 + 5 + 8 = 21, размер — 5: 21 ÷ 5 = 4.2. Для экспорта CSV: (8 + 7 + 7) ÷ 4 = 5.5. Для SSO: (9 + 8 + 7) ÷ 5 = 4.8. Размер здесь оценивается относительно других работ, а не в единицах Effort из RICE.

1. Добавить экспорт CSV
2. Добавить SSO
3. Упростить первый запуск

Разные модели могут ранжировать один бэклог по-разному, потому что в них заложены разные предположения о важном. В RICE большой охват поднимает первый запуск. ICE выделяет экспорт через влияние, уверенность и простоту. В WSJF стоимость задержки помогает SSO подняться выше первого запуска.

Сравнивайте баллы только внутри выбранной модели и общих правил оценки. Число 533.3 по RICE не означает, что задача ценнее результата 486 по ICE или 5.5 по WSJF: у этих чисел разные основания и масштабы. Расхождение списков — повод обсудить критерии, а не усреднять несопоставимые баллы.

RICE vs ICE vs WSJF

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

Если охват неизвестен, его оценка для RICE может потребовать дополнительных исследований. Если главная проблема — последствия задержки, стоит подробнее разбирать Cost of Delay. Если нужно быстро сузить большой список идей, ICE помогает начать обсуждение. Ни один из методов не является универсальным победителем.

Приоритизация бэклога

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

1. Подготовьте сравнимые задачи: опишите ожидаемый результат и договоритесь об уровне детализации.
2. Выберите модель, цель, шкалы и единицы измерения. Заполните критерии, отмечая, какие оценки пока основаны на предположениях.
3. Рассчитайте баллы и отсортируйте список. Проверьте верхние позиции и задачи с неожиданными результатами.
4. Учтите зависимости, дедлайны, обязательные работы, технические ограничения и стратегические договорённости.
5. Примите решение о составе ближайших работ. Вернитесь к оценкам, когда появятся новые данные или изменятся условия.

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

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

Когда RICE, ICE и WSJF не подходят

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

Команда может определить собственные метрики, шкалы и арифметическую формулу. Условный пример: ((Ценность + Срочность + Снижение риска) × Уверенность) ÷ Трудозатраты. Это пример устройства модели, а не готовая рекомендация. Суммируемые показатели нужно привести к согласованным шкалам, иначе один из них случайно начнёт доминировать.

При настройке определите направление каждой метрики. «Риск выполнения» может снижать привлекательность задачи, а «снижение риска после выполнения» — повышать её. Выручку в рублях нельзя бездумно складывать с оценкой стратегической ценности от 1 до 5. Также проверьте, не учитывают ли два критерия один и тот же эффект дважды.

Проверьте формулу на нескольких знакомых задачах и обсудите полученный порядок. Если приходится постоянно объяснять, почему список неудобен, пересмотрите критерии и веса. После изменения шкал старые оценки могут потребовать пересмотра. Собственная модель полезна, когда её правила понятны участникам и соответствуют реальному решению.

В «Доске приоритетов» можно редактировать готовую модель и создать свою модель для очереди. Экран ниже показывает настройку метрик; порядок действий описан в документации по моделям и формулам.

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

Как организовать приоритизацию в Яндекс Трекере

Скоринг можно собрать в самом Яндекс Трекере с помощью полей и вычисляемых значений. Для RICE или собственной формулы не обязательно устанавливать «Доску приоритетов»: штатная настройка тоже позволяет хранить критерии в задачах и рассчитывать результат.

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

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

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

Как это работает в «Доске приоритетов»

«Доска приоритетов» — рабочее пространство для реализации выбранного подхода прямо внутри Яндекс Трекера. В плагине есть готовые модели RICE, ICE и WSJF, редактирование моделей, собственные метрики и конструктор арифметической формулы. Можно начать со стандартных факторов, а затем адаптировать модель под процесс команды.

Таблица, балл и позиция

Таблица приоритетов показывает задачи и метрики активной модели. После заполнения всех необходимых метрик рассчитывается Балл. Позиция показывает место задачи среди оценённых задач текущего представления. Сортировка по позиции помогает просмотреть полученный порядок; она включается нажатием на заголовок «Позиция».

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

Сохранённые представления и матрица

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

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

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

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

Попробовать «Доску приоритетов» →

Частые вопросы

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

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

Что выбрать — RICE, ICE или WSJF?

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

Можно ли использовать RICE для приоритизации бэклога?

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

Нужно ли всегда брать задачу с максимальным баллом первой?

Нет. Балл помогает сравнивать задачи по выбранным критериям. Зависимости, обязательства, риски и технические ограничения могут потребовать другого порядка.

Как использовать RICE и другие модели в Яндекс Трекере?

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