Бэклог продукта (backlog product) — это список задач, которые необходимо выполнить во время работы над проектом. Также бэклогом называется список функций, которые в результате должны получить пользователи. Изначально термин backlog использовался в экономике и обозначал задолженность. Но сейчас его чаще применяют в разработке. В статье рассказываем, из чего состоит идеальный бэклог.
Бэклог: что это такое простыми словами
Бэклогом называется список требований к проекту. Его составляют на основе пожеланий заказчика в самом начале работы. В процессе разработки проекта на основе обратной связи от заказчика бэклог корректируют.
Чем качественнее он, тем глубже команда сможет погрузиться в проект.
В основе бэклога лежат два документа:
- дорожная карта проекта. Это визуализация разработки проекта с установленными сроками, концепцией, стратегией, целями;
- пользовательские истории. Это описание функций продукта, составленное с точки зрения его пользователя. Описание специально составляется простыми словами без специфических терминов.
Часто бэклог продукта путают с бэклогом спринта. Второе обозначает список задач для оптимизации продукта, который необходимо выполнить команде в ближайший спринт. Sprint backlog составляется перед каждой новой итерацией и актуален только на время спринта.
Бэклог помогает эффективно управлять процессами по проекту и контролировать команду. Участники самостоятельно берут в работу задачи из бэклога. Так обеспечивается непрерывная работа над продуктом.
Бэклог — это связующее звено между владельцем продукта и командой разработчиков. Владелец продукта может в любой момент поменять приоритеты в работе. Например, если он получил новую обратную связь от клиентов. В свою очередь, команда определяет сроки выполнения работ.
Составляет бэклог руководитель проекта, иногда аналитик или разработчик, если речь идет о конкретном элементе. Актуальность и приоритетность задач контролирует владелец продукта. Бэклог эффективен в работе, только если его правильно составили и регулярно обновляют.
Из чего состоит бэклог
В минималистичном бэклоге должны быть указаны задачи и их приоритеты. У заданий с высокими приоритетами выше число (100, 300, 700, 1000). Большие зазоры между числами дают возможность вписать еще одну задачу между двумя уже запланированными.
Приоритетность оценивается по следующим условиям: ценность для проекта, стоимость, требуемые усилия и т.д.
В большинстве случаев для качественной работы над проектами минималистичного бэклога недостаточно. Необходимо развернутое описание задач. В этом случае бэклог будет состоять не только из списка задач и их приоритетов, но и будет содержать подробное описание каждого задания.
Чем выше приоритет у задания, тем глубже ее проработка, и тем больше и детальнее ее описание.
Также в нем указывается предварительная трудоемкость. Ее можно измерять в часах или в условных единицах. В последнем случае за 1 балл берется самая простая задача.
Не все задания в бэклоге будут готовы к реализации. Иногда это могут быть идеи заказчика, которые необходимо проверить. В документ также должны попадать: обратная связь от пользователей, технические моменты, требующие доработки, и т.д. В идеальном бэклоге все эти задачи хорошо бы сортировать по типу. Это позволяет быстро получить результаты поиска по запросу.
Для каждого задания в бэклоге важно указывать владельца. Так как задачи постоянно добавляются, легко потерять информацию о том, кто три месяца назад предложил изменить этот элемент и зачем. А при наличии соответствующей пометке в отдельной колонке это легко сделать. В идеале хорошо бы указывать не только исполнителя задания, но и дату добавления его в документ.
Тут есть один момент. Чем больше колонок в бэклоге, тем сложнее поддерживать его актуальность. Еще одна обязательная колонка, которая поможет при фильтрации, — статус. Она поможет сформировать список заданий на текущий спринт и для контроля общего прогресса.
Какими бывают бэклоги
Из предыдущего раздела может сложится впечатление, что бэклог — это всегда таблица. Но это не так. Чем успешнее становится продукт, тем быстрее он обрастает сложным функционалом, увеличивается число пользователей и обратная связь от них, растет объем технического долга. Объем информации может увеличиваться бесконечно. И обычная таблица в Excel может не справиться.
На больших проектах часто бэклог разрабатывают как Customer Journey Map.
Документ формируется вокруг пути пользователя. В этом случае он создает целую картинку о том, как каждый элемент бэклога отвечает за выполнение пользовательской работы.
Например, для реализации сайта с текстовым контентом необходимо разработать разные сценарии пользования для разных ролей, у каждой из которых — свои цели. Например:
- Пользователи — хотят читать свежие новости. Им нужны будут функции поиска, добавления в закладки, комментирования.
- Журналисты — хотят публиковать свои статьи. Им нужен удобный редактор для верстки.
- Редактор — проверяет материалы перед публикацией. Ему необходим инструмент с режимом предпросмотра.
- Администратор — модерирует комментарии, удаляет статьи. Ему необходим специальный функционал на административной панели.
Другой вариант бэклога — воронка идей. Выглядит как синтез канбана с дорожной картой. Такой документ будет состоять из двух полей. В первом указываются задачи, которые сортируются по приоритетности. А во втором поле формируются три колонки: "список дел", "в процессе", "уже сделано".
В формате бэклога возможностей собираются все идеи, проблемы, гипотезы и тщательно рассматриваются на предмет жизнеспособности. Прошедшие проверку переходят в бэклог разработки для дальнейшей реализации.
В бэклоге на основе типов работы приоритетом, как уже понятно из названия, является тип работ: по техническому долгу, по интерфейсам и т.д. Такой вариант подойдет для проектов, где бэклог уже слишком большой, и удобнее выделить задания по типу работ в отдельном документе. Но в целом рекомендуется всю информацию держать в одном месте, файле, трекере и т.д, чтобы ничего не потерять.
Если необходимо визуально показать сложный продукт с множеством функций, то подойдет древовидный бэклог. Он как карта влияния выглядит похожим на дерево решений, где каждая ветка — это незавершенная задача. Под каждой веткой указаны подробности: почему не завершена, кто исполнитель и т.д.
Универсального формата бэклога не существует, все зависит от конкретного проекта.
Структура идеального бэклога
Чем больше и сложнее проект, тем больше элементов в бэклоге. Но существуют универсальные элементы для каждого бэклога.
Функционал. В этом разделе описываются технические возможности для заказчика и для пользователя. Их расставляют по приоритетности.
Ошибки. Если задача была поставлена неправильно, могут появиться баги. Они бывают:
- срочные, связанные с приоритетными заданиями, и требуют быстрого решения;
- несрочные. Их можно решить в текущем спринте;
- с минимальным приоритетом.
Технический долг. Может появиться, когда задачи переносят, чтобы ускорить работу, или из-за неправильного планирования.
Исследования. Перед началом работы над проектом необходимо обработать информацию о нем.
Как не должен выглядеть бэклог
Неправильным считается документ, в котором:
- владелец продукта в начале работы установил требования, но на обратную связь от команды в процессе работы не реагирует;
- команда работает только над задачами, ориентированными на пользователей;
- бэклог не обновляется. У команды нет к нему постоянного доступа.
Периодически любой бэклог необходимо пересматривать. Эта процедура называется груминг. Проводить ее должен владелец продукта. Необходимость в груминге появляется, когда:
- число элементов в бэклоге значительно больше отработанных;
- у заданий большой средний возраст. Например, на элементы с наивысшим приоритетом уходит слишком много времени, и до остальных задач руки пока не доходят. Или задание считается не ценной, но полностью отказываться от нее тоже не хочется. В целом, если задача лежит нетронутой более трех месяцев — пора задуматься;
- элементы в работе против долгосрочных целей. Это значит, что команда застряла на задачах, которые важны, но общий прогресс по проекту маленький. Чтобы избежать такой ситуации, можно распределить отработанные задачи по важным для проекта категориям: техподдержка, пользовательский опыт, исправление багов, технический долг и т.д. И тогда наглядно будет видно, на какое направление команда тратит больше всего усилий.
В процессе пересмотра бэклога:
- делят сложные элементы на несколько мелких;
- удаляют неактуальные элементы;
- добавляют новые;
- переоценивают приоритеты и корректируют старые оценки;
- группируют элементы по смыслу;
- конкретизируют элементы с высоким приоритетом;
- уточняют элементы, по которым в ближайшее время начнется работа.
Груминг проводится в конце спринта, чтобы понять, что бэклог готов к следующему спринту. В идеале владелец продукта постоянно следит за актуальностью заданий. В этом случае на него уходит не более пары часов. Если вы решились сесть за проверку впервые за несколько месяцев активной работы над проектом, потребуется гораздо больше времени.
Отдельно выделяют рефайнмент (refinement) — оптимизацию проекта. В рамках рефайнмента добавляют новые детали и оценки. Эта процедура не должна занимать более 10% рабочего времени команды. Иначе с бэклогом что-то не в порядке.
Чем бэклог отличается от обычного списка задач
У бэклога продукта есть свойства:
- любая отметка должна добавлять ценность для владельца продукта;
- все записи проходят оценку;
- все отметки имеют свои приоритет и порядок;
- постоянно меняется.
Итоги
- Бэклог — список задач, отсортированный по приоритетности, который необходимо выполнить в рамках проекта. Чем важнее задача, тем детальнее описание по ней должно быть.
- В минималистичном варианте в бэклоге два поля: задача и приоритет. Но в крупных проектах они в несколько раз объемнее.
- Составляет бэклог руководитель проекта, разработчик или аналитик. За приоритетность и актуальность элементов отвечает владелец продукта.
- Бэклог может быть в разных форматах. Самый распространенный — электронные таблицы.
- Периодически нужно проверять на актуальность. Эта процедура называется груминг.
- Груминг проводят в конце каждого спринта. В процессе проверяется актуальность и приоритетность задач.
