Именно к этому и стремятся различные методики управления требованиями на основе целей. Цель таких методик – переориентировать руководство проектами с разработки заранее известного списка конкретного функционала на поддержку бизнес-задач и желаемые изменения в поведении пользователей. Конечно, эти идеи вовсе не новы, но все же наибольшую популярность они обрели в начале 2000-х годов, побудив, в частности, интерес к этой проблематике в академических кругах – особенно если говорить о модели I*[6]. Но на мой взгляд, эта модель слишком сложна и по этой причине вряд ли получит широкое распространение.
Чтобы предотвратить расползание границ проекта во время разработки программы Excel для компании Microsoft, Скотт Беркун использовал простой мэппинг между целями, функциями и требованиями. Он убедил заинтересованные стороны сократить количество бизнес-целей, поставленных в рамках одного релиза. Затем он обозначил границы проекта, настаивая на том, чтобы каждая функция была увязана с соответствующим требованием, а каждое требование – с целью, которую оно поддерживает. Беркун позднее писал, что такой мэппинг позволил командам разработчиков принимать эффективные решения следующих типов: какие элементы функциональности следует добавить или исключить; как переопределять приоритеты при изменении бизнес-целей; какие именно элементы функциональности являются критически важными для достижения успеха.
Impact maps делают применение этого процесса еще проще и даже выводят его на более высокий уровень. Вместо того чтобы в начале очередного этапа или проекта просто обозначить связь между конкретной функциональной возможностью и целью, impact maps позволяют нам поддерживать динамическую дорожную карту, которая изменяется по мере поступления новой информации, не упуская при этом из вида конечную цель; в такой системе вещей конкретная функциональность и границы проекта являются вторичными. Мы визуализируем исходные гипотезы, и это помогает нам скорректировать направление, как только эти гипотезы получают подтверждение или отбрасываются.
Рассмотрим пример игровой онлайн-платформы, приведенный в первой части книги. Добавляя полуавтоматическую рассылку, мы преследуем цель помочь игрокам рассылать друзьям приглашения присоединиться к игре. Мы предполагаем, что, добавив эту возможность, мы изменим поведение пользователей. После того как этот функционал будет реализован, мы поймем, было ли наше исходное предположение верным или нет. Если игроки станут приглашать друзей, то нам нужно продолжать инвестировать в это направление. Если нет, то следует остановиться, проанализировать ситуацию и попробовать подойти к решению этой задачи каким-либо иным способом.
На impact map также показана исходная гипотеза более высокого уровня: если игроки начнут рассылать приглашения, то в соответствии с нашими предположениями их друзья будут присоединяться к нашей игре. После добавления соответствующего функционала мы сможем оценить, действительно ли они присоединяются в том количестве, на которое мы рассчитывали. Если да, то нам стоит и дальше расширять эту функциональность. Если нет, то продолжать разрабатывать все новые способы рассылки приглашений было бы неправильно. Мы должны переосмыслить свою стратегию, найти способ улучшить результаты рассылки или вообще сфокусироваться на чем-то ином.