Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке - [16]
Стоимость разработки – не затраты, а инвестиции
Многие организации склонны воспринимать стоимость разработки программного обеспечения просто как еще один вид затрат. Причина – отсутствие широкого взгляда на проект в целом и четкого понимания, зачем вообще предпринимается данная разработка и какие задачи должен решить готовый продукт. В подобной ситуации отчеты о ходе проекта фокусируются скорее на стоимостных параметрах; анализу потраченных ресурсов в них уделяется больше внимания, чем преимуществам и выгодам, которые предполагается получить на выходе. Напротив, impact maps акцентируют внимание на достижении бизнес-целей. Они показывают исходные гипотезы и как именно при помощи включаемой в продукт функциональности предполагается их достичь. С помощью карт необходимость каждого из разрабатываемых или тестируемых элементов функциональности становится более очевидной.
Независимо от метода планирования первые два вопроса, которые обычно задаются при обсуждении проекта, звучат так: «сколько это будет стоить?» и «Сколько займет разработка?». Стремясь соответствовать ожиданиям бизнес-менеджеров, команды отходят от итеративной разработки и начинают тратить больше времени на составление детальных долгосрочных планов. В итоге они не способны в полной мере пользоваться преимуществами, которые дает итеративный подход. К ним относится, например, возможность естественным образом учитывать возникающую при итеративной разработке ценную информацию.
Если мы фокусируемся на бизнес-целях и контрольных параметрах, по которым можно судить об их достижении, нам легче отвечать на вопросы о стоимости разработки и сроках. Мы можем просто спросить заказчика: «Насколько ценной для вас является данная функциональная возможность? Сколько вы готовы инвестировать в ее разработку? Когда она вам понадобится?» Затем информацию, полученную в виде ответов на эти вопросы, мы добавляем в описание соответствующего этапа в качестве контрольных параметров.
Безусловно, в ходе переговоров разработчики не могут просто заявить, что они потратят все время и деньги, отпущенные на проект. Именно поэтому перед заказчиками открывается возможность попытаться сократить бюджет разработки путем переговоров. С позиции разработчика более эффективно представить исходные гипотезы и риски в максимально наглядном виде и договориться с заказчиком о том, что инвестиции будут осуществляться поэтапно.
Если цели сформулированы правильно, то их всегда можно привести к денежному выражению и решить, будет ли получен удовлетворительный возврат на инвестиции. Диалог в таком ключе не раз позволял мне убедить клиентов еще на стадии обсуждения отказаться от ряда обреченных проектов. Но даже если денег и времени для реализации задачи достаточно, мы можем для начала использовать лишь небольшую часть бюджета и протестировать ключевые гипотезы. Если гипотезы не подтверждаются, нам следует остановить проект раньше, чем будет потрачен весь бюджет. Если ключевые исходные предположения окажутся верными, то инвестиции можно совершать поэтапно до тех пор, пока не будет достигнута соответствующая бизнес-цель. При этом остается возможность остановить работы, если цель окажется достигнутой прежде, чем бюджет будет полностью освоен. Применяя такую логику, вместо того чтобы фокусироваться на учете уже потраченных ресурсов и отслеживании исполнения частных задач, мы сможем предложить заинтересованным сторонам более осмысленные промежуточные отчеты, где речь будет идти о реализованных воздействиях и ключевых параметрах, связанных с приближением к глобальной цели.
Используя этот подход, мы перестаем тратить время впустую на решение псевдопроблем вроде составления смет и графиков. Вместо конфликтных переговоров по поводу сумм, которые уже были потрачены, мы переводим обсуждение в более продуктивную плоскость.
Составление Impact map
Для того, чтобы получить от impact map максимальную отдачу, к совместной работе над ними необходимо привлекать одновременно как технических руководителей, так и руководителей со стороны бизнеса. Когда группа людей рассматривает проблему с разных точек зрения, мы можем пользоваться «мудростью толпы» и получать хорошие результаты гораздо быстрее, чем если бы картой занимался один человек. Дополнительным преимуществом кооперации в группы является возможность выработать одинаковое понимание целей и исходных гипотез, что повышает эффективность планирования и позволяет более точно расставлять приоритеты.
При составлении impact map мы уже на входе должны иметь правильно сформулированную измеримую цель. Поэтому важно проводить обсуждение в два этапа: на первом мы формулируем цель и подбираем контрольные параметры, а на втором – рисуем саму карту.
Подготовительный этап 1: Сформулируйте бизнес-цель
В человеческой психологии есть что-то, что заставляет нас полагать, будто бы определенный набор функциональных возможностей и является решением. Большинство моих прошлых проектов начиналось с того, что заказчики предъявляли «список покупок» или функционала, который им хотелось бы иметь в готовом продукте. Бизнес-цели зачастую существовали лишь в голове у руководителя со стороны бизнеса и редко когда были зафиксированы в явном виде или сообщались другим участникам проекта. Такая практика с самого начала обрекает задачи по разработке программного обеспечения на неудачу по двум причинам:
