В разных проектах задачи появляются постоянно: новые идеи, запросы пользователей, исправления ошибок, доработки продукта. Если не фиксировать их в одном месте и не расставлять приоритеты, команда быстро начинает работать в режиме постоянно горящих дедлайнов.
Эльвира Иллензеер, ведущий бизнес-аналитик Embedika, рассказала, почему без правильного ведения бэклога работа команды часто превращается в бесконечный список срочных задач.
Ниже приводим текст оригинальной публикации.
Что такое бэклог и зачем он нужен
Бэклог (от английского backlog — «накопленный объём работы») — это упорядоченный по приоритетности список всех задач, идей и доработок, которые относятся к проекту или продукту. В нём команда фиксирует весь объём будущей работы — от небольших правок до крупных инициатив.
Бэклог проекта — единый перечень всего, что предстоит сделать для развития продукта или реализации проекта. Это могут быть, например, разработка новых функций, исправление ошибок, технические доработки, продуктовые гипотезы и идеи будущих улучшений.
Основная задача бэклога — не дать работе команды превратиться в хаотичное реагирование на срочные запросы. Он делает объём задач прозрачным, снижает количество авралов и упрощает планирование.
Благодаря бэклогу команда видит общую картину и понимает, над чем работать дальше. При планировании специалисты обращаются к бэклогу, выбирают задачи с наивысшим приоритетом, оценивают их объём и забирают в работу. По мере выполнения задачи закрывают, приоритеты пересматривают, а бэклог регулярно обновляют — так он остаётся живым инструментом, а не бесконечным списком задач.
Концепция бэклога появилась с развитием гибких методологий управления семейства Agile — Scrum и Kanban — поэтому чаще всего о бэклоге говорят в контексте IT и разработки. Но на практике его используют не только программисты. Бэклоги ведут продуктовые команды, маркетологи и предприниматели — в любых проектах, где задач больше, чем ресурсов на их моментальное выполнение.
Бэклог ведут там, где команде удобно работать с задачами. Например, это может быть таблица в Google Sheets или Excel или список задач в таск-трекере. Главное — не формат, а принципы составления и ведения бэклога — подробнее об этом говорим ниже.
Какие бывают типы бэклогов
Как правило, используют несколько типов бэклогов для разных задач. При этом границы между ними условны и могут варьироваться в зависимости от проекта.
Структура и наполнение бэклога зависят от того, чем занимается команда и на каком уровне она планирует работу. Условно задачи можно разделить на три уровня:
- Первый — все идеи и требования, которые поступают от стейкхолдеров. Это бэклог продукта или проекта.
- Второй — наиболее приоритетные задачи, по которым уже проведён первичный анализ. Это бэклог команды.
- Третий — задачи, взятые в работу на ближайший период. Это бэклог спринта.
Разберём каждый тип бэклога отдельно.
Бэклог продукта — это основной список задач, связанных с развитием продукта. В него входят новые функции, улучшения интерфейса, технические доработки, найденные баги и гипотезы для проверки.
Такой бэклог показывает стратегическое направление развития продукта и помогает понять, куда команда движется в долгосрочной перспективе. Обычно за него отвечает продакт-менеджер или владелец продукта.
Бэклог проекта — это список задач для достижения оговоренного результата в ограниченные сроки. В отличие от продуктового бэклога, у проектного есть конечная точка — он закрывается после завершения проекта. Бэклог проекта ограничен рамками инициативы: в него попадают только задачи, необходимые для достижения запланированного результата.
Бэклог команды — это список задач, с которыми команда работает в текущий период, например в течение месяца. Сюда попадают элементы из продуктового или проектного бэклога, которые уже прошли предварительный анализ и готовы к реализации. Такой бэклог помогает команде понимать текущую загрузку и синхронизировать работу между участниками.
Бэклог спринта — это часть командного бэклога, которую выбрали для выполнения в ближайший цикл работы, например на неделю. Он показывает, какие задачи команда берёт в работу прямо сейчас и на чём сосредоточится в течение спринта.
Все типы бэклогов связаны между собой. Задачи постепенно проходят несколько этапов: сначала появляются как идея, затем проходят анализ, после чего попадают в проектный и командный бэклог, а потом в спринт.
Как составить бэклог
Главная цель бэклога — помочь команде ориентироваться в большом количестве задач и понимать, что действительно важно. Чтобы он не превратился в хаотичный список идей, бэклог нужно не просто вести, а осознанно собирать и структурировать. Ниже — пять шагов, которые помогут это сделать.
Шаг 1. Собирайте все задачи и идеи в одном месте. Задачи могут появляться в разных источниках: в рабочих или личных заметках членов команды, Excel-таблицах, комментариях в документах, переписке в чатах или обсуждениях на встречах. Если не систематизировать эту информацию, она быстро теряется. Поэтому первый шаг — сделать единый список и дальше добавлять в него все задачи.
Шаг 2. Фиксируйте источник задачи. Полезно указывать, откуда появились идея или требование — от заказчика, пользователей, службы поддержки или команды разработки. Это помогает лучше понимать контекст задачи и её важность.
Шаг 3. Определяйте тип задачи. Задачи в бэклоге могут относиться к разным категориям. Например, в IT-команде — к новой разработке, улучшению функциональности, техническому долгу или исправлению ошибок. Разделение задач по типам упрощает навигацию в бэклоге.
Шаг 4. Указывайте приоритет. Приоритет показывает, какие задачи важнее и с каких стоит начинать. Если в бэклоге нет приоритетов, команда рискует тратить время на второстепенные задачи вместо действительно важных.
Шаг 5. Добавляйте дополнительную информацию. Иногда полезно указать примерную сложность задачи, связь с более крупной инициативой или предполагаемый релиз. Такая структуризация делает бэклог более управляемым.
Как вести бэклог
Бэклог не составляют один раз и навсегда. Чтобы бэклог оставался полезным для команды, с ним нужно регулярно работать:
- Фиксируйте новые требования сразу, чтобы они не потерялись.
- Проводите предварительный анализ задач. Уточните смысл задачи, какую проблему она решает и какую ценность даёт продукту или бизнесу. Минимальный набор информации — краткое описание, бизнес-ценность и контекст обсуждения. Проводить анализ стоит сразу после добавления задачи в бэклог и до того, как она попадёт в план работы команды — это значительно упрощает дальнейшую работу.
- Оценивайте задачи вместе с командой. После предварительного анализа задачам часто дают ориентировочную оценку трудозатрат. Обычно в обсуждении участвуют разные специалисты — такой подход помогает получить более реалистичную оценку и лучше спланировать работу.
- Записывайте контекст появления задачи. Полезно указывать, в какой ситуации возникла задача: например, на встрече с заказчиком, рабочем совещании или после обращения пользователя. Это помогает лучше понять её смысл, даже если к задаче вернутся через несколько месяцев.
- Периодически пересматривайте бэклог. Некоторые задачи со временем теряют актуальность, а приоритеты могут меняться. Поэтому бэклог нужно регулярно обновлять: уточнять формулировки, пересматривать приоритеты и удалять устаревшие задачи.
Главный принцип работы с бэклогом — поддерживать его в понятном и актуальном состоянии. Старайтесь формулировать задачи так, чтобы любой участник команды мог быстро понять их смысл без дополнительных разъяснений.
Как работать с техническим долгом в бэклоге
В IT-командах в процессе разработки неизбежно накапливается технический долг. Это задачи по улучшению и исправлению уже существующего кода и архитектуры продукта, которые команда осознанно отложила ради скорости разработки, сроков или выполнения контрактных обязательств перед бизнесом.
Технический долг может накапливаться и не мешать развитию продукта, поэтому важно правильно работать с такими задачами в бэклоге. Разберём, как это делать.
Фиксируйте задачи технического долга отдельно. Технический долг включает задачи, связанные с улучшением кода и архитектуры — например, рефакторинг, оптимизацию производительности, обновление библиотек или исправление некритичных ошибок. Такие задачи лучше выделять в отдельную категорию бэклога.
Определяйте источник финансирования задач. Важно заранее понимать, кто оплачивает работу. Если технический долг возник из-за внутренних решений команды, его обычно закрывают за счёт ресурсов компании. Если задача связана с развитием функциональности, её может оплачивать заказчик. От этого зависит, в какую категорию бэклога попадёт задача и когда её будут выполнять.
Разделяйте задачи развития и технического долга. Задачи развития добавляют новый функционал и ценность для пользователей, а технический долг касается улучшения уже существующих решений. Такое разделение помогает прозрачнее планировать работу команды: продуктовые задачи выносят в дорожную карту и обсуждают с заказчиком, а технический долг закрывают постепенно — в рамках спринтов или отдельных технических итераций.
Планируйте работу с техническим долгом. Если не выделять время на такие задачи, они постепенно накапливаются и усложняют разработку. Поэтому важно регулярно включать их в план работы команды.
Коротко о бэклоге в 3 пунктах
- Бэклог — это список всей работы по проекту или продукту. В нём собирают задачи, идеи, доработки и гипотезы: от крупных инициатив до небольших исправлений. Бэклог помогает хранить весь объём будущей работы в одном месте.
- В бэклоге задачи расставляют по приоритетам. Команда оценивает ценность и сложность задач и решает, какие из них нужно делать в первую очередь.
- Бэклог постоянно обновляют. По мере развития проекта в список добавляют новые задачи, пересматривают приоритеты и удаляют устаревшие идеи.
