Чем сложнее процессы, тем больше пользы от бэклога — набора задач с приоритетами, точными сроками и исполнителями. Сейчас расскажем, каким бывает бэклог, как его вести, кто должен в этом помогать, а главное — зачем вообще всё это бизнесу 💼
Что такое бэклог
это упорядоченный список требований к цифровому продукту, который ведёт к улучшению этого самого продукта. Фактически это набор функций, где задачи по их реализации расставлены в порядке приоритета. Список может дополняться и меняться по ходу проекта
Это один из ключевых элементов в методологии Agile. Он используется в подходах Scrum и Kanban, чтобы выполнять работы короткими циклами
Представь себе, что все идеи по проекту или продукту собираются как книги в шкафу. Затем этот шкаф как по волшебству выдаёт тебе книги, которые нужно прочитать именно сейчас, потому что они принесут больше всего пользы.
Это не магия, а продуманная методика — за что браться в первую очередь, чтобы достичь целей в нужные сроки. Её придумали IT-разработчики и назвали бэклогом от слов back log. Их можно перевести простыми словами как «ещё не выполненная работа» или как «запас брёвен», то есть топлива. Получается интересно: бэклог обязателен к исполнению, без него далеко не уедешь 🚘
Записывается всё это тоже не вперемешку, а в планировщиках задач с визуализацией процесса — например, в Weeek.
Команды ведут бэклог продукта, чтобы постоянно актуализировать свою разработку, делать её полезной для целевой аудитории и отстраиваться от конкурентов.
✏️ Пример
Студия разработки второй год совершенствует популярное приложение для профессиональных кондитеров. Продукт хотят вывести на рынки нескольких соседних стран. Команда продукта записывает в бэклог следующие блоки задач в порядке приоритетности:
1️⃣ Дополнить базу рецептов локальными блюдами
2️⃣ Уточнить местные единицы измерения, настроить их отображение и конвертацию в зависимости от выбранной страны и языка
3️⃣ Расширить настройки калькулятора ингредиентов
4️⃣ Дополнить премиум-подписку мини-курсами, секретными рецептами, приглашениями на мероприятия от местных экспертов
Работа с бэклогом уже давно ведётся не только в программировании, но и на производствах, в маркетинге и других сферах. Она дарит любому коллективу несколько важных преимуществ:
- быструю обратную связь от заказчика
- понятные процессы с очерченными зонами ответственности для каждого
- сроки, которые нельзя нарушить
Всё это даёт конкретику, помогает сотрудникам создавать полезный продукт и дорабатывать его, чтобы бизнес оставался успешным.
✏️ Пример
Школа творчества для взрослых разрабатывает программу на следующий год. У отдела маркетинга свой бэклог: собрать статистику по популярности курсов и отзывы, продумать новые каналы продвижения, акции и спецпредложения для давних учеников
У методистов свои наборы задач: обновить существующие курсы, продумать новые под запрос, дать ТЗ дизайнерам и программистам для обновления базы обучающих видео
Какие виды бэклога бывают и чем они отличаются
Мы уже разобрались, что для успешной работы нужно продумывать списки дел, а затем жёстко привязывать каждое ко времени и исполнителю. Эти списки не появляются по волшебству, а наработки не исчезают, когда задачи закрыты. Потому что видов бэклога несколько — вот в чём их разница 👇
Бэклог продукта
Основа для достижения долгосрочных целей. Здесь собрано всё, что относится к продукту: его ключевые функции, задачи, которые нужно выполнить для доработки, идеи на будущее, информация по предыдущим ошибкам и их исправлению.
Это не склад идей и дел, а постоянно обновляемый ресурс всей команды. Владелец продукта (Product Owner) дополняет бэклог актуальными данными и отмечает, какие уже не важны. Он расставляет приоритеты, чтобы ориентировать команду, что брать в работу сейчас, а что — позже.
Бэклог спринта
Это уже группа конкретных задач с приоритетами и дедлайнами, рассчитанная на 1–4 недели работы. В процессе спринта продукт дополняется новыми важными функциями — скажем, кнопка «Купить» на сайте переносится в более удобное для пользователей место.
Обычно команда заранее определяет сроки спринта и количество дел, а проджект- или продакт-менеджер следит, чтобы всё шло по плану. Когда спринт начался, добавить что-либо в бэклог уже нельзя. Такое правило помогает не утонуть в дополнительных доработках 😉
Бэклог релиза
Если предыдущий пример — про группу задач для небольших регулярных улучшений товаров и услуг, то этот — про работы для существенных изменений. Релизом может быть запланированное обновление или срочное, ввод нового продукта параллельно со старым или постепенное знакомство конкретных ЦА.
Бэклог релиза опирается на бэклог продукта: какие предложения по улучшению взять в работу из «копилки» прямо сейчас, чтобы подготовить релиз с нужными функциями.
Технический бэклог
Это «даркстор» для разработчиков 👾 Прошлые варианты сосредоточены на клиенте и том, как поддерживать актуальность и уникальность продукта для своей аудитории. В это время технический бэклог — про задачи для поддержания жизни системы в принципе.
Сюда входят работы по улучшению инфраструктуры и производительности, а ещё так называемый технический долг — замена быстрых, но не самых удачных решений на более подходящие.
Бэклог гипотез
Хранилище идей о новых продуктах, сегментах рынка, партнёрствах и других возможностях роста. Необходимо руководству, менеджерам и стейкхолдерам, чтобы понимать, какие предложения сработали, какие нужно «вытащить из сундука» прямо сейчас, а какие ещё подождут.
Проверка гипотез помогает бизнесу сориентироваться даже в сложной экономической ситуации и точнее закрывать потребности покупателей. Для этого нужно вести Карту гипотез, всё время добавлять новые варианты и «докручивать» прежние.
Бэклог команды
В завершение — о запасе практик и задач для развития и сплочения самих сотрудников. Руководитель направления или целого коллектива, HR-менеджер могут заносить сюда:
- планы по дополнительному обучению для конкретных специалистов
- заметки по проведению будущих собраний
- предложения для повышения личной эффективности коллег
- варианты неформального взаимодействия (тимбилдинги и т. п.)
А теперь ещё раз и коротко обо всех видах бэклога:
| Вид бэклога | Что в него входит | Для чего нужен | Кто обычно ведёт | Когда использовать |
|---|---|---|---|---|
| Бэклог продукта | Ключевые функции продукта, все задачи для его улучшения и оптимизации пользовательского опыта, идеи на будущее | Определение УТП продукта, планирование релизов, построение спринтов | Владелец продукта | Постоянно |
| Бэклог спринта | Набор задач для доработки конкретных функций продукта, рассчитанный на 1–4 недели | Периодические небольшие обновления продукта, его актуальность на рынке | Продакт-менеджер, проджект-менеджер | Во время планирования спринта и до завершения цикла работ |
| Бэклог релиза | Хранилище идей, проблем, решений и текущих задач для команды разработки | Поддержание жизнеспособности продукта | Команда разработки | Постоянно |
| Бэклог гипотез | Предложения по развитию бизнеса: новые продукты, ЦА, партнёрства | В зависимости от ситуации — рост, масштабирование или сохранение позиций на рынке | Руководство, стейкхолдеры | Постоянно |
| Бэклог команды | Планы по повышению эффективности сотрудников | Рост квалификации, производительности, сплочённости | Руководители команд, HR-менеджеры | Постоянно |
Составляющие бэклога: какие типы задач формируют бэклог
Стандартного содержания бэклога нет: в отдельно взятой компании он формируется в зависимости от особенностей продукта, команды, методов управления и сроков.
Но бэклога не бывает без двух основных составляющих — задачи и приоритета. Эти элементы есть всегда.
Простейший вариант бэклога — список фич в порядке реализации, но это редкость. Чаще всего там присутствуют и другие типы задач: исправление ошибок, доработка интерфейса, проведение интервью или исследований. Каждая задача может быть расписана подробно — обычно чем сложнее идея, тем больше деталей.
В структуре бэклога встречаются такие элементы:
Требования к продукту (функции)
Характеристики, которые отличают от других в линейке производителя или от предложений конкурентов. Сюда можно отнести внешний вид, набор возможностей и элементы дизайна у сайта, длительность и масштаб промокампании, вкус блюда и экологичность упаковки.
Пользовательские сценарии (User story)
Та же функциональность продукта, но с точки зрения пользователей: насколько удобно пользоваться сайтом людям с особенностями зрения, сколько лидов принесёт промокампания, насколько быстрая доставка еды и свежая ли она. Истории потом разбиваются на конкретные задачи.
Баги и дефекты
Выделяют три вида багов:
- срочные — те, что даже не успевают попасть в бэклог, потому что исправляются на ходу
- спринт-баги — берутся в работу во время текущего цикла
- баги продукта — не входят в текущий спринт и дожидаются исправлений в бэклоге продукта
Из этой части бэклога «вырастают» задания для разработчиков.
Сроки
Количество часов, которые нужны на выполнение задачи, или условная единица измерения Story Point. Особенно важны для спринтов, где нельзя подвинуть момент сдачи работ.
Технический долг
Временные решения, которые появляются из-за переноса задач из предыдущего спринта или ошибок в планировании. Чтобы продумать работоспособную замену на долгий срок, технический долг нужно вписывать в бэклог спринта и декомпозировать на подзадачи.
Исследовательские задачи
Сюда относятся «опыты», которые так же ограничены во времени, как и остальные дела. Они нужны, чтобы получить свежую информацию и двигаться дальше. К примеру, это опрос клиентов, которые недавно купили продукт, проверка API стороннего сервиса для дальнейшей интеграции или создание прототипа страницы.
Инициатор / владелец задачи
Речь не только об исполнителе. Порой через несколько месяцев после старта проекта сложно вспомнить, а кто, собственно, придумал красные кнопки в приложении.
Статус
Как вариант — маркеры приоритетов или теги. Статус позволяет быстро отфильтровать и найти задачи в разросшемся бэклоге. В Weeek теги легко указывать прямо в карточках задач — они будут разноцветными и помогут не заблудиться. Только договорись о системе тегов с командой заранее, чтобы она была понятна всем.
Дополнительные данные
Артефакты, информация, референсы, выдержки из интервью с пользователями — всё, что поможет выполнить задачу.
Бэклог при таком формате обретает большую значимость: чем ответственнее команда разработки отнесётся к проработке, тем проще и быстрее будет работать другим. Можно вспомнить афоризм «Тяжело в учении, легко в походе!», а в нашем случае — «Ответственно в бэклоге, легко в работе!»
Как собрать бэклог
Удобная форма — Канбан-доска. Давай разберём процесс на примере далекоидущих планов Альбуса Дамблдора. Он многое знал наперёд и подготовил соратников. Вот как выглядит в Weeek бэклог проекта по уничтожению Тёмного Лорда.
Шаг 1. Определи цели продукта и команды
Чтобы магия началась, волшебник создал доску в рабочем проекте и придумал ёмкое название.
После этого прошёл в раздел Документы вверху страницы, создал новый документ и прописал цели для продукта — то есть проекта по ликвидации Тёмного Лорда — и для команды соратников. Добавлять обложки, форматирование и другие важные элементы для наглядности можно каждому — заклинания проверены.
Шаг 2. Изучи дорожную карту продукта (Roadmap)
Дамблдор изучал злого волшебника с его детства, поэтому собрал внушительную базу информации. Данные, взаимодействия и цели по каждой фазе легли в основу дорожной карты. Это отдельный документ, который направляет и помогает не забывать, ради чего делается продукт.
Шаг 3. Собери идеи и требования из всех источников
Для привычного нам бизнеса это могут быть аналитические данные по прошлым разработкам, свежие исследования и опросы клиентов, пожелания заказчиков и стейкхолдеров. В случае Дамблдора это были варианты, какие предметы могут оказаться крестражами и где их искать. Такой удобно оформить в подразделе Идеи и заметки.
Шаг 4. Сформулируй элементы бэклога
Давай представим, что Альбус Дамблдор составляет бэклог накануне самых драматичных событий — ожесточённого противостояния светлых и тёмных сил, а затем финальной битвы. Тут пригодится отдельный документ.
Шаг 5. Выпиши задачи на доску
Время возвращаться в раздел Задачи. Волшебник выбирает режим отображения Канбан и записывает, что уже выполнено, что в работе и что только предстоит. Обрати внимание на колонку Бэклог идей: можно заносить ценные мысли сюда, а не на отдельную доску, чтобы держать их перед глазами и обдумывать.
Шаг 6. Декомпозируй крупные дела
Многосоставные задания лучше разбить на шаги помельче, чтобы ничего не забыть и не сбить с толку исполнителей. К примеру, чтобы дать Гарри Поттеру и его друзьям оружие для защиты от Волан-де-Морта, Дамблдор придумывает завещать им вещи с историей и намёками. Всё это он прописывает в подзадачах.
Шаг 7. Добавь описание и контекст
Чтобы исполнителям было проще и быстрее работать, в карточках задач стоит оставлять комментарии. Можно упоминать коллег через @, чтобы они точно заметили важные подробности и сделали всё как надо.
Шаг 8. Определи зависимости
В спринтах практически все задачи зависят друг от друга. Например, одна идёт строго параллельно другой, как вёрстка сайта и корректура. Или вторая начинается, только когда заканчивается первая — скажем, клеить обои можно не раньше, чем побелят или натянут потолки.
В нашем примере Дамблдору важно подсказать, что соратникам сделать в первую очередь для победы над силами зла. Связи легко расставить через одноимённую функцию — она есть в любой карточке задачи над названием.
Если щёлкнуть по меню Связь, легко перетащить в нужные колонки задачи, которые должны выполняться друг за другом. Так в Weeek строится диаграмма Ганта — визуальное отображение этапов проекта со взаимосвязями между ними.
Вот пример того, как будет выглядеть диаграмма Ганта в Week. Связи задач можно настроить так, чтобы к одним можно было приступить строго тогда, когда сделаны предыдущие. Или просто показать последовательность.
Шаг 9. Расставь приоритеты
В бэклоге Дамблдора они уже есть, всё-таки волшебник мыслит на сто шагов вперёд 😎 Сейчас просто покажем, где выбрать приоритет в конкретной карточке задачи.
Шаг 10. Упорядочи бэклог и подготовь его к работе команды
В финале нелишним будет настроить напоминания для себя и последователей — они будут приходить хоть каждый час. Ведь сила не столько в заклинаниях, сколько в фокусе внимания и командной работе 🤝
Что мы видим из этого бэклога? Что многое приходится корректировать, что не всё удаётся сделать без проблем, что баги — неизбежная сторона жизни. Даже если ты величайший в своём деле.
Как приоритизировать бэклог
На практике всё довольно субъективно. Как-то надо учесть и важность, и сложность. Владелец бэклога считает, что нужно сделать кабинет клиента, добавление в избранное и заодно перестроить логику оплаты. А разработчики умрут под шквалом таких суперважных и объёмных задач.
Для приоритизации бэклога есть свои критерии. Опирайся на них, чтобы указать команде верное направление работы и не потратить лишние ресурсы на старте.
Ценность для пользователя
Один из ключевых критериев, особенно для постоянно обновляемых продуктов. Покупатели в интернет-магазине охотнее купят товары с новыми тематическими карточками и ждут более удобных способов оплаты. А, скажем, ученикам в онлайн-школе нужны свежие пакеты вопросов для подготовки к экзаменам. В этих случаях команде лучше сначала подготовить то, что востребовано здесь и сейчас.
Влияние на бизнес-цели
Здесь уже фокус обратный, но о ценности для аудитории тоже не забывай. К примеру, летом у сети клиник падает выручка и нужно выровнять показатели относительно других сезонов. Приоритетами маркетинговой команды будут кампания со спецценами на комплексные обследования, процедуры красоты и осмотры детей к школе. А разработчики сразу возьмутся за соответствующие лендинги и настройку оплаты со скидками.
Срочность задачи
Хороший критерий, когда важно примерно всё 🤷♀️ Тогда на передний план выходят сроки — обычно это касается исправлений багов, возврата технического долга или релиза, без которого уже никак. Представь, что у полиграфической компании горят сроки сдачи сразу нескольких корпоративных заказов. Руководство решает отдать первой партию сувениров, у которых уже переделывали подставки из-за брака на производстве и затянули с дедлайном.
Риски и последствия откладывания
От этого момента зависит лояльность аудитории и репутация бренда. Вернёмся к предыдущему примеру с полиграфией: из тех клиентов, чьи заказы остаются срочными, есть пара организаций с очень жёсткими условиями в договорах. Срыв дедлайнов в работе с ними — это риски неустоек и репутационных скандалов. Поэтому полиграфия выполняет такие заказы первыми, а с остальными клиентами договаривается об уступках и скидках.
Зависимости от других задач
Критерий из разработки: есть составляющие проекта, которые могут выполняться строго перед другими или после них. Например, сеть цветов и подарков планирует маркетинговую акцию в своих офлайн-магазинах. Сначала руководство должно разослать во все точки POS-материалы и призы для участников. Только после этого можно давать анонсы акции в соцсетях, запускать сбор заявок на розыгрыш и считать первые баллы покупателей.
Сложность и объём работ
Полезное ограничение для небольших команд или для многосоставных продуктов, которые создаются в несколько этапов. Скажем, бренд нишевой уходовой косметики с маленьким ручным производством поставит в приоритет продукты, которые производятся и тестируются дольше всего, а параллельно сможет отдавать более простые заказы.
Наличие технических ограничений
Бывает, что для выполнения задач не хватает ресурсов: гаджетов, материалов, рабочих рук, знаний. В этом случае в приоритете окажутся дела, для которых все ресурсы уже есть. Если в студии разработки игр заболел дизайнер, который отвечает за узнаваемый стиль конкретных персонажей, ему дадут время на восстановление, а пока займутся другими участками работы.
Закрепи знания о критериях приоритизации с помощью этой таблицы ⬇️
| Критерий приоритизации | Плюсы | Минусы |
|---|---|---|
| Ценность для пользователя | Фокус на болях и потребностях клиента | Можно упустить бизнес-цели и перегрузить команду частыми изменениями |
| Влияние на бизнес-цели | Фокус на нуждах бизнеса и прибыльности | Есть опасность нарушить логику спринтов и взаимосвязь задач |
| Срочность задачи | Проще придерживаться временных рамок и отрабатывать в первую очередь самое горящее | Легко переработать всем коллективом, упустить взаимосвязи задач и подзадач, а с ними — важные детали |
| Риски и последствия откладывания | Есть возможность гибко договариваться и сохранять лояльность ЦА | Можно утратить доверие клиентов, если не предложить им подходящие условия |
| Зависимости от других задач | Удобно придерживаться логики работы и не забывать о пользовательском опыте | Есть риск не уложиться в сроки или не попасть в изменившиеся ожидания заказчиков |
| Сложность и объём работ | Проще выполнять задачи от самых объёмных к более простым, сохранять продуктивность и мотивацию команды | Легко затянуть сроки и закопаться в усовершенствование функций продукта, которые уже не так важны |
| Наличие технических ограничений | Фокус на имеющихся ресурсах | Опасность опозданий и переработок, которые должны компенсировать нехватку чего-либо |
Расставить приоритеты бывает действительно непросто: они, как мячи в квиддиче, летят в разные стороны и могут серьёзно навредить, если их не замечать. Прокачивай себя и команду, чтобы справляться с приоритетами играючи 💪
Правила управления бэклогом
В завершение давай поговорим, как поддерживать бэклог в рабочем виде, чтобы он оставался актуальным и понятным для всех. Вот несколько проверенных методик:
Почаще советуйся с владельцем продукта
Идеи и задачи могут накидывать все члены продуктовой команды, но именно владелец продукта определяет приоритеты. Его мнение во многом определяющее, ведь именно он анализирует информацию о рынке, чтобы продукт соответствовал последним требованиям. Если это твоя должность — продолжай сиять и указывать путь коллегам 🌞
Регулярно пересматривай бэклог
Актуализация — это груминг. Удаляй лишние элементы и уточняй текущие, добавляй новые, декомпозируй крупные задачи, корректируй приоритеты, задавай связи и группы по смыслу.
Для каждого вида — своя частота обновления. Ориентируйся на результаты предыдущих этапов и потребности команды, чтобы сохранить и развить рабочие практики. Вот как часто можно вносить изменения:
- в технический бэклог — в любой момент, поскольку базовый функционал продукта должен всегда быть доступен без сбоев
- в бэклог спринта — только когда он завершится, чтобы следующие прошли эффективнее
- в бэклог релиза — по итогам каждого спринта, чтобы вовремя исправлять ошибки, внедрять самое актуальное и полезное для клиента
- в бэклог гипотез — после очередного тестирования для обновления приоритетов и подготовки новых вариантов для проверки
- в бэклог продукта — по мере актуализации бэклога гипотез, если какие-то из них сработали
- в бэклог команды — во время и после встреч с коллегами, где вы вместе решаете, как развиваться вместе и персонально
Поддерживай понятную структуру
Используй, например, Канбан-доску. Пусть это будут стандартные колонки К работе, В работе, Готово. Дополни их колонками Выполнено с правками и Сейчас неактуально. Так увидишь, какие задачи уже делаются, что меняли на ходу, а что отложили и попробуют внедрить позже.
Уточняй формулировки
Задачи и подзадачи будут понятнее для всех, если называть их по принципу «глагол в неопределённой форме + существительное». Например, «Собрать прототип лендинга» или «Уточнить статус поставки».
Назначить исполнителей, добавить комментарии и материалы для работы можно в карточке задачи. Не перегружай бэклог — пусть всё будет понятно даже при беглом просмотре.
Отдельно скажем о специальных терминах: будь осторожнее с локальными фразами, аббревиатурами и сленгом, если команда большая и разная.
Удаляй устаревшие элементы
Если дела были одноразовыми и вряд ли станут частью рабочих процессов команды, можно убрать их из бэклога. Неактуальные задачи с важными наработками лучше переместить в архив, чтобы при необходимости быстро найти полезные материалы.
Обновляй приоритеты
От этого зависит производительность команды: не поменяли вовремя правильный порядок задач — потратили время не на то. Будет проще, если кто-то один будет менять приоритеты в установленный момент. Скажем, ежедневно после вечерней синхронизации или раз в неделю за час до конца рабочего дня.
Согласовывай бэклог с целями продукта и команды
Это точно лучше делать во время собраний или сразу после них. Запроси саммари встречи, обнови бэклог и настрой уведомления для всех: если у коллег будут уточнения, они оперативно ответят.
Опирайся на пользовательские истории
User Story — зеркало работы всей команды: чем больше мелочей предусмотрено, тем удобнее и приятнее потребителю использовать продукт. А значит, больше вероятности повторных касаний и расширения аудитории 😉 Данные о симпатиях и недовольстве клиента помогут коллегам верно расставить приоритеты.
Подписаться 
