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

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

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

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

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

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

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

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

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

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

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

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