Знакомство с бэклогом продукта

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

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

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

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

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

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

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

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

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

Бэклог продукта — это не то же самое, что бэклог поставки: каждый из них служит своей цели. 

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

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

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

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

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

Использование отдельных бэклогов для продукта и поставки дает множество преимуществ.

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

• Единая площадка для обсуждений по продукту дает возможность команде со временем накопить базу знаний, избавив себя от поиска нужной информации по десяткам электронных таблиц.

• Единый достоверный источник сведений формирует общее понимание приоритетов по продукту. Это решает типичную проблему команд по продуктам: принятие решений на основе интуиции или мнений самых бойких клиентов и заинтересованных сторон. 

• Единое место общения всех сотрудников компании гарантирует прозрачность при обсуждении приоритетов. Это помогает избежать множества конфликтов при совместной работе с заинтересованными сторонами и командами, взаимодействующими с клиентами.

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

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

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

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

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

Ниже приведены две рекомендуемые схемы, с помощью которых можно структурировать бэклог продукта: «валуны», «камни» и «галька» и длинные, средние и короткие списки. Рекомендуется упорядочивать бэклог по этим тройкам категорий.

В Jira Product Discovery для этого настраиваются особые представления, отображающие нужные идеи, и выбираются поля, которые будут полезными для обсуждений (выбор, рейтинг) и ведения совместной работы (аналитика, голосования, комментарии, реакции).

Boulders (Валуны), Rocks (Камни) и Pebbles (Галька)

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

Как правило, все они разбиваются на три категории. 

• «Валуны»: крупные инвестиции, стратегические возможности, масштабные новые замыслы.

• «Камни»: средние инвестиции, значительные улучшения продукта, ускоряющие достижение нужных результатов.

• «Галька»: небольшие задачи типа исправления мелких, но досадных недочетов в пользовательском интерфейсе и багов.

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

Подробнее об этом подходе см. в разделе Идеи.

Длинный, средний и короткий списки

Другой простой и практичный способ структурировать бэклог продукта предложил один из первых пользователей Jira Product Discovery Брент Джонсон. Он описал работу над продуктом как постоянное управление тремя «корзинами»: длинным, средним и коротким списками.

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

• В длинный список заносятся все идеи, проблемы, возможности и решения, в том числе из разряда «когда-нибудь, может быть». Их количество может превышать 200. 

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

• Средний список — это предварительно отобранные потенциально важные задачи: привлекательные возможности, в которые команда могла бы с полным правом вложиться. Из 200 идей длинного списка в средний могут перекочевать всего 10–20.

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

    • Подробнее см. в разделе Расстановка приоритетов.

• Короткий список — уже почти дорожная карта: это идеи, которые команда взяла в дальнейшую работу. Это подготовка к практической работе над возможностями, проблемами или решениями, позволяющая начать создавать новый продукт или улучшать существующий. 

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

    • Подробнее в разделе Составление дорожной карты.

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

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

Как правило, лучше всего объединять людей, которые ежедневно работают вместе над одним проектом (например, один или несколько отрядов). Однако многие клиенты Jira Product Discovery включают в один проект несколько команд и продуктов. Это особенно полезно, когда нужно поддерживать высокий уровень сотрудничества между этими командами.

Вот видеоролик о том, как это сделать.

С планом Premium для Jira Product Discovery вы сможете визуализировать идеи из нескольких проектов в одном месте с помощью представлений, в которых собраны эти идеи и записана вся история планов по продуктам организации.

Что дальше?

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

• проводить идеи от замысла до реализации;

• настраивать каналы обратной связи и собирать данные для подтверждения идей;

• расставлять приоритеты для значимых идей;

• вы могли создавать дорожные карты для слаженного взаимодействия между командами и заинтересованными сторонами.

Кроме того, мы приведем примеры того, как все это делаем мы сами, команда Jira Product Discovery, с использованием Jira Product Discovery и других продуктов.