Джон Макманус и Тревор Вуд-Харпер, в течение семи лет исследовавшие деятельность коммерческих IT-компаний в странах Евросоюза, составили следующий список пяти основных причин, почему IT-проекты терпят неудачу:

• Общие причины, связанные с состоянием бизнеса.

• Бизнес-стратегия потеряла актуальность.

• За время разработки программного продукта в компании изменились бизнес-процессы.

• Неудовлетворительное управление требованиями.

• Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.

Очевидно, что многие из существующих методов управления проектами и качество коммуникации относительно требований к готовому программному обеспечению не в состоянии в полном объеме обеспечить достижение необходимых бизнес-результатов. Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».

Именно к этому и стремятся различные методики управления требованиями на основе целей. Цель таких методик – переориентировать руководство проектами с разработки заранее известного списка конкретного функционала на поддержку бизнес-задач и желаемые изменения в поведении пользователей. Конечно, эти идеи вовсе не новы, но все же наибольшую популярность они обрели в начале 2000-х годов, побудив, в частности, интерес к этой проблематике в академических кругах – особенно если говорить о модели I*. Но на мой взгляд, эта модель слишком сложна и по этой причине вряд ли получит широкое распространение.

Чтобы предотвратить расползание границ проекта во время разработки программы Excel для компании Microsoft, Скотт Беркун использовал простой мэппинг между целями, функциями и требованиями. Он убедил заинтересованные стороны сократить количество бизнес-целей, поставленных в рамках одного релиза. Затем он обозначил границы проекта, настаивая на том, чтобы каждая функция была увязана с соответствующим требованием, а каждое требование – с целью, которую оно поддерживает. Беркун позднее писал, что такой мэппинг позволил командам разработчиков принимать эффективные решения следующих типов: какие элементы функциональности следует добавить или исключить; как переопределять приоритеты при изменении бизнес-целей; какие именно элементы функциональности являются критически важными для достижения успеха.

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

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

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

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