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

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

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

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