Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?
Менеджеры продукта и его собственники не могут не уделять серьезного внимания продуктовому бэклогу. Не только для облегчения планирования релизов и итераций, но и для оптимизации всего жизненного цикла продукта, над которым намерена работать команда.
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.
Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.
Бэклог продукта vs бэклог спринта
Эти два компонента Scrum несут разный смысл, но их часто путают.
Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать.
Оба бэклога можно представить в обычной таблице Excel, однако сегодня для этих целей опытные менеджеры и собственники продуктов пользуются специальными инструментами для управления продуктом, позволяющими грамотно визуализировать состояние дел.
Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.
В чем смысл бэклога продукта?
Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.
Обычный бэклог продукта включает следующие пункты:
Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.
Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.
Для чего нужен backlog refinement?
Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.
Чем бэклог продукта в Agile отличается от простого списка дел?
У бэклога продукта есть определенные свойства:
Что делать, если бэклог неустанно растет?
Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?
Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:
Структурирование бэклога
В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:
Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.
Оценка идей
В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
Backlog Priority Chart
Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Содержание
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
Идеальный бэклог продукта
И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
Где умирают пользовательские истории
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
Как воскресить бэклог продукта, чтобы он стал идеальным?
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
Для чего и как проводят backlog grooming в продуктовых командах?
Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?
Набор таких задач не несет ценности, если не приносит системной или структурной оптимизации. Очень важно правильно уметь управлять очередью задач, чтобы получить актуальный материал для работы. Как раз это и является целью такого процесса или активности, как backlog grooming.
Еще один тип встреч в Scrum
Backlog grooming — это собрание представителей Scrum-команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.
Наверняка, большинство менеджеров и собственников продуктов благодаря опыту и практике знают, как превратить рутинное управление бэклогом в приятный процесс. Чтобы достичь этого, необходимо тщательно ухаживать за бэклогом, “чистить” и оптимизировать его. Это то, что называется grooming или product backlog refinement.
Согласитесь, любой продукт, как и человек, требует внимания и заботы.
Стратегический смысл груминга в управлении продуктом
Поскольку бэклог представляет собой очередь из пользовательских историй, то, часто, такой список может быстро стать перегруженным. Многие не знают, как справляться с такой перегрузкой, а бэклог продолжает расти.
Когда это случается, члены команды могут потерять фокус на важных задачах, а статус пользовательских историй может утратить ясность. Также могут возникнуть проблемы с оценкой времени и ресурсов.
Уход за бэклогом — это активность с участием менеджера проекта (менеджера продукта/ собственника продукта) и представителя клиента, направленная на то, чтобы разбить бэклог на истории пользователей, переориентировать их и задать новые приоритеты. Backlog grooming в управлении продуктом должен стать постоянным событием, основанном на глубоком анализе и четких действиях.
Этот процесс необходим для того, чтобы задачи, представленные в бэклоге, были актуальными, а те, которые представлены в верхней части списка, были готовы к планированию в спринте, реализации и релизу.
Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.
Процесс не считается формальный частью Scrum. Тем не менее, рекомендуется, чтобы владелец продукта и представители команды выделяли до 15% каждого спринта для такой активности.
Главные цели процесса backlog grooming
Иногда собрание по backlog grooming называют story time session. В любом случае, цель этого мероприятия — обсудить текущий бэклог, определить и предложить действия по его оптимизации. Это может включать следующее:
Результат хорошего груминга
Результатам grooming является здоровый вид бэклога:
Какие инструменты использовать для backlog grooming?
Поскольку определение приоритетов — ключевой момент во время проведения backlog grooming, то очень важно грамотно визуализировать важность и взаимосвязь задач для дальнейшей работы с ними. Для упорядочивания идей и задач менеджеры продуктов используют параметры Value и Efforts. Сравнение этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные задачи.
В качестве заключения
Важно помнить, что grooming должен стать постоянным событием в управлении продуктом, которым не стоит пренебрегать. Этот процесс — это норма для качественного развития продукта. Самое главное в нем — оптимизировать задачи бэклога для последующей работы с ними.
Backlog grooming помогает прояснять релевантность задач, представленных в бэклоге, анализировать существующие вопросы и получать дополнительную информацию о задачах, которые пока не до конца ясны.
Подытоживая, отметим основные преимущества backlog grooming:
Управление проектами что это? Пошаговое руководство!
Управление проектами что это? Пошаговое руководство! Бэклог продукта. Цель проекта. Руководитель проекта. Проектная группа. Бэклог спринта.
Здравствуйте, уважаемые коллеги, руководители среднего и высшего звена, а также Project-менеджеры!
Сегодня расскажу, как профессионально управлять проектами в организации! Тем более, что сам являюсь действующим практиком! В настоящее время я управляю крупным бизнесом, группой компаний с различными направлениями: оптовые продажи, розничные продажи, транспортная логистика, управление недвижимостью, брокерские таможенные услуги.
Итак, все по порядку! Что необходимо делать в project management!
1. Управление проектами. Подготовьте бэклог продукта (product backlog).
Бэклог продукта (product backlog) включает в себя все пожелания, требования внутреннего или внешнего заказчика (product owner), или менеджера продукта (product manager). Product owner может быть в лице высшего руководства компании, где Вы работаете или быть сторонним заказчиком.
Примерами product backlog в моем случае являются:
Можно перечислять и дальше проекты под моим управлением, но будем экономить время!
Итак, что включают в себя требования product owner?
Язык требований product owner включает в себя, как технические параметры, так и общие, широко распространённые и понятные большинству лексические формы.
И структура, и функции, и содержание с формой product backlog состоят из «кирпичиков», отдельных элементов бэклога, которые называются пользовательские истории (user stories). Каждая user stories имеет вес, уровень приоритета, что предполагает разные временные, энергетические, финансовые затраты. Это позволяет проектной команде более гибко распределять свое рабочее время, в зависимости от значимости user stories.
2. Управление проектами. Поставьте цель проекта (project target).
При этом цель должна соответствовать следующим критериям:
Без экологической проверки поставленной цели критериям возрастает риск «прийти туда, не зная куда, получить то, не зная что».
Обычно цель проекта определяется в процессе генерирования идей на основании бэклога продукта уже проектной группой (project team), в составе которой должны быть product owner, product manager.
Цель проекта без бэклога продукта не может быть качественно сформулирована. Однако, наличие бэклога продукта еще не гарантирует генерирование качественной цели проекта (project target), необходимо будет отсечь все лишнее и оставить наиболее важное. Об этом легко говорить, но на деле непросто сделать.
Потому что заказчик (product owner) весьма часто хочет «и на елку залезть, и дрова получить, и в смоле не испачкаться, и об иголки не уколоться».
ПОСМОТРИТЕ ВИДЕО “Переговоры. Как преодолеть возражения?!”
