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

В докладе, опубликованном консалтинговой компанией Forrester Research, утверждается, что большинство организаций придерживается идеологии гибкой разработки только для решения технических задач – при этом принятие бизнес-решений остается вне рамок процесса и это ведет к значительным упущенным выгодам. Многие организации применяют схему, которую Дэйв Уэст назвал Water-Scrum-Fall. На первой стадии до начала разработки принимается большая часть бизнес-решений, на второй происходит собственно итеративная разработка, а завершается все долгим процессом утверждения бизнес-результатов.

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

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

Impact maps позволяют бизнес-спонсорам и разработчикам ни на секунду не упускать из вида общую картину. Благодаря им вам не придется понапрасну тратить ресурсы на детальный анализ всех составляющих проекта до его старта. Поскольку процесс создания карт проходит очень быстро, impact mapping прекрасно сочетается с итеративными методологиями разработки. Я успешно использовал карты в качестве дополнения к более традиционным методам управления итеративной разработкой. С помощью карт мы можем предоставлять заказчику промежуточную информацию о состоянии проекта на гораздо более значимом уровне – делая акцент на реализованных воздействиях или указывая ту область, где мы планируем сосредоточить свои усилия с точки зрения решения бизнес-задачи. Impact maps позволяют нам делать акцент на влияниях, которых мы планируем достичь, а не на конкретной функциональности; в результате спонсоры проекта видят, что мы делаем в данный момент и чем собираемся заниматься в ближайшем будущем. При этом мы сохраняем свободу выбора способов решения той или иной задачи.

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

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

Еще одна типичная ошибка, которую делают команды, состоит в том, что они разрабатывают продукт фрагмент за фрагментом, но бизнес-ценность возникает только в конце проекта, когда все готовые части соберутся вместе. Широко известен пример «Моны Лизы», с помощью которого Джефф Паттон иллюстрирует разницу между инкрементальной и итеративной разработкой.

Impact maps позволяют разделить проект на отдельные ветви и работать над отдельными влияниями, заставляя нас думать о том, как их быстро реализовать, и удерживая разработку в истинно итеративном режиме.