Тяжелые последствия проектов с фиксированной стоимостью

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

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

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

Из Dr Dobb's, автор Скотт Амблер.

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

• заранее написанные спецификации: мы подробно описываем функциональные требования к продукту на раннем этапе жизненного цикла;
• управление изменениями: мы стараемся удержать "расползание границ проекта" (scope creep) на протяжении всего проекта;
• заранее разработанный дизайн системы: мы подробнно описываем архитектуру приложения до начала собственно разработки;
• последовательный цикл разработки продукта.
  

Давайте рассмотрим проблемы, порождаемые каждой из этих практик.
Во-первых, проблема с заранее написанными спецификациями в том, что мы не можем заранее узнать, чего хотят люди, потому что по большому счету они сами не знают, чего хотят. У зачазчиков хорошо получается описать свои пожелания, и потом, увидев прототип интерфейса или уже работающую систему, сказать, что конкретно им в этом не понравилось, и как это переделать. Разрабатывая систему шаг за шагом, мы в конце концов доберёмся до того, что на самом деле нужно заказчику. Но также это значит, что мы далеко уйдем от первоначальных требований, на которых были основаны наши предварительные оценки времени. Эти "изменения спецификаций" (хотя на самом деле меняется наше понимание нужд заказчика) подвергают команду риску выйти за пределы бюджета. То есть - либо у нас есть точная оценка того, что заказчику не нужно, либо - неточная оценка того, что заказчику нужно.

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

В-третьих, заблаговременная разработка архитектуры - тоже сомнительной полезности вещь. Определяя элементы архитектуры на ранних этапах жизненного цикла, мы принимаем серьёзные решения при мининмуме информации (к примеру, на первом месяце проекта мы знаем намного меньше о системе, чем на десятом). А когда архитектура есть, у нас появляется хороший повод её придерживаться, т.к. мы потратили на неё уже кучу времени и сил. Хуже того, если мы неправильно поняли спецификации перед началом работы, то неважно насколько классно разработана архитектура: спецификации, на которых она основывалась, ошибочны!

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

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

На практике проекты часто выходят за рамки бюджета. А заказчики чаще всего все-таки доплачивают разницу, чтобы получить в конце концов заказанную программу. К сожалению, ошибки такого рода заставляют клиентов ещё энергичнее настаивать на более точных оценках перед началом проекта. И похоже, мы никак не вырвемся из этого заколдованного круга!

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

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

Из Dr Dobb's, автор Скотт Амблер.
Перевел Артем Сердюк для scrum.com.ua.