Читаем Impact mapping онлайн бесплатно

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

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

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

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

Еще одна типичная ошибка, которую делают команды, состоит в том, что они разрабатывают продукт фрагмент за фрагментом, но бизнес-ценность возникает только в конце проекта, когда все готовые части соберутся вместе. Широко известен пример «Моны Лизы», с помощью которого Джефф Паттон[13] иллюстрирует разницу между инкрементальной и итеративной разработкой.

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

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

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