Блог Product lab

Дорожная карта и бэклог разработки продукта: в чем разница?

Agile Design thinking
Дорожная карта и бэклог
Мы продолжаем переводить для вас полезные статьи по тематике проектного менеджмента, гибких подходов и управления продуктами, и сегодня предлагаем краткое руководство для UX-специалиста по отличиям дорожной карты от бэклога продукта. 

Путешественник встречает на дороге трех резчиков камня. На вопрос «Что вы делаете?» первый резчик отвечает: «Я режу камень». 

Дорожная карта и бэклог


Заинтригованный, но слегка запутавшийся, путешественник обращается ко второму резчику, и тот говорит:  «Я режу этот камень на куски прямоугольной формы, чтобы из них можно было сложить стену». 
Дорожная карта и бэклог

Начиная понимать, что здесь происходит, но не имея полной уверенности, путешественник подходит к третьему резчику, который отвечает: «Я строю храм». 

Дорожная карта и бэклог

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


Дорожная карта и бэклог

Кирпичи нужны для строительства храма, но никак не наоборот

 


Дорожная карта продукта – это амбициозное видение, которое объединяет команду, направляя ее усилия на создание самого прекрасного в мире продукта и давая «благословение» компании на эту работу. Но в то время как большинство команд в целом согласны, что дорожная карта – это важная вещь, часто наступает путаница в форматах и целях этого документа. Одна из наиболее частых проблем возникает при смешении понятий «дорожная карта продукта» и «бэклог продукта». У этих документов есть много общего, но преследуют они по определению разные цели.  

Что общего у дорожной карты и бэклога продукта

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

Поговорим о различиях 
Дорожная карта продукта – это стратегический инструмент, который отражает долгосрочное видение продукта. У него есть несколько ключевых функций: 
  • Формировать единое понимание продукта для команды; транслировать более общее видение и подход к разработке продукта всем заинтересованным сторонам без заострения внимания на деталях 
  • Фокусировать внимание на создаваемой продуктом ценности и «зачем?» этого продукта, проблемах, которые мы решаем для пользователей, и выгодах, которые принесет бизнесу этот продукт 
  • Стимулировать обсуждение границ и развития продукта 
  • Фиксировать ключевые допущения для утверждения 
  • Помогать команде приоритизировать и планировать работу, имея в виду общую картину, до перехода к детальному бэклогу для разработки 
  • Приносить пользу для любой заинтересованной стороны, как директора с позицией «у меня есть только пять минут, чтобы посмотреть на это», так и владельца продукта, для которого «это основа моих обязанностей» 

Бэклог продукта – это рабочий инструмент, цель которого – помочь разработчикам продукта. Он делит сложный продукт на управляемые пользовательские истории и имеет следующую ценность: 
  • Переводит стратегическую ценность в управляемые фрагменты 
  • Уточняет характеристики и функционал 
  • Определяет последовательность и приоритеты разработки 
  • Дает возможность оценить трудозатраты 
  • Более всего полезен для продуктовых команд и вовлеченных (участвующих в разработке) заинтересованных сторон 

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

Дорожная карта и бэклог

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

1.Направьте обсуждение в сторону концепции и целей 
Дорожная карта продукта должна быть амбициозной. Она должна вдохновлять и наполнять энтузиазмом. Конечно, некоторых людей вдохновляют задачи вроде «создать безопасную систему входа в аккаунт», потому что они понимают все сложности и тонкости, но большинство не разделит такую точку зрения. C другой стороны, большинство людей одобрит возможность продукта оказать влияние, то есть обратиться к целям потребителей, которые имеют значение. Указание на выгоды, связанные с продуктом, нежели чем на его функции и свойства – это простой и эффективный путь увидеть общую картину, а не набор элементов продукта. 
Группировка детальной информации в набор верхнеуровневых функциональных областей – это тоже отличный способ пополнения дорожной карты продукта. Причем даже супер-важные-и-занятые заинтересованные лица с большей вероятностью смогут разобраться в вашем продукте. А если вы сможете связать эти группы с осязаемыми бизнес-целями, то получите готовое видение продукта.  


Дорожная карта и бэклог

Стройте замки, не лепите кирпичи 


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

2.ОтMoSCoWк приоритизации 
Ах, старый добрый метод MoSCoW, «Обязательно-Важно-Желательно-Не нужно»! Сколько умов сотрудников компаний «зажигал» он с течением лет, сколько оплаченных часов он создал! Я не стремлюсь здесь спорить об общей жизнеспособности модели, но в контексте создания дорожной карты продукта есть лучшие способы для приоритизации.   

Кроме того факта, что метод MoSCoW по определению ориентирован на отдельные функции, он также создает ошибочное впечатление, что над некоторыми аспектами вообще не следует работать. «Функция А — желательна» воспринимается как нечто, на что не стоит тратить ресурсы, и эта функция никогда не будет реализована. Тогда зачем, зачем эта категория на вашей дорожной карте? Сложится ли когда-нибудь ситуация избытка ресурсов, при которой бизнес решит потратить их на функции, не приносящие особенной ценности, но разработка которых стоит дорого? Кто в этом заинтересован? А если функция является обязательным требованием, она обязательна, потому что решает проблему конечного пользователя, или потому что это требование законодательства? 
Альтернатива? Матрица приоритетов. Она поможет решить проблемы, описанные выше, и создать твердую основу для обсуждения продукта. В ходе приоритизации, команда может перейти к обсуждению верхнеуровневых целей, и расположить их в порядке приоритетности для конечных пользователей, бизнеса и технической стороны. Результат, который мы здесь получаем, – это относительные оценки. Мы не говорим, что цель «Б» не важна совсем, мы лишь говорим, что цель «А» важнее цели «Б». Матрица приоритетов поможет удостовериться, что оценены и приняты во внимание все варианты, и снизит (если не исключит) субъективность обсуждения.

3.От временных шкал к путешествиям
Вы наверняка видели типичную дорожную карту, структурированную в виде диаграммы Гантта, и наложенную на квартальные планы или даты релизов. На самом деле, это единственный формат, который вы найдете при поиске в Google.  
Ганттификация дорожных карт

Ганттификация дорожных карт. Она реальна. 


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

Более гибкий (и, следовательно, более легкий, ура!) подход состоит в определении нескольких простых фаз. Эти фазы могут называться как угодно, даже «Краткосрочный период», «Среднесрочный период», «Долгосрочный период». Или вы можете выбрать названия, содержащие больше смысла, например, «Пилот», «Минимальный эмоциональный отклик», «Полноценный положительный опыт». Какие названия вы бы ни выбрали, остановиться лучше всего на 3-4 фазах. Чем более отдалена фаза по времени от текущего момента, тем более вероятно, что в нее будут внесены изменения, основываясь на информации, которую команда получит на предыдущих фазах. Последняя фаза также может восприниматься как точка на горизонте, которую вы никогда не достигнете, но к которой будете стремиться.   

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


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

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

Тренинг Design Thinking


Если вы хотите узнать больше про создание прорывных продуктов, тогда вас могут заинтересовать следующие статьи:


Также вас может заинтересовать методология OKR, которая повышает эффективность компании, связывает задачи сотрудников и стратегию организации.
OKR (Objectives and Key Results) - базовая статья про OKR.

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи: