Бэклог – это список новых функций, изменений существующих функций, исправления ошибок, изменений инфраструктуры или других действий, которые команда может выполнить для достижения определенного результата. Он выступает единственным авторитетным источником информации, на который опирается компания. Это означает, что ничего не будет сделано из того, что не находится в этом журнале. Он представляет собой тот вариант работы над продуктом, который есть у команды для достижения конкретного результата.
Характеристики
Добавление элемента продукта в журнал незавершенного производства должно осуществляться быстро и легко, и столь же легко может быть удален из бэклога тот элемент, который не приводит к прямому продвижению к достижению желаемого результата или не позволяет продвигаться к достижению результата.
Элементы бэклога принимаются в различных форматах, причем наиболее распространенными являются пользовательские истории. Команда определяет формат, который они выбрали, и рассматривает элементы бэклога как напоминание об аспектах решения, над которым они работают.
Журнал невыполненных работ позволяет каждому сотруднику подразделения вносить идеи по улучшению продукта или услуги. Процесс расстановки приоритетов определяет, что на самом деле становится частью продукта. Этот метод позволяет воплощать задачи, затрачивая ресурсы только на лучшие идеи, доступные на данный момент. В случае отказа от устаревших идей бэклог иногда дополняется и уточняется.
Бэклог продукта различается по размеру и степени детализации в значительной степени от того, как скоро команда начнет работать над ним. Те задачи, над которыми команда будет работать в ближайшее время, должны быть небольшими по размеру и содержать достаточно деталей, чтобы можно было начать работу. Группа может установить определение готовности, указать свое пожелание касательно информации, которую они хотели бы иметь в наличии, чтобы начать работу над бэклогом.
Последовательность бэклога продукта изменяется по мере того, как команда лучше понимает результаты и находит решение. Такое переупорядочение существующих элементов, постоянное добавление, удаление и уточнение этих элементов определяет динамический характер бэклога.
Виды
Ожидается, что программы будут выполнять требования заинтересованных сторон и планировать их реализацию в качестве проектов. Это обычно происходит на постоянной основе. Структура бэклога полезна для хранения требований, процесса расстановки приоритетов и планирования, в соответствии с которым требования высокой значимости группируются в проекты.
Он может быть реализован отдельным лицом или командой как метод управления временем. Люди имеют ограниченное количество времени и часто должны расставлять приоритеты для задач. Как и в случае с продуктами и программами, можно ожидать, что не все в бэклоге будет завершено.
Кто выбирает задачи для бэклога?
Но, в конце концов, владелец продукта – единственный человек, ответственный за определение приоритетов. Это также является причиной, по которой никогда не должно быть нескольких владельцев продуктов или комитетов владельцев продуктов. Для принятия решений должна быть единственная точка правды – это владелец продукта. Он собирает всю информацию о рынке, бизнесе, заинтересованных сторонах, сложностях и т. д. в одно четкое определение приоритетов.
Команда, работающая над продуктом, может играть определенную роль владельца продукта с основной ответственностью – поддержание продукта. Ключевыми действиями по поддержанию бэклога являются расстановка приоритетов по элементам невыполненных обязательств по продукту, принятие решения о том, какие элементы невыполненных элементов следует удалить из бэклога и содействие уточнению невыполненной работы.
Как выглядит?
Бэклог – это эффективный способ для команды сообщить, над чем она работает и над чем планирует работать дальше. Карты историй и информационные источники могут предоставить четкое представление о текущей ситуации для команды и заинтересованных сторон.
Бэклог может быть представлен в физической форме с использованием учетных карточек или заметок, или он может быть представлен в электронной форме, например, текстовом файле или электронной таблице Excel. Электронная форма – лучший вариант для команды, которая имеет удаленных членов или собирает много дополнительной информации о продуктах. Физические формы дают преимущество, заключающееся в том, что резерв продукта постоянно виден и конкретен во время обсуждений, связанных с продуктом.
Особенности бэклога
После того как бэклог продукта создан, важно регулярно его поддерживать, чтобы идти в ногу с программой. Владельцы продукта должны проверять журнал невыполненных работ перед каждым совещанием по планированию операции, чтобы убедиться в правильности расстановки приоритетов и включении отзывов о последней операции.
После того как бэклог увеличивается, владельцы продукта должны сгруппировать его в краткосрочные и долгосрочные позиции. Ближайшие по смыслу задачи должны быть полностью конкретизированы, прежде чем они будут помечены как таковые. Это означает, что полные пользовательские истории были составлены, сотрудничество с проектированием и разработкой было улажено, оценка разработки была сделана. Более долгосрочные элементы могут оставаться немного расплывчатыми, хотя неплохо бы получить приблизительную оценку от команды разработчиков, чтобы помочь расставить приоритеты.
Бэклог – это связующее звено между владельцем продукта и командой разработчиков. Владелец продукта может в любой момент изменить приоритеты работы в очереди из-за отзывов клиентов, уточняющих оценок и новых требований. Однако как только работа начнется, следует свести изменения к минимуму, так как они нарушают работу команды разработчиков и влияют на фокус и моральный дух.
Ошибки при ведении
Существует несколько основных ошибок при ведении бэклога, за которыми нужно пристально следить:
- Владелец продукта расставляет приоритеты бэклога в начале проекта, но не корректирует его по мере поступления отзывов от разработчиков и заинтересованных сторон.
- Команда ограничивает бэклог теми элементами, которые ориентированы на клиента.
- Он выглядит, как документ, который хранится локально и редко используется, что не позволяет заинтересованным сторонам осуществлять обновления.
Пример бэклога
Для работы с бэклогом не понадобится использовать какие-либо сложные инструменты. Можно начать с бумажных карточек или с таблицы Microsoft Excel.
Наиболее распространенный способ определения элементов бэклога – это пользовательская история. В этом случае можно добавить название для быстрой ссылки (однако при использовании учетных карточек это обычно не делается), а при необходимости добавлять условия удовлетворения на обратной стороне карты.
- Автоматический выбор пива для вечеринки. Покупатель хочет произвести впечатление на своих друзей множеством редких брендов.
- Выбор нового пива по вкусу. Покупатель хочет посмотреть каталог пива, чтобы выбрать новый. Он может видеть различные вкусы прямо на страницах каталога.
- Заказ любимого пива. Постоянный покупатель хочет видеть свои любимые сорта пива, чтобы заказывать их снова каждый раз.
- Рекомендовать дорогое пиво. Владелец магазина хочет, чтобы бар рекомендовал дорогое пиво, дабы увеличивать свою прибыль.
При желании также можно добавить несколько необязательных полей, таких как «Номер», «Оценка», «Условия» и «Приоритет» (которые можно использовать для сортировки бэклога в порядке приоритета бизнеса).
Источник: fb.ru
Бэклог продукта
Бэклог продукта, что это? Какие задачи должны в него попадать и как правильно их приоритезировать?
Совсем недавно сидели с коллегой и обсуждали тему бэклога. Зацепились за вопрос, а какие же задачи должны там появляться? Даже картиночку нарисовали.
И тут, значит, ловлю себя на мысли, что уже немало статей написал по продуктовой тематике, а про него забыл. Ну, как так то? Бэклог, король разработки, ее начало, то место, где у задачи появляется шанс “выйти на свет” к пользователю.
Ладно, хватит диферамбы тут петь, к делу!
Бэклог продукта: на шаг к пользователю
Чтобы лучше понять место бэклога в продуктовой разработке, предлагаю немного сделать шаг назад и посмотреть, как, в идеальной картине мира, задача появляется на свет и оказывается в бэклоге.
Чтобы делать классный продукт, нужно понять для кого ты это делаешь? Кто твои пользователи и какие у них задачи. Общение со своими пользователями (интервью, опросы, тест прототипов и прочего), это самый ценный источник идей. Ведь, если доволен пользователь, то будет доволен и бизнес.
Собирая “боли” пользователей вы формируете гипотезы. А правда ли это настолько важно для него? Может быть, это просто очередное “хочу”? Чтобы проверить гипотезы на жизнеспособность и превратить их в задачи, вы делаете следующий шаг. Проводите а/б тесты, количественные исследования (опросы) и прочее, чтобы сделать вывод: “Да, это и правда важно” или “Легко и без этого проживут”.
Дальше, те гипотезы, которые выжили и подтвердили свою значимость отправляются в список задач. Не все задачи в конечно счете попадут в бэклог. Ведь часть из них может оказать гораздо большее влияние на ваши ключевые метрики, поэтому вам нужен скоринг. Простыми словами, оценка задач с учетом ключевых показателей продукта.
После того, как задачи оценены, их можно брать в бэклог. Вы понимаете какие из них принесут наибольший результат продукту и приоритезируете их относительно других.
Приблизительно так это работает или по-крайней мере должно так работать. Давайте перейдем к самому бэклогу и разберем подробнее, что же это такое и почему я его так нахваливал вначале материала.
Бэклог: это
Бэклог, это список задач, которые решили пускать в разработку.
С точки зрения процесса, бэклог, это первый этап потока разработки. Именно с него начинаются спринты (временные отрезки между релизов), именно из него задачи попадают в анализ и дальше продвигаются по всем стадиям до релиза, то есть до выпуска в реальный мир пользователя.
Виды бэклогов
На самом деле, в управлении продуктом выделяют два основных вида вэклога: бэклог продукта и бэклог спринта.
Основная разница заключается в масштабе и формулировке задач. По процессу задача появляется сперва в бэклоге продукта, а дальше уже идет в бэклог спринта.
Бэклог продукта, это зона продакт менеджера или продакт оунера (как удобно). Здесь живут задачи от бизнеса, сформулированные языком людей: лайки и шэры в мобильном приложении. Они приоритезированы согласно ключевых метрик продукта и ждут свой очереди, чтобы встать в спринт. Задачи в бэклоги могут быть как большие (интеграция с платежными системами), так и маленькие (правки отступов между текстами и картинками).
Если под любимую песню вы дергаете ногой и хотите знать, когда появятся материалы в блоге, то подписывайтесь на наш telegram канал! Продолжаем читать…
Бэклог спринта, это те же самые продуктовые задачи, но разделенные на части (для крупных задач) и переведенные на технический язык. Спринт ограничен во времени, а значит не все задачи с бэклога могут в него попасть. Команда разработки оценивает масштаб задач, претендующих на разработку, и дает обратную связь заказчику (продакту и стейкхолдерам) по тому, что войдет и не войдет в спринт.
Инструменты управления бэклогом
Чтобы управлять бэклогом, его нужно где-то вести. Самым распространенным инструментом в agile командах, являются: Jira, Trello, Redmine.
Данные инструменты позволяют всей команде работать с задачами, обновлять статусы, оставлять комментарии и делать кучу других фишек. В общем, прямо то, что доктор прописал. Есть и другие, но, из моего опыта, эти самые популярные.
Помимо распространенных инструментов, список задач бэклога можно хранить и в табличке excel (облако гугла) с доступами к редактированию для команды. Да, не так удобно, да меньше плюшек, но ведь можно. Было бы желание, решение найдется.
Какие задачи брать в бэклог
По классике, чтобы продукт был сбалансированным, в бэклоге должны появляться задачи следующих типов:
- Функциональные
- Эволюционные
- Аналитические
- Баги
Каждый из типов задач позволяет продукту развиваться комплексно. Мы уже подробно разбирали эту тему здесь, поэтому пойдем дальше.
Задачи могут сыпаться на вас отовсюду: пользователи, заказчики, данные аналитики, ваши собственные идеи. Как мы разобрали вначале, они должны выдержать проверку на “правда нужно” у пользователей. Дальше вы посмотрите на них через призму метрик продукта и решите, какие из них достойны бэклога, а какие дойдут до ближайшего спринта.
Жизнь
На практике, проверить все задачи довольно проблематично. Провести тестирование или исследование по каждой задаче, это прямо вызов. Вам нужно иметь целый отдел исследований, чтобы потянуть такой поток. Поэтому, скорее всего на каких-то задачах вы включите свой продуктовый фильтр и волевым решением часть задач просто положите “на потом”.
Бэклог, это не куча, где команда должна копаться и на интуитивном уровне понимать, что же из этих задач взять в работу? Это приоритезированный список, где задачи стоят строго по приоритетам. Согласно своего веса часть из них пойдет в ближайший релиз, а часть в следующий.
Чтобы эти приоритеты расставить, используйте скоринг (да мы о нем тоже говорили немного тут). Посмотрите на список через призму ценности, которую они приносят продукту и вытащите наверх те, что правда важны. У команды не будет сомнений про то, что же взять в работу, просто следующую сверху.
Вот и все
Мы поговорили о том, что такое бэклог и какую роль он играет в управлении продуктом. Теперь вы знаете какие именно задачи в него приземлять, а значит движетесь в правильном направлении.
- Приоритет задач в разработке продукта
- Бриф: оружие или руководство к действию
Колбасный хайп, можно сказать от сердца отрываю сие творение. Смотрите, что такое Дюжев и колбаса.
Источник: www.alexcouncil.com