Разделяй и управляй: как работает метод приоритезации RICE

Кто пишет: Елена Горопека, в IT-индустрии 10 лет; начинала с тестирования ПО, затем перешла в бизнес-анализ и продукт-менеджмент. «О бизнес-анализе и не только» — о бизнес-анализе в IT, управлении людьми, продуктами и проектами.  

RICE можно использовать для оценки проектов, задач, продуктов. Суть следующая — нужно оценить идею по четырем факторам.

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

Какие определения RICE использую я?

Reach — на какой процент пользователей решение повлияет значимо? 

Часто можно увидеть, что reach оценивается как процент пользователей, которые «увидят» решение. То есть если у нас есть воронка из пяти шагов, тогда решения на первом шаге воронки имеют reach 100%, а на последнем — условно 20%.

Мне такой подход кажется не совсем правильным по нескольким причинам:

• Не всем пользователям нужно решение. Например, вы работаете над сервисом доставки продуктов с рецептами (типо rebox.by). Вы знаете, что только 30% вашей аудитории — вегетарианцы. Соответственно, даже если вы на первой странице воронки регистрации добавите информацию про доступность вегетарианского меню, reach не может быть 100%, потому что большинству пользователей не нужно вегетарианское меню.
• Каждая потребность в разной степени удовлетворена. Например, вы знаете, что для ваших пользователей очень важно разнообразие и большой выбор рецептов. Но вы уже говорите и подчеркиваете это пятью разными способами в разных местах воронки регистрации. Думаю, добавление шестого способа подчеркнуть разнообразие вашего меню повлияет на небольшой процент пользователей (потому вы уже громко и ясно об этом говорите). 

Impact — какой положительный эффект мы получим, если внедрим решение? 

Очень часто команды не чувствуют разницу между reach и impact. А она важна.

Возьмём пример с вегетарианским меню — охват только 30%, но зато потребность может настолько болеть, что impact будет 9 из 10. При этом у вас есть потребность, бОльшая по охвату (скажем — 70%), но вы понимаете, что она не настолько «болит», соответветственно оцениваете impact на 2 из 10. Получается, вегетарианское меню выигрывает (если судить по этим двум критериям).

Confidence — насколько мы уверены в своих оценках reach и impact?

Как «объективно» оценивать уверенность? Я использую только три оценки (50, 80 и 100) по следующей схеме: 

1. 100 — есть много данных (и количественных, и качественных), подтверждающих оценку; успешные эксперименты в прошлом; common sense или стандартные лайфаки (условно если мы снизим цену, или предложим большую скидку, то точно положительно повлияем на процент регистраций).
2. 80 — данных не так много; данные только косвенные; только качественные или только количественные.
3. 50 — по сути нет никаких данных, все оценки основаны исключительно на допущениях.

Efforts — насколько сложно\долго реализовать решение. 

И ещё несколько советов:

1. Обязательно записывайте данные и допущения, которые вы делали при оценке

Ценность приоритезации не только и не столько в конечном результате (делаем такие-то фичи в таком порядке), а в процессе обсуждения и синхронизации команды: когда все опираются на одни и те же данные, и соответственно понимают причины выбора такого-то направления.

Поэтому при приоритезации я всегда записываю данные и допущения, сделанные при оценке. Тогда команде проще обсуждать приоритеты, потому что легче объективно челленджить друг друга: «а помнишь, мы проводили такой-то тест, и он был негативный — поэтому я снизил impact этой фичи», «последние исследования показывают, что пользователи намного чаще стали жаловаться на Х, поэтому мы должны увеличить оценку Reach для такой фичи».

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

2. Помните о ловушке «предвзятость подтверждения»

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

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

Я борюсь с этим следующим образом: 

1. Когда делаю первый раунд оценки, концентрируюсь последовательно на каждой фиче. Ищу данные для объективной оценки reach, impact, confidence, efforts, записываю все сделанные допущения. Я даже не считаю итоговую оценку, чтобы не было соблазна сравнивать с другими фичами и подгонять цифры. 
2. Только после этого я считаю итоговую оценку и сравниваю результаты. И если мне кажется, что какая-то фича выбивается — я ещё раз проверяю данные и допущения. Либо я что-то не учла (тогда что?), либо я должна принять объективные цифры. Иначе зачем тогда всё это было затевать?
3. Привлекаю ещё кого-то к приоритезации. Каждый делает оценку отдельно, и дальше сравниваем и обсуждаем результаты. 

Как интерпретировать данные 

Понятно, что фичи с высоким reach / impact и confidence и низким effort — главные претенденты на попадание в ближайшие планы.

Но не забывайте о идеях с высоким reach / impact, но низким confidence. Эти идеи — главные претенденты на дальнейшее исследование. Каких данных не хватает, чтобы повысить confidence? Как дешево можно протестировать идеи? То есть ваша задача либо убедиться, что у этих идей большой потенциал — и тогда включать в планы по разработке; либо убедиться в обратном — и тогда откорректировать оценку (снизить reach/impact).

Также бывает, что reach/impact/confidence высокие, но effort тоже высокий. Здесь нужно работать с командой разработки. Как можно реализовать эти фичи проще и быстрее? Точно нет никакого элегантного решения, которое займет недели, а не месяцы?

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

Мнение авторов блогов не обязательно отражает позицию редакции. 

Вы тоже можете начать вести свой блог на dev.by — вот инструкция. Или присылайте темы, идеи и вопросы на blog@dev.by

Что ещё почитать?

• Как задавать тупые вопросы и не попасть впросак?
• Айтишник в деревне. Часть 3. Как я выживаю в деревне в мороз и готовлюсь к Новому году
• Как и зачем определять свои жизненные ценности? Советы карьерного коуча из Google

Редакции нужна ваша помощь прямо сейчас. 

Нам можно помочь через Patreon. Выберите ежемесячный уровень поддержки: 10, 20, 30, 100 или 500 долларов — или внесите любую сумму.

А ещё мы принимаем криптовалюту. 

Bitcoin
bc1qae22u3sg8es6j22pg4mmyrdvvym0vxjyesxhhw

Etherium
0×831a6641721E70af32dDa262F4110eB704af8c05

Tether USD (USDT) on ETH Network
0×831a6641721E70af32dDa262F4110eB704af8c05

Zcash
t1R5UM9VMR1hJvJqTJ9w5bAmHxrDLJ9Nxmh

Дзякуй, што вы з намi.