Приоритизация по RICE на практике: пошаговое руководство для ежедневного использования

фасилитатор
Всем привет!

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

Автор статьи: Eric S Perkins
Научный редактор: Ольга Мигачева

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

Многие останавливаются на проверенном временем Фреймворке RICE. Тратят несколько недель, чтобы объяснить всем, что это такое, как это работает, и наконец начать процесс приоритизации всё более растущего списка задач, описания которых, вероятно, покрыты пылью и паутиной.

Но с чего начать?

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

Но ни один из ресурсов не описывает практику использования RICE в повседневной жизни.

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

Содержание:
1. С чего начать?
2. Готовьте войска
3. Подготовьтесь
4. Оценивайте и приоритизируйте
5. Сообщите свой список приоритетов
6. Как справляться с изменениями в приоритизации

С чего начать?

Если вы являетесь продакт-менеджером, есть 5 шагов, которые могут помочь вам эффективно работать по RICE.

  1. Готовьте войска
  2. Подготовьтесь
  3. Оценивайте и приоритизируйте
  4. Сообщите свой список приоритетов
  5. Работайте с изменениями в приоритизации

Готовьте войска

Подготовьте следующих людей: вашего Разработчика, Руководителя дизайна, Владельца успеха (директор, вице-президент) и заинтересованные стороны, которые захотят видеть успех.

Отправьте сообщение со списком пунктов (конкретных, не нужно писать поэму) всем в чате.

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

Пункт 2: Запланируйте официальный старт запуска приоритизации по RICE на день Х и время Y, и отправьте приглашение на более позднюю дату до конца рабочего дня (включите заинтересованные стороны и владельцев, упомянутых выше, как опциональные). Также следует обозначить, что это не единственная встреча, а первая из многих, пока приоритизация не будет "закончена".

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

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

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

  • Reach (Охват) = Количество клиентов, которых затронет этот проект в течение одного квартала (выраженное в целых числах).
  • Impact (Влияние) = Насколько этот проект увеличит конверсию, когда клиент встретится с ним? (Огромное - 3x, Высокое - 2x, Среднее - 1x, Низкое - 0,5x, Минимальное - 0,25x)
  • Confidence (Уверенность) = Насколько мы уверены в оптимистичных оценках для охвата, влияния и усилий? (Высокая - 100%, Средняя - 80%, Низкая - 50%, Маловероятно - 20% или менее)
  • Effort (Усилия) = Оцените общее количество времени, которое потребуется от всех членов вашей команды: продукта, дизайна и разработки. Оценивается в виде количества "человеко-месяцев" или работы, которую один член команды может выполнить за месяц (все, что менее месяца, должно быть представлено в виде "0,5").
** Совет — люди часто застревают на баллах сложности, и это ожидаемо. Для того, чтобы они точнее понимали суть оценки, объясните это так: балл сложности нужен не для того, чтобы определить срок выполнения задачи в 8 месяцев, а для того, чтобы мы могли оценить затраты и действия, необходимые для приоритизации".

Подготовьтесь

Отлично, вы отправили сообщение. Теперь между сообщением и встречей вам предстоит подготовка, потому что вы хотите максимизировать результаты этой встречи.
Красить дом — это 90% подготовки и 10% краски
так говорил мой отец
** Совет – существует разница между работой в вакууме и подготовкой к командной работе, так что будьте осторожны, не делайте слишком много предположений во время подготовки.

  1. Найдите элементы бэклога и поместите их в одну таблицу.
  2. Ваша таблица должна содержать несколько ключевых элементов –
  • Название проекта – с возможностью щелкнуть для получения дополнительной информации (например, в Google-таблицах или Excel, вы можете оставить в поле комментарий с дополнительной информацией - прим. ред.)
  • Колонки RICE – используйте предустановленные выпадающие списки чисел, чтобы избежать двусмысленности
  • Конечный балл RICE – используйте формулу для каждой строки (=RIC/E).
3. Определите и пропишите user-story (пользовательские истории) и критерии приемки для каждого элемента.

ЧТО?!? Да, именно это и является требованиями для эффективной оценки и приоритизации.

ПОЧЕМУ? Потому что сотрудники не могут дать оценку усилий, не понимая, что они должны соорудить (если я попрошу вас построить дом, у вас, вероятно, будут вопросы, например, насколько большой, сколько комнат, ванных комнат и т. д., верно? То же самое предполагается и здесь).

Не нужно работать в в вакууме, задайте себе вопрос – уверен ли я в предполагаемом результате и проблеме, которую должен решить этот проект. Если ответ не совсем «ДА», вы можете оставить заметки для дальнейшего обсуждения, но согласуйте с тем, кто предложил данный проект (если известно). Также обсудите все детали с командой, прежде чем завершить пользовательскую историю и критерии приемки, чтобы все понимали не только "Что", но и "Почему" (также известное как "оптимизация бэклога").

Оценивайте и приоритизируйте

Вы отправили сообщение, подготовились к встрече и готовы к приоритизации, верно?

Давайте сразу проясним – присвоение баллов отличается от приоритизации.

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

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

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

Давайте разложим шаги и представим, что ваша встреча началась в 10 утра:

10:00 утра – убедитесь, что каждый понимает, почему он здесь, и прочитал всю информацию в Google-документе, в который вы вложили так много усилий.

10:01 утра – так как никто не прочитал его, запустите демонстрацию экрана и кратко перескажите основную информацию.

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

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

10:16 утра – нажмите на первый проект. Прочтите заголовок и пользовательскую историю вслух. Задайте всем вопрос – «Понимаете ли вы, какую проблему мы пытаемся решить этим проектом?» – и я бы настоятельно рекомендовал добавить «систему поддержки» для молчаливых участников, которые должны высказаться сегодня. Что-то вроде: «Ничего страшного, если вы не знаете этот проект, я тоже не знаю их все, давайте это обсудим».

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

10:20 утра – отлично! Мы все понимаем проблему, давайте определим наш "R" в RICE (Охват). Задайте этот вопрос вслух группе: «Сколько клиентов этот проект охватит в данном квартале по нашему мнению?».

Должен предупредить вас ... Вы можете подумать, что на этот вопрос сможете быстро дать ответ ... но нет. Этот вопрос должен совпадать с ДАННЫМИ – так как вы хотите, чтобы ваше прогнозируемое количество достигаемых клиентов было основано на данных. Хорошим примером может быть что-то вроде этого от вашего руководителя дизайна:

"Хорошо, сегодня с продуктом X мы видим только 150 клиентов в месяц, и я думаю, что если мы реализуем этот проект, то увидим прирост в 50 человек на основе данных, которые у нас есть от маркетинга, показывающих, что Y люди отваливаются на точке Z... **Открывает электронную таблицу** – и если считать за квартал, то будет прирост в 150 клиентов за квартал, и, вероятно, нам нужно скорректировать это, запустив его в середине квартала."

Не забудьте прикрепить таблицу к проекту!

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

10:30 утра - согласовано количество Охвата в 150. Ура! (Мы действительно это делаем!)

10:31 утра - Влияние... Так много способов расчета, но в этой статье будем использовать простой подход.

Оставив открытым тот же проект, на который вы нажали в 10:16, задайте следующий вопрос: "На сколько процентов проект увеличит конверсию при взаимодействии клиента с ним?"

И мы не ищем четкое числовое значение, как в разделе Охвата. Мы ищем выбранное число от 0,25 до 3.

3 – это максимальное значение, а 0,25 – минимальное.

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

Я лично предпочитаю, чтобы оценка влияния основывалась на сочетании доступных данных и интуиции. Участники команды могут спорить по поводу более высоких или низких чисел, и это нормально. Просто оставайтесь на цели – числе, которое поможет нам определить приоритеты. Когда вы назначили оценки всем проектам, вы можете обнаружить, что оценили влияние неправильно по сравнению с другими, что позволит продолжить обсуждение до переранжирования. Допустим, наша оценка Влияния составляет среднюю или "1".

10:45 утра - тот же проект все еще открыт, и мы определили R и I.

** Совет – вместо перехода к оценке Уверенности (C), перейдите к оценке Усилий (как можно присвоить оценку уверенности, если все числа еще неизвестны?)

Теперь задайте вопрос: "Думая об этом проекте не только с точки зрения разработки, но также дизайна, поддержки, подготовки к обучению, сколько человеко-месяцев на это потребуется по нашему мнению?"

10:46 утра – не хочу вас огорчать, но вам придется повторить, что такое "человеко-месяц". Несмотря на то, что вы этого не хотите, потратьте следующие 10 минут, чтобы убедиться, что все понимают, что это такое, это будет лучше для вас в долгосрочной перспективе.

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

11:00 утра – когда у всех сложится четкое понимание того, что такое человеко-месяц, вернитесь к оценке. Повторите вышеприведенный вопрос и подождите, пока кто-нибудь ответит. Ставлю 10 долларов на то, что это был разработчик. Угадал?

Разработчик говорит: "Ну, я могу ответить только на основе того, что у нас есть в этой задаче/проекте, поэтому, исходя из этого, вероятно, потребуется спринт, чтобы все согласовать, когда мы будем готовы к постройке".

Отлично! Но это только часть головоломки, а что насчет технического обзора, дизайна и т.д.?

"А что думает дизайн-команда?"
Вы уже поняли основную суть.

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

11:15 утра – ВЫ СДЕЛАЛИ ЭТО, вы избавились от трех самых сложных букв R, I, E. Теперь время для простой – C – Уверенности.

** Совет – Смотрите со стороны «насколько вы уверены в числах, которые установили для R, I и E, а не в вашей Уверенности в проекте».

Если вы округлили все числа без данных и разговора, ваша уверенность низкая. Если у вас есть сверхуверенность, потому что это всего лишь небольшое обновление, или ваша команда имеет все исторические и прогнозируемые данные, – уверенность высока.

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

11:25 утра – Уровень Уверенности = 50% или 0,5

11:26 утра – R*I*C/E = 150*1*0,5/2 = 37,5

11:27 утра – Вы справились – у вас есть рейтинг RICE для одного проекта! Теперь вам нужно повторить это еще около 87 раз... Думаю, вы поняли, насколько это может быть времязатратным. Нам потребовалось полтора часа, чтобы получить один рейтинг на нашей первой встрече. Однако со временем и повторением ваша команда будет справляться быстрее.

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

12:00 дня – Надеюсь, вы получили еще один оцененный проект и теперь можете поместить наиболее высоко оцененный элемент на первое место, за которым следует второй элемент на втором месте и так далее. Теперь мы заканчиваем встречу и убеждаемся, что все знают, когда состоится следующая – не позднее чем через неделю, желательно как можно скорее.

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

Это также является повесткой дня для вашего совещания, которую нужно включить на шаге 1.

Сообщите свой приоритизированный список

Ура! Вы сделали это, потратив следующие несколько дней и недель на оценку, и с каждой оценкой вы располагали их от наивысшего балла к наименьшему, и у вас есть «Список». В то же время вы по-прежнему выполняете свои ежедневные задачи, и количество совещаний накопилось, вы устали, даже рассматривали возможность приоритизации асинхронно, но засомневались, потому что вы командный игрок. Поверьте, но вы будете рады, что продержались вместе со своей командой на этом пути.

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

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

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

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

** Совет – Не останавливайте текущий спринт или проекты в работе, пока они не завершатся (если только эти проекты не находятся в самом низу списка или только что были взяты в работу). Завершите спринт, переориентируйте команду и, пока этот спринт идет, готовьте свои Epics (большой объем работы, который можно разбить на несколько историй поменьше - прим ред.), PRD (документ, который следует использовать для отслеживания всех функций и требований вашего продукта по мере продвижения в процессе разработки и запуска - прим. ред.) и т.д. для высоко оцененных элементов.

Как справляться с изменениями в приоритетах

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

Проведя анализ с помощью фреймворка RICE, вы определили Охват, Влияние, Уверенность и Усилия для проекта, что дальше?

Есть еще одна вещь, которая поможет вам при приоритизации. Необходимо ставить цели, которые будут плотно связаны со стратегией и будут сохранять ваш фокус на самом главном. Для этого отлично подойдет методология OKR (Objectives & Key Results - Цели и Ключевые результаты).

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

Обучение OKR на практике: сертификационные семинары, тренинги и курсы

провести фасилитацию
Запросить консультацию по тренингам OKR
Заполните форму и получите ответы
на все вопросы.

Больше статей по теме

Получить консультацию
Заполните форму и получите ответы
на все вопросы.