Что не так с фреймворком RICE или как мы придумывали собственную методологию приоритезации Roadmap

Фреймворк приоритезации RICE является, пожалуй, самым популярным. Именно на примере него знакомят с приоритезацией на всех курсах по менеджменту продукта. Именно он наиболее часто встречается в требованиях к кандидатам, причем его можно встретить в описаниях вакансий как на Junior позицию, так и на Senior. Не ужели этот фреймворк так хорош и универсален? Вовсе нет.

Привет. Меня зовут Олег, я CPO в сервисе сквозной аналитики CallTracking.ru, автор телеграм-канала "Душный продакт", в котором я рассказываю про различные кейсы из профессиональной жизни и делюсь опытом.

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

Reach = охват. Охват кого? Всех пользователей или части? Учитывать когорты? Учитывать персоны? Учитывать JTBD? А сегменты по доходу с клиентов, ведь правило Парето никто не отменял? Если тут не конкретизировать, то можно поставить более высокую оценку для задачи, которая охватывает больше пользователей, но не самых перспективных.

Impact = влияние. Влияние на что? На удержание? На активацию? На какую-то конкретную метрику? Или общее на весь продукт, что вообще невозможно определить?

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

А еще RICE совершенно не подходит для приоритезации внутренних задач, но это тема для отдельного разговора.

НО. Данный фреймворк классно подходит для понимания процесса приоритезации. Его можно взять за основу и адаптировать под себя. Что мы и сделали, придумав методологию RARE.

Все же заметили, что очень модно придумывать что-то и давать аббревиатурные названия? ICE, RICE, MoSCoW, HEART, AARRR etc. Напоминает мне время, когда я управлял логистикой в одной иностранной производственной компании. Там было столь много таких сокращений, что даже был официальный документ с расшифровками. Все эти FMEA, LIFO, APQP, PPAP (и нет, это вовсе не Pen-Pineapple-Apple-Pen)...

Так уж сложилось, что нас не устраивал какой-либо из известных фреймворков для приоритезации нашего Roadmap. Несмотря на то, что CallTracking.ru работает уже больше 10 лет, нам необходима гибкость в планировании чуть ли не на уровне стратапов. Нам нужно иметь возможность очень быстро менять приоритеты в зависимости от ситуации. И именно поэтому была придумана своя методология.

Если коротко, то мы совместили фреймворки RICE и AARRR. Вот как это было сделано:

1. Были внедрены строгие правила для определения Reach с учетом действующих и потенциальных пользователей;

2. Вместо одного единого Impact оцениваем влияние каждой задачи на каждую букву AARRR;

3. Мы напрочь выкинули Confidence;

4. Для Effort учитываем суммарные трудозатраты - исследования, проектирование, разработка;

5. Везде применяется для оценки ряд 1-10.

Получается, что у каждой задачи будет 7 оценок. Финальный скор считается по аналогии с RICE, то есть REACH x IMPACT / EFFORT. Однако использование собственного решения позволяет нам выбирать задачи, которые

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

Например, когда мы запускали полностью обновленный кабинет, нам нужно сделать максимальный акцент на привлечение пользователей, то есть фокус на Acquisition. В дальнейшем нужно было смещать фокус на Retention. Сейчас мы добавили фокус на Referral, так как заметный поток новых клиентов приводят наши агенты.

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

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

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

На мой взгляд, самым эффективным способом оценки трудозатрат на реализацию задач является Planning Poker и его аналоги. И самая главная его часть связана не с тем, что все выставляют свои оценки, а именно с тем, что те, кто принимает участие в оценке должны в итоге прийти к общему значению. Причина ясна – все немного по разному видят и процесс и результат работы. Кто-то сразу замечает какие-то подводные камни, кто-то знает простой способ решения и так далее. И в этом споре реально рождается истина.

Так почему же не использовать подобный подход для других оценок? Возьмем для примера параметр Impact фреймворка RICE (а в нашем случае любой параметр AARRR). Предположим, что он измеряется по шкале от 1 до 10. Какими бы точными не были предварительные расчеты, оценка все равно будет включать субъективность. Даже просто потому, что вам может какая-то идея очень нравится или наоборот.

И вот тут нам может помочь принцип, который используется в Planning Poker – собрать оценки квалифицированных людей, выявить расхождения и их причины. После такого обсуждения можно провести еще одну итерацию оценок.

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

Почему от среднего? Потому что если все поставили приблизительно одинаковые оценки, то всё нормально. Разброс в 1-2 балла не является критичным и говорит о том, что вы одинаково понимаете влияние и ценность задачи. А вот если кто-то поставил оценку 2, а кто-то 8, то это уже точно говорит о том, что что-то не так. Возможно требуется дополнительное исследование, а может просто достаточно подробнее объяснить суть задачи.

Я никого не призываю использовать именно фреймворк, который мы назвали RARE. Да и уникального в нем ничего нет. Цель данной статьи показать пример, как можно совмещать знакомые решения для достижения лучшего результата.

И я больше скажу. Универсального метода приоритезации не существует. Даже разные команды внутри одной компании могут использовать разные подходы. Всегда нужно подбирать что-то оптимальное для конкретной ситуации.

Надеюсь, что эта душнота кому-то да пригодится.