Бэклог: ликбез

Бэклог — штука, которая нам в студии кажется такой же привычной, как утренний кофе или ежедневный стендап. Но недавно мы с ужасом подумали: а вдруг, это так только для нас? Встречайте статью для тех, кто «что-то слышал», «ну, бэклог — это ж просто…», «бэк. что?» и всех, кто не в теме. А если за бэклог вы всё-таки в курсе — освежите знания: вдруг, кругового бэклога в жизни не видели или не знаете, когда стоит провести плановый груминг (нет, это не про стрижку домашних животных мы сейчас).

Возьмите свой список задач на день (он же есть?): там наверняка будут задачи в порядке приоритетов, которые важно сделать сегодня. Возможно, у вас также есть список дел на месяц или год, откуда вы «надергиваете» задачки на каждый день. Если так, то можно сказать, что фактически вы ведете бэклог.

Если не вдаваться в подробности, то бэклог — список всех задач и хотелок в порядке приоритета, которые планируется выполнить. Элементы списка гибкие: их можно менять, выбрасывать или добавлять новые по ходу дела. За это бэклоги любят противники толстых неповоротливых и формальных технических заданий.

Авторы скрамгайда описывают бэклог так:

Бэклог продукта — это упорядоченный список всего, что может понадобиться в продукте, и единственный источник требований для любого вида изменений продукта. Бэклог никогда не бывает полным: изначально он содержит базовые и самые понятные требования. С обновлением и развитием продукта, а также условий рынка и технологий бэклог меняется и становится более объёмным и исчерпывающим.

Бэклог спринта — набор элементов из бэклога продукта для исполнения в текущем спринте. Обычно включает хотя бы одну задачу из ретроспективы предыдущего спринта, план разработки очередной версии продукта и план достижения цели спринта.

Какое-то время бэклоги действительно были присущи только командам разработки, но этот простой и чёткий инструмент может пригодиться вообще в любой сфере: от списка обращений с предложениями в техподдержку до списков дел, которые нужно выполнить за конкретный промежуток времени (привет, планирование!). В продуктовых историях может быть даже отдельный бэклог для гипотез, если их много и важно проработать каждую и упорядочить их по приоритетам.

Минимальный джентльменский набор: задача и её приоритет. Чем больше число — тем выше приоритет, а большие зазоры между числами (100, 200, 500, 1000, 10 000) дают место для маневра: всегда можно вписать ещё одну задачу между двумя другими. Общими факторами приоритизации могут быть: ценность для бизнеса, стоимость (или требуемые усилия) и сопутствующие риски (позитивное влияние реализации фичи или отрицательное влияние от её отсутствия).

Увы, обычно для разработки продукта двух полей в бэклоге маловато, поэтому там также могут появиться и другие колонки:

Идеальный бэклог — тот, где по каждой строке однозначно ясно, что нужно делать. Из краткого описания хотелки не всегда можно уловить весь контекст, поэтому чем выше приоритет у задачи, тем подробнее должно быть её описание.

Чем ниже задача в бэклоге, тем меньше степень её проработки. И наоборот: чем выше задача в списке, тем более ясная формулировка ей нужна и тем выше должна быть её готовность к работе.

Может измеряться в часах, но чаще — в условных единицах, Story Point-ах: за 1 балл принимается самая простая задача из списка, а остальные оцениваются относительно неё.

Задачи в бэклог могут добавляться по разным причинам: иногда это идеи и гипотезы, которые стоит проверить, иногда — обратная связь от пользователей, иногда — технические штуки, которые требуют доработок. Поэтому всегда неплохо сортировать их по типу с помощью условного форматирования, например.

Бэклог продукта — длительно развивающийся организм, который со временем только прирастает в объёме. Поэтому спустя 2−3 месяца довольно сложно бывает вспомнить, кто, когда и зачем предложил перекрасить кнопку в другой цвет, убрать из формы поле с описанием или прикрутить ещё один тип доставки. Такая колонка — как раз в помощь. Можно пойти ещё дальше и указывать дату добавления в бэклог и конкретного исполнителя задачи, но помните: чем больше колонок, тем сложнее содержать бэклог актуальным.

Колонка, опять же, пригодится для быстрой фильтрации, а ещё — для выборки задач на текущий спринт и для отслеживания прогрессов.

Обязательных полей — нет: всё зависит от проекта и процессов. Поэтому, если нужно добавить своих колонок — на здоровье. Лишь бы было удобно всегда держать их в актуальном состоянии.

Кто должен писать бэклог — вопрос ситуативный. Иногда это сам менеджер. Иногда — менеджер вместе с разработчиком. Иногда — разработчик, если дело касается сложных технических аспектов. Иногда — аналитик (в идеале такой, который неплохо ориентируется в мире разработчика). Но если аналитик новичок, всегда имеет смысл давать ему в пару разработчика для написания бэклога, потому что сложные технические истории тот сам не вывезет. Как минимум — проверять бэклог после аналитика до того, как он пойдет в работу.

Добавлять хотелки в бэклог могут все заинтересованные в проекте лица, но за приоритеты задач отвечает всегда только Владелец продукта. Он же отвечает за периодический пересмотр бэклога, когда нужно выкинуть лишнее и устаревшее, обновить приоритеты или улучшить формулировки.

Всегда ли бэклог — это таблица? Необязательно. Чем успешнее становится продукт, тем он сложнее: больше функционала, больше пользователей и их обратной связи, больше технического долга, улучшений интерфейса, гипотез и оптимизаций — список стремится к бесконечности. В такой ситуации иногда простая и привычная таблица может оказаться не самым эффективным вариантом бэклога. И вот на что её можно заменить.

Идея переложить задачи бэклога на пользовательские сценарии принадлежит Джеффу Паттону — тому самому автору книги «Пользовательские истории. Искусство гибкой разработки ПО», вышедшей по мотивам его давней статьи из блога.

Суть в том, чтобы строить бэклог вокруг пути пользователя — насколько продукт приближает его к достижению конкретных задач и целей. Такой подход даёт более целостное представление о том, как каждый элемент бэклога отвечает за выполнение пользовательской работы согласно теории JTBD.

Например, пользователь хочет оплатить товар в корзине. Учитывая довольно стандартную процедуру заказа, элементы бэклога могут быть такими:

• авторизация и вход в учетную запись (с сохранением данных, чтобы не вводить их заново);
• просмотр и подтверждение заказа до оплаты;
• оформление доставки и её варианты;
• оплата картой или платежной системой;
• письмо и/или sms с подтверждением заказа.

А если он хочет искать товар на сайте, то был бы рад, если там будет:

• поиск по наименованию;
  
• поиск по цвету;
  
• поиск по цене;
  
• поиск в конкретной группе товаров.

Карту пользовательских историй для зрелого продукта имеет смысл раскладывать на отдельные пользовательские персоны, цели, работы (JTBD) или проблемы пользователей.

Например, с точки зрения владельца интернет-магазина в сценарии оформления заказа покупателем в бэклоге важны следующие элементы:

• возможность отклонять заказы на сумму менее N рублей, потому что они невыгодны;
• возможность отказать покупателям за пределами РФ, потому что расходы на доставку делают эти заказы невыгодными;
• резервирование заказанных товаров на складе на 48 часов, чтобы другие покупатели видели реальные остатки в карточке товара;
• автоматическая отмена заказов, за которые не пришла оплата в течение 48 часов.

Или, например, сайт, где публикуются статьи — для разных ролей будут разные сценарии и разные задачи для реализации:

• клиенты хотят читать статьи, чтобы быть в курсе важных событий — нужны удобные фичи для поиска, закладок и комментирования;
• журналисты хотят писать статьи, чтобы их могли читать — нужен удобный инструмент для верстки статей;
• редактор хочет просмотреть статью перед публикацией и проверить её на опечатки — нужен режим предпросмотра;
• администратор хочет удалять статьи с сайта, чтобы бороться с оскорбительным контентом — нужен функционал в админ-панели для этого.

Работая с пользовательскими историями, есть соблазн расписать их до уровня технических деталей. Но тогда теряется контекст и происходит дублирование:

• «Как пользователь, я хочу, чтобы серверная часть делала то-то и то-то»;
• «Как пользователь, я хочу интерфейс, который делает то же самое».

Хорошая пользовательская история должна приносить пользу конечному пользователю и затрагивать весь стек технологий (или такой его объём, чтобы функционал был рабочим). Истории, распотрошенные на технические детали, не представляют никакой ценности для пользователей: так, например, веб-интерфейс для них бесполезен, пока не соединен с базой данных.

Хороший вариант, если нужно визуализировать бэклог и физически ограничить количество его элементов. Подход поможет расставить приоритеты и сфокусироваться, с ним легко достичь гибкости без лишней формальной структуры.

Всё, что нужно — два поля:

• в левое отправляются все хотелки, которые нужно отсортировать по параметрам («сейчас, следом, скоро, позже» или «хорошо бы сделать, важно сделать, обязательно сделать»);
• в правом поле — три колонки по типу доски канбана: список дел, в процессе, уже сделано.

Фактически это сочетание канбана с дорожной картой, которое может быть очень удобным: вместо двух артефактов у вас всего один.

Призван собрать в себе все идеи, гипотезы, проблемы и потенциальные возможности. Каждый элемент такого бэклога затем пристально рассматривается, и если его признают жизнеспособным, тот переходит в бэклог разработки. И даже если в итоге хотелка не выживет — это будет отличный опыт, который поможет найти ещё больше новых возможностей для развития продукта.

Да, вы и так можете делить задачи в бэклоге на типы с помощью ярлыков или сортировок. Проблема лишь в том, что чем бэклог больше, тем сложнее это деление поддерживать. Решение — разделить один бэклог на несколько по типам работ. Тогда всё несделанное по техническому долгу будет лежать в одной кучке, а по интерфейсам — в другой.

С одной стороны, идея логичная: каждый тип задач в своей группе. С другой, появляется проблема несогласованности: дизайнеры заботятся только о дизайне, спец по базам данных обособленно пилит базу данных, разработчик пишет код, а тестер тестирует. В итоге, чтобы получить прирост функциональности продукта, придётся ждать выполнения перечня задач по каждому отдельному бэклогу. Если будут недоделки по технической части или случится заминка с дизайном — продукт начнет буксовать.

Такой бэклог подходит для сложных продуктов с множеством различных функций, поскольку в таком формате проще визуально показать, как те взаимосвязаны между собой и как изменения в одном месте могут затронуть другие аспекты продукта. Один из классных примеров — дорожная карта австралийского банка Up в виде дерева. А если пойти ещё дальше, то можно составить дерево возможностей: на каждую проблему предложить несколько решений, а к ним — добавить эксперименты для проверки.

В дереве решений каждая ветка — элемент незавершенной работы, здесь же под каждой веткой — ответы на вопросы: почему → кто → что → как.

Бэклог в виде карты влияния поможет визуализировать и продумать множество альтернативных путей пользователя, ведущих к конкретному результату. Но такой формат вряд ли справится с отображением в бэклоге технического долга или списка проблем в продукте для устранения.

Круговой бэклог помогает наглядно категоризировать задачи и при этом сохранить целостность общей картинки. А экспериментируя с размером фрагментов можно физически ограничивать work in progress. Фактически, это такой же гибрид канбана с бэклогом как бэклог в виде воронки — только вид сверху :)

Идеален для продуктов, где есть чёткая конверсия — например, в е-коммерс. Всё, что нужно — структурировать элементы согласно воронке конверсии. При таком формате бэклог объединяет количественные данные об отказах или потенциальных барьерах в воронке с потенциальными возможностями их улучшения. В таком виде бэклог сам по себе определяет приоритеты задач: на каком этапе воронки больше всего проблем — там и надо работать.

Такой тип бэклога подойдёт продуктам как на ранней стадии развития, так и более зрелым, поскольку держит в фокусе самые ключевые факторы, которые влияют на отклик пользователей — гадать над тем, что им важнее, здесь не приходится.

Каким бы ни был бэклог по форме и где бы он ни хранился, его постоянно нужно актуализировать — эта процедура лежит на плечах Владельца продукта и зовётся грумингом или рефайнментом. Груминг — термин адептов скрама, рефайнмент — сторонников других гибких методологий, но суть одна: это регулярный пересмотр и уточнение элементов, чтобы требования и хотелки к продукту не превращались в огромный неподвластный команде снежный ком.

Можете собрать статистику вручную, а можете использовать встроенные инструменты в Jira или Trello. Установите пороговые значения, когда количество задач станет для вас избыточным, и отслеживайте регулярно. Порог превышен — пора навести красоту.

Для этой цели, кстати, отлично подойдёт методика MoSCoW: сопоставляя объёмы работ из разных групп задач (must have, should have, could have, would like), легко понять, где список задач на данный момент избыточен.

Его можно отследить только, если фиксировать у каждого элемента изначально. В той же Jira есть инструмент статистики для отслеживания этого параметра. Причин устаревания задач может быть несколько:

• слишком много проблем по текущим элементам с наивысшим приоритетом;
• в целом слишком большой объём элементов;
• элемент на самом деле не ценный и не существенный, но выбросить пока жалко.

Если не иметь взгляда «сверху», то легко застрять на выполнении задач, которые важны, но не глобально — из-за этого общий прогресс по бэклогу будет мизерным. Чтобы такого избежать, стоит классифицировать уже отработанные элементы бэклога за последние 120 дней, и посмотреть, насколько равномерно распределялась нагрузка. Категории могут быть такими:

• рост выручки;
• пользовательский опыт;
• вовлечение пользователей;
• технический долг;исправление багов;
• техподдержка и прочее.

Если потрудиться и составить диаграмму на основе этих категорий, то можно запросто оценить, на что тратится большая часть времени команды и как это соотносится со стратегией развития продукта.

Частая проблема — слишком большие элементы бэклога: если таких в спринте будет несколько, то даже выход за рамки отведенного времени по одному из них срывает сроки всего спринта. А если таких сложностей будет несколько? Груминг спешит на помощь: если грамотно разделить элемент на более мелкие, шансы на успех выше. Но вообще-то, конечно, это — первоочередная задача декомпозиции.

Элементы бэклога могут устаревать по разным причинам:

• сменилось направление развития продукта;
• проблему уже исправили в рамках другой проблемы, случайно или намеренно;
• элемент устареет из-за другой функции, над которой планируется работать в ближайшем будущем;
• элемент уже не жизнеспособен из-за архитектурных изменений — тогда его нужно либо полностью переработать, либо удалить к чертовой матери;
• новые знания о пользователях, рынке или продукте говорят, что элемент на самом деле не решит проблему, ради которой его добавили в бэклог.

Список — не исчерпывающий.

Есть мнение, что огромный бэклог продукта — признак слабости его владельца. Поэтому, сокращая список элементов, вы фактически боретесь с двумя видами производственных потерь:

• потерями из-за перепроизводства: планируем сделать гораздо больше, чем нужно — не проще ли делать то, что актуально прямо сейчас?
• потерями из-за запасов: лишние элементы в огромном бэклоге мешают сосредоточиться на самых важных вещах.

Если говорить ещё проще, сокращая бэклог, вы получаете элементы, которые базируются только на самых свежих и важных данных, избавляетесь от лишней работы по пересмотру и переоценке бэклога и уменьшаете время на его обсуждение с командой.

Чтобы навсегда распрощаться с элементом в бэклоге, задайте себе эти три вопроса:

1. Сколько элементов в бэклоге продукта сейчас (очевидно, что больше 300 — уже проблема)?
2. Сколько времени существует самый старый элемент (если он хранится нетронутым три года — может, чёрт с ним вообще)?
3. Сколько времени вы тратите на уточнение элементов, которые никогда не доходят до спринта, но всё ещё аккуратно хранятся в бэклоге (если вы тратитесь на такое — элементы того точно не стоят)?

Беспощадно избавляйтесь от всего, что:

• добавляет ненужные обязательства, ограничения или зависимости;
• добавляет ненужную сложность и раздувает функционал;
• дублирует предыдущие идеи и задачи полностью или частично (стоит объединить с уже существующим или дополнить его);
• устарело на данный момент;
• вызывает сложности с интерпретацией или пониманием гипотез;
• не отражает проблему, которую нужно решить.

Новые элементы могут добавляться в ответ на изменение бизнес-среды или рынка, появление нового видения продукта или новых комментариев от пользователей. А могут — потому что команда способна отработать больше элементов за спринт, чем предполагалось изначально. Если скорость работы — 20 элементов за спринт, то в бэклоге их должно быть хотя бы вдвое больше — чтобы было, из чего выбирать.

Новые элементы могут быть важнее тех, что были самыми важными до этого. А оценки могут меняться из-за добавления новых задач в бэклог — поэтому придётся пересмотреть их у каждой задачи.

• уточнения по элементам, с которыми будут работать в ближайшее время;
• конкретизацию элементов с высоким приоритетом;
• редактирование или усиление существующих элементов;оценку элементов (если её ещё нет);
• группировку элементов по смыслу и создание подзадач.

Обычно груминг проводится ближе к концу текущего спринта — это помогает убедиться, что бэклог готов к следующему спринту. Но обычно грамотный владелец продукта не ждет, пока запахнет жареным, и постоянно следит за актуальностью списка задач.

Если груминг вошёл в привычку, потребуется не больше 1,5 часов для 4-недельных спринтов (если ваши спринты короче — справитесь ещё быстрее). Но если груминг проводится впервые за несколько месяцев, готовьтесь выделить гораздо больше времени.

1. Бэклог — список задач к выполнению, отсортированный по приоритетам. Чем выше задача в этом списке, тем детальнее она должна быть проработана.
2. Минимальный набор полей для бэклога: задача и её приоритет. Если нужны другие детали — не вопрос, добавляйте на здоровье. Идеально, если будет условное форматирование в колонках.
3. Писать бэклог может руководитель проекта или продукта, аналитик или разработчик, но за приоритеты и актуальность задач всегда отвечает только Владелец продукта.
4. То, как выглядит бэклог — не столь важно, лишь бы было удобно им пользоваться. Но электронные таблицы, кажется, по-прежнему в топе.
5. Груминг бэклога — регулярный процесс пересмотра задач (обновление, добавление, удаление и актуализация).
6. Если задачи в бэклоге устарели, долгосрочные цели по-прежнему далеки или объём выполненных работ сильно меньше элементов в бэклоге — пришла пора груминга.
7. Груминг стоит проводить в конце каждого спринта (а лучше не запускать).

Ну вот, теперь вы настоящий бэклоговый гуру :)