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

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

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

При составлении impact map мы уже на входе должны иметь правильно сформулированную измеримую цель. Поэтому важно проводить обсуждение в два этапа: на первом мы формулируем цель и подбираем контрольные параметры, а на втором – рисуем саму карту.

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

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