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

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

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

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

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

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

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

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

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

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

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

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

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

Reach

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

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

Impact

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

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

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

Confidence

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

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

Effort

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

«Что делать в первую очередь»: приоритизация задач с помощью RICE

Создание продукта связано с реализацией проектов, тестированием идей и гипотез. Иногда их накапливается так много, что встает вопрос: за что браться в первую очередь? Определиться помогает приоритизация. Но как это сделать? Специалисты предлагают разные методы. В этой статье вы узнаете о простом методе приоритизации RICE.

На первый взгляд кажется, что расставить задачи по приоритетам — плевое дело, на которое уйдет минут 15. Но уже в процессе появляются сложности. Приоритизация растягивается на несколько часов и потом еще приходится команде аргументировать, почему корзину в приложении надо сделать быстрее, чем основной интерфейс. Из-за чего возникают эти трудности?

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

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

В-третьих, начинающие продакты и предприниматели часто не учитывают усилия на проекты, являющиеся частью других, более крупных.

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

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

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

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

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

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

Оценка идей по методике проводится по четырем факторам:

Из первых букв сложилась аббревиатура-название метода — RICE.

От предвзятого отношения к идеям позволяет избавиться определение охвата. Иными словами — на какое количество клиентов/пользователей повлияет изменение продукта.

Фактор измеряется количеством людей/событий за период времени. Причем субъективные оценки, взятые с потолка, не подойдут. Берите только реальные данные, привязанные к определенным метрикам продукта.

Вот несколько примеров:

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

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

Для количественного выражения влияния используют шкалу множественного выбора:

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

Вот несколько примеров:

Идеи бывают интересными и перспективными, но данных для подтверждения нет. Чтобы не впутаться в авантюру, определите уровень уверенности в оценках.

Уверенность указывают в процентах. 100% — высокая уверенность, 80% — средняя и 50% — низкая. Это стандартная шкала, применяемая большинством продактов. Все, что ниже 50% — иллюзия, которая в реальности не даст ожидаемых результатов. От таких идей отказывайтесь, не тратьте на них ни время, ни деньги.

Вот несколько примеров:

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

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

Вот несколько примеров:

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

Приоритеты определяются по формуле: (Reach x Impact x Confidence) / Effort. Рассчитаем итоговые показатели для трех проектов:

Обратите внимание, что «уверенность» в формулу записывается не в процентах, а в долях. Если в таблице 100%, тогда в расчете — 1.

Рассчитав итоговый показатель, мы узнали значимость проектов. Самый высокий показатель — 1560 — говорит о том, что проект 3 принесет больше пользы за время работы, поэтому его реализуем в первую очередь. Остальные — по убыванию.

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

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

Главное преимущество RICE по сравнению с другими методами приоритизации — скорость. Оценить несколько проектов и определить значимость можно в течение нескольких часов.

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

Источник

Приоритизация в Scrum по ICE. Опыт Авито

Привет! Меня зовут Илья, в Авито я разработчик и по совместительству скрам-мастер в B2B-команде, которая делает Автотеку.

Сегодня хотел бы рассказать о том, как мы с командой запускали процесс приоритизации задач, формировали процессы их оценки и переоценки. С какими трудностями нам пришлось столкнуться и какие профиты удалось приобрести. Надеюсь, статья будет полезна командам, бэклог которых содержит > 50 айтемов, а знания о том, что делать, есть только у product owner.

Введение в скрам

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

Scrum с английского переводится как «схватка», это название одного из элементов регби. Цель схватки — возобновление игры после незначительного нарушения или её остановки. Эти процессы заложены и в методологию командной работы Scrum. Команда сотрудников, которая работает по скраму, должна постоянно совершенствоваться, достигать поставленных целей, анализировать свой опыт и извлекать из этого опыта, каким бы он ни был, ценные уроки. Для содействия этому, методология предполагает ряд инструментов и встреч.

Рабочий процесс в скраме разделён на итерации, которые называются спринтами. Каждый спринт длится от 1 до 4 недель. В нашем случае это 2 недели.

Перед началом спринта мы собираемся на планирование, где набираем себе задачи. Это те задачи, которые должны быть выполнены в рамках будущей итерации. Главным артефактом спринта является цель. Цель — это то, на чём сфокусирована вся команда в процессе итерации. Если цель не выполнена, спринт считается проваленным. Кроме цели, итогом планирования является набор задач. Он называется sprint backlog.

Помимо планирования есть ежедневные короткие встречи — daily, где команда обсуждает процесс движения к цели. Один раз в спринт проводится встреча, которая называется product backlog refinement (PBR), где мы уточняем предстоящие задачи, производим оценку их сложности, декомпозируем большие задачи на те, которые можно сделать в рамках спринта.

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

В этой статье я описываю изменение рабочих процессов в промежутке между планированием и PBR.

Предпосылки к использованию приоритетов

Мы занимаемся развитием B2B-продукта, что подразумевает гетерогенность задач, большое количество A/B-тестов и проверок гипотез, а наша работа часто похожа на поиск и создание инновационных решений. Команда образовалась летом 2020 года, её участники уже работали по скраму и имели представления о таких процессах как ретроспективы, дейли, планирования и прочее. Это позволило быстро начать доносить продуктовую ценность до пользователей. После создания команды роль владельца продукта, дальше я буду называть его PO, выполнял tech lead. Вместе мы сформировали бэклог продукта, начали работать, и всё было хорошо.

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

Также появилась проблема с тем, что хвост бэклога редко рассматривался, то есть мы упускали из виду важные вещи. В итоге на очередной ретроспективе мы договорились провести обзор техник приоритизации и попробовать использовать какой-либо фреймворк для оценки задач. Мы надеялись, что это снизит когнитивную нагрузку от постоянного определения приоритетов на планировании и на product backlog refinement (PBR).

Нам хотелось понять:

Как определять приоритеты и делать это на основании данных экспериментов и A/B-тестов.

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

Как сразу обрабатывать фичареквесты и не допускать их гибели в бесконечных Слак-чатах.

Какие методологии оценки и инструменты помогут поддерживать бэклог в актуальном состоянии.

По итогам ретро стала понятна целевая картина:

В команде есть методология оценки задач.

Бэклог всегда находится в актуальном состоянии и отсортирован по приоритету.

Команда, когда это необходимо, может дать оценку приоритета новой задаче без PO.

Новые задачи не теряются в недрах бэклога, и им проставляется приоритет на общекомандных мероприятиях.

ICE, RICE или WHY’s?

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

Тем не менее, выбор нужно было сделать. Мы определили, что:

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

CustDev ещё не был поставлен на поток, поэтому оценить охват аудитории, на которую та или иная фича оказывала влияние, было достаточно сложно. Поэтому при выборе систем приоритизации мы исключали те, которые учитывают этот фактор.

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

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

ICE стоит на трёх столпах:

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

Уверенность (Confidence) показывает, насколько мы уверены в оценках влияния и лёгкости реализации.

Лёгкость реализации (Ease) — это оценка того, сколько усилий и ресурсов потребуется для реализации идеи.

При оценке задачи мы определяем значение каждого показателя, перемножаем их и получаем ICE score. Просто и, как показала практика, достаточно эффективно.

Процесс оценки задач

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

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

Оценка impact

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

Источник

12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие

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

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

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

Ниже — 12 наиболее распространенных методов, о которых мы расскажем:

Эта система оценки измеряет каждую фичу или инициативу по четырем параметрам: охват (reach), влияние (impact), достоверность (сonfidence) и усилия (effort).

Что означает каждый из параметров и как его можно оценить количественно:

Сколько пользователей затронет эта фича за определенный период?

Пример: Пользователей в квартал, транзакций в месяц.

Какое влияние эта фича окажет на пользователя?

Пример: Насколько эта фича повлияет на коэффициент конверсии?

Насколько мы можем быть уверены в своей оценке параметров reach и impact? Как много данных у нас есть, чтобы подтвердить свою оценку?

Сколько времени потребуется инвестировать в эту инициативу (продукт, дизайн, разработка)? Параметр оценивается в человекомесяцах.

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

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

Плюсы метода приоритизации RICE:

Минусы метода приоритизации RICE:

Если вы ищете метод быстрой приоритизации, модель ICE подойдет вам даже лучше, чем RICE.

Говоря словами Ануйя Адии, автора «Гроузхакинга для чайников»: воспринимайте ICE как MVP в мире приоритизации.

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

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

ICE это акроним из следующих слов:

Каждый из этих факторов оценивается по шкале от 1 до 10, а среднее арифметическое из трех параметров дает общую оценку по методу ICE.

Вы можете использовать этот шаблон, чтобы рассчитать оценку по ICE:

Один из минусов модели состоит в том, что разные люди могут оценивать одну и ту же инициативу совершенно по-разному. Модель ICE дает систему относительной приоритизации, а не точных подсчетов, основанных на данных.

Чтобы минимизировать неоднородность оценок, убедитесь, что верно определяете каждый параметр в системе ICE. Договоритесь, что то именно означает Impact 5, Confidence 7, Ease 3 и т. д. внутри вашей команды.

Плюсы метода приоритизации ICE:

Минусы метода приоритизации ICE:

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

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

Такие способы оценки как value vs. effort помогают продуктовым командам легко и быстро определить приоритеты.

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

Плюсы метода приоритизации «Ценность против усилия»:

Минусы метода приоритизации «Ценность против усилия»:

Модель Кано представляет собой систему координат, где на горизонтальной оси отражены потребности клиента, которые могут быть разделены на три пункта:

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

На горизонтальной оси слева размещаются потребности, которые вообще не удовлетворены, справа те, которые удовлетворены полностью.

Вертикальная ось отражает уровень удовлетворенности пользователя. Шкала функциональности показывает, насколько хорошо реализована фича, от «не реализована вообще» до «полностью реализована».

Как это выглядит в сборе:

Пример из ресторанного бизнеса:

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

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

Источник