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

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

Со всеми заинтересованными лицами договариваться о приоритетах задач. Установить четкие критерии приоритизации бэклога.

Story Mapping, MoSCoW, Value/Effort, ICE Scoring

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

Если собрать 5 топов одной крупной IT–компании и попросить их расставить приоритеты к своим задачам, то каждый будет ставить своим нулевой приоритет. То есть именно их нужно брать и делать прямо сейчас. Как же быть в такой ситуации?

Есть хорошие новости. Существует несколько методы, которые помогают с этим справиться.

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

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

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

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

Для продуктов, которые только–только запускаются, определяем: сроки, ресурсы и содержание. На каждом этапе смотрим, что можно сократить, что увеличить. Собираемся всем командой и набрасываем как можно больше идей по продукту. Затем их все оцениваем. Лучшие добавляем на Story Map (карту историй).

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

Перед компанией стояла задача: запустить с нуля игру для пользователей системы платежей Qiwi. Сроки: 3- 5 недель.

Игра в чем–то схожа с Зимними Олимпийскими играми. Участники выполняют задания, делают покупки и получают за это пройденные километры. Всего в игре 9 этапов. За каждый пройденный этап полагается кэшбэк. А если пройти все — то есть шанс получить главный приз в 1 миллион рублей, его разыгрывают между всеми участниками, кто накопит больше 7 тысяч километров.

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

• Пользователь узнал об игре

• Понял выгоду и захотел поучаствовать

• Захотел выполнить все задания и получить призы.

Затем провели брейншторм с командой и выписали идеи, как это все можно реализовать. Самые реалистичные выписали на стикеры и все разбили по этапам. Вот что получилось:

Цветами отразили сроки и сложность. Так, темно–зеленым выделили то, что реализовать проще и быстрее всего. Желтым — то, что чуть сложнее. Синим — самое сложное и долгое.

Оценили сроки, те задачи, которые выполнить вовремя никак не получалось — убрали. В итоге оставили по 2-3 задачи каждого уровня сложности. Получили более реалистичную карту:

И начали ее реализовывать. В итоге компания успела выпустить игру за 5 недель.

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

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

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

M — must have. Это тот самый функционал, без которого далеко не уедешь. То, без чего продукт не заработает и никому не будет нужен. Здесь задачи и требования с самым высоким приоритетом.

S — should have. Если вернуться к примеру с машиной, то это двери, фары и сидения, вместо табуреток. Это важные требования к продукту, но не с самым высоким приоритетом.

C — could. То, что желательно сделать к релизу. В машине это будет коробка автомат, вместо механики, например.

W — would. Это все остальное, наименее критичные требования. Если не успеете — не страшно, их можно будет перекинуть на следующий релиз.

На конкретных примерах понять будет легче. Разберем пример Hygger. Это платформа для управления проектами.

Must have для них — внедрить график для отбора самых ценных идей и передачи их в разработку. Ранжировать идеи по метрикам Value (ценность) / Efforts (усилия). Предоставить поддержку командам разработки с помощью досок Kanban и Sprint. Чтобы отслеживать прогресс по принту добавить Burndown Chart.

Should have — внедрить функцию Time tracking (чтобы учитывать отработанное время). Внедрить Cycle /Lead Time Report, чтобы контролировать процессы. Выполнить интеграцию с корпоративным мессенджером Slack, чтобы получать обновления на досках.

Could have — создать раздел My Tasks, чтобы отслеживать задачи и статусы. Добавить функцию Client Access, чтобы приглашать/добавлять клишкалуентов в проект.

Would have — организовать SAML SSO /G Suite SSO для единого входа всех сотрудников в приложение. Внедрить функцию Calendar View для доски. Добавить интеграцию с системами управления проектами: JIRA, PivotalTracker, Trello.

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

Как работает: рисуем (или используем готовые инструменты/платформы для управления продуктами) две шкалы Value (ценность) и Effort (усилия). Рисунок будет выглядеть как большой знак плюс.

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

Привлечение (acquisition) — это задача поможет привлечь новых клиентов в продукт?

Активация (activation) — как скоро пользователи ощутят ценность новой функции?

Охват (reach) — скольких клиентов охватит новая функция?

Доход (revenue) — как эта функция поможет продукту зарабатывать?

Удержание (retention) — поможет ли эта функция удерживать или возвращать клиентов в продукт? Сделает ли она их активнее?

Виральность (virality) — пользователи станут приглашать больше друзей/коллег в продукт? То есть, как функция повлияет на виральность?

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

Кому подойдет: когда вы только планируете делать ту или иную функцию продукта, оцениваете эффект от нее.

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

Для удобства идем по каждой букве аббревиатуры ICE:

I — Impact. Это влияние новой функции на продукт с точки зрения стратегии бизнеса (привлекает ли новых пользователей, удерживает ли существующих, улучшает ли конверсию в покупку, добавляет ли ценности продукту). Либо оцениваем сколько денег эта фича принесет, что она даст пользователям. Используем шкалу оценки от 1 до 10 или до 100, чтобы разбег был побольше.

C — Confidence. Это про вашу уверенность в идее, оценку того, насколько сложно ее будет реализовать, влияние на продукт в целом. Допустим, вы придумали какую–то функцию и, конечно, считаете, что она круто повлияет на продукт. Но аналитики нет, и чем ниже уверенность команды в вашем личном мнении, тем ниже будет оценка. Также от 1 до 10. Уверенность может опираться не только на личное мнение, но и на аналитику, опросы и интервью пользователей, A/B тесты, UX–исследования, наблюдения за конкурентами и тп.

E— Ease. Насколько сложно будет реализовать этот самый функционал. Чем проще, тем балл выше.

Чтобы рассчитать ICE просто перемножьте все три параметра:

ICE Scoring= impactconfidenceease. Чем больше оценка, тем выше приоритет этой задачи.

Представим, что у нас есть три гипотезы:

• Если переверстать все страницы интернет–магазина, то мы упростим путь пользователя до оплаты товаров. Конверсия из трафика в покупки вырастет.

• Если добавим на сайт алгоритм подбора релевантного контента, то увеличим метрику stickiness, клиенты будут больше времени проводить у нас.

• Если изменим текст на главной странице, то увеличим конверсию из трафика в зарегистрированных пользователей.

Теперь начнем оценивать.

Первая гипотеза:

• за влияние на целевую метрику — 5 баллов

• за нашу веру в результат — 3 балла

• за простоту в реализации — 4 балла.

Вторая гипотеза:

• за влияние на целевую метрику — 7 баллов

• за нашу веру в результат — 7 баллов

• за простоту в реализации — 3 балла.

Третья гипотеза:

• за влияние на целевую метрику — 3 балла

• за нашу веру в результат — 3 балла

• за простоту в реализации — 9 баллов.

Теперь перемножаем баллы по каждой гипотезе и получаем:

60 баллов у первой гипотезы, 147 баллов у второй гипотезы, 81 балл у третьей гипотезы.

Значит, нулевой приоритет отдаем гипотезе номер два. Ее и надо делать в первую очередь.