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

Хороший прием – разделить группу на небольшие подгруппы, каждая из которых должна заняться какой-либо частью первоначального списка и найти способ отобразить его в базовой версии карты. Через 15–20 минут соберите всех вместе и обсудите результаты. Сотрудничество в отдельных группах должно психологически подготовить участников к следующему шагу. Карты, где скомбинировано несколько вариантов, представленных разными группами, должно быть достаточно, чтобы склонить участников к обсуждению альтернативных действующих лиц и влияний.

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

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

Одна из самых распространенных ошибок при составлении impact map – перепрыгивать через уровни, пропуская некоторые влияния и не увязывая технические границы проекта с действующими лицами. Это создает проблемы, поскольку затрудняет создание прочной основы для дивергентного мышления и не позволяет должным образом выявить подразумеваемые гипотезы. Если вы заметили, что команда имеет тенденцию перескакивать через уровни, заставьте ее в явном виде указать всю недостающую информацию.

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

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

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

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

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