Как составлять бэклог: краткое руководство

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

Работу с бэклогом стоит начинать со «скелета» — базовых функций, которые должны присутствовать в продукте. Здесь будет полезен план развития — Product Roadmap. Детализировать задачи можно с помощью User Stories, на основе которых строится Customer Journey Map. Разберёмся, что скрывается за этими английскими словами и как к ним подступиться.

Что это такое?

Product Roadmap (дорожная карта) — верхнеуровневый стратегический план, в котором отражено направление разработки вашего продукта. В идеале — со сроками реализации. Roadmap не даёт конкретных пояснений по каждой задаче — это общее видение проекта. Но при этом он содержит основные цели, миссию и объясняет предпосылки того, что вы делаете. 

Пример дорожной карты

User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей.

Например, User Story может звучать так: «Я хотел бы видеть всплывающие подсказки при входе в приложение, если прихожу сюда впервые».

Пример с knowledgehut.com

Customer Journey Map (карта путешествия клиента) — это визуализированный опыт пользователя продукта с учётом его целей, эмоций, барьеров, мотивов. Карта составляется под определённую User Story, отражает путь клиента к продукту, показывает «узкие места», даёт понять, над какими этапами и метриками нужно работать в первую очередь.

Очень важно всегда быть в контексте пользователя, поэтому CJM нужно регулярно обновлять. 

Пример CJM онлайн-магазина

Как на основании этих документов собрать бэклог?

1. Составляем список функций. Если есть возможность, сразу задаём их приоритет согласно Roadmap.
2. Прописываем User Story для каждого предложения и анализируем, насколько эта функциональность ценна пользователю.
3. Расставляем фичи, прошедшие отбор, по приоритету и записываем в бэклог.
4. Обсуждаем задачи с командой, определяем сроки и ответственных.
5. Обновляем список задач по мере их завершения или поступления новых вводных. 

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

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

Пример бэклога: 

Название задачи всегда должно быть ёмким и понятным, отражать её суть и не вводить в заблуждение. 

В графе «Важность» проставляется значимость фичи для проекта. Оценку могут дать менеджер или команда, но она будет субъективна. Также можно сделать выводы о важности задачи на основе накопленных знаний о пользователях: сколько из них будет охвачено новыми функциями и как фичи повлияют на пользовательскую историю.

Трудозатраты оценивает команда. Scrum Poker или метод KJ помогут упростить этот процесс.

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

В поле «Тип задачи» мы указываем направление, с которым работаем:

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

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

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

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

Научиться вести работу над проектами в разных сферах вы сможете на факультете проджект-менеджмента GeekUniversity.