Метод приоритизации задач RICE был впервые предложен компанией Intercom. По сути, это скоринговая модель, которая позволяет учесть несколько факторов и свести эту оценку к общему баллу.
- Reach — охват (измеряется в количестве пользователей, которых затронет новая функция продукта)
- Impact — влияние (оказывает огромное влияние на пользователей — 3 единицы; высокое — 2 единицы; среднее — 1 единица; низкое — 0,5 единицы; минимальное — 0,25 единицы)
- Effort — трудозатраты (авторы предлагают оценивать в человеко-месяцах. Другим словами, сколько сотрудников должны работать полный месяц, чтобы эта функция появилась в продукте).
- Confidence — уверенность в правильности оценки охвата, влияния и трудозатрат
Нет смысла подробно пересказывать саму технологию. Вот отличная статья в блоге Intercom. Зато, стоит поговорить о том, как это безобразие заставить работать, и какие у этой модели недостатки.
Мы забыли о пользователях. Оценка по модели RICE показывает субъективное мнение команды, но ничего не говорит о предпочтениях тех, для кого создается продукт. Да, вы и ваши коллеги постоянно думаете о пользователях, проводите интервью, смотрите в метрики. И все же. Вас это не смущает?
Пусть все мучаются. Чтобы субъективных оценок было меньше, попросите всех членов команды выставить свои оценки, а потом посчитайте среднее. Именно среднеарифметические значения используйте при расчете итогового рейтинга. Субъективизма будет чуть-чуть меньше. Надо же как-то доказать свою беспристрастность))
И тут началось. Вы собрали оценки со всех членов команды, посчитали итоговый балл, а позже, кто бы мог подумать, выяснили, что в команде работают люди с разным мировоззрением и восприятием. О чем это? О том, что прежде чем кидаться с головой в простейшую математику, надо коллегам объяснить за что и какие оценки выставлять. Вот, что такое «огромное влияние на пользователе», которое дает 3 балла? Какое это состояние? Можно примеры? Нет, нельзя, примеры должны быть вашими. Правила выставления оценок надо определить и донести заранее.
А теперь еще раз. Кстати, может и не раз. Окей, вы объяснили команде принципы присвоения баллов. Вам даже показалось, что все поняли. Но! Когда собрали результаты, выяснилось, что из 10 членов команды трое оценили «влияние» на 3 балла, четверых выставил за тот же параметр по единице, а еще у троих — 0,25. Ну, и что с этим делать? Правильно, обсуждать функцию заново и переоценивать. Либо же признать, что кто-то неадекватен)) Случается. Возможно, что неадекватны будете вы после 3ех — 4ех таких подходов к снаряду.
Intercom молодцы, никто не спорит. А может зря? Модель получила широкое распространение. Уже слышатся лозунги — большинство не может ошибаться. Конечно, звучит здраво, виден и понятен результат, много степеней свободы. Но, почему именно такой набор параметров в модели? Например, есть метод ICE (Impact, Confidence, Ease). Только там каждый параметр оценивается по шкале от 1 до 10, и баллы просто перемножаются. И какой подход правильны? Ответ прост. Правильного варианта нет. Вы можете придумать свою собственную модель с любым набором параметров. Можно даже реализовать свою математику для итоговой оценки. Ну, не знаю, возводить в степень, извлекать корень. Так будет выглядеть заумнее. Кстати, наверно так и рассуждал создатели сервиса Hygger, которые дали пользователям возможность приоритизировать задачи руководствуясь собственными критериями. Так вот. Будьте смелее, модифицируйте общепринятые модели скоринга под свой продукт. Ну, хоть добавьте фактор влияния на рост зарплаты и бонусов продакт менеджера ))
