Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке

Гойко Аджич

Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке

Благодарим за помощь в создании книги компанию ScrumTrek в лице управляющего партнера компании Алексея Пименова

Переводчик А. Олейник

Редактор К. Бычкова

Руководитель проекта А. Василенко

Корректор Е. Аксёнова

Компьютерная верстка А. Абрамов

Дизайн макета и обложки Никола Корач

© Gojko Adzic, 2012

© Provoking Thoughts, 2012

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2017

Все права защищены. Произведение предназначено исключительно для частного использования. Никакая часть электронного экземпляра данной книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для публичного или коллективного использования без письменного разрешения владельца авторских прав. За нарушение авторских прав законодательством предусмотрена выплата компенсации правообладателя в размере до 5 млн. рублей (ст. 49 ЗОАП), а также уголовная ответственность в виде лишения свободы на срок до 6 лет (ст. 146 УК РФ).

* * *

Предисловие

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

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

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

Множество барьеров на пути эффективного сотрудничества возникает из-за неразделенных, никогда не обсуждавшихся и непроверенных исходных предположений. Специалисты в разных областях исходят из разного набора допущений и гипотез. Если эти допущения и гипотезы сформулировать в явном виде, то получится их своевременно проанализировать и протестировать. В результате все последующие решения будут приниматься гораздо быстрее. Именно с этой точки зрения impact maps (карты влияния) являются эффективным инструментом. Они позволяют в наглядном виде представить ответы на вопросы «ЗАЧЕМ», «КТО», «КАК» И «ЧТО», связанные с проблемой, которую необходимо решить в рамках конкретного проекта.

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

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

Мы наблюдаем, как на наших глазах совершается переход от подхода «push» к подходу «pull»[1], от директивного управления к адаптивному. Подход «push» предполагает, что мы говорим людям, что им делать; «pull» начинается с формулировки проблемы, открывшейся возможности или какого-либо вызова – при этом кроссфункциональная команда должна самостоятельно во всем разобраться и решить эту задачу. Подход «pull» предполагает фундаментальный сдвиг: чтобы достичь своей цели, мы переносим фокус внимания c «производства» продукта, который заказал клиент, на сотрудничество со всеми заинтересованными сторонами. Это требует перехода от внешней мотивации («push») к внутренней или самомотивации («pull»). Как элегантно выразился Дэн Пинк, внутренняя мотивация возникает при наличии автономии, профессионализма и понимания своего предназначения.

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

Использование impact map помогает сосредоточиться на процессе понимания и прийти к решению «эволюционным путем» даже в тех случаях, когда вы имеете дело со «злыми проблемами»[2] (с ними в наши дни приходится сталкиваться все чаще). Эта книга призывает раз за разом возвращаться к каждому исходному элементу и каждому первоначальному предположению. По-видимому, именно такой подход и нужен нам сегодня. Любое желательное влияние, требуемый эффект или цель, выбранные в начале проекта, основаны на определенных гипотезах относительно изменяющегося во времени положения компании и состояния рынка; отсюда вытекает необходимость постоянно их перепроверять.

Смысл продуктового дизайна – найти и протестировать потенциальные решения, которые могли бы оказать необходимое влияние. Здесь критически важны не столько сами по себе причины и вызываемые ими следствия, сколько проверка самих гипотез, их соединяющих. Реальную ценность удается создавать в тех случаях, когда предположения подтверждены данными неоднократных практических экспериментов. Impact maps – это по существу карты гипотез, связывающих причины со следствиями. Они помогут вам понять, какие вопросы следует задавать – и это гораздо труднее, чем находить верные ответы.

Том Поппендик

Введение

Потратив девять лет и миллиарды фунтов, правительство Великобритании недавно отказалось от завершения одного из своих IT-проектов, потому что он «утратил актуальность». Подобные примеры (правда, в менее эпических масштабах) можно найти повсюду. Только в 2004 году на неудавшихся IT-проектах компании стран ЕС потеряли €142 миллиарда (в основном из-за плохого согласования бизнес-целей или устаревания бизнес-стратегий к моменту выхода готового программного обеспечения). Это примерно равно стоимости программы МКС, включая все уже совершенные полеты, и в два раза превышает стоимость программы Apollo, в рамках которой астронавты шесть раз успешно высаживались на Луне.

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

Данная книга представляет собой практическое руководство по созданию impact maps. Impact mapping – это простой, но невероятно эффективный метод, помогающий еще на стадии стратегического планирования организовать сотрудничество различных специалистов и в результате создавать эффективные программные продукты. Он позволяет составлять более действенные планы и дорожные карты, способные обеспечить соответствие разрабатываемого программного обеспечения бизнес-целям организации и возможность его легкой адаптации к неизбежным изменениям в ходе проекта. Конечно, impact maps – не первое и не последнее решение в этой области. И тем не менее это важная система, поскольку она прекрасно вписывается в современные тенденции разработки программного обеспечения, включая регулярные релизы, управление клиентскими требованиями, ориентированность на достижение бизнес-целей, гибкие и бережливые методологии, экономичное управление стартапами и дизайн-мышление.

Для кого предназначена эта книга?

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

• Бизнесмены, чья роль состоит в управлении проектами по разработке ПО, научатся более четко выражать свои идеи.

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

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

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

Отдавая должное предшественникам

Impact maps – это разновидность карт бизнес-эффектов, которые предложили Мийо Балич и Ингрид Домингес (Оттерстен) в рамках своего метода InUse, скомбинированные с картами эффектов Роберта Бринкерхоффа для образовательных учреждений, идеями Криса Мэттса по поводу добавления функциональности («введения фич»), а также принципами измеримости и итеративной разработки Тома Гилба. Моя методика в значительной степени опирается на их работы – здесь достаточно сказать, что все ключевые идеи принадлежат им, а я лишь связал их вместе и поместил в контекст современных методов разработки программного обеспечения. В конце данного издания приведены ссылки на источники, откуда взяты эти концепции. Соединить их вместе и прояснить многие аспекты того, о чем пойдет речь в этой книге, мне помогли вдохновляющие и весьма непростые дискуссии с Крэгом Ларманом, Томом и Мэри Поппендик, Дэном Нортом, Гордоном Вейром, Джеффом Паттоном и Маттиасом Эдингером (перечисляю их не в порядке важности).

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

В книге описано, как лично я применяю impact maps. В более ранних публикациях я называл их effect maps (картами эффектов), поскольку между ними и картами эффектов по методу InUse действительно имеется значительное сходство. Но в моем подходе также есть и существенные отличия. Он гораздо ближе к тому, что в своей модели HET[3] Бринкерхофф называет roadmaps (дорожными картами) и итерационными планами отдельных этапов. Кроме того, я обнаружил, что надо внести некоторые изменения в список используемых ключевых вопросов – это повысило полезность impact maps (по крайней мере в тех проектах, которыми мне приходилось заниматься). Карты эффектов InUse скорее ориентированы на содействие инновационному дизайну продуктов и дизайну пользовательского опыта. Однако наиболее распространенными проблемами в компаниях, с которыми я работаю в качестве консультанта, являются недостатки в применяемых методах разработки, расползание границ проекта, тенденция упускать из вида общую картину, недостаточная ориентация разработчиков на достижение бизнес-целей. Эти организации бесполезно тратят массу времени и усилий на создание не того программного обеспечения, которое им нужно. Impact mapping представляет собой фантастический способ свести эти страдания к минимуму.

Когда ранее я называл свои impact maps картами эффектов, это приводило к определенным недоразумениям. Дело дошло до того, что известный консультант однажды сказал одному из моих клиентов, что «Гойко совершенно не понимает, что такое карты эффектов. Хотя и в его подходе что-то есть». После нескольких моих выступлений на конференциях в Швеции (кстати, именно Швеция – родина метода InUse), некоторые участники пожаловались, что я неправильно интерпретирую само понятие «карты эффектов». Дабы избежать дальнейшей неразберихи, в этой книге я решил прибегнуть к термину impact maps.

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

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

Добивайтесь осязаемых результатов!

Я полагаю, что использование impact maps позволит изменить правила игры и значительно улучшит способность многих команд и организаций создавать эффективные программные продукты и реализовывать проекты. Цель этой книги – повысить осведомленность разработчиков об этом методе и связанных с ним идеях, а также пробудить активность профессионального сообщества. Именно поэтому я преднамеренно ограничил объем данного издания. Вы cможете быстро прочитать его и держать под рукой в качестве краткого справочника. Вместо того чтобы пытаться сразу охватить все детали моей методики, я даю немало ссылок, которые позволят вам при необходимости глубже погрузиться в смежные темы.

Поскольку речь идет о новом подходе, объединяющем многие важные тенденции в области разработки программного обеспечения, я надеюсь, что impact mapping будет развиваться вместе с этим профессиональным сообществом. Для этого мне понадобится ваша помощь. Попробуйте воспользоваться моим методом для решения поставленных задач. Проверьте, какие из его элементов сработают для вас сразу, а какие из них придется адаптировать. Поделитесь тем, что вы узнали, с другими специалистами – это поможет усовершенствовать нашу методику. Чтобы выяснить, как можно обсудить полученный опыт с другими практикующими разработчиками, зайдите на сайт www.impactmapping.org.

Кроме того, подумайте о том, чтобы оставить отклик об этой книге на сайте Amazon или сайтах других интернет-магазинов. Количество отзывов сильно влияет на репутацию книги – даже если эти отзывы состоят всего из одной строки. Ваше мнение поможет заинтересовать других людей и будет способствовать распространению изложенных в книге идей.

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

Чтобы получать уведомления о появлении новых видео, статей и книг по этой тематике, зарегистрируйтесь на сайте www.gojko.net/impact.

Почему все это имеет значение?

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

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

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

Impact mapping обладает рядом уникальных преимуществ:

• В основу положен метод, изобретенный известным агентством, специализирующимся на интерактивном дизайне. Кроме того, impact maps как инструмент напоминают один из известных методов тимбилдинга. В совокупности это означает, что impact mapping облегчает сотрудничество и взаимодействие. Это куда менее бюрократический и гораздо более простой в использовании метод, чем многие из имеющихся альтернатив. Он позволяет вовлекать в обсуждение группы людей из разных предметных областей, то есть как технических специалистов-разработчиков, так и менеджеров со стороны бизнеса, тем самым помогая организации воспользоваться «мудростью толпы»[4].

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

• Это скоростной метод. Один из моих клиентов недавно заметил, что его компании потребовались бы несколько месяцев, чтобы достичь того, что нам удалось всего за два дня. По этой причине метод прекрасно вписывается в итеративные модели, которые в настоящее время начинают широко использоваться при разработке программных продуктов.

По существу, impact maps стоит заниматься просто для того, чтобы помочь себе создавать продукты и реализовывать проекты, которые действительно делают жизнь пользователей лучше.

Что такое Impact mapping?

Impact mapping – это способ визуализировать границы проекта и основные гипотезы, созданные совместными усилиями лиц, принимающих технические и бизнес-решения. Это ментальная карта, возникающая в ходе обсуждения ответов на следующие четыре вопроса:

Цель

Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это делаем? Это цель, которую мы стремимся достичь.

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

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

Поместив ответ на вопрос «ЗАЧЕМ?» в центр impact map, мы получаем возможность убедиться, что все знают, зачем они выполняют те или иные действия. Это помогает командам лучше соотносить свою текущую деятельность с конечной целью, точнее формулировать требования к функциональности и находить оптимальные с точки зрения дизайна решения.

Рекомендации

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

Цели не должны описывать сам продукт, процесс его создания или устанавливать границы проекта. Они обязаны объяснять, почему данный продукт будет полезен.

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

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

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

Примеры

• Открыть торговлю ценными бумагами в Бразилии в марте следующего года.

• За три месяца увеличить конверсию пользователей на 20 %.

Действующие лица

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

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

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

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

Рекомендации

К важным действующим лицам относятся конечные пользователи, а также внутренние или внешние по отношению к проекту люди, принимающие решения. Алистер Коберн советует искать действующих лиц трех типов:

1. Первичные действующие лица, на удовлетворение потребностей которых направлен процесс разработки, например, игроки игровой системы.

2. Вторичные действующие лица, которые предоставляют услуги, например, команда, занимающаяся предотвращением мошенничества.

3. Закулисные действующие лица, которые имеют заинтересованность в проекте, но непосредственно не извлекают из него выгоду и не предоставляют услуги. Пример – государственные агентства, регулирующие данный вид деятельности, лица, принимающие решения на самых высоких уровнях в соответствующих компаниях.

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

Примеры

• Майк Смит из отдела маркетинга.

• Пользователи в возрасте до 18 лет, приходящие на концерты, имея при себе мобильные устройства.

• Сотрудники Apple, утверждающие приложения, прежде чем разместить их в iTunes.

Примеры влияний

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

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

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

Рекомендации

Не стремитесь перечислить все возможные запросы данного действующего лица. В список должны войти только те влияния, которые действительно помогут вам продвинуться к основной цели.

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

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

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

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

Примеры

• Возможность пригласить друзей принять участие в онлайн-игре.

• Возможность приобрести билеты без звонка в колл-центр.

• Более быстрая продажа билетов.

Поставляемый функционал

Ответив на первые три вопроса, можно переходить к обсуждению границ проекта. Третий уровень impact map призван ответить на следующий вопрос: что мы можем сделать, чтобы добиться необходимых влияний? Имеются в виду ожидаемые результаты проекта, поставляемые функциональные возможности и организационные изменения, которые могут потребоваться в этой связи.

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