В докладе, опубликованном консалтинговой компанией Forrester Research, утверждается, что большинство организаций придерживается идеологии гибкой разработки только для решения технических задач – при этом принятие бизнес-решений остается вне рамок процесса и это ведет к значительным упущенным выгодам. Многие организации применяют схему, которую Дэйв Уэст назвал Water-Scrum-Fall
[12]. На первой стадии до начала разработки принимается большая часть бизнес-решений, на второй происходит собственно итеративная разработка, а завершается все долгим процессом утверждения бизнес-результатов.
Наблюдение, сделанное Уэстом, что «большинство фирм сначала разрабатывают планы и требования к готовому продукту и лишь затем приступают к формированию Scrum-команды», рисует довольно мрачную картину использования гибких методологий на практике. Impact maps способны помочь решить эту проблему, так как они побуждают бизнесменов и технических экспертов совместно уточнять бизнес-цели, фокусироваться на оказании необходимых влияний и воспринимать первоначально установленные границы проекта не более как гипотезы, которые могут подтвердиться, а могут и нет.
Целостное видение
Одна из распространенных причин разрыва в коммуникации между бизнесом и разработчиками – поставка осуществляется слишком небольшими инкрементами, которые с точки зрения бизнеса не вызывают сколько-нибудь ощутимых улучшений. В результате проект превращается в бесконечную вереницу вносимых в продукт мелких изменений – при этом может быть утрачено представление об общей картине или крупных преимуществах, которые данный проект призван обеспечить. Заказчиков редко интересуют микроскопические усовершенствования – они ждут завершения процесса. Хуже того, они часто настаивают, чтобы границы проекта и его бюджет были зафиксированы с самого начала, что в значительной степени обесценивает итеративную разработку. Разменяв целостное видение проекта на возможность быстро вносить изменения, многие команды попадают в ситуацию, похожую на продвижение внутри темного туннеля – конечно, мы точно не знаем, куда в итоге попадем, зато передвигаемся небольшими шагами, и это вселяет уверенность, что по крайней мере мы никуда не провалимся.
Impact maps позволяют бизнес-спонсорам и разработчикам ни на секунду не упускать из вида общую картину. Благодаря им вам не придется понапрасну тратить ресурсы на детальный анализ всех составляющих проекта до его старта. Поскольку процесс создания карт проходит очень быстро, impact mapping прекрасно сочетается с итеративными методологиями разработки. Я успешно использовал карты в качестве дополнения к более традиционным методам управления итеративной разработкой. С помощью карт мы можем предоставлять заказчику промежуточную информацию о состоянии проекта на гораздо более значимом уровне – делая акцент на реализованных воздействиях или указывая ту область, где мы планируем сосредоточить свои усилия с точки зрения решения бизнес-задачи. Impact maps позволяют нам делать акцент на влияниях, которых мы планируем достичь, а не на конкретной функциональности; в результате спонсоры проекта видят, что мы делаем в данный момент и чем собираемся заниматься в ближайшем будущем. При этом мы сохраняем свободу выбора способов решения той или иной задачи.
Более эффективная приоритизация
Стараясь вовлечь пользователей в процесс разработки, многие команды делают это неудачно. Это происходит потому, что они просят пользователей расставлять приоритеты между функциями, которые предполагается включить в готовый продукт. В итоге пользователи начинают диктовать последовательность разработки.
Impact maps позволяют при обсуждении приоритетов сосредоточиться на бизнесе заказчика и необходимых влияниях (второй уровень карты), а не на характеристиках продукта и конкретной функциональности (третий и более низкие уровни). По моему опыту, когда обсуждение осуществляется на втором уровне, вовлеченность пользователей оказывается гораздо выше и им удается принимать более эффективные решения.
Итеративная, а не инкрементальная разработка
Еще одна типичная ошибка, которую делают команды, состоит в том, что они разрабатывают продукт фрагмент за фрагментом, но бизнес-ценность возникает только в конце проекта, когда все готовые части соберутся вместе. Широко известен пример «Моны Лизы», с помощью которого Джефф Паттон
[13] иллюстрирует разницу между инкрементальной и итеративной разработкой.
Impact maps позволяют разделить проект на отдельные ветви и работать над отдельными влияниями, заставляя нас думать о том, как их быстро реализовать, и удерживая разработку в истинно итеративном режиме.
Пользовательские истории
В современных гибких методологиях стандартом при управлении проектами де-факто являются пользовательские истории. Они нужны, чтобы определить границы проекта (не привлекая чрезмерные усилия к предпроектному анализу) и обеспечить гарантии, что на каждом этапе проекта будет создана очевидная бизнес-ценность.
У многих организаций не получается воспользоваться всеми преимуществами пользовательских историй, поскольку изначально их создают слишком много, пытаясь охватить весь проект и ничего не упустить. Да, при таком подходе необходимость в тяжеловесном предпроектном анализе снижается, но мы все равно остаемся со слишком масштабным списком пользовательских историй. Всеми этими историями необходимо управлять, что приводит к пустой трате времени. Хуже того, если в бизнесе заказчика что-то изменилось и требуется масса усилий, чтобы заново расставить приоритеты или даже вообще разобраться в этих перечнях. Джим Шор называет подобную ситуацию «ад пользовательских историй».
Impact maps позволяют избежать этих проблем. Причина, почему организации попадают в подобные ситуации, – им трудно отказаться от своей привычки к долгосрочному планированию. Заинтересованные лица, опасаясь, что их потребности будут по каким-либо причинам забыты и не удовлетворены, настаивают на том, чтобы эти потребности были каким-то образом зафиксированы. Вместо того, чтобы писать сотни пользовательских историй низкого уровня, impact maps позволяют отобразить потребности как желательные изменения в поведении действующих лиц. Возникает возможность с самого начала проекта ограничиться обсуждением только наиболее важных влияний на наиболее важных действующих лиц. Когда мы приступим к работе над тем или иным значимым воздействием, мы сможем дополнительно уточнить границы проекта. Вместо того чтобы работать с сотней пользовательских историй одновременно, мы занимаемся картой и лишь десятком историй.
