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

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

Каскадирование целей

Бизнес инвестирует в развитие продуктов на длительное время. У бизнес-заказчиков есть представление о том, какое развитие должен получить продукт, какие свойства он должен приобрести через пару месяцев, какие возможности предоставлять потребителям через полгода.

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

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

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

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

Для каждой задачи свои инструменты

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

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

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

Среднесрочное планирование – зачем оно нужно?

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

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

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

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

Как целевое состояние, которое мы хотим получить на текущем этапе, раскладывается в цели итераций? Когда, уже пора обсудить заказчиком требования в рамках ближайшей итерации? Сколько займёт уточнение требований, какие дополнительные согласования потребуются и сколько обычно времени они занимают? Когда можно планировать принятие требований в работу? На каком этапе понадобится синхронизация со смежниками, когда пора к ним обратиться, исходя из их особенностей? Как будет организована поставка? Когда согласовать с бизнесом приёмочные работы? В какой период зарезервировать ресурсы сервисных команд?

Это всего лишь пример того, какой состав работ может быть зафиксирован в дорожную карту и разложен по календарю. Логика тут должна опираться на здравый смысл, а содержание карты включать в себя ровно столько, чтобы план был достаточно чётким для достижения целей, но не перегруженным.