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

Аджич Гойко

Impact Mapping – практическое пособие по картам влияния, простому, но очень эффективному методу разработки программного обеспечения. Он помогает еще на стадии стратегического планирования организовать сотрудничество различных специалистов и в результате создавать эффективные программные продукты.

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

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

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

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

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

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

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

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

* * *

Предисловие

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

В книге описано, как лично я применяю impact maps. В более ранних публикациях я называл их effect maps (картами эффектов), поскольку между ними и картами эффектов по методу InUse действительно имеется значительное сходство. Но в моем подходе также есть и существенные отличия. Он гораздо ближе к тому, что в своей модели HET Бринкерхофф называет 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 облегчает сотрудничество и взаимодействие. Это куда менее бюрократический и гораздо более простой в использовании метод, чем многие из имеющихся альтернатив. Он позволяет вовлекать в обсуждение группы людей из разных предметных областей, то есть как технических специалистов-разработчиков, так и менеджеров со стороны бизнеса, тем самым помогая организации воспользоваться «мудростью толпы».

• Метод способствует визуализации предположений. Другие методы, как правило, не позволяют эффективно и в явном виде сообщать исходные гипотезы. 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 призван ответить на следующий вопрос: что мы можем сделать, чтобы добиться необходимых влияний? Имеются в виду ожидаемые результаты проекта, поставляемые функциональные возможности и организационные изменения, которые могут потребоваться в этой связи.

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

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

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

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

Рассматривайте свое первоначальное представление о готовом продукте в качестве факультативного: что не все желаемые функциональные возможности в итоге будут непременно реализованы.

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

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

Примеры

• Продажа билетов онлайн.

• Размещение бланка заказа непосредственно на стартовой странице сайта.

• Оптимизация скриптов, по которым работают сотрудники колл-центра.

• Подписание контрактов с реселлерами.

Никогда не стремитесь воплотить в своем продукте все без исключения элементы impact map.

Вместо этого найдите с ее помощью кратчайший путь к цели!

Пример: Платформа для онлайн-игр

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

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

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

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

Пример: Обработка финансовых транзакций

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

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

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

Роль

Impact maps

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

Три ключевые функции

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

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

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

Стратегическое планирование

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

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

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

При стратегическом планировании для эффективного использования impact maps требуется выполнение следующих двух условий:

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

• участие руководителей технического и бизнес-направлений.

Требования к качеству

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

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

Чтобы эффективно использовать impact maps для определения требований к качеству, необходимо согласие заинтересованных сторон о том, что:

• цель разработки – поддержка желательных изменений в поведении действующих лиц;

• контрольные показатели действительно выражают ожидания заинтересованных сторон в части этих изменений.

Управление дорожными картами

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

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

Чтобы использовать impact map для управления дорожными картами, необходимы следующие условия:

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

• осуществление регулярных итеративных релизов, позволяющих отслеживать продвижение к цели;

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

Impact maps позволяют решать типичные проблемы

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

Расползание границ проекта

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

Неверные решения

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

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

«Любимчики» или ненужная функциональность

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

Неверные исходные предположения

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

Возможность избежать случайных приоритетов

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

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

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

Решение бизнес-задач, а не функционал как таковой

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

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

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

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

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

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

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

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

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

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

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

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

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

Постановка измеримых целей

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

Ключевым признаком здесь является измеримость – если цель измерима, то легче определиться и с остальными обязательными элементами. Например, формулировка «рост числа пользователей» является некорректной. Очевидно, что решение, позволяющее в течение года увеличить количество пользователей на 50 %, будет радикально отличаться от решения, которое позволит увеличить их количество на 200 % в течение двух месяцев. После того как мы договоримся, чего именно, в каком количестве и как быстро мы хотим достичь, становится гораздо легче оценить, является ли данная задача вообще осуществимой. В книге «Конкурентный инжиниринг» (Competitive Engineering) Том Гилб показывает, каким образом выбор измеримых целей помогает убедиться в их правильности и сфокусироваться на их реализации. Именно акцент на измеримости позволил мне остановить несколько обреченных на провал проектов прежде, чем они начались; в конечном итоге удалось синхронизировать ожидания всех заинтересованных сторон и сформулировать новые цели, которые были одновременно и измеримыми, и реалистичными.

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

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

Как избежать «тщеславных метрик»

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

Эрик Рис в книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» предостерегает от использования «тщеславных метрик», чья единственная цель состоит в том, чтобы заставить людей чувствовать себя хорошо. По его мнению, это самая серьезная проблема, препятствующая успешной разработке программных продуктов. Он советует фокусироваться на показателях, которые стимулируют к конкретным действиям. Поскольку impact maps обязывают нас думать о влиянии на поведение действующих лиц и о том, как это влияние отследить, они помогают выбирать действительно полезные параметры.

Параметры двух уровней

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

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

Адаптивное планирование

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

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

Книга Тима Харфорда «Через поражения – к победе. Законы Дарвина в жизни и бизнесе» полна удивительных рассказов о глобальных планах, обернувшихся эпическими бедствиями, начиная с неудачных попыток Российской империи в XIX веке реорганизовать горнодобывающую промышленность, заканчивая тщетными стараниями американских военных контролировать мятежи на территории Ирака и недавним обвалом банковского сектора. Харфорд противопоставляет эти провалы успехам, таким как разработка самолета Spitfire и господство компании Google в интернете, предлагая в качестве инструмента следующий контрольный список:

• Альтернативы: поиск свежих идей и тестирование нестандартных подходов.

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

• Отбор: стремление получать обратную связь и желание учиться на своих ошибках.

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

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

Разработка – измерение – обучение

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

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

Итеративная разработка

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

В докладе, опубликованном консалтинговой компанией Forrester Research, утверждается, что большинство организаций придерживается идеологии гибкой разработки только для решения технических задач – при этом принятие бизнес-решений остается вне рамок процесса и это ведет к значительным упущенным выгодам. Многие организации применяют схему, которую Дэйв Уэст назвал Water-Scrum-Fall. На первой стадии до начала разработки принимается большая часть бизнес-решений, на второй происходит собственно итеративная разработка, а завершается все долгим процессом утверждения бизнес-результатов.

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

Целостное видение

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

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

Более эффективная приоритизация

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

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

Итеративная, а не инкрементальная разработка

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

Impact maps позволяют разделить проект на отдельные ветви и работать над отдельными влияниями, заставляя нас думать о том, как их быстро реализовать, и удерживая разработку в истинно итеративном режиме.

Пользовательские истории

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

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

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

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

Пользовательские истории должны быть честными

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

Часто бывает, что заказчику в силу личных предпочтений просто очень нравится какой-либо функционал и он предпринимает попытку продвинуть необходимость его реализации, замаскировав свое пожелание под пользовательскую историю. Обычно такие истории сформулированы весьма расплывчато, в них может отсутствовать указание на бизнес-ценность, или же они содержат очевидные логические ошибки («порочный круг»). Классическими примерами являются тексты вроде «Я трейдер, и мне необходимо торговать, поскольку я являюсь трейдером» или «Мне нужно, чтобы из системы можно было распечатать отчет по отдельно взятому клиенту».

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

Дизайн-мышление

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

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

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

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

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

Кроме того, impact maps могут содействовать в использовании четырех из десяти ключевых инструментов дизайн-мышления, перечисленных Жанной Лидтка и Тимом Огилви в книге «Думай как дизайнер: Дизайн-мышление для менеджеров»:

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

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

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

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

Эффективные совещания

По мнению Дэвида Сиббета, существует три причины, почему визуализация делает совещания более эффективными:

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

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

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

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

Impact maps являются визуальным инструментом. Руководители технического и бизнес-направлений, заинтересованные в результатах проекта, совместно рисуют карты на флипчартах, повышая эффективность обсуждения за счет наглядности и тех самых дополнительных 80 пунктов IQ, высвобождая энергию и творческий потенциал друг друга. В результате продуктивность совещаний неуклонно возрастает. Многие из моих клиентов были поражены, как много нам удавалось сделать за один или два дня работы по составлению карт, особенно в сравнении с традиционными стратегическими совещаниями, которые принято проводить с использованием презентаций, состоящих из десятков слайдов («смерть через PowerPoint»). Возможно, это экстремальный пример, но один из моих клиентов отметил, что в его компании к сравнимым результатам обычно приходят после шести месяцев переговоров.

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

Стоимость разработки – не затраты, а инвестиции

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

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

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

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

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

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

Составление

Impact map

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

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

Подготовительный этап 1: Сформулируйте бизнес-цель

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

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

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

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

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

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

Подготовительный этап 2: Выберите эффективные метрики

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

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

• что мы собираемся измерять (Гилб называет это «объект измерений»);

• как мы будем измерять его («параметр»);

• какова ситуация на данный момент («бенчмарк»);

• минимально допустимое значение, точка безубыточности для инвестиций («ограничение»);

• целевой показатель («цель»).

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

Недавно я проводил серию консультаций, в ходе которых выяснилось, что первоначальный список включает порядка 20 целей. Обсудив их вместе с возможными способами измерения, мы вычеркнули 17 из 20 – они оказались не такими уж важными.

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

ЭКСПЕРИМЕНТИРУЙТЕ С НАЗВАНИЯМИ

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

Подготовительный этап 3: Наметьте первую контрольную точку

После того как у вас возникнет список целей и соответствующих им параметров, проанализируйте его еще раз. Убедитесь, что все цели и параметры действительно относятся к текущему этапу проекта, и если возможно, отложите некоторые из них. Как правило, в «списке покупок» существует только одна доминирующая цель – и очень важно, чтобы люди, отвечающие за бизнес-составляющую проекта, были с ней согласны. Я часто прибегаю к голосованию: в процессе каждый из присутствующих получает несколько стикеров, чтобы прикрепить их к тем целям, которые ему представляются наиболее важными. Если для голосования использовать виртуальные деньги, то иногда удается получить более точные результаты. Создайте условные наличные (например, указав на листочках номинал £100) и раздайте их участникам голосования таким образом, чтобы каждый получил меньше «купюр», чем имеется потенциальных целей. Еще одна опция – раздать участникам голосования деньги для игры в «Монополию» или любые другие деньги, используемые в настольных играх, – их можно купить практически в любом магазине игрушек. Попросите заказчиков «инвестировать» эти средства в бизнес-цели, которые им представляются наиболее ценными. Количество стикеров или выраженный в виртуальных деньгах бюджет, предназначенный для той или иной цели, в итоге дадут вам список приоритетов.

Команды, ведущие итеративную разработку, должны по возможности единовременно трудиться только над одной целью. Лучше выполнить пять последовательных этапов, каждый из которых имеет только одну бизнес-цель, чем один этап, подразумевающий частичное достижение пяти целей сразу. Причина в том, что ландшафт может измениться после того, как вы добьетесь первой цели. Поэтому можно разделить этап с двумя ключевыми целями (скажем, рост числа игроков с 300 000 до 1 миллиона и сокращение затрат на IT на 40 %) на два. Целью первого будет увеличение числа игроков при сохранении затрат на IT на прежнем уровне, а второго – сокращение затрат на IT без негативного влияния на число игроков. Когда цели распределены между этапами, вторая цель становится активной сразу же после того, как первая окажется позади.

Если для достижения первой цели требуется слишком много времени или слишком рискованно ждать, пока число игроков достигнет 700 000, то, прежде чем взяться за сокращение затрат на IT, следует пересмотреть имеющиеся цели. Целью первого этапа могло бы стать увеличение количества пользователей до 100 000, а второго – сокращение расходов на IT. Затем вы можете вернуться к задаче дальнейшего увеличения числа игроков.

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

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

Если ответ «нет», вернитесь к началу: вы выбрали неправильные целевые параметры.

Составление impact map: Этап 1 создание «скелета» карты

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

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

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

• Реалистично ли наше ожидание, что данная функциональность будет способствовать оказанию необходимого влияния?

• Правда ли это влияние способно воздействовать на данное лицо?

• Действительно ли данное влияние будет способствовать достижению цели?

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

Также всегда полезно разделить группу на несколько подгрупп, а через 20 минут собрать всех вместе и сравнить результаты. Это помогает ускорить работу над базовой структурой карты.

Составление Impact map: Этап 2 поиск альтернатив

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

• Что еще эти люди могли бы для нас сделать?

• Кто еще может нам помочь? Каким образом?

• Кто может нам помешать?

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

Если вы хотите по максимуму использовать потенциал команды, можно воспользоваться какой-либо из кооперативных игр, описанных в книгах «Бизнес-игры» [Hohmann, 2006] и «Геймшторминг» [Gray, 2010].

Составление Impact map: Этап 3 определение ключевых приоритетов

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

• Какие решающие факторы могут остановить нас еще до начала разработки?

• Есть ли какие-либо влияния, которые мы можем оказать без особых усилий?

• Какие ключевые гипотезы необходимо протестировать?

Если обсуждение не приводит к убедительному ответу на вопрос, с чего целесообразнее всего начать разработку, можно прибегнуть к голосованию.

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

Улучшаем структурированность карты

Если вы хотите сделать обсуждение еще более последовательным, ознакомьтесь с моделью Кано и моделями, направленными на синхронизацию проектных целей со стратегическими приоритетами компаний. В модели Кано [Cohn, 2006] используется опросник, помогающий разделить ожидаемую функциональность продукта на несколько категорий: базовая (продукт не может ее не иметь), линейная (чем ее больше, тем лучше) и восхищающая (ее присутствие даже в ограниченной степени может существенным образом повысить удовлетворенность продуктом). В модели синхронизации целей [Pixton, 2009] различные категории функциональности определяются как критически важные для рыночной дифференциации продукта, сравнимые (должны быть не хуже, чем в других аналогичных продуктах), партнерские (некритичные для миссии продукта, их можно приобрести в составе других продуктов) и безразличные для потребителя (допустимо вообще не включать).

Составление Impact map: Этап 4 обучение на ошибках

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

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

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

• Как проще всего поддержать данную активность? Что еще мы могли бы сделать?

• Если мы не уверены в своей гипотезе, как ее проще всего протестировать?

• Можем ли мы протестировать ее, не прибегая к созданию кода?

• Можно ли привести данную гипотезу в рабочее состояние, даже если поначалу часть операций будет совершаться вручную?

Если для того, чтобы протестировать ключевые гипотезы, у вас не получается сознательно ограничить масштаб проводимого эксперимента, попробуйте воспользоваться картами пользовательских историй Паттона [Patton, 2008 и Patton, 2009] или «методом гамбургера» [Adzic, 2012], которые помогают разделить итеративную разработку на небольшие фрагменты и быстро получить подтверждение своей гипотезы или как минимум – сделать полезные для дальнейшей разработки выводы.

Задайте вопрос: «Уверены ли мы, что гипотеза, лежащая в основе пункта #1 нашей карты, является верной?»

Если ответ «нет», найдите способ проверить эту гипотезу, не выходя за рамки имеющегося «бюджета на обучение»!

Отображение метрик на карте

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

Добавить показатели в виде отдельных пунктов списка

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

Переименование узлов

Когда к конкретному узлу карты относятся всего один или два ключевых показателя, мы можем просто переименовать его, включив в название соответствующие параметры. Так, название узла «рост числа игроков» можно изменить на «рост числа игроков до 800 000–1 млн в течение 6 месяцев». Это одинаково эффективно как для метрик, относящихся к главной цели проекта, так и для ориентированных на измерение влияний. Так структура impact map не изменяется и остается предельно ясной. Его недостаток в том, что текст, размещенный внутри конкретного узла, становится длиннее. Из-за этого данный способ удачен только тогда, когда ключевых показателей, относящихся к данному узлу, не так много. При переименовании узлов часто приходится опускать еще больше информации, чем при использовании маркированных списков.

Показатели собраны в отдельной таблице

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

Добавление дополнительных узлов

В книге «Управление IT-проектами через эффекты» (Effect Managing IT) Балич и Домингес предлагают отражать показатели на карте, вводя в нее дополнительные узлы. Преимущество этого способа состоит в том, что он позволяет отобразить полную информацию о контрольных показателях и даже расставить их в иерархическом порядке. Этот подход работает в любых приложениях для ментальных карт, поскольку для метрик создаются стандартные дополнительные ветви. Недостаток подхода – усложняется структура карты и общая картина порой выглядит несколько запутанной, поскольку разные понятия могут оказаться на одном и том же уровне. В частности, становится сложнее воспринимать показатели, которые относятся к влияниям, а не только к бизнес-целям.

Предварительные итоги

Impact maps вместе с измерением контрольных показателей позволяют повысить сосредоточенность проектов на целях, синхронизировав их с глобальными стремлениями организации. Но именно поэтому impact maps могут превратиться в очередную ловушку, которая приведет к провалам, сравнимым с провалами в городском строительстве и сельском хозяйстве, от которых предостерегает Джеймс Скотт. Он показывает, каким образом планы, сфокусированные на достижении одного конкретного результата (как правило, коммерческого характера) поначалу имеют все шансы преуспеть («нельзя отрицать чрезвычайную силу подобного подхода для увеличения урожаев»). Однако при этом возникают «слепые пятна» по отношению ко всему, что осталось вне суженного поля зрения проектантов, в частности, долгосрочные результаты и влияние, которое оказывается на третьи стороны. Такие проблемы, как правило, остаются незамеченными до тех пор, пока они не начинают негативно влиять на изначальные цели проекта. Но в этот момент часто уже слишком поздно что-либо менять.

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

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

По мнению Тома Гилба, стоимость каждой итерации в ходе проекта не должна превышать 2 % от общего объема инвестиций. Эрик Рис рекомендует проводить регулярные совещания, в центре внимания которых должен быть вопрос о том, стоит ли придерживаться избранного курса или необходимо коренным образом изменить направление разработки. С самого начала договоритесь с командой, как часто вы собираетесь оценивать, насколько вы продвинулись к цели: например, раз в неделю или раз в месяц. Постарайтесь сразу определить, какого рода события должны указывать на необходимость поддержания или изменения курса и в какие сроки.

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

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

Крупномасштабные карты

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

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

Если в результате разработки ключевые цели так и не были достигнуты, пришло время пересмотреть стратегию!

Типичные организационные ошибки

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

Задействовано слишком много людей

Работая в одиночку, невозможно воспользоваться «мудростью толпы». В то же время чем больше людей присутствует в совещаниях, тем труднее модератору выполнять свою роль. Оптимальное количество участников особенно важно для подготовительного этапа, цель которого состоит в том, чтобы определиться с бизнес-целями и контрольными параметрами. Каждому из собравшихся захочется высказать свое мнение, а если в комнате собралось 20 человек, то первый раунд может занять несколько часов. Поэтому при проведении первого совещания постарайтесь ограничиться пятью или шестью участниками. Убедитесь, что присутствуют все ключевые технические руководители и лица, принимающие решения со стороны бизнеса. Если вам все же приходится работать с большой группой, разделите ее на несколько подгрупп, которые должны будут провести обсуждение параллельно, а затем представить свои результаты. На втором совещании может присутствовать от 10 до 20 человек – это позволит в полном объеме воспользоваться преимуществами дивергентного мышления с последующим синтезом. Чтобы при такой численности участников обсуждение было эффективным, необходимы услуги модератора. Профессионального модератора нанимать необязательно, но следует убедиться, что есть по крайней мере один человек, который может взять на себя его роль. Его задача состоит в том, чтобы продвигать обсуждение вперед (модератору необязательно самому вносить предложения по заполнению карты). Проводя совещание, модератор обязан контролировать использование времени: ни у кого из участников не должно быть возможности продавливать свои частные интересы и все должны успеть задать правильные вопросы.

Неправильный подбор участников

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

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

Планировка помещения

Идеальная планировка облегчает взаимодействие, позволяя людям временно объединяться в группы, переходить от группы к группе и обратно. Наихудший вариант планировки – аудитория или класс с немобильными стульями: все просто уснут. Неудобны и варианты планировки, где 90 % полезной площади занимает большой стол. В конце концов, вы же не собираетесь проводить встречу с целью подписания мирного договора, а просто хотите разработать хорошую дорожную карту. Рассадка вокруг большого стола провоцирует людей играть во время выступлений со своими мобильными телефонами, а не участвовать в работе. Меня не раз отчитывали офис-менеджеры за то, что я сдвигал все столы в одну сторону комнаты – но дело того стоило. Предоставьте людям пространство, где им будет легко передвигаться и взаимодействовать, и они ответят вам тем, что начнут активно предлагать более эффективные идеи.

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

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

Типичные ошибки модерации

Слишком ранняя критика

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

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

Обсуждение замыкается в одной большой группе

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

Реверс-инжиниринг

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

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

Хороший прием – разделить группу на небольшие подгруппы, каждая из которых должна заняться какой-либо частью первоначального списка и найти способ отобразить его в базовой версии карты. Через 15–20 минут соберите всех вместе и обсудите результаты. Сотрудничество в отдельных группах должно психологически подготовить участников к следующему шагу. Карты, где скомбинировано несколько вариантов, представленных разными группами, должно быть достаточно, чтобы склонить участников к обсуждению альтернативных действующих лиц и влияний.

Погружение в излишние детали на ранних этапах

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

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

Типичные ошибки при составлении Impact map

Прыгун с шестом

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

Астронавт

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

Сюрреалист

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

Любитель шопинга

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

Оптимист

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

Мечтатель

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

Робот

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

Осьминог

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

Список литературы

Основные методологические материалы

• [Balic, 2007] Effect Managing IT, Mijo Balic, Ingrid Ottersten, Copenhagen Business School 2007, ISBN 978-8763001762

• [Brinkerhoff, 1994] The Learning Alliance: Systems Thinking in Human Resource Development, Robert O. Brinkerhoff, Stephen J. Gill, Jossey-Bass 1994, ISBN 1555427111

• [Gilb, 2005] Competitive Engineering, Tom Gilb, Butterworth-Heinemann 2005, ISBN 978-0750665070

• [Matts, 2011] Feature Injection: three steps to success, Chris Matts and Gojko Adzic, InfoQ 2011

Источники статистических данных (см. Введение)

• Troubled £12bn NHS IT system to be scaled back, BBC News, 6 December 2009

• NHS pulls the plug on its £11bn IT system, The Independent, 3 August 2011

• Costs of US piloted programs by Claude Lafleur, 2010

• Также см. [McManus, 2008]

Другие книги и статьи

• [Adzic, 2012] Splitting user stories: the hamburger method, Gojko Adzic

• [Berkun, 2005] Art of Project Management, Scott Berkun, O'Reilly 2005, ISBN 978-0596007867 (На рус. яз.: Беркун C. Искусство управления IT-проектами. – СПб.: Питер, 2014. – 432 с.)

• [Brown, 2009] Change by Design: How Design Thinking Can Transform Organizations and Inspire Innovation, Tim Brown, Collins Business 2009, ISBN 978-0061766084 (На рус. яз.: Браун Т. Дизайн-мышление: От разработки новых продуктов до проектирования бизнес-моделей. – М.: Манн, Иванов и Фербер, 2012. – 256 с.)

• [Cohn, 2004] User Stories Applied for Agile Software Development, Mike Cohn, Addison-Wesley Professional 2004, ISBN 978-0321205681 (На рус. яз.: Кон М. Пользовательские истории. Гибкая разработка программного обеспечения. – М.: Вильямс, 2012. – 256 с.)

• [Cohn, 2006] I didn't know I needed that, Mike Cohn, Better Software Magazine February 2006

• [Gray, 2010] Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, Dave Gray, Sunni Brown, James Macanufo, O'Reilly Media 2010, ISBN 978-0596804176 (На рус. яз.: Грей Д. Геймшторминг. Игры, в которые играет бизнес / Д. Грей, С. Браун, Дж. Макануфо. – СПб.: Питер, 2012. – 288 с.)

• [Harford, 2011] Adapt: Why Success Always Starts with Failure, Tim Harford, Farrar, Straus and Giroux 2011, ISBN 978-0374100964 (На рус. яз.: Харфорд Т. Через поражения – к победе. Законы Дарвина в жизни и бизнесе. – М.: Альпина Паблишер, 2012. – 282 с.)

• [Hohmann, 2006] Innovation Games: Creating Breakthrough Products Through Collaborative Play, Luke Hohmann, Addison-Wesley Professional 2006, ISBN 978-0321437297 (На рус. яз.: Хоманн Л. Бизнес-игры: Создание революционных продуктов с помощью клиентов. – М.: Символ-Плюс, 2008. – 224 с.)

• [Hubbard, 2010] How to Measure Anything: Finding the Value of «Intangibles» in Business, Douglas W. Hubbard, Wiley 2010, ISBN 978-0-470-62568-2 (На рус. яз.: Хаббард Д. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе. – М.: Олимп-Бизнес, 2009. – 298 с.)

• [Klein, 1999] Sources of Power: How People Make Decisions, Gary Klein, MIT Press 1999, ISBN 978-0262611466

• [Lapouchnian, 2005] Goal-Oriented Requirements Engineering: An Overview of the Current Research, Alexei Lapouchnian, Department of Computer Science, University of Toronto

• [Liedtka, 2011] Designing for Growth: A Design Thinking Toolkit for Managers, Jeanne Liedtka, Tim Ogilvie, Columbia University Press 2011, ISBN: 978-0231158381(На рус. яз.: Лидтка Ж. Думай как дизайнер: Дизайн-мышление для менеджеров / Жанна Лидтка, Тим Огилви. – М.: Манн, Иванов и Фербер, 2015. – 240 с.)

• [McManus, 2008] A study in project failure, Dr John McManus and Dr Trevor Wood-Harper, BCS, The Chartered Institute for IT, June 2008

• [Patton, 2008a] I don't know what I want but I know how to get it, Jeff Patton, 2008,

• [Patton, 2008b] User Story Mapping, Jeff Patton 2008, (На рус. яз.: Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО. – СПб.: Питер, 2017. – 288 с.)

• [Patton, 2008c] The new user story backlog is a map, Jeff Patton 2008,

• [Pixton, 2009] Stand Back and Deliver: Accelerating Business Agility, Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald, Addison-Wesley Professional 2009, ISBN 978-0321572882

• [Ries, 2011] The Lean Startup, Eric Ries, Crown Business 2011, ISBN 978-0670921607 (На рус. яз.: Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. – М.: Альпина Паблишер, 2017. – 255 с.)

• [Scott, 1999] Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed, James C. Scott, Yale University Press 1999, ISBN 978-0300078152 (На рус. яз.: Скотт Д. Благими намерениями государства. – М.: Университетская книга, 2011. – 568 с.)

• [Shore, 2005] Beyond Story Cards, James Shore, 2005

• [Sibbet, 2010] Visual Meetings: How Graphics, Sticky Notes And Idea Mapping Can Transform Group Productivity, David Sibbet, John Wiley and Sons 2010, ISBN 978-0470601785 (На рус. яз.: Сиббет Д. Визуализируй это! Как использовать графику, стикеры и интеллект-карты для командной работы. – М.: Альпина Паблишер, 2017. – 280 с.)

• [West, 2011] Water-Scrum-Fall is the reality of Agile for most organisations today, Dave West

• [Yu, 2011] Social Modeling for Requirements Engineering, Eric Yu, Paolo Giorgini, Neil Maiden, John Mylopoulos; MIT Press 2011, ISBN 978-0262240550

Дополнительные ресурсы и ссылки доступны на сайте .

Ссылки

[1] Распространенное обозначение двух различных стратегий – маркетинговых, мотивационных и т. п. (от англ. pull и push, то есть «толкать» и «тянуть»). – Прим. пер.

[2] Такие проблемы очень трудно или даже вообще невозможно решить, поскольку они сопровождаются не до конца сформулированными, противоречивыми или постоянно меняющимися требованиями, которые к тому же нелегко распознать. Слово «злые» в данном случае означает, что подобные проблемы «сопротивляются» попыткам их решения. Кроме того, попытки решить один из аспектов такой проблемы часто приводят к возникновению непредвиденных последствий или очередных сложностей. – Прим. пер.

[3] Highly Effective Training (высокоэффективное обучение). – Прим. пер.

[4] Этот термин стал особенно популярен после выхода книги: Шуровьески Дж. Мудрость толпы: Почему вместе мы умнее, чем поодиночке, и как коллективный разум влияет на бизнес, экономику, общество и государство. – М.: Манн, Иванов и Фербер, 2014. – 320 с. – Прим. пер.

[5] Goal-Oriented Requitements Engineering, GORE. – Прим. пер.

[6] I* model – это язык моделирования, применяемый на ранних этапах проектирования для того, чтобы понять домен решаемой проблемы . – Прим. ред.

[7] Хаббард Д. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе. – М.: Олимп-Бизнес, 2009. – 298 с.

[8] Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. – М.: Альпина Паблишер, 2017. – 256 с.

[9] Скотт Д. Благими намерениями государства. – М.: Университетская книга, 2011. – 568 с.

[10] Героические предположения – предположения или гипотезы, являющиеся маловероятными из-за своей нереалистичности. – Прим. пер.

[11] Харфорд Т. Через поражения – к победе. Законы Дарвина в жизни и бизнесе. – М.: Альпина Паблишер, 2012. – 282 с.

[12] Иногда этот метод разработки называют «каскадный» или «водопад». – Прим. пер.

[13] Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО. – СПб.: Питер, 2017. – 288 с.

[14] Лидтка Ж. Думай как дизайнер: Дизайн-мышление для менеджеров / Жанна Лидтка, Тим Огилви. – М.: Манн, Иванов и Фербер, 2015. – 240 с.

[15] Техника, используемая для изучения причинно-следственных связей, лежащих в основе той или иной проблемы. Основной задачей техники является поиск первопричины возникновения проблемы с помощью пятикратного повторения вопроса «почему?». – Прим. ред.

[16] Хоманн Л. Бизнес-игры: Создание революционных продуктов с помощью клиентов. – М.: Символ-Плюс, 2008. – 224 с.

[17] Грей Д. Геймшторминг. Игры, в которые играет бизнес / Д. Грей, С. Браун, Дж. Макануфо. – СПб.: Питер, 2012. – 288 с.

[18] Set-Based Design – метод проектирования, при котором рассматриваются одновременно несколько вариантов архитектуры, а по мере реализации продукта и получения новых знаний, количество этих вариантов уменьшается до одного, наиболее приемлемого. – Прим. ред.