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

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

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

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

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

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

При составлении impact map мы уже на входе должны иметь правильно сформулированную измеримую цель. Поэтому важно проводить обсуждение в два этапа: на первом мы формулируем цель и подбираем контрольные параметры, а на втором – рисуем саму карту.

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

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