Приоритизация бэклога по ICE и RICE: сравниваем фреймворки

Привет! Эта страница случайно хорошо проиндексировалась, это не часть нашей стратегии. Мы хороший аусторс, умеем быстро и дешево запускать цифровые продукты на нашей платформе для low-code разработки Oberton, собирать команды под ваши задачи. Пишите ;)

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

Зачем приоритизировать бэклог

Приоритизировать бэклог — значит определить, в каком порядке нужно выполнять задачи или разрабатывать фичи из «списка ожидания». 

При грамотной приоритизации:

1. стейкхолдеры, менеджеры и продакшн-команда всегда знают, что происходит с продуктом и на какой он стадии разработки — это отражают в roadmap проекта;
2. быстрее проходят релизы и обновления за счёт грамотно планирования — какие-то фичи можно разрабатывать параллельно;
3. команда разрабатывает только важную для бизнеса и пользователей функциональность. То, что было придумано «для красоты» и «на потом» изживает себя и умирает в бэклоге;
4. снижаются риски перегрузки бэклога, недостатка ресурсов, конфликта интересов и потери фокуса команд проекта.

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

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

В этой статье:

• сравним, чем отличаются ICE и RICE Scroring;
• разберём на примерах, как ими пользоваться;
• разберём их преимущества и недостатки.

Фреймворк ICE 

ICE — это фреймворк приоритизации бэклога, который использует три переменные для оценки приоритета фичи: Impact (влияние), Confidence (уверенность) и Ease (трудозатраты). 

Формула выглядит так:

Impact (Влияние) — это оценка того, насколько сильно задача или фича повлияет на пользователей или бизнес.

Impact можно оценить разными способами:

1. По количеству пользователей, которых затронет изменение;
2. По текущему уровню удовлетворенности этих пользователей;
3. По увеличению доходов или снижению издержек после релиза фичи;
4. По тому, насколько фича решит текущие бизнес-задачи компании. Например, поможет привлечь новых пользователей, удержать старых, добавит ценности продукту и отстроит его от конкурентов, увеличит конверсию из пробного периода в покупку и так далее.

Impact оценивают по шкале от 1 до 10, где 1 — минимальное влияние, а 10 — максимальное. При этом под 1-10 вы можете подразумевать всё, что угодно — нет чётких критериев ранжирования.

Confidence (Уверенность) — это оценка вашей уверенности, насколько фича повлияет на продукт и как просто её будет реализовывать. В идеальном сценарии уверенность должна опираться на данные о продукте, потребителях и конкурентной среде. Чтобы не возникало кейсов, когда вы считаете, что новая фича повысит удовлетворённость пользователей, но ни разу не измеряли NPS до текущего момента. 

Confidence также оценивается по шкале от 1 до 10, где 1 — низкая уверенность, а 10 — высокая .

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

Как вы могли догадаться, Ease также оценивается по шкале от 1 до 10, где 1 — очень сложно, а 10 — очень легко .

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

Допустим, вы хотите приоритизировать три фичи для вашего продукта: A, B и C. Вы оцениваете каждую фичу по трём переменным: Impact, Confidence и Ease. Вот ваши оценки:

Вы подставляете их в формулу и получаете результаты:

Согласно ICE фреймворку, фича B имеет наивысший приоритет, A — средний, C — наименьший.

Преимущество

ICE фреймворк легко понять и применить. Он не требует много данных или сложных расчётов.

Недостатки

ICE фреймворк основан на субъективных оценках переменных, которые могут быть неточными, непоследовательными или смещёнными. Он не дает чётких критериев для измерения: чем отличается уверенность с оценкой 4 от уверенности с оценкой 6? Это может приводить к разногласиям или непониманию внутри команды, приоритизирующей бэклог. Более того — одна и та же фича может оцениваться по-разному одним и тем же лицом в разное время.

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

Фреймворк RICE

RICE — это фреймворк приоритизации бэклога, который использует четыре переменные для оценки приоритета фичи: Reach (охват), Impact (влияние), Confidence (уверенность) и Effort (затраты).

Формула по RICE выглядит так:

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

Пример:

В среднем приложение скачивают 7000 человек в месяц, 70% регистрируются и проходят онбординг. Если мы поменяем флоу онбординга, это затронет 4900 пользователей.

Impact (Влияние) — как и в предыдущем фреймворке, это оценка, насколько фича повлияет на продукт и пользователей, но здесь другая модель измерения.

Компания Inrecom разработала пятиуровневую шкалу для оценки влияния: 3 — для массового влияния, 2  — для высокого, 1 — для среднего, 0,5 — для низкого и, наконец, 0,25 — для минимального.

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

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

В RICE Confidence оценивают в процентах по шкале от 10% до 100%, где 10% — низкая уверенность, а 100% — высокая.

Например, у вас есть есть данные по охвату и трудозатратам, но вы не уверены насчёт влияния фичи на продукт, проект получает коэффициент уверенности в ~80%.

Effort (Затраты) — это оценка ресурсов команды разработки для реализации фичи в часах работы.

Пример

Допустим, вы хотите приоритизировать те же три фичи для вашего продукта: A, B и C. Вы оцениваете каждую фичу по четырем переменным: Reach, Impact, Confidence и Effort. Вот ваши оценки:

Вы подставляете свои оценки в формулу приоритета по RICE и получаете следующие результаты:

Согласно RICE фреймворку, фича A имеет наивысший приоритет, фича B — средний, а фича C — наименьший.

Преимущество

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

Недостатки

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

Итого

1) ICE фреймворк подходит для кейсов, когда:

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

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

2) RICE фреймворк подходит для кейсов, когда:

У вас больше данных о продукте, вы можете их собрать и проанализировать.
Вы хотите использовать более объективные критерии для измерения параметров.

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