• Значительно повышается вовлеченность, поскольку участники обсуждают идеи в наглядном графическом представлении.

• Мышление происходит на более высоком уровне («общая картина»), что позволяет группе легче выявлять закономерности, сравнивать имеющиеся идеи и находить новые.

• Улучшается групповая память, поскольку результаты совещания фиксируются в виде картинок, по которым впоследствии легче отслеживать исполнение.

Сиббет утверждает, что визуализация делает команды умнее: «Визуализация добавляет 80 пунктов к групповому IQ», поскольку она высвобождает энергию, интеллект и творческие способности участников совещания.

Impact maps являются визуальным инструментом. Руководители технического и бизнес-направлений, заинтересованные в результатах проекта, совместно рисуют карты на флипчартах, повышая эффективность обсуждения за счет наглядности и тех самых дополнительных 80 пунктов IQ, высвобождая энергию и творческий потенциал друг друга. В результате продуктивность совещаний неуклонно возрастает. Многие из моих клиентов были поражены, как много нам удавалось сделать за один или два дня работы по составлению карт, особенно в сравнении с традиционными стратегическими совещаниями, которые принято проводить с использованием презентаций, состоящих из десятков слайдов («смерть через PowerPoint»). Возможно, это экстремальный пример, но один из моих клиентов отметил, что в его компании к сравнимым результатам обычно приходят после шести месяцев переговоров.

Говоря о продуктивности совещаний, еще одним интересным аспектом impact maps является сходство вопросов, задаваемых при их составлении, с вопросами, используемыми в модели командообразования по версии Гибба – Дрекслера – Вайсборда. Еще в 1960-х годах Джек Гибб, Марвин Вайсборд и Алан Дрекслер предложили модель построения команд, базирующуюся на результатах исследований групповой динамики и организационного развития. Они структурировали свою модель вовлеченности вокруг четырех основных вопросов: «зачем мы здесь?», «кто ты?», «что мы делаем?» и «как мы собираемся сделать это?». Их модель помогает синхронизировать цели команд с целями организации и напрямую коррелирует с порядком обсуждения при создании impact maps. На практике это означает, что сама структура карт непосредственно способствует продуктивному обсуждению и сплочению отдельных игроков в группу, объединенную общей целью.

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

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

Если мы фокусируемся на бизнес-целях и контрольных параметрах, по которым можно судить об их достижении, нам легче отвечать на вопросы о стоимости разработки и сроках. Мы можем просто спросить заказчика: «Насколько ценной для вас является данная функциональная возможность? Сколько вы готовы инвестировать в ее разработку? Когда она вам понадобится?» Затем информацию, полученную в виде ответов на эти вопросы, мы добавляем в описание соответствующего этапа в качестве контрольных параметров.

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

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

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

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