По данным исследований, одна из основных причин того, что инвестиции в разработку продукта не оправдывают ожиданий высшего руководства, — неверно расставленные приоритеты при выборе идей, продуктов или функций (фич). Сложность с приоритизацией занимает второе место в списке проблем, с которыми сталкиваются продакт-менеджеры, выше в списке только отсутствие четкой стратегии продукта. Чтобы помочь разобраться в инструментах приоритизации, мы подготовили их обзор, включив в него такие популярные инструменты, как модель Кано, QFD, RICE и ICE, «Купи фичу», MoSCoW и многие другие.

Максим Якубович, партнер Product Lab, и Андрей Бадин, CEO Product Lab

Из статьи вы узнаете: 

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

Что такое приоритизация 

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

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

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

Таким образом, вопрос приоритизации идей и функций стоит перед менеджером продукта на протяжении всего жизненного цикла продукта с этапа создания MVP.  

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

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

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

Подходы к приоритизации 

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

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

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

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

Например, в подходе к ICE используются три фактора для оценки приоритета, а в подходе MoSCoW — один.

Предложенная нами модель выбора инструментов приоритизации (модель ВИП) легко используется на практике: когда вы находитесь на начальных этапах жизненного цикла продукта и у вас еще нет еще реальных пользователей и даже прототипа продукта,  стоит использовать инструменты, описанные в левом нижнем углу модели ВИП. Чем на более позднем этапе ЖЦ продукта вы находитесь, тем более сложные инструменты можно использовать, так вы постепенно перемещаетесь в правый верхний угол.

Подходы, ориентированные на мнение внешних сторон

Модель Кано 

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

Модель предполагает проведение анкетирования пользователей и обработку его результатов.

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

На каждый вопрос, как вы себя почувствуете, если у вас будет/не будет этой функции, возможны ответы:

• мне это нравится;
• я ожидаю этого;
• ничего не чувствую;
• я могу это терпеть;
• мне это не нравится.

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

Как правило, приоритеты в реализации категорий расставляются в следующем порядке:

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

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

Плюсы модели Кано:

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

Минусы модели  Кано:

• Довольно трудозатратный подход.
• Не все функции легко объяснимы текстовым описанием. Иногда респондентам нужна визуализация для понимания сути функции.

В сравнении с другими подходами к приоритизации модель Кано ориентирована на эмоциональную реакцию клиентов, а не только на бизнес-ценность или сложность реализации.

Подход QFD

QFD (Quality Function Deployment/структурирование функции качества) — это подход, который позволяет преобразовать требования пользователей в технические требования к продукту, провести сравнительный анализ с продуктами-конкурентами и после этого расставить приоритеты в реализации технических требований. Этот подход еще называют «домом качества», так как итоговая матрица схожа по своей форме с домом:

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

Типовые шаги в определении приоритетов по методу QFD

1. Сбор голосов клиентов (Voice of the Customer, VoC)

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

2. Формирование требований клиентов (What’s)

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

3. Определение технических характеристик (How’s)

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

4. Создание матрицы «дом качества»

Основной инструмент QFD — это матрица «дом качества». В ней на одной оси размещены требования клиентов (What’s), а на другой — технические характеристики продукта (How’s). Матрица заполняется таким образом, чтобы отобразить связь между потребностями клиентов и техническими решениями. Например, сильная связь может означать, что определенная функция продукта напрямую влияет на удовлетворенность клиента.

5. Оценка важности требований клиентов

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

6. Оценка технических характеристик

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

7. Определение конкурентоспособности

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

8. Установление приоритетов

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

9. Разработка плана действий

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

10. Мониторинг и корректировка.

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

Плюсы QFD:

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

Минусы QFD:

• Еще более трудоемкий, чем метод Кано.
• В меньшей степени фокусируется на эмоциональной реакции пользователей, в отличие от метода Кано.

Подход RICE

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

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

В RICE для каждого требования оценивается 4 фактора.

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

Impact (влияние) — насколько функция повлияет на ключевую продуктовую метрику, которую растит команда (выручку, конверсию или др.). Влияние можно оценивать по шкале от 0,25 до 3: 

• 3 — сильное влияние;
• 2 — высокое;
• 1 — среднее;
• 0,5 — низкое;
• 0,25 — минимальное.

Confidence (уверенность) — насколько команда уверена в оценках охвата, влияния и сложности.

Можно использовать 3 варианта для оценки уверенности:

• 100% — высокая;
• 80% — средняя;
• 50% — низкая.

Effort (усилия) — сколько времени понадобится, чтобы реализовать функцию.

Чаще всего усилия измеряются в человеко-часах или человеко-днях. Если команда оценивает разработку функции в 1 человеко-день, то значение Effort равно 1,0. Если оценка реализации функции командой равна 2 человеко-дням, то значение Effort равно 2.

Для получения оценки функции по RICE используется формула:

Чем выше оценка по RICE, тем выше приоритет у функции.

Плюсы подхода RICE:

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

Минусы подхода RICE:

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

Подход ICE

Этот подход похож на RICE, но для расчета приоритета не используется Reach (охват), а вместо Effort (усилия) применяется Easy (простота в реализации). По сути, Effort и Easy — очень похожие параметры оценки сложности реализации функции.

Для расчета оценки по ICE используется следующая формула:

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

Чем выше окажется балл по ICE, тем выше приоритет функции.

Плюсы ICE по сравнению с RICE:

• Подход проще, т. к. требует оценки только трех факторов.
• Может быть более эффективным для оценки продукта с небольшой аудиторией.

Минусы ICE по сравнению с RICE:

• Отсутствие оценки охвата.

Метод WSJF 

Метод WSJF (Weighted Shortest Job First) был разработан в рамках методологии SAFe (Scaled Agile Framework) для управления созданием продуктов большим количеством команд. Он применим для приоритизации задач и функций в условиях ограниченных ресурсов и времени. Главная цель WSJF — помощь в выборе задач, которые следует выполнить в первую очередь, исходя из их важности и затрат на реализацию.

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

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

Суть метода WSJF

Ключевые компоненты метода:

1.  Стоимость задержки (Cost of delay/CoD) — этот показатель учитывает три фактора:

• Бизнес-ценность (ценность для бизнеса) — насколько важна эта проблема с точки зрения пользователей и бизнеса.
• Срочность (критичность времени) — насколько срочная эта задача. Чем выше срочность, тем больше будет стоить задержка.
• Снижение риска — как выполнение задачи снижает риски.

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

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

Чем выше показатель WSJF, тем выше приоритет задачи.

В отличие от других методов приоритизации, WSJF делает акцент на стоимость задержки (Cost of Delay). Это позволяет более точно учитывать потери, связанные с откладыванием выполнения задачи. Этот подход сосредоточен на краткосрочных результатах, т. к. задачи с меньшей длительностью и высоким бизнес-эффектом получают приоритет.

Плюсы метода WSJF:

1.     Эффективное использование ресурсов.

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

2.     Прозрачная приоритетность.

Метод WSJF делает процесс приоритизации более наглядным и понятным для всех участников команды. Они могут легко объяснить, почему была выбрана та или иная проблема.

3.     Фокус на минимизации задержек.

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

4.     Гибкость и применимость в масштабных проектах.

Легко применять как для небольших задач, так и для крупных проектов, в том числе в масштабируемой agile-среде, например в SAFe.

Минусы метода WSJF:

1.     Сложность оценки стоимости задержки.

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

2.     Недооценка долгосрочных задач.

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

3.     Зависимость от качественных оценок.

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

4.     Ориентация на быстрые результаты.

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

Оценка возможностей (Opportunity scoring)

Этот метод основан на концепции инноваций, ориентированных на результат (ODI), Энтони Ульвика. 

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

Opportunity scoring основывается на анализе удовлетворенности пользователей текущими функциями и важности этих функций для них. Это достигается путем проведения опросов или интервью, в которых пользователей просят оценить важность различных функций и их удовлетворенность текущей реализацией. Основные шаги включают:

1. Сбор данных о важности и удовлетворенности

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

• важность (насколько это важно для них);
• удовлетворенность (насколько они довольны текущей реализацией).

2. Выявление возможностей

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

3. Ранжирование возможностей

Каждая возможность оценивается по уровню приоритета с помощью разницы между оценками важности и удовлетворенности. Формула для расчета приоритета может быть такой:

Приоритет = Важность − Удовлетворенность

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

Плюсы подхода:

• Фокус на нуждах пользователей.

Метод позволяет выявить и сосредоточиться на действительно значимых для пользователей проблемах.

• Простота.

Сбор и анализ данных относительно просты и не требуют сложных вычислений.

• Гибкость.

Opportunity scoring можно адаптировать к различным типам продуктов и услуг, что делает его универсальным.

Минусы подхода:

• Ограниченность в использовании количественных данных.

Подход опирается на субъективные оценки пользователей

• Не учитывает затраты и техническую реализацию.

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

Карта пользовательских историй

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

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

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

Карта историй пользователя организована следующим образом:

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

• Вертикальная ось обозначает приоритетность в реализации.

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

Плюсы подхода:

• Помогает команде лучше понять продукт с точки зрения пользователя.
• Улучшает коммуникацию и сотрудничество внутри команды.

Минусы подхода:

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

MoSCoW

MoSCoW — это аббревиатура, каждая буква которой обозначает одну из четырех возможных категорий приоритетности (в название подхода добавлены две буквы о, чтобы сделать его легко запоминающимся): Must Have (критически необходимые), Should Have (важные), Could Have (полезные, но не критичные) и Won’t Have (необязательные).

В MoSCoW все функции подразделяются на 4 группы:

• Must Have — критически важные функции, без них продукт не будет выполнять свое назначение.
• Should Have — эти функции важны, но не критичны для следующей версии продукта.
• Could Have — эти функции желательны, но не обязательны для следующей версии продукта. Обычно это недорогие усовершенствования. 
• Won’t Have — эти функции не соответствуют стратегии продукта, их стоит исключить.

К плюсам подхода можно отнести следующие:

1. Простота.

Сам подход  довольно прост в понимании, а встреча по приоритизации может пройти всего за полчаса.

2. Вовлечение заинтересованных сторон в принятие решений.

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

Минусы подхода  MoSCoW следующие:

1. Отсутствие анализа сложности реализации и затрат.

MoSCoW не включает в себя анализ затрат на реализацию каждого требования.

2. Встреча требует участия модератора.

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

3. Результаты приоритизации субъективны.

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

4. В категории Must Have может оказаться довольно много требований. Если команда разработки работает по итерациям (или спринтам), то ей нужно будет определить приоритеты для требований, попавших в категорию Must Have. Придется менеджеру продукта расставить приоритеты внутри этой категории.

Product Tree (Дерево продукта)

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

Основные компоненты продуктового дерева:

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

Источник картинки: Lucidspark

Процесс работы с Product Tree

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

Плюсы Product Tree:

• Визуализация и наглядность. Product Tree дает команде простую и визуально понятную модель приоритизации задач. Члены команды могут увидеть общую картину развития продукта и легко согласовать дальнейшие действия.
• Гибкость. Метод легко адаптируется к изменениям. Команды могут добавлять новые «ветви» и «листья» по мере необходимости, чтобы отразить развитие продукта и смену приоритетов.
• Командное взаимодействие. Product Tree поощряет участие всех членов команды, что способствует совместному принятию решений и лучшему пониманию продукта. Это повышает вовлеченность и способствует лучшей координации между участниками проекта.
• Фокус на долгосрочное планирование. Product Tree помогает командам думать о долгосрочных перспективах продукта, не забывая при этом о текущих задачах и улучшениях.

Минусы Product Tree:

• Сложность детализации. Хотя метод полезен для общей стратегии, он может быть недостаточно детализирован для управления небольшими задачами и требованиями. Мелкие детали могут быть упущены в процессе.
• Использование метафоры дерева может ограничить представление о продукте, особенно если проект сложный и имеет много взаимосвязанных задач.
• Трудность в измерении прогресса. Product Tree дает визуальное представление развития, но не позволяет количественно оценить прогресс, поэтому менее полезен для управления сроками и ресурсами.
• Не идеально подходит для технических решений. Product Tree хорошо показывает видение продукта, но может не учитывать технические долги или внутренние задачи, которые не всегда сразу видны в «ветвях» дерева.

Купи фичу

«Купи фичу» — подход, при использовании которого заинтересованные стороны покупают фичи (функции), которые они хотели бы видеть в продукте. Стоимость функций определяется сложностью их реализации, а участникам приоритизации предоставляется некоторое количество нереальных денег (как в «Монополии» или других похожих играх), на которые они могут покупать функции. Количество выданных денег составляет примерно ⅔ от стоимости всех функций, поэтому участники вынуждены выбирать те, которые им больше всего нужны.

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

Плюсы подхода:

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

Минусы подхода:

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

Подходы, ориентированные на мнение внутренней команды

В эту категорию попали такие подходы, как:

• финансовый анализ;
• скоринговые модели;
• ценность против риска;
• ценность против затрат,

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

Рассмотрим подробнее эти подходы.

Финансовый анализ 

Этот подход предполагает, что для каждой функции будет выполнен прогноз по получению финансовой выгоды от ее реализации. Чаще всего используются такие финансовые показатели, как NPV (Net Present Value/чистая приведенная стоимость), IRR (Internal Rate of Return/внутренняя норма доходности инвестиций) или срок окупаемости с учетом дисконта.

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

Скоринговые модели

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

Последовательность использования подхода обычно такая:

1. Выбор функций, которые хотелось бы включить в следующую версию продукта.
2. Определение критериев для оценки и веса каждого параметра.
3. Встреча с заинтересованными сторонами и обсуждение критериев и их веса.
4. Каждой функции присваиваются баллы по каждому критерию.
5. Устанавливается приоритет для каждой функции по правилу: чем выше балл, тем выше приоритет.

Пример таблицы приоритизации представлен ниже:

Ценность против риска

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

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

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

Ценность против стоимости

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

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

Чем больше угол наклона от оси «ценность» к оси «затраты», тем выше приоритет функции. Логика очень проста: чем больше ценности и меньше затрат на реализацию, тем выше приоритет, то есть больше будет угол наклона от точки на оси координат до оси «затраты».

Тематический скрининг

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

Процесс такой:

1. Определить критерии, по которым оцениваются функции.
2. Для каждого критерия выбрать базовую функцию. Подходящая базовая функция — та, которая с большей вероятностью будет выбрана для следующего релиза продукта.
3. Для каждой функции провести сравнение с базовой и поставить + (если она оказывает большее влияние, чем базовая), 0 (если она нейтральна) и — (если оказывает меньшее влияние).
4. Для каждой функции рассчитать ее балл по сумме + и — в строке.

Классификационный рейтинг 

Этот вид приоритизации один из самых простых в использовании. 

Процесс приоритизации следующий: 

1. Определяется шкала для приоритетов, например от 1 до 10, где 10 — самый высокий приоритет.
2. Каждой функции присваивается значение по данной шкале, а затем составляется рейтинг.

Несмотря на всю простоту этого подхода, он находит применение на практике в условиях ограниченного времени на принятие решений о приоритетах. 

Плюсы подхода:

• Простота и удобство.

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

• Гибкость.

Шкала может быть адаптирована под конкретные нужды и параметры проекта. Например, можно использовать другую шкалу (допустим, от 1 до 5) или дополнительные параметры, такие как высокий, средний и низкий приоритет.

• Быстрая оценка.

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

• Универсальность.

Легко адаптируется для любых проектов и типов задач независимо от их сложности.

Минусы подхода:

• Субъективность оценки.

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

• Отсутствие глубины анализа.

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

• Ограниченное понимание взаимосвязей.

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

• Сложности с масштабируемостью.

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

Feature Buckets («Ведра с фичами»)

Этот подход был разработан CEO Daffy Giving Адамом Нэшем и предполагает разделение всех продуктовых функций на 4 категории:

1. Metric Movers (двигатели метрик)
   Функции, которые напрямую влияют на ключевые метрики продукта или бизнеса, такие как доход, вовлеченность, конверсия и т. д. Это приоритетные задачи, которые приносят значительное и измеримое улучшение показателей.
2. Customer Requests (запросы клиентов)
   Функции, которые были запрошены клиентами. Эти функции добавляют ценность за счет закрытия текущих потребностей клиентов, повышения их удовлетворенности и укрепления лояльности. Хотя они не всегда влияют на ключевые метрики, они важны для поддержки существующих пользователей.
3. Delight Features (функции удовольствия)
   Функции, которые не обязательны, но могут существенно улучшить пользовательский опыт. Эти задачи часто создают вау-эффект и помогают отличить продукт от конкурентов. Они важны для повышения пользовательской привязанности и формирования положительного восприятия.
4. Strategic Features (стратегические функции)
   Функции, которые поддерживают долгосрочные цели компании и способствуют созданию стратегических преимуществ. Эти задачи могут включать внедрение инновационных технологий, подготовку к будущим изменениям на рынке или создание новых возможностей, которые потребуются в будущем.

Плюсы подхода:

• Простота.

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

• Гибкость.

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

• Сбалансированный подход.

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

Минусы подхода:

• Отсутствие конкретных критериев для ранжирования внутри категорий.

Не всегда очевидно, какие задачи приоритетнее внутри одной категории, что может привести к субъективным решениям.

• Сложности при распределении функций.

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

• Игнорирование стоимости и ресурсов.

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

Как выбрать подход к приоритизации списка требований

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

Фактор 1. Этап жизненного цикла продукта

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

Таким образом, использование подходов к приоритизации в зависимости от этапа жизненного цикла продукта может выглядеть следующим образом. Чем более ранний этап ЖЦ продукта, тем меньше факторов для приоритизации стоит использовать и тем меньше возможностей есть у продакт-менеджера, чтобы учитывать мнение пользователей. А с продвижением по этапам ЖЦ подходы к приоритизации можно усложнять с точки зрения количества факторов, влияющих на приоритет. Кроме того, с продвижением по этапам ЖЦ продукта появляется все больше возможностей учитывать мнение пользователей и других заинтересованных сторон.

Однако это не жесткое правило, а скорее рекомендация, на которую стоит обратить внимание.

Поиск идеи

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

Исследования и Выход на рынок 

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

• Цель этапа Исследования: исследование клиентского опыта, поиск идей, быстрое прототипирование, проверка идеи.
• Цель этапа Выхода на рынок: выпуск MVP, привлечение пользователей.
• Подходы: MoSCoW, Story mapping, стоимость задержки, Feature Buckets, Opportunity scoring, скоринговая модель, «Купи фичу», «Дерево продукта», Value vs Effort, модель Кано, Opportunity scoring  — в приоритизацию вовлекается больший круг заинтересованных сторон, т. к. коллективный разум чаще всего помогает принимать более взвешенные решения о приоритетах.

Поиск сегментов рынка и Масштабирование

• Цель этапа Поиска сегмента: поиск Product Market Fit (соответствие продукта рынку).
• Цель этапа Масштабирования: масштабирование, удержание пользователей. 
• Подходы: RICE, ICE, модель Кано, «Купи фичу», WSJF — на этих этапах надо учитывать мнение большего количества потребителей, потому нужно переходить на модели из правого верхнего квадранта.

Выход в лидеры

• Цель: стать лидером рынка.
• Подходы: WSJF, QFD — на этом этапе нужно учитывать стоимость упущенной выгоды от невыпуска фич вовремя, потому можно перейти на WSJF. 

Также на этом этапе возникает необходимость начать сравнивать продукт с конкурентами, чтобы сделать продукт-бестселлер, потому можно начать использовать подход QFD.

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

Какие подходы используют некоторые компании

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

Выводы

1. Выбор подхода к приоритизации функций должен учитывать стадию жизненного цикла продукта. 
2. Некоторые менеджеры продукта используют два подхода для приоритизации функций, на первом этапе разделяют список на 4 группы, например, с помощью MoSCoW, а затем для категории Must Have делают приоритизацию с помощью RICE или «Купи фичу». Использование второго подхода позволит получить приоритеты для функций, которые планируются в ближайшей версии продукта.
3. Подход к приоритизации можно менять при переходе с одного этапа развития продукта на другой.

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

Тогда записывайтесь на наш курс «Полное погружение в продакт-менеджмент»!

На курсе вы:

• Научитесь запускать внутренние и внешние продукты и управлять ими
• Улучшите метрики существующего продукта
• На практике систематизируете свои знания и освоите все аспекты продакт-менеджмента
• Освоите 50+ инструментов и фреймворков из мира продакт-менеджмента
• Научитесь использовать Искусственный Интеллект в целях продакт-менеджмента

А для владельцев, которые хотят оптимизировать работу команды и эффективно управлять ресурсами

Мы подготовили комплексный курс по agile, где вы:
Научитесь профессионально использовать Agile, Scrum и Kanban, выстраивать эффективную работу команды, быстро реагировать на изменения, визуализировать рабочие процессы и точно оценивать время выполнения задач.

В результате обучения вы:

• Освоите принципы Agile и откроете для себя мир гибкого управления
• Узнаете как управлять проектами и продуктами в условиях неопределенности с помощью гибких подходов
• Выясните для себя, как внедрить Agile в своей компании

На курсе мы разберем

• Как применять Scrum и Kanban на практике
• Как улучшить процессы своей команды и ускорить разработку продуктов
• Как претендовать на карьерное продвижение и многое другое!

В обучение входят:

• 17 занятий с практической отработкой
• 9 практикумов
• Шаблоны для эффективной работы с проектами и командами
• Бесплатная премиум подписка на Kaiten
• международный сертификат от консорциума ICAgile
• сертификат от Product Lab