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

• Тестирование гипотез, чтобы проверить их состоятельность: исходные предположения отображаются на impact maps в виде картинок, что облегчает целенаправленный поиск фактов, которые могли бы подтвердить или опровергнуть наши исходные утверждения.

• Включение потенциальных потребителей в процесс дизайна: визуальный характер impact maps , а также их ориентация на коллективное обсуждение позволяют вовлекать в дискуссию как самих разработчиков, так и потенциальных потребителей и в результате их совместных усилий находить эффективные решения.

По мнению Дэвида Сиббета, существует три причины, почему визуализация делает совещания более эффективными:

• Значительно повышается вовлеченность, поскольку участники обсуждают идеи в наглядном графическом представлении.

• Мышление происходит на более высоком уровне («общая картина»), что позволяет группе легче выявлять закономерности, сравнивать имеющиеся идеи и находить новые.

• Улучшается групповая память, поскольку результаты совещания фиксируются в виде картинок, по которым впоследствии легче отслеживать исполнение.

Сиббет утверждает, что визуализация делает команды умнее: «Визуализация добавляет 80 пунктов к групповому IQ», поскольку она высвобождает энергию, интеллект и творческие способности участников совещания.

Impact maps являются визуальным инструментом. Руководители технического и бизнес-направлений, заинтересованные в результатах проекта, совместно рисуют карты на флипчартах, повышая эффективность обсуждения за счет наглядности и тех самых дополнительных 80 пунктов IQ, высвобождая энергию и творческий потенциал друг друга. В результате продуктивность совещаний неуклонно возрастает. Многие из моих клиентов были поражены, как много нам удавалось сделать за один или два дня работы по составлению карт, особенно в сравнении с традиционными стратегическими совещаниями, которые принято проводить с использованием презентаций, состоящих из десятков слайдов («смерть через PowerPoint»). Возможно, это экстремальный пример, но один из моих клиентов отметил, что в его компании к сравнимым результатам обычно приходят после шести месяцев переговоров.

Говоря о продуктивности совещаний, еще одним интересным аспектом impact maps является сходство вопросов, задаваемых при их составлении, с вопросами, используемыми в модели командообразования по версии Гибба – Дрекслера – Вайсборда. Еще в 1960-х годах Джек Гибб, Марвин Вайсборд и Алан Дрекслер предложили модель построения команд, базирующуюся на результатах исследований групповой динамики и организационного развития. Они структурировали свою модель вовлеченности вокруг четырех основных вопросов: «зачем мы здесь?», «кто ты?», «что мы делаем?» и «как мы собираемся сделать это?». Их модель помогает синхронизировать цели команд с целями организации и напрямую коррелирует с порядком обсуждения при создании impact maps . На практике это означает, что сама структура карт непосредственно способствует продуктивному обсуждению и сплочению отдельных игроков в группу, объединенную общей целью.

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

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