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

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

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

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

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

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

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

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

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

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

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

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

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

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

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