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

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

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

Метод RICE Score

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

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

Узнай, какие ИТ - профессии
входят в ТОП-30 с доходом
от 210 000 ₽/мес

Павел Симонов

Исполнительный директор Geekbrains

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

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!

Скачивайте и используйте уже сегодня:

Павел Симонов

Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

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

Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка

Только проверенные нейросети с доступом из России и свободным использованием

ТОП-100 площадок для поиска работы от GeekBrains

Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽

Получить подборку бесплатно

pdf 3,7mb

doc 1,7mb

Уже скачали 31984

Единицы, в которых рассчитывается каждый показатель, мы выбираем сами. Например, влияние фичи можно оценить как процентную величину от 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) – «хотелки». Фичи-пасхалки, дополнительный контент — например, ивенты внутри приложений.

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

Модель Кано

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

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

Читайте также!

Soft skills: почему они сегодня столь важны

Подробнее

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

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

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

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

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

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

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

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

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

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

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

Дарим скидку от 60%
на курсы от GeekBrains до 01 декабря

Уже через 9 месяцев сможете устроиться на работу с доходом от 150 000 рублей

Забронировать скидку

У методологии 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

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

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

Только до 25.11

Скачай подборку материалов, чтобы гарантированно найти работу в IT за 14 дней

Список документов:

ТОП-100 площадок для поиска работы от GeekBrains

20 профессий 2023 года, с доходом от 150 000 рублей

Чек-лист «Как успешно пройти собеседование»

Чтобы получить файл, укажите e-mail:

Введите e-mail, чтобы получить доступ к документам

Подтвердите, что вы не робот,
указав номер телефона:

Введите телефон, чтобы получить доступ к документам

Скачать подборку бесплатно pdf 2,5mb

Уже скачали 52300

Я подтверждаю согласие на обработку персональных данных.

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

«Walking Skeleton»

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

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

Модель Systemico

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

Читайте также!

Сквозная аналитика: этапы внедрения, базовые настройки

Подробнее

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

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

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

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

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

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

Автор статьи:

Екатерина Никерина