Теперь нам надо определить с набором действий. Например, модератор форума может попробовать давать ответы на вопросы в течение одной минуты. Как вы думаете, повысит это удовлетворённость пользователей? У нас есть предположение, что повысит, поэтому записываем этот «impact». То же самое делаем для остальных ролей (рис. 8).

Рис. 8. Гипотезы, которые помогут в достижении цели

Несколько рекомендаций:

1. Необязательно, но желательно, чтобы воздействия тоже были измеримыми. Мы написали не просто Отвечать на форуме, а Отвечать на форуме в течение одной минуты.

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

Мы дошли до самого несущественного в Impact Mapping. В последнем узле нашей карты находится та самая корзина с покупками, с которой обычно начинается работа над проектом. Разница в том, что теперь мы понимаем ценность каждой фичи, почему эта фича здесь и к чему приведёт её реализация (рис. 9).

Рис. 9. Финальная часть со списком задач

Несколько замечаний и лайфхаков:

1. В конечных узлах карты можно написать User Story или названия модулей/подсистем.

2. Эту часть карты можно подробно не расписывать, можно даже не заполнять, а лишь проговорить её основные моменты. Полный список всех User Story вы успеете создать на User Story Mapping'е.

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

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

Вот и готов наш Impact Mapping. Осталось приоритизировать каждую колонку. Не все цели одинаково важны, то же самое можно сказать про остальные узлы карты. Есть разные способы. Так как мы идём по пути простоты и визуализации, я могу рекомендовать ставить звёздочки. Каждому участнику даётся по пять звёзд, и он может ставить их куда считает нужным. Таким образом можно выявить самые приоритетные узлы.

Результат работы нужно повесить у всех на виду. Если команда распределённая, то следует выложить Impact Mapping в общую базу знаний или повесить перед экраном, который видят все участники разработки. Главная цель – обеспечить видимость и достижимость задач, ведь мы опираемся на них при работе над проектом[18].

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

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

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

Какая колонка идёт последней на вашей Kanban-доске? Могу поспорить, что это Release, Deploy, Done или что-то в этом духе. Последней колонкой на доске должна стать – «Проверка достижения цели». Недостаточно просто залить фичу на сервер, нам нужно проверить, достигли ли мы цели.

Как продать создание Impact Mapping бизнесу перед началом проекта?

Лучше всего идти от проблемы. Попросите заказчика вспомнить случаи, когда было сделано много фич, а бизнес от этого только пострадал. Почему так произошло? Может, надо чётко описать цели?

Должна ли эта работа оплачиваться?

Да, обязательно. Составление Impact Mapping может занять несколько дней и имеет ценность для бизнеса.

Что если заказчик не хочет этого делать?

Вы как профессионал должны предоставить бизнесу прогноз на будущее. Расскажите о возможных проблемах и рисках. После этого дайте клиенту выбрать. Если вы донесли возможное проблемное будущее и клиент принял его, отказался от Impact Mapping'а при полной ясности последствий, то теперь это не ваша проблема; просто делайте ему фичу.

Всегда ли бизнес чётко знает свои цели?

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

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

Разбор нюансов создания Impact Map на примере притчи

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

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

В прошлой главе мы рассмотрели структуру Impact Map (рис. 5). Идея этого подхода в том, чтобы прорисовать связь от задач (Deliverable) к цели (Goal). По задумке, задачи оказывают воздействие (Impact) на какую-то группу (Actor), и это воздействие приводит бизнес к цели. Таким образом, нет бесполезных задач, и чётко видно, что и зачем мы собираемся делать.

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