Очень часто можно наблюдать ситуацию, когда выполняется много задач из бэклога, все участники команды максимально загружены работой, но как такового существенного улучшения свойств продукта нет. Продукт обрастает функциональностью бессистемно, теряется целостность бизнес-логики, ожидаемых больших изменений не происходит.
При этом зачастую ещё и количество задач в бэклоге неубывает, а наоборот, кажется, задачи множатся, как гремлины под дождём. И всё равно бизнес заказчики недовольны темпом работы. Хотя стоит иметь в виду, что их на самом деле интересует не то, как быстро разработчики умеют писать код, а темп улучшения продукта, заложенный в целевую картину развития бизнеса.
Каскадирование целей
Бизнес инвестирует в развитие продуктов на длительное время. У бизнес-заказчиков есть представление о том, какое развитие должен получить продукт, какие свойства он должен приобрести через пару месяцев, какие возможности предоставлять потребителям через полгода.
Дорожная карта при этом выполняет роль связующего звена между долгосрочным планированием и составом работ в каждой конкретной итерации создания новой функциональности в продукте.
Можно ли без неё обойтись? Что будет, если развитие продукта планировать сразу на уровне бэклога? Опыт показывает, что при этом легко теряется фокус на предназначении продукта для бизнеса, и работа сводится к перемалыванию требований в бэклоге без чёткой картины того, каким должен стать продукт.
Это похоже на сборку мебели без инструкции. Вроде ничего сложного и результат в конце концов будет получен, но медленно. И, может быть, для этого придётся просверлить пару новых дырок, чтобы не переделывать сборку неправильно прикрученных элементов в очередной раз.
Наследование бизнес-целей верхних уровней и их приземление на ежедневную деятельность команды позволяет сфокусироваться на том, что действительно нужно бизнесу. Каждая итерация в создании функциональности – это шаг, который может либо приближать к цели, либо идти в сторону. Чтобы дорожка не была слишком уж кривой нам и нужна дорожная карта.
На нашем курсе “Product: создание и развитие успешных цифровых продуктов” мы подробнее разбираем как происходит приземление верхнеуровневых стратегических целей на тактику развития продукта и состав работ в текущем периоде. Связность целей различных уровней планирования позволяет не отклоняться от выбранного направления и максимально поддерживать развитие бизнеса.
Для каждой задачи свои инструменты
В бэклоге находятся все известные на текущий момент требования к развитию функциональности. В нем лежат бизнес-идеи, продвигающие продукт к его целевым состояниям; есть оперативные задачи, возникшие как запрос на улучшение уже реализованной функциональности; могут быть технические задачи, направленные на оптимизацию производственной среды. Балансировать эти элементы между собой без опоры на какой-то среднесрочный план сложно. Легко происходит перекос в сторону оперативных задач, поскольку они наиболее понятны, и часто бизнес настойчиво и громко требует делать эти улучшения прежде всего. Так же легко случается отклонение в сторону долгосрочных крупных изменений, которые требуют сил всей команды, а повышение качества уже реализованной функциональности задвигается на второй план.
Подобная разбалансировка легче контролируется, когда можно опереться на визуализированный среднесрочный план и распределить ёмкость ресурса, необходимого для реализации различных типов требований. Бэклог как инструмент выстраивания приоритизированных очередей и отслеживания подготовки состава работ текущей итерации не даёт такой возможности. Это инструмент планирования в краткосрочном периоде.
Для достижения баланса хотелось бы иметь возможность не только работать с набором требований, но и понимать, каким образом управлять ожиданиями бизнеса. Что именно самое важное в какой момент времени должно быть сделано. Хотелось бы смотреть не на текущую и следующую итерацию, а заглядывать на пару шагов вперёд, планировать в среднесрочном горизонте. И для этого нужен свой инструмент.
Среднесрочное планирование – зачем оно нужно?
В целом среднесрочное планирование позволяет удерживать нужный темп и направление развития продукта. Оно определяет то, каким должен стать продукт через несколько месяцев, раскладывается в набор целевых состояний, постепенно наращивающих его потребительские свойства. Достижение этих состояний идет этапами – вехами развития продукта.
На практике часто можно столкнуться с вариантами дорожных карт, повторяющих содержимое бэклога, разбитое на кучки по месяцам. Это очень вырожденный вариант, задействующий небольшую долю потенциала этого инструмента. Поскольку дорожная карта предназначена для более высокоуровневого охвата при планировании, работать с ней лучше в терминах целевых состояний, а не конкретных требований
Очень часто можно услышать, что в гибком управлении ИТ-разработкой нет возможности предсказывать сроки реализации тех или иных требований. Так чаще всего бывает, когда даты начала и завершения работ пытаются натянуть на бэклог тем или иным способом. При этом приходится выстраивать сложные логические схемы взаимосвязей между задачами, а следовательно, планировать только на пару недель вперёд, а дальше точность теряется.
Все гораздо проще становится при визуализации с помощью дорожной карты. Сначала можно обозначить конкретные целевые состояния и сроки, в которые необходимо эти целевые состояния достигнуть. Затем определить состав работ по достижению этих целевых состояний. Это не только список требований (строго говоря, он нам тут и не нужен), но вся деятельность. Которая потребуется для движения к этому состоянию. И под этот состав работ уже наметить календарь конкретных действий, используя свой опыт.
Как целевое состояние, которое мы хотим получить на текущем этапе, раскладывается в цели итераций? Когда, уже пора обсудить заказчиком требования в рамках ближайшей итерации? Сколько займёт уточнение требований, какие дополнительные согласования потребуются и сколько обычно времени они занимают? Когда можно планировать принятие требований в работу? На каком этапе понадобится синхронизация со смежниками, когда пора к ним обратиться, исходя из их особенностей? Как будет организована поставка? Когда согласовать с бизнесом приёмочные работы? В какой период зарезервировать ресурсы сервисных команд?
Это всего лишь пример того, какой состав работ может быть зафиксирован в дорожную карту и разложен по календарю. Логика тут должна опираться на здравый смысл, а содержание карты включать в себя ровно столько, чтобы план был достаточно чётким для достижения целей, но не перегруженным.
На нашем курсе DevOps: современный подход к организации работы ИТ мы разбираем трудности, возникающие при приземлении DevOps на реальные ландшафты организаций. При этом у вас есть возможность обсудить с тренером барьеры, существующие в вашей практике и мешающие полноценно получать выгоду от использования DevOps.
А что это даёт команде разработки?
- Возможность планировать нагрузку на ресурсы на несколько месяцев вперёд. Например, дорожная карта подскажет, когда ведущему разработчику легко уйти в отпуск, не создавая аврала, или когда назначить техническую сессию в системе.
- Способ вести диалог с бизнесом на основе визуализированного плана действий. Решение о том, сосредоточиться ли на оперативных задачах или выполнять долгосрочную программу принимает заказчик, однако он должен чётко понимать влияние своих решений, и визуальный контроль с помощью дорожной карты при этом очень помогает.
- Возможность чётче планировать прогнозные сроки реализации запросов бизнеса. В потоке требований для определения срока недостаточно отталкиваться от сложности задачи, нужно понимать сколько всего будет задач в периоде и накапливать опыт о пропускной способности производственной системы, а бэклог не даёт достаточной визуализации этого процесса.
- Позволяет равномерно распределить усилия на обработку требований, поскольку даёт ориентир на то, какая их часть сейчас имеет наибольший приоритет. Намеченные целевые состояния перетекают из дорожной карты в бэклог продукта в виде структурированной последовательности требований, при этом детализируются и уточняются только те, которые относятся к текущему этапу развития продукта, без перебора всего списка.
Таким образом, дорожная карта избавляет команду от лишней работы. Она решает проблему выбора направления развития, поддерживает баланс ресурсов разработки между долгосрочными и оперативными задачами, повышая качество создаваемых решений. Помогает удерживать нужный темп развития продукта, ожидаемый бизнесом, отсекая лишние требования, создающие перегрузку на данном этапе. Создаёт устойчивость развития в течение нескольких месяцев, и является той основой, на которой строится принятие решений и совместный диалог с бизнесом.
Можно ещё глубже погрузиться в механику использования этого инструмента и разобрать как именно он работает для решения тех или иных аспектов планирования. Если у вас есть вопросы или проблемы, связанные со среднесрочным развитием продукта, напишите о них в комментариях, и я постараюсь разобрать их в следующих статьях. Или приходите на наши курсы и вебинары по этой теме, где можно в интерактивном режиме обсудить ваши вопросы.
Светлана, добрый день!
Интересно увидеть от вас статью-продолжение на тему «Как построить дорожную карту продукта и связать её с бэклогом?», в которой вы бы осветили тему методов и инструментом с примерами из вашей практики.