Чем плох способ приоритизации по rice

RICE: Простая приоритезация для Product-менеджеров

Перевод статьи подготовлен специально для студентов курса «Product Manager IT-проектов»

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

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

Приоритезация – это сложно

Почему так сложно определить приоритеты в дорожной карте продукта? Давайте я перечислю причины:

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

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

Оценка RICE: простой инструмент для расстановки приоритетов

Именно в этот момент в игру вступает балльная система. Хорошая структура приоритезации поможет вам оценить каждую идею и объединить их в строгую последовательность для выполнения.

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

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

RICE: 4 фактора оценки приоритета

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

Reach

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

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

• Проект 1: 500 клиентов достигают определенной точки в воронке регистрации каждый месяц, и 30% выбирают определенный вариант. Охват составляет 500 х 30% х 3 = 450 клиентов в квартал.
• Проект 2: Каждый клиент, который использует конкретную функцию каждый квартал будет видеть внесенное изменение. Охват составит 2000 клиентов в квартал.
• Проект 3: Определенное изменение один раз повлияет на 800 существующих клиентов и не будет иметь постоянного эффекта. Охват за квартал составит 800 клиентов.

Impact

Чтобы сосредоточиться на проектах, которые двигают вас к вашей цели, оцените impact (влияние) на каждого конкретного человека. Моя команда понимает это так: «Насколько этот проект увеличит конверсию, когда клиент с ним столкнется?». Ваша команда может интерпретировать это иначе, вроде «как увеличить применение» или «максимизировать удовольствие от использования».

Влияние трудно измерить. Поэтому я буду выбирать из шкалы множественного выбора: 3 – «массовое влияние», 2 – «высокое», 1 – «среднее», 0.5 – «низкое» и, наконец, 0.25 – «минимальное». Эти показатели будут умножаться на конечный результат, чтобы масштабировать его в большую или меньшую сторону.

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

• Проект 1: На каждого клиента, который увидит этот проект, он окажет большое влияние. Балл влияния – 3.
• Проект 2: Этот проект будет иметь меньшее влияние на каждого клиента. Оценка влияния – 1.
• Проект 3: Этот проект окажет среднее влияние. Оценка влияния – 2.

Confidence

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

Уверенность – это процентное соотношение. Я использую шкалу множественного выбора, чтобы не парализовывать решения. 100% — «высокая уверенность», 80% — «средняя», 50% — «низкая». Все, что ниже этих показателей – просто авантюра. Будьте честны с собой: насколько вы действительно верите в свою оценку?

• Проект 1: У нас есть количественные показатели охвата, пользовательские исследования для уверенности в показателе влияния и оценка требуемых усилий для реализации. Такой проект получает 100% уверенности.
• Проект 2: У меня есть данные для оценки охвата и требуемых усилий, но в факторе влияния я не уверен. Такой проект получает 80% уверенности.
• Проект 3: Охват и влияние могут оказаться ниже, чем предполагалось, а затраты усилий могут оказаться выше. Такой проект получит 50% уверенности.

Effort

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

Усилия (effort) оцениваются как количество «человеко-месяцев» — то есть работа, которую один член команды может выполнить за месяц. Здесь есть много неизвестных переменных, поэтому я ставлю грубые оценки, придерживаясь целых чисел (или значения 0.5 для половины месяца). В отличие от других положительных факторов, большой показатель усилий – это плохо, поэтому он будет делителем для общего воздействия.

• Проект 1: На этот проект потребуется неделя планирования, 1-2 недели на проектирование, 2-4 недели на разработку. Я поставлю оценку в 2 человеко-месяца.
• Проект 2: На этот проект понадобится несколько недель планирования, большое количество времени на проектирование, и как минимум два месяца на разработку. Я дам этому проекту оценку в 4 человеко-месяца.
• Проект 3: Проект потребует недели на планирование, никаких затрат на создание архитектуры и несколько недель на разработку. Я поставлю оценку в 1 человеко-месяц.

Как выставляется итоговый балл по методологии RICE?

Чтобы быстро просуммировать все четыре фактора:

Reach: На какое количество человек это повлияет? (Оценивается за определенный период времени)

Impact: Насколько сильно это повлияет на каждого человека? (Очень сильно – 3х, сильно – 2х, средне – 1х, мало – 0.5х, минимально – 0.25х )

Confidence: Насколько вы уверены в своих оценках? (Очень уверен – 100%, средне – 80%, не особо уверен – 50%.)

Effort: Сколько «человеко-месяцев» это займет? (Используйте целые числа и минимум полмесяца – не лезьте в дебри при оценке.)

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

(Reach x Impact x Confidence)/Effort=RICE Score

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

Можете спокойно использовать эту таблицу для своих нужд или скачать ее в .xls .

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

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

Как эффективно использовать методологию RICE

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

Иногда так может случиться, что вам нужно работать над задачами проекта не в строго определенном порядке. И это нормально! С балльной системой вы сможете четко определить, в какой момент нужно прибегнуть к компромиссу.

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

Источник

RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта

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

Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.

Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.

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

В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.

Метод RICE Score

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

Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.

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

• Reach — это охват
• Impact — влияние
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
• Effort — трудозатраты

Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.

Reach (Охват)

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

Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.

Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.

Impact (Влияние)

Влияние показывает какой вклад приносит эта фича продукту.

Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:

1. Улучшают trial-to-paid конверсию (metric movers)

Исходя из ваших текущих целей у вас будут свои метрики.

2. Помогают привлечь новых пользователей

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

Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.

3. Помогают сохранить текущих пользователей

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

4. Добавляют ценности продукту и отстраивают нас от конкурентов

На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.

К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.

Confidence (Уверенность в оценке)

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

Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.

Effort (Трудозатраты)

Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.

Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.

Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.

Метод оценки ICE

Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.

Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.

ICE Scoring: Как это работает?

Рассчитайте оценку для каждой фичи или идеи, согласно формуле:

• Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
• Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
• Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.

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

В качестве примера, применим это к фиче «Виджеты для Dashboard»:

• Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?
• Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?
• Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?

Недостатки ICE

ICE Scoring иногда подвергается критике за его субъективность:

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

Как использовать RICE и ICE Scoring?

Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.

Во-первых, у вас должны уже быть собранными необходимые фичи и идеи продукта на вашей Kanban-доске. Используя Hygger, вы можете структурировать их с помощью горизонтальных колонок Swimlanes, а также применяя Labels. Вы также можете настроить процесс работы с фичами с помощью Columns. К примеру, можно создать следующий рабочий процесс:

• Backlog — здесь вы собираете все идеи и фичи
• Next Up — сюда вы перемещаете фичи, над которыми хотите работать в ближайшее время
• Specification — тут вы собираете требования и пишите спеки на фичи
• Development — фичи находятся в разработке, и здесь вы можете отслеживать их текущий статус
• Done — фичи были успешно залиты на прод и теперь доступны вашим пользователям.

В меню Hygger вы найдете варианты моделей для оценки и приоритизации фичей, в том числе, RICE и ICE:

Оценка в Hygger по RICE

Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.

Все фичи также можно увидеть в таблице:

Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.

Push работает так:

• создается задача по реализации фичи на доске разработке — на Канбан или Спринт доске внутри Hygger (да-да, Hygger поддерживает Kanban и Scrum). В будущем мы добавим интеграцию с Jira и с другими трэкерами задачи, так как прекрасно понимаем, что многие команды используют для разработки Jira и уйти с нее на что-то другое — анрил
• задача на бэклог-доске и задача на доске разработки линкуются между собой
• когда задача на доске разработке будет полностью выполнена, задача на бэклог-доске также будет перенесена в done-колонку.

Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.

Оценка в Hygger по ICE

Такой же алгоритм и в случае с выбором модели оценки ICE.

Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.

Удобная таблица также визуализирует все ваши фичи:

Другие способы приоритизации в Hygger

Приоритизация Value & Effort (aka Lean Prioritization)

Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и

• Value — это то, какой вклад приносит конкретная фича.
• Effort — это усилия, необходимые для реализации фичи.

Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).

В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):

• Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
• Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
• Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
• Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.

Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.

Источник