Гойко Аджич - Impact mapping - Как повысить эффективность программных продуктов и проектов по их разработке

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

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

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

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

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

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