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

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

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

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

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