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

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

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

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

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

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

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

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

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

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

• [Balic, 2007] Effect Managing IT, Mijo Balic, Ingrid Ottersten, Copenhagen Business School 2007, ISBN 978-8763001762

• [Brinkerhoff, 1994] The Learning Alliance: Systems Thinking in Human Resource Development, Robert O. Brinkerhoff, Stephen J. Gill, Jossey-Bass 1994, ISBN 1555427111

• [Gilb, 2005] Competitive Engineering, Tom Gilb, Butterworth-Heinemann 2005, ISBN 978-0750665070

• [Matts, 2011] Feature Injection: three steps to success, Chris Matts and Gojko Adzic, InfoQ 2011