Всё, что менеджеру проектов нужно знать о бэклоге

Впервые я столкнулся с чем-то, напоминающим протобэклог, в 2011 году, в Utimate Guitar. У руководителя отдела был текстовый файл с перечнем доработок, которые мы должны сделать в разных продуктах. Он открывал файлик в Notepad+ и при помощи горячих клавиш ловко менял строки местами, делая что-то вроде приоритизации.

Потом я пришёл в «Системные технологии» и там уже увидел более полноценный бэклог в виде системы Microsoft TFS, в которой было свалено в кучу множество запросов на доработку. В разных продуктах запросы имели разные типы, везде за приоритет отвечали разные поля, которые назывались по разному, приоритеты тоже выставлялись по разному, где-то сотнями, где-то единицами, в общем, каждый продакт выстраивал свою систему приоритизации бэклога. Но это уже было что-то, по крайней мере, система была доступна для сотрудников компании и хранилась централизованно.

В процессе работы эта система дорабатывалась, создали единое пространство для верхнеуровневых запросов, сделали одно поле для приоритета. В общем, ситуация стала лучше.

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

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

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

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

Если линкадиновский блок не отображается, включите vpn или автоматические прокси:

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

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

Какие виды бэклогов существуют?

Бэклог продукта

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

Бэклог спринта

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

Бэклог гипотез

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

Бэклог обращений

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

Какие поля должны быть в элементе бэклога

• Айдишник. Называть элемент бэклога в общении с коллегами по заголовку или краткому наименованию неудобно. Нужно иметь постоянные идентификаторы.
• Приоритет. Поле, по которому бэклог будет упорядочиваться.
• Инициатор. Наличие этого поля очень здорово помогает на старте работы с элементом — становится понятно, к кому идти за уточнением требований.
• Дата добавления в бэклог. Чтобы понимать, насколько документ старый, очень полезное поле.
• Краткое наименование. Заголовок, как при создании бага.
• Детальное описание. Я считаю, что продакт обязан составлять детальное описание фичи, хотя бы на бизнес-языке. Более формальное описание уже позже подготовят аналитики.
• Критичность. Можно в виде «да/нет». Помечать особо важные истории.
• Комментарий. Для всего, на что не хватило остальных полей.

Обслуживание бэклога

В том же «Систехе» я время от времени занимался тем, что открывал бэклог, переходил к самым нижним элементам и связывался с инициаторами, задавая им один и тот же вопрос: «Насколько актуальна эта доработка?» Очень часто получал ответ, что доработка потеряла актуальность и её можно исключить.

В «Инвитро» мы собирались с тимлидом, ведущим аналитиком и тестлидом, просматривали бэклог в джире, искали там заведомо неактуальные вещи самостоятельно, потому что из-за текучки найти инициатора было почти невозможно. Например, в один прекрасный момент руководство Инвитро решило закрыть интернет-магазин и, как следствие, все доработки интернет-магазина стали неактуальными.

В процессе груминга можно вчитываться в описания доработок и по ходу действия вырабатывать вопросы к продакт-овнеру. Можно их фиксировать там же.

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

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