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

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

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

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

Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это делаем? Это цель, которую мы стремимся достичь.

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

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

Поместив ответ на вопрос «ЗАЧЕМ?» в центр impact map, мы получаем возможность убедиться, что все знают, зачем они выполняют те или иные действия. Это помогает командам лучше соотносить свою текущую деятельность с конечной целью, точнее формулировать требования к функциональности и находить оптимальные с точки зрения дизайна решения.

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

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

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