Зачастую клиенты спрашивают, какой тип контракта выбрать: time&materials or fixed price. Давайте обратимся к теории и выясним, чем они отличаются.
1. Fixed-price (FP) контракт
Договор, определяющий цену за известный объём работ, независимо от фактической стоимости их выполнения. Этот тип контрактов может предусматривать финансовые поощрения за достижение отдельных заданных целей проекта. Он делится на следующие:
a. Fixed-price контракт с поощрительным вознаграждением (FPIF) — контракт, определяющий стоимость работ за известный объём работ, независимо от фактической стоимости их выполнения. Также при достижении определённых критериев выполнения работ, заказчик выплачивает оговоренную премию.
b. Fixed-price контракт с фиксированной ценой (FFP) — именно этот вид контракта имеется ввиду, когда заказчик выбирает fixed price контракт, потому что стоимость и объём работ определяются до начала работ и в последствии не меняются.
c. Fixed-price контракт с оговоркой о возможной корректировке цены — удобен, если исполнение работ растягивается на продолжительное время, в течение которого условия изменятся.
2. Time&Materials contract
Смешанный тип контракта, по которому заказчик возмещает исполнителю все фактические затраты по оговоренным в контракте фиксированным ценам. Применительно к IT сфере, заказчик оплачивает всё затраченное время разработки по фиксированной часовой ставке.
Из всего разнообразия контрактов наиболее часто работы производятся по FP (FFP) или TM. Они совершенно различны по сути и у каждого из них есть свои преимущества и недостатки. Давайте рассмотрим наиболее значимые моменты:
1. Оплата рисков. В цену fixed price контракта закладываются риски, которые могут произойти при выполнении проекта. Риски могут произойти, а могут и не произойти, но заказчик платит за них всегда. Стоимость рисков вычисляется как произведение вероятности их возникновения на стоимости их реализации. Например, в проекте стоимостью 50,000$ есть едиственный риск, вероятность его возникновения небольшая, 20%, но если он произойдёт, то цена проекта вырастет на 10,000$, т.е. стоимость риска равна 2000$. Независимо от того сработает риск или нет, заказчик заплатит за проект 52,000$. При TM контракте, заказчик платит столько, сколько будет стоить реализация проекта, т.е. если риск не сработает то 50,000$, но если сработает то 60,000$.
2. Предоставление содержания работ. Поскольку при TM контракте заказчик платит за фактически затраченное время выполнения, то он может предоставлять содержание работ постепенно, по мере выполнения работ. При этом он несёт ответственность за конечный результат. При выполенении FP проекта, объём выполняемых работ предоставляется и оценивается до подписания контракта и в последствии не может меняться. Изменение объёма работ при FP контракте приводит к прекращению текущего контракта, оплате сделанной работы и подписанию нового контракта для нового объёма работ.
Для планирования своего бюджета, иногда заказчик просит сделать точную оценку работ длительного проекта. Любая точная оценка требует ясного видения результата проекта и детального описания продукта в виде содержания работ, документации, спецификаций с изображениями будущего продукта. Создание детального описания продукта — трудоёмкая работа, но без неё точной оценки стоимости работ предоставить невозможно. Чем менее детально описан продукт, тем менее точную оценку стоимости работ возможно сделать. Точная оценка трудозатрат по грубому содержанию работ может быть сделана, если недостающая информация дополняется предположениями и закладыванием рисков, на случай, если предположения ошибочны. Чем больше предположений, тем больше закладываются риски и тем больше оценка трудозатрат.
Так же надо обратить внимание на факт, если заказчик потратил несколько недель/месяцев на создание детального описания продукта, а конкуренты нет, то разработка его продукта будет отставать от конкурентов на несколько недель/месяцев. На рынок его продукт выйдет позже, поскольку конкуренты работали по методу набегающей волны — разбили проект на фазы и следующие части описания предоставлялись по мере необходимости.
Хорошо работает схема, по которой работа над продуктом разбивается на фазы и каждая из них выполняется согласно непродолжительного fixed price контракта. В таком случае заказчик предоставляет содержание работ на следующую фазу при завершении предыдущей.
Особенности TM контракта
Хочу обратить внимание на неочевидную особенность TM контракта, иногда приводящую заказчика в недоумение.
При TM контракте процесс разработки прозрачен, заказчик видит процесс разработки как есть, видит все появившиеся баги, определяет цели и содержание каждой версии продукта. Если заказчик не хочет тратить время на устранение багов и основной упор делается на добавление функциональности, то от версии к версии продукта количество неустранённых багов увеличивается. Через несколько месяцев такой разработки багов становиться столько, что эффективность QA падает, разработчики создают новую функциональность, базируясь на багах существующией функциональности. Разработка новых функциональностей идёт все медленнее и медленнее, заказчик начинает нервничать и искать причины проблем и виноватых. Причина замедления разработки — баги. Кто их создаёт — разработчики. Причина и виновные найдены.
В принципе позиция заказчика понятна — новые функциональности определяют сорт продукта. Чем больше фич — тем выше сорт и тем громче можно заявить о продукте, тем красочнее будут рекламные буклеты и лозунги. Количество багов определяет качество продукта. При рекламе продукта никто не сообщает сколько багов было пофикшено, этим потребителя не привлечёшь.
По мнению заказчика, разработчики должны предоставлять код без багов. Т.е. у заказчика ожидания качества работы разработчика на TM проекте аналогичные качеству предоставленного результата работы на FP проекте. При этом игнорируется тот факт, что на FP проекте, созданный разработчиком код, проходит контроль качества и последующий баг фиксинг всех найденных багов, прежде чем его увидит заказчик. На FP проекте устраняются все баги, без исключения и только потом заказчик видит результат. Заказчик не указывает разработчику какие баги фиксить, а какие нет. Он даже не знает о том, что баги были, ему никто ничего не говорит. Заказчик получает готовый продукт требуемого качества. А на TM проекте заказчик видит баги и решает какие баги фиксить, а какие нет, и поскольку устранение багов не увеличивает ценность продукта, они накапливаются. Когда количество багов становиться критичным — разработка останавливается и проект может прекратиться.
Для того, чтобы избежать краха проекта, надо в начале проекта убедиться в понимании заказчиком, что на TM проекте он видит процесс, включающий в себя фазы создания, тестирования и исправления. Игнорирование любой из этих фаз, в конечном счёте, приводит к краху проекта. Так же необходимо договориться, что в каждой выпускаемой версии продукта будут устранены все известные баги. Качество каждой выпускаемой версии продукта на TM проекте идентично качеству выпускаемой версии на FP проекте. При работе по методологии SCRUM следует обратить внимание на тот факт, что не каждый спринт может приводить к выпуску версии. Например, несколько спринтов предназначены для добавления новой функциональности, а последний для стабилизации продукта и выпуска версии. При таком подходе разработка проекта будет использовать плюсы TM контракта — быстрое начало проекта и лёгкость изменения объёма работ под требования рынка, и плюсы FP контракта — выпуск версий без багов (potentially shippable product).
Выводы
Так какой же контракт выбрать TM или FP? Однозначного ответа нет. Закрытость FP проекта от момента размещения заказа и до момента его полной реализации, предполагает полную уверенность заказчика в правильности своего взгляда на продукт. В то же время TM контракт позволяет делать процесс разработки прозрачным, эффективным и управляемым. И если заказчик замечает слабые места в проекте, то он может вовремя отклонится от первоначального плана и не тратить время и деньги для реализации ошибочного подхода. Однако, иногда некоторая неоптимальность продукта допустима в отличие от риска не вложится в бюджет. Поэтому, выбирая между типами контрактов, думайте сразу о всех составляющих — бюджет, время, конечный результат.
