Что такое бэклог продукта и бэклог спринта
📌 Бэклог продукта — приоритизированный список будущих функций. Он подвижный: его формируют и меняют запросы бизнеса, требования и пожелания аудитории, тренды рынка, запросы заинтересованных сторон (заказчиков или стейкхолдеров).
Если говорить по факту, как это работает в Scrum–командах: бэклог продукта — это функции продукта, которые нужно выпустить в ближайшие месяцы. Бэклог представляет собой список пользовательских историй, оцененных по приоритету и трудозатратам.
Бэклог продукта формирует бэклог спринта — перечень функций, которые нужно разработать за один период работы, то есть спринт. Спринт длится от двух до четырёх недель. Задачи для него берут из бэклога продукта — в порядке приоритетов.
Бэклог продукта приоритизируют с помощью методов, которые мы описали ниже. Затем проделывают то же самое с бэклогом спринта — учитывая загруженность команды и сложность задач.
Рассмотрим на примере. Мы разрабатываем мобильное приложение по доставке еды. Что нам нужно разработать:
✔️ Аккаунт пользователя, корзину и личный кабинет
✔️ Каталог с поиском по фильтру, карточки товаров с описанием, отзывами и рейтингом
✔️Оплату
✔️ Отслеживание заказа
Это будет бэклогом продукта.
Но в бэклог спринта сразу так много не войдёт. За спринт можно реализовать только часть функциональности — к примеру, возможность выбрать, заказать и оплатить товар.
Зачем нужно приоритизировать бэклога
Когда фичу берут из бэклога в работу, времени на десять других не остаётся. И наоборот — решая не создавать фичу, команда освобождает время и ресурсы на что-то другое.
Приоритизация помогает решить, что важно сделать в ближайшее время. А ещё:
- Команда знает, когда и над чем будет работать. Это повышает её производительность
- Компания успешнее фокусируется на запросах рынка и аудитории — а это залог успеха продукта
- Совместное обсуждение пула задач позволяет сотрудникам чувствовать вклад в общее дело. Это повышает командный дух
- Снижаются риски — команде проще находить и решать важные задачи, которые влияют на успех проекта
Как расставить приоритеты в бэклоге
Шкала приоритетов формируют несколько факторов.
Дорожная карта продукта, или roadmap
Не путать с бэклогом продукта: карта задаёт стратегическое направление развития. Это бизнес-инструмент, а бэклог — рабочий инструмент для разработчиков и других команд. В дорожной карте выставляют общие этапы и приоритетность, которые влияют на бэклог продукта.
Стратегически важные задачи из дорожной карты как правило приоритетнее остальных. Ещё этот инструмент помогает видеть параллельные этапы и учитывать их связи при формировании бэклога.
👉 Подробнее про дорожную карту
Обратная связь от пользователей
Информация, собранная с помощью кастдевов, из отзывов и после других касаний. Помогает определить, какие функции востребованы у юзеров. Если что-то ценно для аудитории, значит, это также может быть приоритетно.
Тут начинается лавирование между приоритетами бизнеса из дорожной карты и приоритетами от аудитории. Запросы, которые приходят от пользователей, требуют дополнительной продуктовой и бизнес-верификации приоритетами и оценкой востребованности. Если выполнять все хотелки подряд, получится не продукт, а винегрет из функций.
Изменения на рынке
Появление сильных конкурентов или новый уникальный продукт порой меняют ситуацию на рынке и влияют на расстановку приоритетов.
В 2023 году так выстрелили нейросети. Встроенный ИИ в любом виде стал «новым чёрным» в среде цифровых продуктов — и для многих команд это стало приоритетом. В таких ситуациях задачи, влияющие на конкурентоспособность, выходят на первый план.
Сложность и объём задач
Это последний и не менее важный рубеж для приоритизации задач, причём наиболее актуальный для команды. Ведь функции реализовывают разработчики — и если окажется, что приоритетная задача не укладывается в спринт, её нужно либо дробить (и снова приоритизировать), либо растягивать на несколько спринтов.
В случае, когда недоработанные приоритетные задачи встревают в текущий спринт, может возникнуть конфликт приоритетов с будущими задачами. Тогда нужно договариваться с командой о том, сколько приоритетных для бизнеса фич могут войти в один спринт — то есть вводить ограничения на количество работы.
❗Ещё есть фиксы багов. Такие задачи почти всегда меньше и проще, чем разработка фич с нуля. У них всегда высший приоритет.
6 методов приоритизации задач в бэклоге
Факторов, которые могут повлиять на приоритеты в бэклоге, много. И они существуют одновременно. Чтобы не разрываться в противоречиях, нужны внешние объективные методы оценки приоритетов — вот шесть из них.
MoSCoW
Приоритизирует задачи и цели по четырём уровням:
- Must Have — обязательные, без которых продукт не имеет смысла
- Should Have — желательные, которые стоило бы реализовать после обязательных
- Could Have — хотелки и идеи, которые могли бы добавить уникальности продукту
- Would Have — необязательные, то, без чего продукт обойдётся. Либо это никогда не будет реализовано, либо в более поздние спринты
Этот метод позволяет отобрать критически важные функции при разработке — в нашем мобильном приложении это, например, наличие списка продуктов для доставки. А рейтинг и отзывы можно отложить на потом.
Value vs. Effort
Матрица предлагает сравнить все задачи по двум параметрам: ценность (value) и усилия, необходимые для реализации (effort).
Ценность — это что мы получаем, а усилия — какой ценой мы это получаем. Матрица сочетает количественную и качественную оценку и показывает, есть ли смысл в выполнении задачи. Например, стоит ли разработка фичи вложенных в неё денег.
👉 Почитать подробнее про методы MoSCoW и Value vs. Effort
WSJF (Weighted Shortest Job First — более ценная и простая задача сначала)
Этот метод соотносит ценность задачи и трудозатраты на её выполнение. Расчёт производится по формуле:
Cost of delay — сложность выполнения работы, включает:
- User-Business Value (бизнес–ценность) — какую пользу получит проект: новая фича, снижение затрат на разработку и так далее
- Time Criticality (временная критичность или спешка) — насколько важно выполнить задачу быстро
- Risk Reduction (фактор риска) — насколько задача снижает риски
- Opportunity Enablement (фактор возможностей) — принесёт ли это новые возможности. Например, новых клиентов
Job size — это оценка времени и усилий на выполнение задачи. Считается в человеко-часах или днях. Оценка производится с помощью StoryPoints — единиц оценки трудоёмкости работы.
Так выглядит пустая таблица:
👉 И забрать её можно отсюда
На выходе получится список, в котором задачи будут убывать по ценности для проекта.
Buy a Feature (купить фичу)
Суть метода в том, чтобы смоделировать бэклог для клиентов и предложить им самим выбрать приоритетную фичу. Здесь важно выбрать понятные, большие и ощутимые для клиентов задачи: смена интерфейса, добавление или удаление фич, улучшение клиентского сервиса.
❗Пунктов должно быть не больше десяти. Каждая задача имеет «цену», а у клиентов есть «баллы», которыми они голосуют за ту или иную фичу.
Так будет выглядеть шаблон:
👉 Взять его с готовой формулой можно тут
А вот пример того, как выглядит заполненная таблица:
Удивишься, но по итогам приоритетными для клиентов могут оказаться совсем не те фичи, на которые ставил ты.
Kano
Kano основывается на идее, что не все фичи одинаково влияют на удовлетворение пользователей. Метод делит задачи бэклога на пять категорий.
Рассмотрим на примере приложения доставки:
- Базовые — нужные для конкурентоспособности: возможность заказать продукты
- Ожидаемые — производительные характеристики: возможность находить и добавлять продукты в корзину
- Привлекательные — фичи, которые порадуют клиентов: рейтинг товара
- Нежелательные — то, что снижает удовлетворённость пользования: баги и долгая загрузка
- Неважные — не вызывают эмоций: доска сотрудников месяца
Метод позволяет проанализировать разные атрибуты продукта и показывает, какие фичи порадуют юзеров.
RICE
Приоритизирует задачи по четырём критериям:
- Reach (Охват) — сколько пользователей затронет фича или сколько событий произойдёт. Берётся показатель на выбранный период: как много людей обратится в чат поддержки за сутки?
- Impact (Влияние) — как сильно фича повлияет на пользователей: на сколько по шкале от 1 до 3 создание раздела «Избранное» увеличит количество покупателей?
- Confidence (Уверенность) — субъективный параметр уверенности в своих оценках, где 50% — это низкая уверенность, а 100% — высокая, когда есть данные по охвату и значимости.
- Effort (Затраты) — сколько человеко-часов уйдёт на создание фичи. Прокачанные команды используют для оценки сторипоинты.
Задачи с наивысшими RICE-оценками получают приоритет.
👉 Подробнее о том, как применять этот метод
Как приоритизировать бэклог — пошаговое руководство
Рассказываем, как сделать это за пять шагов.
Шаг 1. Определить видение и цели продукта
Обратись к дорожной карте продукта. Цели, записанные в ней, определяют важные для развития продукта задачи.
Дорожная карта формирует стратегический план развития продукта. Она задаёт приоритеты на длительный промежуток времени — чаще всего на ближайший год, самое меньшее — квартал.
Это этап определения бизнес-приоритетов. Дальше следующая ступень — определение потребностей аудитории.
Шаг 2. Понять потребности пользователей
Продуктовые команды постоянно работают с аудиторией — проводят кастдевы, коридорки, глубинные интервью, анализируют отзывы. Запросы от пользователей также «падают» напрямую — скажем, заходит крупный клиент и просит конкретный набор функций.
Нередко именно запрос от пользователей выдвигает фичу в приоритет. Но при правильном подходе нужно идти в таком порядке:
➡️ появился запрос на фичу — например, от отдела продаж к разработке
➡️ разработчики не кидаются делать их, а идут к продактам
➡️ те верифицируют востребованность у большей части аудитории
➡️ если запрос на фичу есть — он включается в приоритетные задачи
Шаг 3. Разбить цели на управляемые задачи
Как уже ни раз намекнули, даже если сделать очень большую задачу приоритетной, вас с командой разорвёт на части.
Например, наша цель: проработать дизайн. Чтобы сделать её достижимой, надо разбить её на мелкие задачи и приоритизировать уже их. И тогда бэклог будет состоять из разработки дизайна кнопок, текстовых полей и так далее.
Шаг 4. Применить техники приоритизации
Для приоритизации используй одну из техник, описанных выше ☝️
Применили? Зафиксируйте в бэклоге. Лучше сразу разметить задачи с помощью маркеров приоритетов. Если используете оценки задач в цифрах, то можно расставить теги или значения кастомных полей.
Шаг 5. Пересматривать и обновлять бэклог
Иногда внешние запросы, которые определяли приоритеты, могут поменяться.
Например, сегодня мы следуем целям дорожной карты, а завтра крупный стейкхолдер требует новую фичу. Или вдруг множество пользователей стали жаловаться на баги. Либо оценка сложности задач оказалась неверной, и надо пересматривать подходы.
Нужно регулярно синхронизироваться командой и собирать обратную связь, а также «спускать» от продукта и бизнеса информацию о смене приоритетов.
Роль команды в приоритизации бэклога
Взаимодействие в команде позволяет сбалансировать цели, технические требования и пользовательские ожидания. За что отвечает каждый сотрудник:
- Менеджер продукта отвечает за общее видение и стратегию продукта, согласовывает приоритеты задач с целями развития, пользователями и дорожной картой.
- Разработчики оценивают технические аспекты и знают, как оценить задачи с точки зрения реалистичности, затрат времени и ресурсов.
- Дизайнеры знают всё о пользовательском опыте и о том, как оценить влияние задач на удобство и привлекательность продукта для клиента.
- Маркетологи анализируют рынок, отслеживают конкурентов и тренды, что помогает в оценке приоритетов.
Проблемы при приоритизации бэклога и как их решить
Приоритизация имеет свои слабые места. Перечислим основные проблемы и методы решения.
Субъективный выбор приоритетов. Когда приоритеты выставляются так, как придёт в голову владельцу продукта.
🔧 Решение. Находить подтверждение приоритетности задач вовне.
Несогласованность в команде. Например, менеджер продукта считает приоритетными стратегические задачи, в то время как разработчики или дизайнеры отстаивают свои.
🔧 Решение. Проводить регулярные встречи для обсуждения приоритетов и целей. На этих встречах должен быть тот, кто будет транслировать задачи и цели бизнеса, при этом понимая их связь с реальными запросами аудитории.
Слишком много задач. Переполненный задачами бэклог делает проект тяжёлым и неповоротливым. Команде сложно сосредоточиться на задачах.
🔧 Решение. Использовать такие фреймворки, как MoSCoW, RICE или WSJ с целью оставить в списке только важные задачи. Пересматривать бэклог и удалять неактуальные задачи.
Конфликт долгосрочных и краткосрочных задач. Когда тушение мелких пожаров отвлекает от стратегических задач.
🔧 Решение. Разделить задачи на краткосрочные и долгосрочные, выделить ресурс на каждую категорию. Пересматривать бэклог, чтобы контролировать долгосрочные цели.
WEEEK как инструмент для приоритизации бэклога
Рассказываем, какие функции в WEEEK помогут расставить задачи по приоритетам и организовать удобный бэклог.
Маркер приоритета
У нас четыре маркера приоритета: Высокий, Средний, Низкий, Замороженный. При их расстановке задача окрасится в красный, жёлтый, зелёный и голубой цвета.
Потом найти задачи с нужным приоритетом можно с помощью фильтра либо отсортировать по приоритету.
Теги и кастомное поле для выставления оценки
После оценки приоритета и сложности задачи по одному из методов у вас появится цифра — та самая оценка. Её стоит перенести внутрь таск-менеджера.
Поставить оценку можно с помощью тега. Для этого достаточно ввести число в строчку «Тег» и оно появится на задаче. Правда так можно создать очень много разных тегов — и в рабочем пространстве будет хаос.
Если вы с командой из раза в раз используете одинаковые оценки — скажем, сторипоинты в формате S, M, L, XL — лучше использовать кастомные поля с выбором из готовых значений.
Создай кастомное поле с форматом «Выбор», присвой ему название — например, «Оценка» — и задай собственные значения.
Кастомное поле так же удобно использовать, если у вас разные значения. Для этого подойдёт поле в формате «Текст» — там вы с командой сможете прописывать любые обозначения сложности.
Приоритизированные выводы
- Бэклог продукта — это список всех будущих фич продукта
- Бэклог спринта — это перечень фич для разработки в одном спринте
- Приоритизация помогает команде быть адаптивной и сосредотачиваться на важных задачах, снижает риски и показывает, над чем команда будет работать
- Чтобы правильно расставить приоритеты, нужно смотреть на дорожную карту продукта, запросы клиентов по итогам кастдевов, изменения на рынке, сложность и объём задач
- Методы приоритизации помогают сформировать бэклог и подбираются под определённые задачи и команды
- Для приоритизации бэклога нужно определить видение и цели продукта, понять потребности юзеров, затем декомпозировать задачи и выбрать метод приоритизации. Собранный бэклог нужно регулярно обновлять
- WEEEK упрощает процесс приоритизации с помощью фич для автоматизации, аналитики и отчётов
Подписаться 
