Рассказывает
Алексей Гальченко Технический директор 17 лет опыта
Продуктовые менеджеры, заказчики и исполнители все больше внимания уделяют бэклогу. Хотя в основном это понятие звучит в сфере IT, его давно используют для оптимизации процессов реализации проектов в других сферах. В этой статье рассмотрим, что такое бэклог, как его применять.
Что такое бэклог
Так называют документ, который по форме похож на список задач. В нем фиксируют все действия, которые команда выполнит во время разработки продукта. Однако это не типичный список, поскольку в него также вносят требования, возможные ошибки и результат, который должен быть получен.
При этом бэклог допускает регулярную доработку. Он составляется на подготовительном этапе, но после завершения крупных задач пересматривается. Документы дорабатывают, потому что в процессе могут измениться цели, или на проект повлияют внешние факторы.
Бэклог продукта / Product Backlog / Что это такое?
В каких отраслях используют бэклог
Понятие бэклога преимущественно фигурирует в IT-компаниях, но его активно используют в других отраслях. Внешне документ похож на техническое задание, но оно подробнее и затрагивает всех специалистов команды, т. е. действия программистов, дизайнеров указаны в одном файле.
Кроме IT, бэклог применяют на производстве и в маркетинге, включая SEO, SMM и другие направления. Для создания нового продукта используется множество специалистов, работу которых нужно организовать. Бэклог решает эту задачу, поскольку продакт-менеджер и команда заранее утверждают список работы, а руководитель может отслеживать прогресс по этому документу. В результате команда непрерывно работает над продуктом.
Виды бэклогов и их применение
Бэклоги классифицируют по разным основаниям, но в основном их делят на 2 вида:
Это структурированный перечень элементов, функций и задач, которые команда должна реализовать. Его разрабатывает продакт-менеджер после согласования технического задания с заказчиком. В документе отражаются все пожелания клиента и требования.
В нем не используют узкоспециальные термины и подробно не описывают задачи, поскольку конкретизацией будут заниматься руководители команд. Продакт-менеджер старается в общих чертах отразить задачи, чтобы их понимали все специалисты.
Когда документ будет готов, менеджер представляет бэклог командам разработчиков, дизайнеров, маркетологов и другим специалистам, которые будут участвовать в проекте. Первичный бэклог обсуждается и согласуется с исполнителями, которые позже займутся планированием спринтов.
Продуктовый бэклог существует в течение всей работы над крупной задачей и регулярно дорабатывается..
Это уже более конкретные документ. Он является вторым компонентом методики управления проектов Scrum. Планирование спринтов находится в зоне ответственности узких специалистов, поскольку в нем крупные задачи из бэклога продукта дробятся на мелкие.
Бэклог Продукта — Объяснение
Еще одна особенность спринта — небольшой размер. Документ составляют на каждом этапе проработки продукта. В новых бэклога учитываются результаты и сложности предыдущего спринта.
Бэклог спринта составляют примерно на 1–2 недели, т. е. пока команда не перешла на следующий этап работы.
Основные элементы бэклога
Нет строгих требований к оформлению и содержанию бэклога. В минимальный набор входят:
- Задача. Это описание того, что должен сделать исполнитель.
- Приоритет. Измеряется в числах и показывает, насколько задача важна. Обязательный элемент, отражающий возможность перемещать задания или увеличивать срок выполнения, если объем работы оказался больше ожидаемого.
Стоит отметить, что второй параметр зависит от факторов приоритизации, например: ценность для бизнеса, возможные риски из-за пропуска задачи и т. д. К примеру, если программист не добавит в приложение форму для авторизации, значит, пользователь не сможет войти в личный кабинет. Тогда возникает вопрос: “а зачем софт нужен?”. Такая задача будет иметь максимальный приоритет.
Таблицы из 2 колонок редко бывает бывает достаточно. Исполнители, особенно если их много, не особо поймут, что нужно делать, что уже выполнено, какой отдел или специалист должен этим заняться. Чтобы устранить недопонимание, компании добавляют дополнительные элементы. Кратко рассмотрим их:
- Тип задания. Задачи классифицируют и помечают цветом. В рамках проекта специалисты занимаются проверкой гипотез, разработкой кода, созданием дизайна, сбором обратной связи и доработками. Чтобы длинная таблица была удобной, ее размечают цветом или добавляют дополнительную колонку с названием задачи.
- Приблизительная трудоемкость. Измеряют в часах или условных единицах. Во втором случае берут самую простую задачу и ставят один балл. А затем в сравнении с ней определяют сложность других заданий.
- Инициатор. Спустя месяц работы трудно вспомнить, кто предложил изменить цвет кнопки или добавить новую анимацию. Чтобы не искать хозяина задачи, его указывают в отдельной колонке.
- Статус. Важный элемент, который особенно важен в бэклогах спринтов. Руководители смогут отслеживать продуктивность конкретных сотрудников и распределять ресурсы между заданиями. Достигнув поставленной цели, исполнители указывают “Выполнено”. Если же нужно внести правки, пишут “На доработке”. Данный столбец сильно упрощает контроль результатов, потому что все отображаются в одном окне, и нет необходимости связываться с исполнителями.
Как составить и вести бэклог
Чтобы разработать бэклог, нужно составить несколько первичных документов, которые дают максимально общее понимание о продукте и процессе его разработки. Компании составляют:
- Дорожную карту. Это стратегический план, в котором отражены направление реализации проекта и сроки выполнения каждого этапа.
- Пользовательскую историю. Так называют рассказ заказчика с точки зрения пользователя или клиента. Он описывает то, что должен увидеть конечный потребитель. User Story может звучать следующим образом: “Хочу видеть всплывающие подсказки при первом запуске приложения”..
- Карта путешествия клиента. Визуализированный пользовательский опыт с учетом его цели, барьеров, эмоций. Карта отражает User Story и отражает “узкие места” продукта.
Затем продакт-менеджер вместе с исполнителями:
- Составляет список функций и анализирует их ценность для пользователя. Прошедшие отбор фишки записывает в бэклог.
- Определяет сроки реализации и распределяет задачи.
Затем руководители подразделений создают бэклоги спринтов, которые более конкретны, но по своей сути мало отличаются от продуктового. Крупные задачи делят на мелкие элементы, которые можно выполнить в краткосрочной перспективе.
Ведением бэклога занимаются специалисты всех уровней, включая отдельных программистов, дизайнеров. Они отмечают статус задачи. Руководители среднего и высшего звена вносят правки в продуктовый бэклог с учетом промежуточных результатов. Корректировки вносят на основе выводов по последним итерациям с целью пересмотра приоритетов, сроков, требований и т. д.
Если бэклог оказался очень широким, в нем выделяют краткосрочные и долгосрочные задачи. Первая группа задач детально расписывается и обсуждается, а вторая строится по упрощенному сценарию.
Инструменты для ведения бэклога
Небольшие компании в основном работают с Google-таблицами. В них расписывают задачи, сроки, указывают исполнителей, а затем руководитель раздает доступ подчиненным. Его функционала достаточно, но не хватает визуализации, из-за чего продакт-менеджеры часто пользуются специализированными сервисами, например:
- Monday.com. Простой в настройке и эксплуатации сервис с базовыми инструментами.
- ClickUp. Универсальный и бесплатный сервис для разработки бэклогов любого размера.
- Craft.io. Удобный инструмент со встроенными рекомендациями по выстраиванию иерархии и повышению эффективности.
- Backlog. Продвинутый сервис с уведомлениями и инструментами для контроля статусов задач.
- Productboard. Отличается простым интерфейсом, который выполнен в виде дашборда. Ее преимущество — возможность выделить свои задания из общей массы и перенести их на отдельную доску.
Плюсы и минусы использования бэклога в проектах
Бэклоги становятся популярнее традиционных технических заданий и простых списков задач, потому что он упрощает расстановку приоритетов и контроль результатов. Кратко рассмотрим основные преимущества использования бэклога:
- Повышение эффективности. Продакт-менеджер и руководители команд определяют приоритеты, дедлайны. Благодаря этому исполнители могут эффективнее управлять временем.
- Гибкость. Бэклоги постоянно дорабатываются с учетом скорости выполнения проекта, изменения приоритетов и внешних факторов.
- Упрощение взаимодействия. Бэклоги сочетают в себе как масштабные, так и мелкие цели, поэтому их проще обсуждать и согласовывать на всех уровнях иерархии.
- Согласование ожиданий. В едином документе отражены статусы заданий, и все специалисты смогут отслеживать результаты друг друга. Это поможет выстроить непрерывный рабочий процесс.
Недостатки бэклога в основном связаны с тем, что требуется много времени на составление и актуализацию. Если продакт-менеджер, руководители среднего звена не занимаются им, то возникнет множество проблем из-за:
- Неактуальных сведений.
- Неверного распределения приоритетов.
- Ограниченного доступа к документу.
Пример успешного использования бэклога
На скриншоте ниже представлен общий бэклог по продукту, включая разработку, UX и контроль качества.
В таком формате обычно составляют первичные бэклоги спринтов. У каждого этапа есть приоритет, название пункта, требования клиента. Позже их разделят на более мелкие цели, чтобы распределить задачи между конкретными специалистами.
Какие ошибки надо избегать при ведении бэклога
Распространенные ошибки, которые приводят к сбоям в процессе разработке продукта:
- Приоритизация через посредников. У бэклога может быть только один владелец, который управляет приоритетами и упорядочивает задачи. Основным документом занимается продакт-менеджер, а спринтами — руководители команд. Передавать права на приоритизацию кому-то еще нельзя, иначе возникнут проблемы со взаимодействием.
- Перегрузка документа. Бэклог даже крупных проектов редко превышает 5 страниц, потому что задач должно быть столько, сколько команда может закончить за 3–6 спринтов. Если их больше, цели делят на 2 группы: кратко- и долгосрочные.
- Редкая актуализация. Все элементы документа нужно проверять после завершения спринта. Это предотвратит расходование сил и ресурсов на неактуальные задания.
- Излишняя детализация. Бэклог — документ, который в общих чертах описывает задачу, поэтому нет смысла тратить много времени на предварительном этапе. Тем более в процессе работы он будет постоянно дополнятся и уточнятся.
- Нет критериев приемки. Их не всегда указывают прямо в бэклоге, а выносят в отдельные документы, но где-то должны быть прописаны критерии оценки. Они позволят исполнителям лучше разобраться в задаче и самостоятельно проверить результат.
- Мало пунктов. Бэклог должен содержать приоритеты, время, имена исполнителей и другую информацию, которая нужна для налаживания внутренних процессов. Если информации недостаточно, таблица будет бесполезной, поскольку взаимодействие просто будет вестись за рамками бэклога.
- Нет исследований. В перечне задач всегда присутствуют исследовательские задания, которые нужны для выявления возможных рисков и проблем. Их стоит разбирать заранее, чтобы грамотно распределять время, ресурсы и не срывать сроки из-за неожиданных трудностей.
Источник: medianation.ru
Что такое бэклог: для чего нужен и как вести
Для оптимальной работы над проектом необходимо знать, что такое бэклог, его составляющие и правила ведения. Простыми словами, это список предстоящих задач, составленный с учетом приоритета каждого пункта.
Звучит просто, однако на деле нередки ситуации, когда бэклог принимает огромные размеры, а время, необходимое для решения всех задач в нем, составляет даже не месяцы, а годы. В нашей статье мы расскажем, каковы задачи бэклога, что в нем должно быть и как правильно его оптимизировать, чтобы работа была эффективной.
Что такое бэклог
Этот термин разработчики используют для обозначения списка заданий, который ранжирован по рейтингу их важности. Он составляется на основании «дорожной карты» проекта и его требований. В начале бэклога продукта идут самые важные задачи, которые команда должна выполнить первыми.
При этом, на скорость их выполнения не влияют пожелания собственника. Участники рабочей группы сами выбирают для работы задачи бэклога, как только у них появляются соответствующие ресурсы. Они могут осуществлять выполнение заданий итерациями (Scrum) или безостановочно (Kanban).
Все задачи бэклога следует сохранять в одном трекере. Для поиска багов, отслеживания требований владельца и выполненных пунктов списка должна применяться только одна система. Если появляется новая задача для участников рабочей группы, она должна попадать в один и тот же бэклог.
Отличия бэклога продукта от бэклога спринта
Бэклог продукта (product backlog) представляет собой структурированный перечень компонентов, задач и список функций, которые необходимо реализовать в рамках разработки проекта.
Product owner или продакт-менеджер представляет бэклог команде разработчиков, обеспечивает описание его основных элементов в ходе встречи, где осуществляется планирование спринта. Такой специалист управляет работой команды.
Для описания элементов перечня задач важно использовать понятные всем термины, избегая узкоспециальных названий. Важно, чтобы задания были понятны всем, кто работает над проектом. В перечне задач должны отражаться все изменения и новые требования к продукту.
Для вас подарок! В свободном доступе до 04.06 —>
Скачайте ТОП-10
бесплатных нейросетей
для программирования
Помогут писать код быстрее на 25%
Чтобы получить подарок, заполните информацию в открывшемся окне
В свою очередь, бэклог спринта представляет собой список конкретных заданий по реализации уже отобранных для работы элементов. Здесь находится перечень задач по оптимизации, которые разработчики будут выполнять в течение ближайшего спринта, а также описание вариантов их реализации.
Бэклоги продукта и спринта являются двумя отдельными компонентами методики управления проектом (Scrum). Их часто путают, но они существенно отличаются по смыслу.
Оба эти элемента могут быть отображены в форме стандартной таблицы Excel. Опытные продакт-менеджеры для представления бэклогов продукта и спринта чаще используют специальные приложения для управления проектами. Такие инструменты обеспечивают эффективную визуализацию процесса разработки.
Отметим также, что бэклог продукта разрабатывает продакт-менеджер, а перечень задач спринта находится в зоне компетенций команды разработчиков. Есть еще одно важное отличие в рассматриваемых понятиях. Product-бэклог оформляется уже в ходе первого планирования спринта. В свою очередь Sprint-бэклог необходимо создавать в ходе проработки плана для каждого отдельного спринта.
Таким образом, бэклог продукта будет жить в течение всей работы над проектом, а перечень задач Sprint существует лишь 7 – 14 дней, пока идет работа над очередным спринтом.
Составляющие бэклога
Стандартный набор бэклога – задачи и их приоритетность. Чем выше цифра — тем больше приоритет, а существенные пробелы между числами (100, 300, 600, 2000 и т.д.) дают возможность различных комбинаций: в любое время можно вставить дополнительную задачу между имеющимися.
Классическими критериями приоритизации бэклога могут являться преимущества для бизнеса, затраты (или необходимые ресурсы) и возможные риски (положительное воздействие внедрения определенной части продукта или же негативное влияние отсутствия фичи).
Для всего процесса создания продукта двух разделов в бэклоге будет недостаточно, поэтому здесь вносятся и другие поля.
Подробное описание целей и желаний
Совершенный перечень рабочих задач – это тот, где в каждой строчке обозначено определенное задание. При неполном представлении конкретных пожеланий владельца продукта сложно понять их смысл, поэтому, чем выше приоритетность задания, тем детальнее должно быть его представление.
Узнай, какие
ИТ-профессии входят
в ТОП-30 с доходом от 200 000 ₽/мес
Команда GeekBrains совместно с международными специалистами по развитию карьеры подготовили материалы, которые помогут вам начать путь к профессии мечты.
Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!
Скачивайте и используйте уже сегодня:
Александр Сагун
Эксперт GeekBrains
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ ресурсов об IT-сфере
Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT
ТОП 50+ сервисов и приложений от Geekbrains
Безопасные и надежные программы для работы в наши дни
Скачать подборку бесплатно
Уже скачали 21047
Чем ниже уровень задачи бэклога, тем менее детализированным будет ее описание. Есть и обратная сторона: чем выше задание в списке, тем более развернутым необходимо сделать его представление, чтобы повысить подготовленность к дальнейшей работе.
Возможные сложности
Могут измеряться в часах, но часто разработчики прибегают к условным единицам измерения — в часах, Story Point-ах: один балл – классическая задача бэклога, а все остальные будут оцениваться сравнительно с ней.
Категория компонентов
Задачи в список могут быть добавлены по различным обстоятельствам: как правило, это мысли и предположения, а иногда и отклики от клиентов и технические параметры, требующие модернизации. В этом случае было бы неплохо распределять задания по определенным категориям при помощи, например, переформатирования.
Инициатор или владелец задачи
Пример бэклога продукта – это медленно формирующаяся система, которая через некоторое время начинает значительно разрастаться. Таким образом, после нескольких месяцев бывает очень сложно вспомнить, кто, в какое время, а, главное, для чего посоветовал «покрасить кнопку в красный цвет», удалить из формы поле с представлением задачи или прибавить ещё одну категорию доставки.
Подобный раздел будет очень полезен. В связи с этим стоит задать дату внесения задачи в список и ее инициатора, но нужно учитывать, чем больше число колонок, тем сложнее поддерживать актуальность бэклога.
Статус
Колонка может пригодиться для процесса быстрой фильтрации, а ещё для отбора определенных задач спринта и удобства наблюдения за развитием.
Необходимых полей нет, многое зависит от самого проекта и действий по его разработке. Следовательно, если есть необходимость добавить индивидуальные колонки, то такая возможность есть всегда. Главная цель – поддерживать их актуальность.
Приоритизация задач в бэклоге
В зависимости от этапа работы над проектом, задачи могут подлежать разной степени детализации.
Большинство запросов к проекту фильтруются и регистрируются, но детальному описанию подлежат те, которые отправятся в работу в ближайшее время. Если каждая задача будет детально разбираться, то она в скором времени потеряет всю свою актуальность.
Чтобы назначать приоритет задания, необходимо соответствие как минимум двух идентификаторов: насколько оно важно с точки зрения бизнес-процессов, и сколько затрат потребуется на его создание.
Только до 5.06
Скачай подборку тестов, чтобы определить свои самые конкурентные скиллы
Список документов:
Тест на определение компетенций
Чек-лист «Как избежать обмана при трудоустройстве»
Инструкция по выходу из выгорания
Чтобы зарегистрироваться на бесплатный интенсив и получить в подарок подборку файлов от GeekBrains, заполните информацию в открывшемся окне
Первый показатель будет определять хозяин продукта, а анализ общей работы оценивает команда на начальном этапе планирования спринта. К примеру, для коммерческой деятельности задача на девять баллов будет носить очень значимый характер, а по сложности работы это четыре story point (баллы сложности, вычисляемые по сравнению с иными задачами). В действительности, процедура оценивания намного труднее, чем кажется, и зачастую носит спорный характер.
Таким образом, в спринт подбираются важнейшие задачи при учете общей загруженности. В Scrum это видно при подробном разборе списка на собрании разработчиков, что упрощает анализ задач и их отбор на последующий курс.
Порядок составления бэклога
Так как в ходе работы над проектом не исключено появление конкурентов в рыночной нише, изменение стоимости, рыночных требований и других условий, оказывающих влияние на конечный продукт, бэклог должен постоянно обновляться.
Как было отмечено ранее, существует ряд инструментов, который продакт-менеджеры используют для создания backlog. Это product roadmap, user stories и customer journey map. Рассмотрим каждый из них в отдельности:
- «Продакт роудмэп» визуализирует задачи и общие свойства продукта, пути его развития и стадии создания. В большинстве случаев этот документ не содержит отдельных деталей, но включает сроки выполнения заданий, а также позволяет рассчитывать время их выполнения.
- «Юзер сторис» упрощает составление требований и способствует более точному пониманию пользователей. Этот инструмент имеет вид сжатого описания тех моментов, которые связаны с хотелками пользователя, и объяснения, почему ему это необходимо.
- «Кастомер Джорни Мэп» визуализирует цели, эмоции клиента и преграды, возникающие на его пути. Такую карту клиентского пути необходимо формировать под каждую «Юзер сторис». Customer journey map способствует выявлению слабых мест продукта и позволяет более точно расставить приоритеты в работе разработчиков. Также, как и предыдущие документы, Джорни Мэп необходимо постоянно корректировать и обновлять.
Рассмотрим алгоритм действий по разработке бэклог продукта с использованием трех представленных выше инструментов:
- Составьте перечень функций, планируемых для реализации в продукте, и расставьте их в порядке важности с использованием «продакт роудмэп».
- Сформулируйте user stories (истории пользователей) по каждой отдельной функции и сделайте анализ их ценности для потенциального клиента.
- Определите основные функции, которые будет иметь будущий продукт, расставьте их в порядке важности и внесите в product backlog.
- Проставьте планируемые сроки выполнения заданий и определите ответственных членов команды по каждому из них.
- Организуйте проведение встречи с командой разработчиков, проведите обсуждение составленного бэклога и внесите необходимые корректировки.
Постановка задач в рамках product backlog осуществляется по методике SMART. Необходимо подробно прописать все важные для работы элементы на один или два ближайших спринта.
Дальнейшие задачи, вероятнее всего, будут требовать корректировок с учетом итогов первых спринтов и обратной связи. Важно скрупулезно собирать все необходимые данные и помнить о необходимости постоянного анализа и обновления product backlog.
Груминг и рефаймент бэклога
Груминг бэклога представляет собой процесс постоянного уточнения и корректировки проекта. В переводе с английского «grooming» — это «причесывание». Это слово раскрывает суть процесса, связанного с исследованием, систематизацией компонентов проекта и расстановкой приоритетов.
Рефаймент бэклога – мероприятия по его оптимизации. Их цель состоит во внесении новых элементов, оценок и обеспечении упорядоченности этапов плана. На рефаймент уходит до 10% времени разработчиков.
Кто может вносить правки в существующий план работ?
- Члены рабочей группы, создающей продукт.
- Собственник продукта, участник команды, выступающий в качестве эксперта и контролирующего органа. Такие лица могут корректировать направление разработки и приоритетность задач.
- Скрам-мастер решает вопросы повышения производительности членов рабочей группы.
- Стейкхолдеры – другие участники процесса, заинтересованные в проекте.
Популярные статьи
В мероприятиях по актуализации перечня задач могут участвовать и другие специалисты.
Что включает grooming бэклога?
- Детальный обзор требований владельца продукта.
- Расстановку необходимых опций продукта в зависимости от их сложности и приоритетности.
- Повторный анализ утвержденных и новых задач.
- Дополнение бэклога новыми описаниями и элементами.
- Группировка деталей плана.
- Разделение масштабных задач на отдельные стадии.
- Проработка несоответствий и элементов, не соответствующих логике задач.
Бэклог refinement предполагает удаление из существующего плана «лишних» элементов. Обновление перечня задач дает возможность оптимизировать занятость разработчиков и снимает лишние задания. Этот процесс позволяет упростить планирование занятости рабочей группы и избавиться от неопределенности в хотелках владельца продукта.
Благодаря постоянной актуализации задач удается предотвратить повторную работу над отдельными пунктами плана и их дальнейшую переделку. Таким образом оптимизируется работа разработчиков и ускоряется процесс реализации всего проекта.
Чтобы оптимизировать деятельность рабочей группы, следует предусмотреть организацию груминга в виде коротких собраний с периодичностью, которая определяется, исходя из имеющихся условий работы и потребностей процесса. Как правило, такие встречи участников команды разработчиков проводятся один-два раза в неделю перед тем, как перейти к новому этапу работы над продуктом.
Уменьшение бэклога
Стоит отметить, что чрезмерно расширенный активный список бэклога может свидетельствовать о неумении расставлять приоритеты и является признаком непрофессионального подхода к организации процесса. Мнение о том, что это следствие нехватки ресурсов, является ошибочным.
Опытный специалист всегда сможет компенсировать недостаток ресурсов точными расчетами, договориться с участниками об удалении элементов бэклога, последующем анализе объемов задач с учетом принципов разработки, о привлечении дополнительных членов в рабочую группу. Рассматривать на каждом собрании огромные объемы информации бэклога, включающего сотни пунктов, о которых уже давно забыли инициировавшие их участники – это не лучшее решение.
Благодаря этой рекомендации обеспечивается оптимизация бэклога. На представление задач на собраниях команды разработчиков не придется каждый раз тратить много времени и выслушивать от них разраженные замечания «зачем каждый раз говорить об одном и том же».
Единого совета для всех ситуаций не существует, но есть моменты, которые следует сделать, чтобы упростить работу с бэклогом:
- Провести анализ актуальности задач. Возможно их инициировали те участники, кто уже давно покинул проект или они потеряли к этому всякий интерес.
- Сделать проверку на наличие дублей. Есть примеры, когда в списке присутствует много одинаковых, но по-разному сформулированных пунктов.
- Сделать расчеты по трудозатратам и продолжительности реализации бэклога, учитывая статистику появления новых задач. Возможно, перечень заданий только выглядит большим, а на практике вашей команде, с учетом профессионального планирования работ, удастся справиться за несколько месяцев. Отдельно остановимся на динамике прироста задач. Цифры – упрямая вещь, и с ними не поспоришь. Нужно получить максимально подробную информацию по источникам заданий. Возможна ситуация, когда инициатором почти всех задач выступает один не ключевой «отдел администрирования» и для оптимизации процесса его на время следует «забанить».
Описанный выше комплекс мероприятий часто приносит требуемый результат.
Оптимизация бэклога, независимо от того, какой продукт подлежит разработке, является обязательным элементом управленческого инструментария.
Опытный специалист по управлению проектами, используя специальные инструменты, всегда сможет разобраться с бэклогом и превратить рутинное управление проектом в интересный процесс.
Источник: gb.ru
Что такое бэклог продукта
При работе над проектом важно планировать и определять приоритет задач в проекте.
Бэклог продукта — это перечень задач, которые необходимо выполнить в ходе работы над проектом, и список функций, которые хотят получить пользователи и заинтересованные лица. В него входят как уже запланированные шаги, так и пожелания заинтересованных лиц по улучшению продукта.
- В бэклог продукта включаются только первоочередные задачи и требования клиентов к качеству. Первыми в списке располагаются приоритетные цели, благодаря чему команда всегда знает, на чем стоит сосредоточиться в первую очередь.
- Бэклог гибок и постоянно адаптируется под текущий рабочий процесс. По мере работы над проектом, Agile-команда сверяется с бэклогом продукта и редактирует его в зависимости от выполненной работы и потребностей клиента.
- Владельцу продукта нет необходимости раздавать задачи исполнителям, так как участники берут их из бэклога самостоятельно, что обеспечивает непрерывную работу над проектом.
Стоит учитывать, что бэклог работает таким образом только в том случае, если он грамотно составлен и постоянно обновляется.
Чем бэклог в Agile отличается от простого списка задач
Бэклог имеет свои уникальные особенности:
- это постоянно меняющийся документ, в котором нет низкоуровневых задач;
- важность каждой выделенной задачи для клиента;
- оценка каждой задачи в бэклоге;
- каждая задача получает свой приоритет и оценку.
Из чего состоит бэклог продукта
Бэклог — это модульный документ, который состоит из четырех групп. У каждой из них свое назначение и специфика.
Функции
Функции продукта — это технические возможности проекта, которые полезны для клиента или конечного пользователя. Они должны иметь объективную ценность для бизнеса, поддаваться тестированию, соответствовать критериям приемлемости пользователей, быть достаточно информативными, для того, чтобы Agile-команда могла их беспристрастно оценивать.
Каждая функция в бэклоге продукта делится на более простые пользовательские истории. Функции расставляют по приоритету, каждой из них присваивается свой стори пойнт.
Ошибки и баги
Ошибки и баги возникают в случаях, когда продукт некорректно работает или не соответствует своей изначальной задаче. Бэклог продукта существует в том числе и для контроля своевременных правок.
Выделяют три вида багов:
- срочные баги, связанные с текущими задачами и требующие немедленной реакции. Их обычно не заносят в бэклог, так как их необходимо исправить сразу после обнаружения;
- баги, которые необходимо исправить в течение текущего спринта. Не требуют немедленной реакции, их можно добавить в бэклог конкретного спринта, а не в бэклог продукта;
- баги, которые не будут исправлены в текущем спринте. Их необходимо добавить в бэклог продукта, так как работа над ними не влияет на успех продукта в текущем спринте.
Технический долг
Техдолг — это задачи, отложенные в угоду скорости исполнения или из-за неправильного планирования. Из-за этого решения в будущем вам придется вносить некоторые изменения.
Простой пример технического долга — вы настояли на том, чтобы ускорить разработку программного обеспечения, из-за чего в следующем спринте вам придется написать дополнительный код, который исправит возникшие в процессе внедрения ошибки. Таким образом вы потратите время, которое было запланировано на решение других задач.
Исследования
Разработка продукта невозможна без предварительного изучения информации. Эта задача не имеет отношения к пользователю, однако для полного понимания функций перед началом работы, необходимо проводить предварительные исследования и включать их в бэклог продукта.
Их результатом можно считать полученные знания в ходе поиска информации и мозгового штурма. Однако подобные исследования необходимо делать только в том случае, если вы не уверены в реализации некоторых рабочих элементов. К тому же стоит ограничивать время, затрачиваемое на данную деятельность.
В Kaiten можно создать отдельную доску для бэклога продукта. Есть даже готовый шаблон scrum-доски, которая состоит из доски спринта и доски бэклога вместе.
На чем основан бэклог продукта
Основой бэклога продукта обычно служат два важных элемента: дорожная карта и пользовательские истории.
Дорожная карта проекта — это визуализация стадий разработки проекта. С ее помощью владельцы продукта устанавливают сроки реализации. Дорожная карта ориентирована на глобальные задачи, она отображает концепцию продукта, его стратегию и достигнутые цели.
Дорожную карту нередко путают с бэклогом продукта. Однако в бэклоге указываются более частные задачи, которые раскрывают, как именно должен идти рабочий процесс над целями, отмеченными в дорожной карте.
Пользовательские истории — описание функций продукта простыми, общими словами, составленное с точки зрения пользователя. Благодаря им участники Agile-команды понимают, какими преимуществами будет обладать продукт после нововведений и что получит пользователь. Это позволяет работать более целенаправленно.
В Kaiten есть специальный модуль — User Story map. Он помогает увидеть большую картину продукта в формате Roadmap и структурировать пользовательские истории.
Для каждой пользовательской истории в модуле User Story map можно создавать карточки — добавлять описание, присваивать метки, статусы и размер. А главное — привязывать к ним конкретные задачи на рабочих пространства.
Как собрать бэклог продукта
В рамках Agile владелец продукта отвечает за создание и управление бэклогом. Для этого необходимо выполнить четыре шага:
1. Составить четкую дорожную карту проекта
Прежде чем добавлять новые элементы в бэклог, необходимо четко понимать, чего хотят пользователи от конечного продукта, какие у них требования. Чем больше понимания, чего именно хотят пользователи, тем точнее будет составлена дорожная карта.
2. Создать элемент невыполненной работы
Владелец продукта на основе пожеланий клиентов формирует список задач, которые необходимо выполнить по ходу работы над проектом. Необходимо вносить в этот список только те цели, которые имеют ценность для проекта.
3. Приоритизировать задачи
Для понимания, на чем конкретно необходимо сосредоточить свое внимание, стоит правильно оценивать важность каждой задачи по критериям:
- Ценность
- Сложность и риск
- Ожидания клиентов
- Усилия по развитию
По ходу работы приоритеты могут меняться, именно поэтому владельцу продукта необходимо вовремя обновлять бэклог.
4. Постоянная доработка бэклога продукта
Список невыполненных задач необходимо актуализировать, убирать уже выполненное, редактировать старые пользовательские истории, добавлять новые и разбивать те, что стали слишком большими, переоценивать приоритеты и обновлять их.
Так называемый Agile-уход за бэклогом гарантирует, что он останется актуальным, подробным и будет соответствовать текущей стратегии проекта.
Бэклог спринта vs бэклог продукта
Это два разных явления, которые также часто путают. Они несут похожий смысл, однако отличаются масштабностью.
Бэклог спринта — это список задач для оптимизации продукта, над которой команда будет работать в ближайший спринт и описание этого рабочего процесса. Над ним работает команда Agile, тогда как бэклог продукта составляет его владелец. Бэклог спринта команда составляет перед каждой новой итерацией, таким образом он живет от одной до четырех недель, то есть всё время спринта.
Тогда как бэклог продукта создается во время планирования первого спринта и существует на протяжении всей работы над проектом.
Вывод
Бэклог продукта помогает команде следовать принципам Agile. Он позволяет:
- делать только те задачи, которые принесут реальную пользу клиенту;
- избавиться от ненужной работы ради работы;
- свести к минимуму лишнюю документацию;
- быть гибкими и вносить важные изменения в продукт по мере его производства.
Есть 2 важных условия, при которых бэклог продукта будет приносить пользу:
- Он должен быть грамотно составлен на основе пользовательских историй;
- Его нужно регулярно чистить и обновлять.
Kaiten позволяет удобно управлять бэклогом продукта:
- Фиксировать элементы невыполненной работы на отдельной доске на одном рабочем пространстве с остальными функциональными досками;
- Распределять задачи по приоритетам;
- Вести коллективную оценку задач в бэклоге;
- Создавать пользовательские истории и связывать их с карточками на рабочем пространстве;
- Видеть прозрачную отчетность по задачам и следить за прогрессом их выполнения.
Попробуйте инструменты Kaiten для Scrum и Kanban на своем проекте бесплатно
Визуализация OKR в Kaiten. Кейс KCELL
Как визуализировать цели и ключевые результаты на пространствах Kaiten, показать их зависимости с разными подразделениями компании и отслеживать прогресс достижения целей.
Дарья Лебедева 30 мая 2023 г. • 5 min read
Как управлять командой проекта
Советы по созданию эффективной команды. О стилях управления, ролях в команде и инструментах для удобного планирования и контроля.
Дарья Лебедева 24 мая 2023 г. • 8 min read
Планировщик задач Kaiten — ваш личный карманный секретарь
Как освободить голову от шума и повысить личную продуктивность
Источник: kaiten.ru