Задач по продукту часто оказывается больше, чем команда успевает сделать в ближайшее время. Идеи приходят от клиентов и руководителей, ошибки находят пользователи, требования меняются по ходу работы, а дедлайны подгоняют все сразу. Без общего порядка этот поток превращается в хаос: срочное вытесняет важное, а договоренности остаются в чатах и памяти отдельных участников.
Структурированный план действий из такого хаоса помогает собрать бэклог продукта (backlog). Он объединяет задачи в один список и выстраивает их по ценности для продукта, поэтому команда, владелец продукта и бизнес опираются на одни и те же приоритеты. Маркетологу, проектному менеджеру или владельцу небольшого бизнеса он показывает, какие задачи есть у команды разработки и в каком порядке их планируют.
В статье разобраны определение бэклога, его состав и примеры формулировок, отличие от бэклога спринта и дорожной карты, роли в команде и порядок составления. Отдельные разделы посвящены приоритизации задач, ведению бэклога в доступных в России инструментах и типичным ошибкам.
- Что такое бэклог продукта
- Зачем нужен бэклог продукта
- Что входит в бэклог продукта
- Примеры бэклога продукта
- Бэклог продукта в Scrum и Agile
- Как составить бэклог продукта
- Приоритизация задач в бэклоге
- Как управлять бэклогом
- Типичные ошибки при ведении бэклога
- Частые вопросы о бэклоге
- Коротко о главном
Что такое бэклог продукта
Бэклог продукта (backlog, product backlog) — упорядоченный, постоянно развивающийся список того, что нужно для улучшения продукта. В Scrum, методологии командной разработки, где работа идет спринтами, он служит единственным источником работы команды.
Простыми словами, это список задач по продукту с приоритетами: сверху лежит то, что команде нужно сделать раньше, снизу то, что подождет. Бэклог входит в гибкую методологию разработки как артефакт Scrum, а в более широком смысле глоссарий Agile Alliance описывает его как перечень новых функций, изменений существующих функций, исправлений ошибок, изменений инфраструктуры и других действий, которые команда может выполнить ради определенного результата. Попадание в список не гарантирует, что задачу выполнят: пункт бэклога остается вариантом, а не обязательством.
Зачем нужен бэклог продукта
Бэклог дает команде общий порядок работы над продуктом: видно, что делается сейчас и что идет следующим. Практическая польза складывается из трех вещей.
- Приоритет и фокус. Такой перечень задач помогает определить, над какими задачами работать в первую очередь, а какие отложить. Команда сосредоточивается на изменениях с наибольшей пользой и для продукта, и для его пользователей, а второстепенные цели не отвлекают.
- Прозрачность. Список служит единым централизованным источником информации о планируемых задачах, поэтому о текущем состоянии знают все участники команды, а не только сами разработчики.
- Адаптивность. В отличие от жесткого плана, бэклог — живой документ: его корректируют по мере появления новых требований и идей.
Что входит в бэклог продукта
В бэклоге лежат задачи нескольких типов, и всех их объединяет связь с улучшением продукта. Формат пунктов выбирает сама команда, чаще всего это пользовательские истории.
- Пользовательские истории — описания сценариев с точки зрения пользователя или другого получателя пользы. Например: «Как пользователь, я хочу иметь возможность войти в приложение через свой аккаунт Google, чтобы быстрее регистрироваться».
- Исправление ошибок, или багов (Bug Fixes) — задачи по устранению обнаруженных ошибок. Например: «Исправить ошибку, из-за которой приложение вылетает при нажатии на кнопку “Отправить”».
- Технические задачи — улучшение качества кода, рефакторинг, оптимизация производительности или модернизация инфраструктуры. Например: «Рефакторинг модуля авторизации для повышения безопасности».
- Исследования и эксперименты — исследования рынка, анализ поведения пользователей, A/B-тестирование и другие эксперименты, направленные на улучшение ПО. Например: «Провести A/B-тестирование двух вариантов дизайна главной страницы для повышения конверсии».
Часть технических задач составляет работа по возврату технического долга. Технический долг — метафора Уорда Каннингема: накопленные недостатки внутреннего качества кода усложняют изменение и расширение системы, а дополнительные усилия на новые функции выступают процентами по долгу. По описанию Мартина Фаулера, выплачивать такой долг лучше постепенно.
%201.png)
%201.png)
%201.png)
%201.png)
%201.png)
Примеры бэклога продукта
Формулировки задач для разных продуктов показывают, как типы из предыдущего раздела выглядят на практике.
| Продукт | Пользовательская история | Исправление ошибки | Техническая задача или исследование |
|---|---|---|---|
| Мобильное приложение для поиска ресторанов | «Как пользователь, я хочу видеть список ближайших ресторанов со средним чеком, чтобы выбрать, где мне пообедать» | Исправить ошибку, из-за которой приложение некорректно отображает карту на устройствах с Android 10 | Техническая задача: оптимизировать загрузку изображений для уменьшения потребления трафика |
| Интернет-магазин одежды | «Как пользователь, я хочу иметь возможность сохранять товары в избранное, чтобы купить их позже» | Исправить ошибку, из-за которой не приходит подтверждение заказа на email пользователя | Исследование: провести анализ поведения пользователей на странице оформления заказа для выявления причин низкой конверсии |
| Образовательная онлайн-платформа | «Как студент, я хочу иметь возможность отмечать пройденные уроки, чтобы отслеживать свой прогресс в курсе» | Исправить проблему с воспроизведением видео на iOS-устройствах при использовании Safari | Техническая задача: внедрить систему кэширования для ускорения загрузки учебных материалов |
| Сервис доставки продуктов | «Как клиент, я хочу иметь возможность оставлять заметки курьеру по доставке, чтобы уточнить детали получения заказа» | Устранить проблему с некорректным отображением времени доставки в push-уведомлениях | Техническая задача: оптимизировать алгоритм распределения заказов между курьерами для сокращения времени доставки |
Как растет бэклог интернет-магазина после MVP
После выпуска минимально жизнеспособной версии (MVP) бэклог продолжает расти вместе с продуктом. Допустим, интернет-магазин стартовал с просмотром каталога товаров и оформлением заказов. Дальнейшее развитие может дать такие пользовательские истории:
- Отслеживание заказа в личном кабинете покупателя.
- Промокоды.
- Система скидок.
- Интеллектуальные рекомендации товаров на основе предыдущих покупок.
- Интеграции с разными платежными системами.
- Инструменты для анализа потребительского поведения.
Помимо функций для покупателей, важно не забывать и про развитие возможностей для владельцев магазина: управление товарным ассортиментом, складскими запасами, ценообразованием и различными маркетинговыми инструментами.
Бэклог продукта в Scrum и Agile
В Scrum работа идет спринтами, то есть событиями фиксированной длины, внутри которых проходят остальные события. На планировании спринта разработчики в диалоге с владельцем продукта выбирают элементы бэклога продукта, которые войдут в текущий спринт, и могут уточнять их по ходу. Каждый рабочий день спринта разработчики на 15-минутной ежедневной встрече проверяют ход работы к цели спринта и при необходимости корректируют бэклог спринта. По итогам спринта команда показывает результат ключевым заинтересованным сторонам на обзоре спринта, где бэклог продукта могут скорректировать под новые возможности, а на ретроспективе анализирует, что прошло хорошо и что можно улучшить в следующем спринте.
Бэклог продукта и бэклог спринта
Слово «бэклог» без уточнения обычно означает бэклог продукта. Бэклог спринта — связанное, но другое понятие: он состоит из цели спринта, выбранных на планировании элементов бэклога продукта и плана их выполнения. Дорожная карта (roadmap) показывает направление развития продукта во времени, а бэклог содержит задачи, которые служат этому плану. Два документа дополняют друг друга.
| Понятие | Что это | Как связано с остальными |
|---|---|---|
| Бэклог продукта | Упорядоченный список того, что нужно для улучшения продукта | Из него берут элементы в спринт; список ведет владелец продукта, а его содержимое постоянно уточняется |
| Бэклог спринта | Цель спринта, выбранные элементы бэклога продукта и план их выполнения | Разработчики выбирают элементы на планировании в диалоге с владельцем продукта |
| Дорожная карта (roadmap) | Общий источник сведений о видении, направлении и ходе развития продукта во времени | Задает высокоуровневые цели и приоритеты, а бэклог перечисляет задачи, которые им служат |
Цель продукта (Product Goal) описывает будущее состояние продукта, к которому команда планирует работу. В Scrum она находится в бэклоге, а остальные элементы бэклога определяют, что именно обеспечит ее достижение.
Кто отвечает за бэклог
За бэклог отвечает владелец продукта (Product Owner): он формулирует цель продукта и доносит ее до команды, создает и описывает элементы бэклога, следит за прозрачностью списка и его понятностью для всех. Эту работу он может делегировать, но ответственность остается за ним. Размер задач оценивают разработчики, которым предстоит их выполнять. Владелец продукта может представлять интересы многих заинтересованных сторон, а те, кто хочет изменить бэклог, убеждают его, поэтому решение о порядке задач остается за одним человеком, а не за комитетом.
.jpg)
Как составить бэклог продукта
Бэклог начинают с цели продукта: идеи и требования собирают уже под нее, а затем доводят верхнюю часть списка до состояния, пригодного для планирования.
- Определите цель продукта. Опишите будущее состояние продукта, под которое будет строиться весь список.
- Создайте список всех задач. Соберите в одном месте идеи и требования команды, клиентов и руководителей: так получается единый список требований и основа для создания задач.
- Добавьте описания. Запишите каждую задачу в едином формате: пользовательская история, ошибка, техническая задача или исследование.
- Уберите дубли и устаревшие пункты. Оставьте только то, что относится к цели продукта.
- Расставьте приоритеты. Метод выбирают по описанию в следующем разделе.
- Опишите подробно верхнюю часть бэклога. Размер этих задач оценивают разработчики, которым предстоит с ними работать, после чего список можно использовать на планировании.
Подробно описывайте только те задачи, до которых команда доберется в ближайших спринтах. Остальные оставляйте крупными: по мере приближения к ним их уточнят.
Пользовательские истории и шаблон user story
Пользовательская история (user story) — короткое описание желаемой функциональности с точки зрения того, кому она нужна.
Чаще всего историю пишут от лица пользователя или клиента, но бывает и точка зрения заинтересованной стороны или другой системы. Важно, чтобы история вела к осмысленному результату и не сводилась к внутренней задаче команды. Распространенный шаблон пользовательской истории выглядит так:
«Как [роль пользователя], я хочу [что пользователь хочет сделать], чтобы [зачем это нужно пользователю]»
Формулировка служит поводом для разговора с командой: полное требование проясняется в обсуждении. Чаще всего хорошая история отвечает четырем принципам:
- Формулировка от лица того, кому нужна функция, чаще всего пользователя.
- Краткость, максимальная ясность.
- Независимость от технических деталей реализации.
- Описание ценности для пользователя.
Чтобы историю можно было проверить, к ней добавляют критерии приемки: условия, при выполнении которых задачу считают выполненной. Описание задачи отвечает на три вопроса: что нужно сделать, зачем это нужно и как понять, что сделано хорошо. Историю, которую команда способна выполнить за один спринт, считают готовой к выбору на планировании спринта, а слишком крупную делят на более мелкие.
Приоритизация задач в бэклоге
Порядок задач в бэклоге опирается на ценность для бизнеса и для пользователей. Прежде всего приоритет получают задачи, критически важные для достижения бизнес-целей и удовлетворения основных потребностей пользователей. Опираться только на допущения разработчиков не стоит, поэтому важность требований регулярно уточняют у заинтересованных сторон. Лишнее помогает отсечь бережливый подход (Lean): к нему относятся концепция MVP, то есть версия продукта, которая позволяет команде собрать максимум проверенных знаний о клиентах при минимуме усилий, и постепенное наращивание функциональности. К полезным инструментам относятся и регулярные приоритизационные сессии с широким кругом участников. Для самой расстановки есть несколько методов.
| Метод | Как работает | Особенности |
|---|---|---|
| MoSCoW | Все задачи делятся на четыре категории: Must have, Should have, Could have и Won't have this time. Must have — минимальный набор, без которого решение нежизнеспособно | Поставка задач из Should have и Could have не гарантирована |
| RICE | Каждую идею оценивают по четырем факторам: охват (reach), влияние (impact), уверенность (confidence) и затраты (effort); общий эффект делят на затраты | В описании Intercom влияние оценивают по шкале от 0,25 до 3, уверенность в 100, 80 и 50 %, затраты в человеко-месяцах; это рекомендация автора метода для своей команды |
Записывайте в бэклог и то, что решили не делать в этот раз (Won't have): без записи такие задачи возвращаются в работу неформально.
Пример из практики Kokoc: при переезде сайта IT-компании на новый домен на подготовку дали всего месяц, поэтому после полного SEO-аудита нового сайта все замечания разбили на две категории. Критические были такими, без которых переезжать нельзя, терпимые можно исправить после. Клиент оперативно исправил критические ошибки, после чего запустили переезд.
Как управлять бэклогом
Управление бэклогом строится как цикл. Создание задач и их описание сменяются приоритизацией, оценкой и распределением по спринтам. По мере выполнения идет обновление бэклога: статусы задач меняются, а это позволяет проще отслеживать прогресс и своевременно выявлять задержки.
- Создали задачи. Члены команды заводят задачи в трекере, описывают пользовательские истории, уточняют ошибки и другие элементы бэклога.
- Приоритизировали. Задачам присваивают приоритеты по ценности, срочности, сложности и другим критериям; самые важные планируют к выполнению в первую очередь.
- Оценили сложность. Команда оценивает каждую задачу, например в story points, то есть баллах размера задачи.
- Организовали по спринтам. В Scrum задачи из бэклога распределяют по спринтам длиной не более месяца; в справке Яндекс Трекера указано, что обычно спринт длится одну или две недели. Обязательство команды относится к цели спринта, а состав работ внутри него можно уточнять.
Уточнение бэклога (backlog refinement) — регулярная работа, в которой владелец продукта вместе с частью или всей командой проверяет элементы бэклога: нужны ли они, приоритизированы ли и готовы ли верхние к выполнению. Раньше эту работу называли грумингом бэклога (grooming), но из-за негативного оттенка слова сегодня чаще говорят об уточнении.
Чистка устаревшего служит лишь одним из действий при уточнении. Команда также создает новые истории под выявленные потребности, пересматривает относительные приоритеты, оценивает еще не оцененные истории и делит слишком крупные приоритетные. Так бэклог остается актуальным и отражает текущие приоритеты.
Инструменты для ведения бэклога
Для бэклога подходят сервисы, в которых можно создавать, структурировать, приоритизировать и отслеживать задачи. У Яндекс Трекера есть доска «С бэклогом и спринтами»: на ней управляют спринтами и бэклогом, оценивают задачи и смотрят диаграмму сгорания. В Kaiten есть готовый шаблон для Scrum из доски Backlog и доски Sprint, в «Битрикс24» инструмент «Скрам» с бэклогом, спринтами, ролями и доской задач, а в Shtab бэклог продукта представлен списком задач без спринта, отсортированным по приоритету. Начать можно с простого инструмента, главное, чтобы у всех участников был к нему общий доступ.
Доступ к части зарубежных сервисов для пользователей из России сейчас ограничен. В августе 2023 года Atlassian, разработчик Jira и Trello, сообщила российским и белорусским клиентам, что сворачивает деятельность в России и Беларуси и отключит их учетные записи в течение 30 дней с момента получения уведомления. По сообщению Хабра, с 20 марта 2025 года Asana ограничила доступ к платформе для пользователей из России по геолокации.
Типичные ошибки при ведении бэклога
Ошибки в ведении бэклога чаще всего связаны с приоритетами, описаниями задач и распределением ответственности.
- Нет приоритетов. Задачи берут в работу в порядке поступления. Помогает ранжирование методом из раздела о приоритизации: отмечайте приоритет для каждой задачи и начинайте с самого важного.
- Нечеткие описания. Исполнители понимают задачу по-разному. Помогают критерии приемки к каждой задаче.
- Детализация всего бэклога сразу. Время уходит на задачи, до которых команда доберется нескоро. Достаточно подробно описать верхнюю часть списка.
- Нет ответственного за порядок. Приоритеты меняются без объяснений. Помогает назначить владельца бэклога, за которым остается решение о порядке.
- Приоритеты не согласованы со сторонами. Важные для заинтересованных сторон задачи обнаруживаются поздно. Помогает регулярное обсуждение приоритетов с ними.
Частые вопросы о бэклоге
Можно ли вести бэклог в таблице?
Да. Глоссарий Agile Alliance называет электронную таблицу среди допустимых форм бэклога наряду с карточками и стикерами, текстовым файлом и специальными инструментами. По оценке Agile Alliance, электронные доски выигрывают, если в команде есть удаленные участники или к задачам прикладывают много сопутствующей информации. Физические доски, в свою очередь, делают бэклог постоянно видимым.
Что делать с задачами, которые давно не берут в работу?
Сначала решить, нужна ли задача продукту. Истории, которые потеряли значимость, удаляют при уточнении бэклога, а нужные, но не срочные оставляют ниже в списке и, когда до них доходит очередь, оценивают заново и разбивают, если они слишком крупные.
Что такое эпик и чем он отличается от пользовательской истории?
В Agile-практике команд эпик — это крупная пользовательская история, которую нельзя выполнить за одну итерацию или которую можно разбить на более мелкие истории. Единой формы записи эпика нет. Он позволяет хранить в бэклоге крупные нечетко определенные идеи одним пунктом, не загромождая список, а при уточнении бэклога команда делит эпик на отдельные истории.
Коротко о главном
- Бэклог продукта — упорядоченный живой список работ над продуктом, который меняется вместе с ним.
- Бэклог упорядочен по ценности и меняется вместе с продуктом, а пункты в нем остаются вариантами, а не обязательствами.
- В нем лежат пользовательские истории, ошибки, технические задачи и исследования.
- Бэклог спринта берется из бэклога продукта, а дорожная карта показывает направление развития.
- Составляют бэклог от цели продукта и приоритизируют проверенным методом, например MoSCoW или RICE.
- Ведут бэклог регулярным уточнением и избегают размытых задач и спорных приоритетов.
.png)
.png)
Комментарии (7)
Оставить комментарий