Антихрупкость в IT - стр. 13

6. Не надо вытягивать искусственные цели. Бывают проекты, которые просто есть, потому что инвесторам хочется поиграть в создателей ПО. С этим нужно смириться и свернуть работу по составлению Impact Mapping.

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

Рис. 7. Акторы в Impact Map, влияющие на цель

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

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

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

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

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

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

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

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

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

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

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

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

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

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