Приоритизация фичей

29 июня 202029 июн 2020

13 мин

Оглавление

Введение
Что такое фича
Зачем вообще нужна приоритизация фичей

Введение

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

Что такое фича

Фича (англ. feature) — в жаргоне программистов, геймеров и других пользователей компьютеров, необычные программные возможности, особые функции, что-либо, что привлекает особое внимание. Из IT-сленга термин отчасти перекочевал и в обычную жизнь — необычные возможности техники (например, бытовой), интересный дизайн объектов, нестандартные функции также нередко называют фичами. Иногда слово фича в речи заменяют созвучным «фишка». Блоги и посты, посвященные фичам, называют фичреквестами. Распространено крылатое выражение-неологизм: «это не баг, а фича».

Зачем вообще нужна приоритизация фичей

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

Легче всего это понять на простом примере.

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

Записаться на курсы вождения
Начать изучать строение двигателя
Поиграть в Need For Speed

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

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

Для продакт-менеджера умение приоритизировать не просто полезный навык — это основа успеха в профессии.

Как оценивать фичи

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

Существуют различные подходы и виды оценивания. В сети бродит периодическая таблица техник приоритизации для продукта. Выглядит она так:

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

Вертикальная ось ранжирует методы от качественных (Qualitative) к количественным (Quantitative). В качественных методах все основано на экспертных (личных) мнениях, в количественных же на метриках, классификациях и так далее.

Также выделяют быстрые и медленные подходы к оценке фичей.

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

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

Основные методы приоритезации

Модель Кано

Модель Кано — технология, разработанная японцем Нориаки Кано в 1984 году. Именно тогда он опубликовал статью, в которой расписал методологию.

С помощью модели Кано можно наглядно описывать удовлетворение каких потребностей оставляет потребителей неудовлетворенными или же приводит в восторг.

Кано предлагает систему координат, где по оси Y измеряется удовлетворенность, по оси Х — уровень выполнения.

В модели Кано выделены 3 основные составляющие профиля качества, влияющие на удовлетворенность потребителя: ожидаемое, основное, и привлекательное, вызывающее восхищение.

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

Часто в качестве примера ожидаемых свойств приводят работу авиалиний. Гарантия того, что всем хватит места в салоне самолета – это ожидаемое свойство.

Основные свойства — это желаемое. Их выполнение влияет напрямую на удовлетворенность потребителя. Именно на основных свойствах продукты пытаются выделится и создать конкурентное преимущество.

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

Свойства, вызывающие восхищение — это неожиданные для потребителя свойства: дополнительные, необычные, носящие характер сюрприза.

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

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

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

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

Метод RICE Score

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

Reach — это охват

Impact — влияние

Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат

Effort — трудозатраты

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

Reach (Охват)

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

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

Impact (Влияние)

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

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

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

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

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

Подробнее о RICE

Пример расчета

Метод ICE

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

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

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

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

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

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

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

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

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

Scorecard

В технике Scorecard (Система показателей) цель состоит в том, чтобы определить приоритеты функций по набору критериев, которые были согласованы с заинтересованными сторонами.

Вот разумный довод Даниэля Элизальде по этому вопросу:

Начните с четкой стратегии, которая была проверена пользователями;
Выберите функции, которые наиболее связаны с общей стратегией для следующей версии;
Определите критерии и веса для подсчета очков;
Встретьтесь с заинтересованными сторонами и уточните критерии и вес;
Перейдите по всем функциям / темам и назначьте оценку (например, от 1 до 100) по их влиянию на каждый критерий.

Другим способом, позволяющим в полной мере использовать точечный масштаб, является определение функции/темы, которая считается посередине каждого критерия. Затем запишите все другие функции по сравнению с ним; более короткий масштаб (от 1 до 5) будет работать лучше всего в этом подходе.

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

Однако для этого метода существует здоровая критика:

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

MoSCoW

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

Этот термин является акронимом из букв, стоящих за одной из возможных категорий приоритетов (с добавлением “Os”, чтобы сделать ее легко запоминающимся). Требования классифицируются следующим образом:

Must have (Должно быть) — они имеют решающее значение и должны быть включены в продукт. Если даже одно требование не включено, релиз считается провальным. Они могут быть опущены, если между заинтересованными сторонами будет достигнуто согласие.
Should have (Надо бы иметь) — эти требования важны, но не имеют решающего значения для выпуска. Они являются первым уровнем «Nice to have» (Хорошо бы иметь) и, как правило, разделяют важность требований “Должно быть”, не будучи настолько чувствительными к времени.
Could have (Могут быть) — эти требования желательны, но не нужны для выпуска. Обычно это недорогие усовершенствования продукта. Из-за их меньшей важности они являются вторым уровнем функций «Nice to have».
Won’t have (Не будут) — они считаются наименее критичными или даже не соответствуют стратегии продукта. Они должны быть отброшены или пересмотрены для будущих выпусков.

Этот метод предлагает быстрое и простое решение для определения приоритетов. Проблема связана с отсутствием классификации по категориям. Например, как мы можем узнать, какие требования ДОЛЖНЫ быть или МОГУТ быть более важными, чем другие? Из-за этого ограничения метод MoSCoW, вероятно, лучше подходит для внутренних проектов, а не для продуктов с большим количеством клиентов — общение с несколькими заинтересованными сторонами в тонкостях приоритизации всегда будет проще, чем более крупный контакт с конечными клиентами.

QFD

QFD (Quality Function Deployment) или Развертывание функции качества.

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

В статье Джеффа Сауро описывается как использовать QFD для цифровых продуктов. Вот суть процесса:

1. Определите желания и потребности клиентов

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

2. Определите «Голос клиента»

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

3. Определите How (Голос Компании)

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

Связь между «Голосом клиента» и «Голосом компании»

Установите взаимосвязь между тем, Что и Как хотят клиенты, и тем, как компания предлагает с этим разобраться. Эти отношения следует оценивать в нелинейном масштабе, поэтому различия в воздействии более акцентированы. Это общие значения, которые должны быть определены для каждой комбинации Want + How:

9 → Прямые и сильные отношения
3 → Умеренные отношения
1 → Слабая / косвенная связь
Пусто → Нет отношений

5. Создание приоритетов

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

6. Изучите приоритеты

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

Так выглядит QFD-матрица, следуя методу Сауро.

Story Mapping

Методология Story Mapping стала известна в начале века из статьи Джеффа Паттона.

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

Горизонтальная ось представляет последовательность использования. Задачи на ней размещаются в последовательности, в которой они выполняются пользователем.

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

Группы связанных историй группируются как активности.

Сильные стороны методологии Story Mapping

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

Метод четко определяет, как постепенно выпускать итерации продукта.

Выводы

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

В заключении приведу краткий алгоритм приоритизации:

1. Найдите ТОП-3 ключевые метрики для конкретного сервиса.

2. Соберите гипотезы для прокачки этих метрик: из бэклога или вне его.

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

4. Проведите быструю оценку и отбросьте «слабые» фичи.

5. Проведите детальную оценку оставшихся фичей.