10 способов разобраться в своём бэклоге 

10 способов разобраться в своём бэклоге 

Ты можешь быть прекрасным скрам-мастером, но какой в этом смысл, если ты не умеешь приоритизировать свой бэклог
8 минут953

Финансовые отчёты демонстрируют очевидное: правильная оценка рассчитывается на основе ROI, NPV, времени окупаемости или хотя бы чистой прибыли. К сожалению, на практике этот метод неприменим, поскольку просчитать всё это заранее очень сложно, либо невозможно вовсе. Поэтому приоритизация элементов бэклога — один из актуальных и непростых вопросов в управлении продуктом. Ведь значительная часть предположений о ценности или сложности фичей остаётся приблизительной вплоть до старта разработки. 

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

Метод RICE Score

Один из самых популярных методов приоритизации в крупных IT-компаниях. Аббревиатура RICE включает 4 фактора — Reach, Impact, Confidence, Effort, — которые влияют на оценку важности продуктовых фичей.

  • Reach — охват, то есть количество людей, которые опробуют функциональность.
  • Impact — ценность фичи для процесса, к которому она имеет отношение, например, для вашего user flow или привлечения новых пользователей. Это может быть и уровень её новизны, и уникальности на нашем рынке.
  • Confidence — уверенность в оценке охвата, влияния и трудозатрат. Иными словами, величина риска. Обычно Confidence является процентным показателем. Показатель снижается, когда точность остальных метрик сложно посчитать.
  • Effort — трудозатраты (количество человеко-часов, требуемых для разработки и внедрения).

Единицы, в которых рассчитывается каждый показатель, мы выбираем сами. Например, влияние фичи можно оценить как процентную величину от 0% до 100% или же присвоить ей рейтинг по 10-балльной шкале. RICE Score рассчитывается по формуле для каждой из фичей бэклога, требующих оценки: 

RICE Score = Reach X Impact X Confidence / Effort 

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

Метод ICE Score

ICE Scoring похож на RICE, но учитывает только три показателя: 

  • Impact – влияние
  • Confidence – уверенность
  • Ease – простота реализации

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

ICE Score = Impact X Confidence X Ease 

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

Недостаток метода в его субъективности. Разные люди могут оценить одну и ту же фичу по-разному. В этом плане трудозатраты RICE Score являются более сбалансированным показателем. 

Метод MoSCoW 

Аббревиатура MSCW в данном случае – степени приоритетности:

  • M (must) – задачи, которые имеют самый высокий приоритет и обязательно должны быть выпущены к релизу. Это могут быть элементы базовой функциональности или фикс критичных ошибок. 
  • S (should) – требования, не имеющие критического значения, но важные для разработки. К ним можно отнести оптимизацию процессов, весомый технический долг. 
  • C (could) – желательные требования. Например, это будут фичи, которые улучшат пользовательский опыт при уже приемлемых показателях удовлетворённости. 
  • W (would) – «хотелки». Фичи-пасхалки, дополнительный контент — например, ивенты внутри приложений. 

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

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

Модель Кано

Модель Кано базируется на системе координат, где по оси Y измеряется степень удовлетворённости функциональностью, по оси Х — степень реализации фичи (её наличие или отсутствие). 

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

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

Возможные ответы:

  • Мне она нравится.
  • Я ожидаю её.
  • Я нейтрально отношусь к фиче.
  • Я могу это терпеть.
  • Мне это не нравится.

В итоге мы можем выделить следующие категории фичей:

  1. Нейтральные функции (у пользователей нет восторга при их наличии и нет раздражения при их отсутствии). Чаще всего это следствие гипотез, не проверенных с помощью кастдевов. 
  2. Обязательные функции (не вызывают восторг при наличии, зато вызывают раздражение при их отсутствии). Это важные для реализации функции, которые при этом не могут играть роль конкурентных преимуществ.
  3. Желанные функции, вызывающие восторг при их наличии. Например, расширенная программа лояльности или реферальная программа. Именно они могут стать конкурентными преимуществами. 
  4. Одномерные — чем лучше реализована такая фича, тем она привлекательнее для пользователя. К таким относится система скидок, свободное место в приложении, количество доступного контента. 

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

b_5a43a74b1cdba.jpg

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

Методология KJ

Суть этого метода — в привлечении команды для расстановки приоритетов.

Для реализации нужны модератор, флип-чарт со стикерами и команда (рабочая группа), собранные в одной переговорке. Порядок работы таков:

  1. На стикерах выписываются все фичи, которые нужно приоритизировать. Они могут быть известны заранее либо сформулированы и расставлены во время митинга. 
  2. Каждый участник команды или рабочей группы расставляет приоритеты на основании субъективной оценки ценности. Результатом работы каждого сотрудника является его собственный рейтинг. При этом каждый может добавить новые стикеры, то есть новые идеи, которые посчитает нужными. 
  3. Схожие темы стикеров группируются, и команда голосует за важность каждой темы. Результаты голосования становятся результатами приоритизации. 

У методологии KJ есть интересное расширение: игра «Купи функцию».

«Купи функцию»

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

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

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

Weighted Shortest Job First

Система оценки, согласно которой каждой фиче присваивается коэффициент в зависимости от атрибутов — Business value, Time Criticality, Risk Reduction or Opportunity Enablement, Job Duration. Чем выше коэффициент, тем приоритетнее задача. 

Факторы, влияющие на итоговый коэффициент:

  • Ценность для клиента/бизнеса (Business value) — показывает, насколько выполнение конкретной задачи будет полезно клиентам и бизнесу.
  • Срочность (Time Criticality) — насколько критично выполнить задачу сейчас. Например, от этого зависит конкурентное преимущество или доступ к разработке новых фичей. 
  • Минимизация рисков или реализация возможностей (Risk Reduction or Opportunity Enablement) — насколько фича снизит риски продукта или откроет новые возможности для развития. 
  • Длительность разработки = уровень сложности работы (Job Duration). Измерение этого показателя в поинтах позволяет на верхнем уровне оценить затраты на разработку относительно друг друга.

Итоговый коэффициент рассчитывается по формуле: 

WSJF = Cost of Delay / Job Duration

Cost of Delay = Business value + Time Criticality + Risk Reduction

Technology Risk Based 

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

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

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

«Walking Skeleton»

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

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

Модель Systemico

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

Для оценки необходимо собрать данные:

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

Принято разделять этот этап на 4 категории:

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

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

Преимущество этого метода — в чётком разграничении по задачам Core-, Use-, Engage- и Explore-функций. Метод применим для работы с пользователями на разных уровнях конкретики: от условного пользовательского пути, до конкретных интерфейсов.

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

Сентябрь — отличное время, чтобы построить далеко идущие планы и начать идти к новым целям! Если вы хотите освоить профессию мечты, то с 1 по 11 сентября 2020 г. мы дарим вам скидку 40% почти на все программы обучения GeekBrains. Успехов! :)

 

менеджментproductmanagement
Нашли ошибку в тексте? Напишите нам.
Спасибо,
что читаете наш блог!
Posts popup