Беклог продукту: як направити розробників у правильне русло

Сучасні методи розробки, такі як Agile та Scrum, вимагають певних інструментів для коректної роботи команди. Один з таких інструментів – це беклог продукту (Product Backlog). Без цього документа неможлива успішна розробка та її продуктивна організація. Давайте розберемося, що це за артефакт, з чого він складається, навіщо потрібен, і головне – як його сформувати.

Що таке беклог продукту

Product Backlog – це артефакт, в якому зібрані та впорядковані всі вимоги до майбутнього програмного продукту. У цьому вся документі описано усе, що потрібно реалізувати у процесі розробки, яке створенням займається власник самого майбутнього продукту.

Вам як клієнту при розробці власного програмного продукту доведеться створювати беклог для успішної розробки за сучасними стандартами. Фактично, сьогодні власник практично будь-якого бізнесу потребує розуміння беклогів та вміння працювати з ними.

Які беклоги бувають?

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

Великі компанії і світові проекти потрібно ретельно продумати, але це буває складно зробити відразу. Для цього створюються дорожня карта або роадмап, які допомагають побачити всю картину цілком.

Якщо проект невеликий, або це абсолютно новий стартап, можна відразу перейти до написання користувача сторі (історій користувачів). У такому випадку всі деталі будуть описані та працювати команді розробки буде простіше.

Навіщо потрібен беклог продукту

Для того, щоб зрозуміти необхідність у даному артефакті, необхідно поглянути на те, як саме відбувається робота по скраму.

Вся технологія ділиться на спринти – невеликі відрізки від однієї до чотирьох тижнів – які виконується певний обсяг робіт. Ціль кожного спринту полягає в тому, щоб зробити повністю готовий самостійний підпродукт, який можна включити в реліз. Щоб усе було організовано та злагоджено, на спринт із загального беклогу вибирається список завдань, які виконуватимуться.

Такий підхід забезпечує чітке дотримання вимогою, уберігає від недоглядів чи переробок, забезпечуючи планомірний рух до мети.

Беклог продукту та беклог спринту: в чому різниця

У рамках методології Scrum команди розробників працюють невеличкими інтервалами – спринтами. Кожен спринт присвячений виконанню певного обсягу роботи. Як правило, спринти тривають від 2 до 4 тижнів. Це важливо для розуміння різниці між беклогом продукту та беклогом спринту.

Приміром, що таке беклог продукту? Це повний перелік та опис вимог, завдань, функціоналу – усього, що треба реалізувати під час розробки. Він дає змогу розробникам зрозуміти й візуалізувати завдання, які вони мають вирішити, розставити пріоритети з огляду на інтереси клієнта, оцінити завдання у годинах розробки. Зазвичай керівником product backlog виступає його власник (product owner). Його роль полягає в тому, аби забезпечити якість кінцевого продукту в контексті інтересів клієнта.

Водночас беклог спринта – це результат короткострокового планування, який створюється й керується розробниками. За беклог спринта відповідає не product owner, а Scrum-команда.

Розробники вносять в беклог спринта перелік завдань на даному етапі розробки й за необхідності оновлюють його. Беклог спринта має бути максимально деталізованим та гнучким, аби команда могла розуміти свій прогрес.

З чого складається беклог продукту

Як і будь-який інший документ, беклог має певні критерії, які мають бути дотримані для успішної роботи. Ці критерії описують те, яка інформація має бути зазначена, як вона повинна бути структурована і хто відповідає за це.

Яка інформація має бути в белогу?

В першу чергу беклог продукту повинен містити повний опис майбутнього програмного рішення. Сюди відноситься опис кінцевого продукту, опис кожної окремої функції, їх взаємозв’язків та структури.

Також у беклозі повинні бути згадані і нефункціональні вимоги, наприклад, продуктивність, швидкість роботи, безпека і таке інше.

Ще один важливий критерій стосується структуризації вимог до продукту в белог. Усі вимоги мають бути зазначені у порядку важливості та пріоритетності. Адже під час розробки до спринту братимуться перші вимоги зі списку, і далі по порядку до кожного наступного.

Хто і як веде беклог продукту

За створення бэклога відповідає замовник або product owner, до його обов’язків входить складання та ретельний опис усіх вимог, а також обговорення цих вимог з командою розробки. Безумовно, вимоги мають бути однозначними та зрозумілими, але якщо у команди виникнуть будь-які питання, ви маєте змогу на них відповісти та уточнити будь-які нюанси.

Як створити беклог продукту

Створення беклог продукту проводиться в кілька кроків.

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

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

Наступним кроком необхідно створити історії користувачів, описати хто, що і навіщо робитиме у вашому програмному продукті. Тут важливо врахувати абсолютно всі нюанси та ситуації, які можуть виникнути.

У белогу повинні бути ретельно описані всі функції, і навіть всі елементи системи, їх очікувана поведінка, а також поведінка системи в непередбачених ситуаціях.

Як керувати backlog

Дуже важливо підтримувати беклог завжди у актуальному стані. Для цього, по-перше, необхідно періодично переглядати пріоритети, щоб найактуальніші завдання завжди були у топі списку. А по-друге, важливо вчасно оновлювати історії користувачів, щоб у них завжди були актуальні. При цьому необхідно звертати увагу на взаємозв’язки елементів та оновлювати дані у всіх місцях, де вони зустрічаються, інакше може виникнути двозначність вимог, що викличе багато питань у процесі розробки.

Типові помилки у роботі з пріоритетами беклогу – як їх уникнути

• Пріоритети варто розставляти на початку, а не у середині чи тим паче наприкінці робіт. Від цього залежить, наскільки беклог проекту буде відповідати реальним потребам клієнта.
• Важливо, щоб product owner прислухався до зауважень розробників й вчасно коректував backlog продукту у комунікації з клієнтом. Без цього проект може зазнати невдачі.
• Беклог продукту має бути доступним для розробників у будь-яку мить. Понад те, оновлення у беклозі мають супроводжуватсь відповідною комунікацією. Інакше команда не зможе вчасно дізнатися про зміну у пріоритетах і буде працювати в хибному напрямку.
• Дорожню карту проекту не завжди вдається на 100% реалізувати в повному обсязі та у визначені строки, однак нехтування цим інструментом може привнести у роботу ще більше хаосу.
• При розбиванні робіт на спринти варто враховувати у плануванні форс-мажори та “підводні камені”, що можуть сплисти під час роботи.

Висновки

Белог – це необхідний для успішної розробки інструмент. З ним команда завжди знає, які завдання необхідно виконувати та вибирає на спринт лише найактуальніші цілі.

Створення та ведення беклогу – завдання власників продукту (Product Owner), яке потребує ретельного та відповідального підходу. При цьому детальний і правильно складений беклог – запорука ефективної розробки та успішного результату.

Тепер, коли ми розібралися з тим, що таке беклог продукту, у вас з’явилося ще більше розуміння внутрішньої сторони процесу розробки.

Якщо вам потрібно створити сайт або програму, ми в Wezom з радістю допоможемо. 22 роки досвіду у розробці навчили нас уникати типових помилок та створювати продукти для вирішення реальних проблем бізнесу. Залишайте заявку на сайті, ми передзвонимо вам та відповімо на всі ваші запитання. Давайте виведемо ваш бізнес на новий цифровий рівень!

FAQ

Що таке Беклог продукту?

Беклог це документ, що містить повний список завдань, функцій та елементів, що мають втілити у життя розробники на проекті. Тут є детальний опис майбутнього продукту, кожної функції, логіки роботи модулів тощо. Також в документі можна прописати вимоги щодо безпеки, продуктивності та іншого.

Чим відрізняються Беклог продукту та беклог спринту

Робота з беклогом продукту – один з найперших етапів створення ПЗ. Документ зазвичай складає власник проекту (product owner), часто це менеджер зі сторони клієнта. Він вносить у беклог повний перелік вимог щодо функціоналу, цілей, завдань проекту. Беклог спринту складає розробник для предметного планування та організації робіт. Він містить детальний план щодо роботи над певним елементом продукту впродовж визначеного періоду.

Як правильно вести беклог

Робочі завдання треба розставити у порядку пріоритетів на основі дорожньої карти. Найважливіші задачі, які потрібно виконати насамперед, мають знаходитись на початку беклогу. Комунікація між власником продукту, клієнтом та розробниками вкрай важлива. Беклог має бути доступним для членів команди, щоб вони звірялися з ним постійно й працювали у потрібному напрямку.

Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?

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

Бэклог продукта (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 отличается от простого списка дел?

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

• Любая отметка в backlog продукта добавляет ценности для клиентов.
• Все записи в бэклоге продукта оцениваются.
• Все отметки получают свой приоритет и порядок.
• Уровень детализации зависит от позиции отметки в Scrum backlog.
• Бэклог продукта — это живой документ без каких-либо бездействий или задач низкого уровня приоритета.

Что делать, если бэклог неустанно растет?

Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?

Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:

• Структурирование бэклога на основе Kanban-досок, лейблов и горизонтальных Swimlanes.
• Оценка идей (с помощью удобных критериев Value and Effort).
• Визуализация и приоритезация важных идей на основе диаграммы Backlog Priority Chart.

Структурирование бэклога

В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:

• Collect Ideas — для сбора всех идей.
• Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
• Score Ideas — для оценивания идеи.
• Approval — для проверки идеи Scrum-мастером или менеджером проекта.
• Developing — для отправления идеи в разработку.
• Done — для реализованных идей. Это означает, что функция «залита» на продакшн.

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

Оценка идей

В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.

• Value показывает, какую бизнес-ценность может принести ваш продукт или бизнес.
• Efforts измеряют ресурсы, необходимые для выполнения задачи.

Backlog Priority Chart

Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:

• Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
• Big Bets для идей, имеющих большие ценность и усилия.
• Maybes для идей с низкими ценностью и усилиями.
• Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.

Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.