У любой команды всегда копится бэклог — явный или призрачный, записанный или только устный. И чем больше людей в команде, тем больше задач под контролем.
Но хаос может начаться и в небольших командах. Когда приоритеты размыты, сложно сосредоточиться на главном. Вы прыгаете между задачами, теряя фокус.. Кто-то из заинтересованных лиц постоянно приходит с новой «горящей» задачей, и вы хватаете все сразу, но почти ничего не доводите до конца.
Если вы не понимаете, какие задачи действительно важны, при этом число стейкхолдеров растет — это красный флаг, что система дает сбой. Эта статья для тимлидов, разработчиков, DevOps, project-менеджеров — тех, кто ежедневно сталкивается с растущим списком задач и расставлением приоритетов. Под катом мы разберемся, какими бывают бэклоги, рассмотрим правила приоритизации и способы держать процесс под контролем без микроменеджмента.
Виды и типы бэклогов
У разных видов бэклогов могут быть разные типы. Начнем с видов. На изображении ниже вы сможете ознакомиться с рядом из них.
Небольшое дополнение - мы не будем отдельно рассматривать бэклог обучения и технический.
Классический продуктовый бэклог
Сюда попадают задачи, связанные с пользовательским опытом:
закрытие «хотелок» пользователей;
упрощение эксплуатации продуктивной среды;
повышение качества техподдержки;
сокращение воронки продаж продукта.
Правила работы:
Если задача не связана с продуктом, ей здесь не место.
Добавляйте новые полезные функции.
Важно приоритезировать задачи внутри продуктового бэклога.
Спринтовый бэклог
В него заносят новые фичи, критичные баги и задачи техдолга.
Но спринты бывают разные: итеративные, разовые, растяжимые. Поэтому и правила работы с такими бэклогами тоже отличаются:
Можно убирать задачи, но не добавлять новые! (исключения возможны для DevOps из-за наличия смешанного бэклога, но только заранее согласованная доля).
Согласуйте долевое распределение задач в техдолге (рефакторинг, безопасность, работы на элементах инфраструктуры или CI/CD-конвейере и т. д.).
Необходима сквозная приоритизация и понимание, что может перейти в другой спринт.
Проводите ретро/рефлексии спринта (для DevOps при необходимости, если не настроена система отчетности).
Виды спринтов
Итеративные спринты — классический формат спринтов по методологии Scrum. Подразумевает повторяющиеся циклы фиксированной длины (обычно 1–4 недели). Каждый спринт — отдельный цикл работ. Если результат не соответствует заданию или ожиданиям клиента, в следующей итерации можно внести изменения в продукт.
Разовые спринты — проводятся один раз для достижения конкретной цели (например, внедрение инструмента, проведение аудита или пилота). Количество спринтов не ограничено, может проводиться друг за другом без остановки и зависит от сложности задачи, состава и опыта команды.
Растяжимые спринты — имеют гибкую продолжительность, т.е. длительность и содержание могут меняться в зависимости от задач, приоритетов или внешних факторов. Требуют высокой зрелости команды, чтобы не терять фокус.
Релизный бэклог
В такой бэклог входят несколько спринтов, планируемый техдолг, а также ожидания и реальность по поставкам фич. У этого вида тоже есть свои правила:
Добавляйте задачи только с блокирующим приоритетом.
В приоритизации участвуют все заинтересованные лица. Если их слишком много, это может стать проблемой. Лучше выстроить прозрачный и понятный процесс для всех — кто и на каком основании может добавлять или отменять задачи, менять им приоритет. То есть производительность команды, количество задач и времени будут фиксированными.
Про работу со стейкхолдерами
Контроль релиза и формирование его состава должны быть прозрачными.
Для этого рекомендуется учитывать следующие факторы:
- ресурсы команды на релиз — с учетом больничных, отпусков и прочего.
- подход к оценке задач — например, принцип Фибоначчи, “майки” и др. - виды задач. входящих в релиз: фичи, баги, MVP и т.д.
- принципы приоритизации задач, попадающих в скоуп релиза
- фиксированный % задач на бэклог:рефакторинг, исправление уязвимостей низкого приоритета и т.д.
- правила исключения задач в пользу более важных , а также порядок их переноса в следующие релизы.
На основе этих базовых параметров необходимо:
- определить всех стейкхолдеров, а в некоторых случаях, и приоритеты между ними.ними)
- описать процесс планирования задач, где они принимают участие. Например, фиксированный день в последнюю неделю релиза встречу для формирования релиза или автоматическое обновление Kanban-доски.- установить часть релиза, когда задачи не могут попадать в релиз, например,в начале регресса. В некоторых случаях, еще вводят практику маратория на внесения изменений в CI/CD-инфраструктуру и манифесты пайплайнов для инженеров.
Помимо оперативного планирования, существует квартальное, полугодовое и годовое. Отдельный процесс оценки и реализации долгосрочных задач может проходит в формате переписки или встречи, например, раз в месяц или квартал.
Для контроля таких задач можно использовать Structure Jira или любые инструменты, визуализирующие подходы диаграммы Ганта или Kanban.
Важно поддерживать постоянную обработку обратной связи от заказчиков и пользователей системы.
Типы бэклогов
Воронка идей
Позволяет последовательно составлять очередь из накапливающихся задач в зависимости от срочности и возможности их реализации. Обозначать приоритеты можно разными цветами (как на картинке) или метками.
Такие бэклоги удобно реализовать в продуктах вроде Notion, Trailer, Redmine, Yougile и др.
Возможности
Визуализация бэклога возможности на примере PESTEL-анализа
Пример структуры бэклога возможностей
Бэклог возможностей может быть представлен в виде таблицы или списка, содержащего следующие поля:
Название Задачи: Краткое описание задачи.
Описание: Более подробное описание задачи.
Источник: Откуда поступила идея задачи.
Потенциальная Ценность: Оценка ценности задачи для пользователей и бизнеса (например, по шкале от 1 до 5).
Соответствие Стратегии: Оценка соответствия задачи стратегическим целям компании (например, по шкале от 1 до 5).
Риски: Оценка рисков, связанных с реализацией задачи (например, по шкале от 1 до 5).
Необходимые Ресурсы: Оценка необходимых ресурсов для реализации задачи (например, низкие, средние, высокие).
Сложность: Оценка сложности реализации задачи (например, низкая, средняя, высокая).
Приоритет: Приоритет задачи (например, высокий, средний, низкий).
Статус: Статус задачи (например, новая, в оценке, на проверке, отклонена, перенесена в бэклог разработки).
Ответственный: Ответственный за оценку и проверку задачи.
Комментарии: Дополнительные комментарии и заметки по задаче.
В таком бэклоге собираются задачи, возможность реализации которых еще не подтверждена. Сделать больше, чем позволяют ресурсы команды (capacity правит балом!), невозможно. И по мере проверки задач они либо отбрасываются, либо переносятся в бэклог разработки. Главный приоритет – устранение багов. Вот как это может выглядеть:
Классы работ
В этом случае есть четкая классификация задач по классам (или типам). В Jira, например, для каждого класса есть свой фильтр, который выводит определенный набор задач с распределением по ответственным. Главное, не заниматься микроменеджментом.
Бэклог по классам работ может выглядеть так:
Древовидный бэклог
От продукта ветвятся возможности, от возможностей — приоритеты, от приоритетов — производительность команды. Такой бэклог можно рассматривать как карту влияния: он помогает четко понять, как взаимодействуют бизнес и конечные пользователи, будь то внутренние или внешние.
Эта карта строится на основе постоянного сбора обратной связи и чаще используется в крупных компаниях.
Круговой бэклог
Круговой бэклог – это метод организации работы, который представляет собой непрерывный цикл, включающий следующие этапы:
Планирование: Определение целей, задач и приоритетов на основе текущей ситуации и обратной связи.
Выполнение: Реализация запланированных задач и проектов.
Оценка: Анализ результатов, выявление проблем и возможностей для улучшения.
Адаптация: Внесение изменений в планы и процессы на основе результатов оценки.
Такой бэклог часто используется в продуктовой разработке.
Представим, что продукт позволяет формировать скидки в крупном маркетплейсе. У разработчиков есть ряд гипотез, которые хочется проверить на клиентах, но при этом есть техдолг, задачи по улучшению UX и добавлению новых фич. Их можно разложить на этот бэклог исходя из приоритета и сроков реализации.
Другие варианты использования:
Маркетинг: Круговой бэклог может использоваться для управления маркетинговыми кампаниями, позволяя командам постоянно тестировать новые подходы и оптимизировать результаты.
Управление продуктом: Круговой бэклог помогает командам управления продуктом постоянно собирать обратную связь от пользователей и улучшать продукт на основе этой обратной связи.
Управление проектами: Круговой бэклог может использоваться для управления любыми проектами, требующими гибкости и адаптивности.
Воронка конверсии
Конверсия предназначена для извлечения наибольшей прибыли. Пожалуй, это самый конфликтный тип бэклога, потому что придется спорить с бизнесом. Такой тип бэклога чаще всего используется при разработке крупных систем вроде SAP или 1C. Более того, на практике воронка конверсии была замечена при наличии waterfall-подхода разработки.
Пользовательский путь
Ряд практических советов:
Определите ключевые этапы воронки конверсии для вашего продукта.
Проанализируйте воронку конверсии, чтобы выявить узкие места.
Сгенерируйте элементы бэклога, направленные на улучшение каждого этапа воронки.
Приоритизируйте элементы бэклога на основе их потенциального влияния на конверсию.
Отслеживайте влияние внедренных изменений на воронку конверсии.
Регулярно пересматривайте бэклог и воронку конверсии, чтобы адаптироваться к изменяющимся потребностям пользователей и рынка.
Основные элементы бэклога
Фичи | Баги | Технический долг | Прототип |
Полезные для клиентов и бизнеса | Ошибки, которые нужно исправить как можно быстрее или до завершения спринта. | Отложенные, невыполненные вовремя задачи из-за ускорения работы над проектом или ошибок в планировании. | Предварительное изучение информации для лучшего понимания функций продукта. Сюда входят и RnD-задачи. |
«Ингредиенты» эффективного бэклога:
формулировка задачи;
её приоритет;
развернутое описание;
предварительная оценка трудоемкости;
тип элемента (идея, исследование и т. д.);
заинтересованное лицо (к кому обращаться, если возникают вопросы или сложности при решении задачи);
нынешний статус.
Выбираем бэклог под себя
Для начала ответьте на вопросы:
Какой вид бэклога вам ближе?
Какой тип бэклога вам ближе?
Кто основные заинтересованные лица?
Какая производительность команды при выбранном виде бэклога?
Какую долю техдолга будете брать?
Какую долю оставите под входящие обращения?
Какую долю внеспринтовых задач (если таковые имеются) заложите?
Какими инструментами пользуетесь?
Допустим, у вас инженерная команда, живущая по трехнедельным спринтам. При этом есть задачи спринтовые и внеспринтовые, а за спринт команда может выполнить до 30 задач. Ответы на вопросы могут быть такими:
Какой вид бэклога вам ближе? Спринтовый (три недели = 120 часов).
Какой тип бэклога вам ближе? По типам работ.
Кто основные заинтересованные лица? Разработчики, QA, архитекторы, TL DevOps, DevOps-инженеры, CTO.
Какая производительность команды при выбранном виде бэклога? 30 задач.
Какую долю техдолга будете брать? 5-10%
Какую долю оставите под входящие обращения? 20%
Какую долю внеспринтовых задач заложите? 10-20%
Какими инструментами пользуетесь? Jira: дашборд, канбан, структура (в результате все сводится к диаграмме Ганта).
Подход к сквозной приоритизации задач
Самый простой вариант: создать систему меток. Ими можно отмечать приоритетность задач:
Это реально помогает, ведь количество задач может исчисляться сотнями, и при таких объемах легко потерять самые важные и срочные.
С помощью меток удобно обозначать принадлежность задач к бэклогу определенной команды, например, devops_backlog.
Главное — заранее прописать правила присвоения меток: кто за что отвечает, кто и когда ставит ту или иную метку. Без общих и понятных правил быстро начинается самодеятельность и бардак.
Раз в спринт проверяйте состояние задач на «летучках» или ретро, а также давайте разработчикам выговориться. Иногда на них наваливается столько задач, что они начинают выгорать, конфликтовать или подумывать об увольнении. Пообщайтесь с ними, послушайте. Можно даже записать результаты беседы.
Создание сквозного бэклога
Вот пример бэклога на основе структуры Atlassian, но, фактически, это иное представление диаграммы зависимостей при помощи типизации задач:
Поскольку речь о сквозном бэклоге, здесь есть определенный набор столбцов со сквозными приоритетами, которыми должны управлять только вы, и больше никто. Этот столбец со значениями приоритетов и есть сквозной бэклог.
Вы спросите: «Зачем такие сложности?». Дело в том, что у нас ч��тко отслеживается SLA по выполнению задач. С помощью меток мы контролируем нужные задачи, числами выбираем диапазоны реализации: день, неделя, две недели, квартал и так далее:
1-20 — epic link
20-50 — 1-5 дней
51-70 — 5-15 дней
71-100 — 15-30 дней
101+ — работы на квартал или год
Например, задача может быть с меткой red, но с приоритетом больше 100, потому что мы ждем поставку оборудования.
Индикаторы пересмотра приоритета задач
Чтобы пересматривать сроки, можно использовать Agile или что-то свое. Анализируйте удельную производительность команды: сколько задач она решает в единицу времени — спринт, релиз и так далее. Набрав статистику, можно уже прогнозировать, что если вам назначат на 30% больше задач, чем вы сможете выполнить, то пора пересматривать бэклог.
При этом производительность — характеристика непостоянная, она может меняться со временем в ту или иную сторону.
Другой сигнал о необходимости пересмотра — большой средний «возраст» задач:
много задач с наивысшим приоритетом;
большой объем входящих задач;
мусорные задачи, которые жалко отменить.
Я обычно не жалеюмусорные задачи и выкидываю их из бэклога. Даже если раньше у них был высокий приоритет, со временем он мог снизиться, или сами задачи стали неактуальными.
Один мой руководитель раз в квартал без сожалений отрезал от бэклога все, что превышало расчетную производительность команды. Для этого можно периодически выгружать аналитику по статусам, чтобы проверять, сколько и в каком статусе провела каждая задача за рассматриваемый период. После этого можно спрашивать ответственных об ее актуальности, и почему она столько времени пролежала в бэклоге.
Вот как может выглядеть пример подобного запроса:
issuetype in ("QA Task") AND status changed FROM "IN REVIEW" TO "READY TO TEST" AND project = SHTURVAL AND status = Done AND resolutiondate >= startOfMonth(-3) ORDER BY resolutiondate ASC, issuekey DESC
Мы берем все выполненные запросы с типом QA Task в проекте SHTURVAL и выводим их время перехода из статуса IN REVIEW в READY TO TEST за последние 3 месяца. Так мы можем отследить какие задачи могли долго находиться в одном статусе.
Третья причина пересмотра бэклога — противоречие задач долгосрочным целям. У команды есть цели на разные периоды, и они могут меняться. То, что было важно в предыдущем квартале, может потерять смысл в текущем. От таких задач тоже нужно избавляться.
Грумим бэклог
Как можно обрезать бэклог:
Делить сложные задачи на более мелкие.
Удалять неактуальные задачи.
Добавлять новые элементы — не задачи, а то, что поможет улучшить уже открытые: виды приоритетов, заинтересованные лица, проекты и т. д.
Пересматривать приоритеты в соответствии с правилами и корректировать оценки. Возможно, предыдущая оценка была неверной, и задача на самом деле потребует гораздо больше работы. Такие пересмотры можно регулярно проводить со всеми заинтересованными лицами.
Установить явные правила работы с устаревшими задачами, которых может быть много.
Планировать на несколько релизов или спринтов вперед. Желательно минимум на полгода. А еще отслеживать, что делает каждый участник команды.
Резюме
Бэклог — это инструмент, а не средство, он зависит от конечной цели.
Есть много разных подходов к ведению бэклога, выбирайте подходящий или доработайте под себя один из предложенных не только исходя из вашего опыта, но и в зависимости от условий в компании.
Помните, что реализация бэклога зависит от используемых инструментов.
Микроменеджмент — ваш худший враг.
Подробнее о ведении бэклогов можно почитать в этих книгах:
И напоследок — полезные ссылки:
Автор: Александр Крылов, СРО «Штурвала» в «Лаборатории Числитель»
