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

Стоимость разработки – не затраты, а инвестиции

Стоимость разработки – не затраты, а инвестиции

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

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

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

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

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

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

Оглавление книги