RICE-приоритизация: формула, пример расчёта и ошибки

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

Какова формула RICE-приоритизации?

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

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

Как оценивать каждый фактор RICE?

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

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

Как выглядит пример RICE-оценки?

Возьмём четыре запроса из отслеживаемого бэклога, оценённые на один квартал.

Разберём первую строку: 400 × 1 × 0,8 ÷ 1 = 320. Тёмная тема охватывает втрое больше людей, но каждый из них выигрывает мало, поэтому она оказывается чуть ниже экспорта. У интеграции со Slack хорошая оценка влияния, которую уверенность режет вдвое, и это говорит, что следующий шаг — исследование, а не разработка.

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

Какие ошибки в RICE встречаются чаще всего?

Первая — ложная точность. Охват 1 247 и влияние 1,3 выглядят строго и несут не больше информации, чем 1 200 и 1. Округляйте решительно.

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

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

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

Когда стоит использовать что-то кроме RICE?

Когда нет данных об охвате, используйте ICE (impact, confidence, ease): он отбрасывает охват и заменяет усилие оценкой лёгкости, и придётся смириться с тем, что он грубее. Когда вопрос в том, какого рода ценность несёт функция, а не в том, сколько её, модель Кано классифицирует запросы на обязательные, линейные и восхищающие функции, и обе модели хорошо сочетаются. Когда решение касается порядка и сроков, а не ранжирования, лучше подходит формат roadmap, о котором рассказывает статья как составить product roadmap.

Как сохранять честность оценок RICE со временем?

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

FAQ

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

Чем RICE отличается от ICE? ICE перемножает влияние, уверенность и лёгкость и не учитывает охват. Его быстрее заполнить, но он менее точен, когда функции затрагивают сильно разное число пользователей, а именно для такого случая создавался RICE.

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

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

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Документация для разработчиков, Сравнение инструментов changelog