Все статьи
Коварство простоты или приоритизация бэклога
Дата: 30.08.2024
Приоритизация бэклога – один из ключевых инструментов продуктового менеджера. 9 из 10 начинающих продуктовых менеджеров, выбрав ICE или RICE, думают, что это и есть приоритизация, и часто разочаровываются в результатах. Как избежать основных ошибок и настроить приоритизацию так, чтобы она действительно помогала принимать совместные решения, мы расскажем в статье.
Проблема с приоритетами влияет на многие аспекты продуктовой деятельности. Давайте посмотрим многообразие проблем, которое вызывает простое отсутствие прозрачных приоритетов в бэклоге:
| Поломка | Описание | Как это выглядит в команде (красные флажки) |
| Процесс приоритизации отсутствует | Формального процесса приоритизации нет, но задачи всё равно как-то приоритизируются. |
|
| Процесс приоритизации не влияет на реальные приоритеты | Приоритеты по факту определяются иначе, чем в формальном процессе. |
|
| Результаты приоритизации размыты | Участники могут по-разному понимать задачи, или задачи меняются после детализации. |
|
Также для всех вышеописанных ситуаций типично:
- Продукт развивается не с учетом продуктового видения и стратегии компании, а с целью быстрого тушения конфликтов.
- Каждый новый релиз только усиливает конфликты, потому что продукт «не тот» и не соответствует ожиданиям участников.
Как результат, неявные и непрозрачные механизмы делают процесс приоритизации хаотичным и неуправляемым.
Что же такое приоритизация?
Приоритизация – это инструмент, который помогает расставлять задачи по важности.
Приоритизация бэклога используется во всех agile фреймворках и хотя выглядит как заполнение таблиц – на самом деле это инструмент совместного принятия решений. От кажущейся простоты может появиться иллюзия, что заполнение карточки само по себе дает результат, а это не так. При этом количество времени людей с разными мнениями, доступное продуктовому менеджеру, крайне ограничено. Также качественно выстроенный процесс приоритизации помогает управлять ожиданиями ключевых участников.
Т.е. формула в выбранном методе должна соответствовать бизнес-модели успеха продукта, даже если она явно не описана. Продуктовые метрики также должны быть продолжением этой гипотезы и увязываться с методом приоритизации, иначе решения будут приниматься исходя из одних данных, а выводы делаться – на других.
Один из основных рисков, с которым может столкнуться продуктовый менеджер при неправильно организованном процессе приоритизации: пока он решает ресурсные конфликты – фокус на стратегические цели продукта может быть потерян. И это уже проблема не только продуктового менеджера, у которого есть глобальная задача – развивать продукт в заданном направлении, но и всей компании.
Поэтому приоритизация – одна из ключевых задач в любой компании. Приоритизация отвечает не просто за порядок задач в бэклоге и состав спринта, а является сквозным процессом связующим стратегические решения и результат. И хоть запуск приоритизации зачастую происходит по инициативе и силами продуктового менеджера, по факту это – один из основных управленческих процессов в компании.
Какие же основные шаги должен сделать продуктовый менеджер, чтобы избежать основных ошибок?
- Выбрать метод приоритизации (и придерживаться его).
- Определить участников приоритизациии, за какие параметры модели они отвечают.
- Продумать и донести до участников процесс приоритизации – частота, как запустить пересмотр, и т.д.
- Определить правила голосования, не допускать к нему неподготовленных.
- Разослать материалы участникам, убедиться, что все в общем контексте.
- Провести голосование.
- Обсудить результаты, окончательно их зафиксировать.
Давайте теперь посмотрим специфику и многообразие разных методов приоритизации, достоинства и недостатки каждого метода:
Описание:
Способ приоритизации бэклога, который анализирует три фактора:
• Impact (влияние) – оценка того, насколько реализация задачи повлияет на ключевую метрику.
• Confidence (уверенность) – оценка степени уверенности в точности оценок влияния и простоты реализации.
• Ease (простота реализации) – оценка объема усилий и ресурсов, необходимых для реализации задачи.
Для каждого из параметров используется шкала от 1 до 10. Можно интерпретировать значения от 1 до 10 по своему усмотрению, главное, чтобы они были согласованы между собой, и участники приоритизации понимали их одинаково.
Для каждого элемента бэклога по этим факторам вычисляется приоритет по формуле:
Impact x Confidence x Ease = ICE Score
Достоинства:
- Простота и быстрота оценки: метод легок в использовании и не требует сложных вычислений.
- Гибкость: метод подходит для различных типов решений и может быть адаптирован под конкретные нужды команды.
- Учет риска неопределенности: включение уверенности (Confidence) как одного из критериев позволяет учесть риски и неопределенности, что особенно важно при работе с новыми или сложными задачами.
Недостатки:
- Субъективность и непостоянство оценок: разные участники могут по разному понимать шкалу оценок.
- Нестабильность оценок: один и тот же человек может давать разные оценки в разное время.
- EASE как параметр – контр-интуитивен, непонятно, что является единицей простоты. Также реверсивная шкала (чем больше – тем легче) запутывает участников.
Примеры использования:
Метод ICE может быть хорош на ранних этапах разработки продукта, либо для быстрой оценки множества новых идей и функций. Также ICE актуален для использования в небольших командах, находящихся в общем контексте.
Описание:
Способ приоритизации бэклога, который анализирует четыре фактора:
• Reach (охват) – оценка уровня охвата количества пользователей/событий за определенный период.
• Impact (влияние) – оценка того, насколько реализация задачи влияет на ключевую метрику.
• Confidence (уверенность) – оценка степени уверенности в точности оценок охвата, влияния и простоты реализации.
• Effort (трудозатраты) – оценка объема усилий и ресурсов, необходимых для реализации задачи.
Для каждого элемента бэклога по этим факторам вычисляется приоритет по формуле:
Reach х Impact x Confidence/Effort = RICE Score
У метода RICE есть автор – компания Intercom, довольно точно его описавшая. Поэтому если в ICE смысл для каждого значения всегда определяет команда, то в оригинальном RICE параметры шкал заданы (что, конечно, не мешает командам задавать свои шкалы):
Reach (охват) – количество пользователей/событий за определенный период.
Impact (влияние) – используется следующая шкала:
3 — огромное влияние;
2 — высокое влияние;
1 — среднее влияние;
0,5 — слабое влияние.
Confidence (Уверенность):
100% — высокая уверенность;
80% — средняя;
50% — низкая.
Effort (Усилия) – трудозатраты в человеко-месяцах.
Достоинства:
- Прозрачность: Метод легко объясним и может быть представлен различным заинтересованным сторонам, обеспечивая прозрачность приоритетов.
- Объективность: Количественная оценка влияния и трудозатрат снижает уровень субъективности приоритизации.
- Учет риска неопределенности: включение уверенности (Confidence) как одного из критериев позволяет учесть риски и неопределенности, что особенно важно при работе с новыми или сложными задачами.
Недостатки:
- Трудоемкость: метод требует времени и усилий для тщательной оценки каждой задачи.
- Зависимость от данных: необходимы достоверные данные для точной оценки охвата и уверенности, что не всегда возможно.
- Не учитывает зависимости между задачами.
Примеры использования:
Метод RICE может быть хорош для использования на массовом рынке.
Описание:
Метод Weighted Shortest Job First (WSJF) используется для определения приоритетов задач на основе их относительной стоимости задержки (Cost of Delay) и продолжительности выполнения (Duration).
User-Business Value – оценка полезности задачи для бизнеса и пользователей.
Time Criticality – оценка критичности по времени.
Risk Reduction or Opportunity Enablement – оценка вероятности снижения рисков или открытия возможностей.
Job Duration or Job Size – оценка длительности или ресурсоемкости выполнения работ.
Для каждого элемента бэклога по этим факторам вычисляется приоритет по формуле:
WSJF = (User-Business Value + Time Criticality + Risk Reduction) / (Job Duration).
Для наиболее эффективной оценки фичей по WSJF часто используют StoryPoints (по аналогии с покером планирования в SCRUM) – меру трудоёмкости или сложности задач бэклога, основанную на числовом ряде Фибоначчи – числовой последовательность, где первый элемент 1, а последующие равны сумме двух предыдущих.
Важно, что в отличие от ICE и RICE метод систематизирует весь бэклог единовременно – задачи оцениваются последовательно по каждому из параметров, начиная с самой малозначительной, которой проставляется 1 поинт. В каждой колонке должна быть хотя бы одна единица.
Достоинства:
- Детализированная модель параметров.
- Единовременная приоритизация всего беклога.
- По каждому из параметров есть эталонное значение – самый малозначительный элемент.
Недостатки:
- Трудоемкость оценки: Требует детальной оценки стоимости задержки и продолжительности выполнения для каждой задачи, что может быть сложно и времязатратно.
- Субъективность входных данных: Хотя метод основан на числовых оценках, сами данные для оценки могут быть субъективными и зависеть от мнений членов команды.
- Сложность в использовании: Для правильного применения метода требуется хорошее понимание концепций стоимости задержки и риска, что может быть сложным для менее опытных команд.
Примеры использования:
В зрелых командах с многозадачными бэклогами.
Описание:
Метод MoSCoW — это техника приоритизации, которая помогает определить наиболее важные требования и задачи в проекте, разделяя их на четыре категории:
• Must have (Обязательно) — критические требования или задачи, которые должны быть выполнены для того, чтобы проект был успешным. Без них проект нельзя считать завершенным.
• Should have (Желательно) — важные требования или задачи, которые должны быть выполнены, если это возможно. Они не являются критически важными, но значительно влияют на успех проекта.
• Could have (Может быть) — дополнительные требования или задачи, которые могут быть выполнены, если есть достаточное количество времени и ресурсов. Эти элементы приятны, но не обязательны.
• Won’t have (Не будет) — задачи или требования, которые не будут включены в текущую версию проекта, но могут быть рассмотрены в будущем.
Достоинства:
- Обеспечивает вовлечение участников без технических знаний.
- Быстрый, простой и интуитивно понятный метод для обсуждения приоритетов с командой и клиентами.
- Способствует обдуманному распределению ресурсов уже на этапе установления приоритетов.
Недостатки:
- Команды и ключевые участники часто склонны завышать обязательность функций.
- Метод не учитывает трудоемкость элементов бэклога в явном виде.
- Отсутствие объективной методологии для ранжирования функций.
Примеры использования:
Для первичной сортировки объемного бэклога. Для определения MVP.
Описание:
«Купи функцию» — это игра, в которой могут участвовать клиенты и стейкхолдеры, в зависимости от продукта и целей. Когда игра проводится с клиентами, метод помогает количественно оценить ценность функции или идеи для конечных потребителей.
Игра проходит следующим образом:
- Оцените стоимость каждого элемента бэклога. Оценка должна учитывать ресурсоемкость.
- Соберите группу и установите сумму денег, которую может «потратить» каждый из участников.
- Попросите участников «купить» функции, которые им наиболее интересны. Некоторые участники могут вложить все свои деньги в одну любимую функцию, а другие — распределить их между несколькими различными функциями.
- Попросите участников объяснить свои решения по распределению денег.
- Составьте ранжированный список функций, основываясь на количестве потраченных на них средств.
- Предполагается, что стоимость некоторых функций может быть настолько высока, что никто не сможет приобрести их в одиночку. Это должно побудить участников к сотрудничеству и объединению ресурсов.
Достоинства:
- Интуитивная простота ранжирования.
- Ограничение «денег» у участника защищает от ситуации, когда все функции определяются как очень нужные.
- Оценка стоимости каждого пункта может оказаться трудоемкой или субъективной.
Недостатки:
- Участники могут принимать решения, основываясь на личных предпочтениях или ограниченном понимании потребностей рынка, что может привести к субъективным и не всегда объективным результатам.
- Участники могут склоняться к выбору функций, которые приносят быстрые результаты, игнорируя функции с долгосрочным стратегическим значением.
- Доминирующие или более влиятельные участники могут повлиять на решения группы, что может исказить распределение ресурсов и приоритеты.
Примеры использования:
Для быстрого вовлечения внешних или внутренних клиентов в процесс ранжирования.
Итого, при запуске приоритизации важно помнить, что это инструмент совместного принятия решений. Метод приоритизации нужно выбирать с учетом гипотезы об успехе продукта, участники приоритизации должны быть погружены в единый контекст перед голосованием. Приоритизация является сквозным процессом, связующим стратегические решения и результат, и это нужно учитывать при проработки шагов для запуска.
Автор статьи: Вия Павлова, эксперт по продуктовому и проектному управлению. В ИТ-сфере более 15 лет, последние несколько лет выпускает продукты в области ИИ.
