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

Бэклог продукта — совершенный список задач

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

Просмотр тем

Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.

Что такое бэклог продукта?

Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).

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

Два столпа бэклога продукта

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

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

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

Что может повлиять на то, как владелец продукта расставляет приоритеты?

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

Правильное ведение бэклога

После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить расстановку приоритетов и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога в кругах специалистов по Agile часто называют «грумингом» или «ведением бэклога» (некоторые используют термин «уточнение бэклога»).

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

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

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

Плохие примеры, которые лучше не повторять

Бэклоги продукта и верность команды принципам agile

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

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

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

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

Источник

Что такое бэклог продукта: основы

Узнайте, как создать и вести бэклог продукта

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

Содержание

Как вести бэклог продукта

За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.

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

Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.

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

Чем бэклог продукта отличается от бэклога спринта

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

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

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

Как создать бэклог продукта

Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.

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

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

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

Источник

11 советов по оптимизации бэклога

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

Как управлять бэклогом эффективно? На этот вопрос помогут ответить 11 практических советов для тех, кто стремится навести порядок в бэклоге и “довести” его до идеального состояния.

1. Начните с подготовительной работы

Перед тем, как приступать к управлению бэклогом продукта, то есть очередью скопившихся задач (product backlog), оцените стратегию своего продукта: все ли с ней в порядке. Хорошо описанная стратегия — это способ реализовать свое видение продукта. Это начало начал, без которого дальнейшая жизнь продукта не представляется возможной. Этап подготовки стратегии происходит с одновременным исследованием и анализом рынка.

2. Сфокусируйтесь на главном

Сосредоточьте свой бэклог на предстоящем релизе, так как это стратегическая составляющая, в которой описаны все детали продукта и истории пользователей, которые должны быть реализованы. Долгосрочные планы по развитию продукта удобнее всего описывать в дорожной карте продукта (product roadmap).

3. “Содержите” бэклог в управляемом состоянии

Иногда собственники продуктов и менеджеры могут допускать 50, 100, 200 и даже больше накопившихся вопросов и задач. Такой бэклог выглядит неконтролируемым и, порой, безнадежным. В этом случае, им довольно сложно управлять и создавать прозрачность. Логично, что сказать, куда двигается продукт при таких обстоятельствах, не так просто.

Как менеджер продукта, менеджер проекта или product owner, вы должны решить, как максимизировать результат, минимизируя затраты и усилия.

4. Используйте дорожную карту

Управление бэклогом с помощью удобной дорожной карты поможет “набросать” и спланировать способы использования и реализации вашего продукта и его жизненного цикла. Часто этот документ является основой успешного управления бэклогом.

Product roadmap поможет визуализировать предстоящие релизы с их целями и этапами. Вот как дорожную карту помогает реализовать сервис Roadmunk:

5. Коммуницируйте и сотрудничайте

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

6. Поделитесь бэклогом с заинтересованными сторонами

Не нужно скрывать актуальное состояние бэклога. Сделайте его прозрачным для заинтересованных сторон (stakeholders), чтобы все могли проверить последний статус продукта и предоставить полезную обратную связь. Это поможет в принятии трудных решений.

7. Устраивайте встречи по оптимизации бэклога

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

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

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

8. Работайте с историями пользователей

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

9. Регулярно актуализируйте дорожную карту

Проверяйте и вносите изменения. Если вы работаете по Agile, изменений, скорее всего, будет достаточно. Обновляйте состояние roadmap в промежутке от трех недель до трех месяцев. Это обычно зависит от того, насколько “молод” ваш продукт и насколько динамичен рынок.

10. Назначайте приоритеты

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

Многие менеджеры продуктов используют для определения приоритетов удобные параметры Value и Efforts для каждой идеи.

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

11. Визуализируйте

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

Пример такого инструмента — Backlog Priority Chart в Hygger.io.

А как вы управляете очередью задач продукта? Какие из перечисленных шагов по оптимизации продуктового бэклога показались вам наиболее полезными?

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник