Time and Material, Fixed Price, Fixed Budget: процесс работы, риски и ограничения при различных моделях оплаты

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

Перед клиентом, отдающим проект в разработку, встает вопрос: на чем остановить свой выбор — Time and Material (почасовая оплата), Fixed Price или Fixed Budget (тут стоит отметить, что альтернативы, конечно, имеются, но мы сосредоточимся на этих трех моделях, т.к. они не только являются самыми популярными, но и имеют много преимуществ)?
 
Этот вопрос актуален не только для заказчиков — для нас, разработчиков, он также имеет огромное значение. Почему?

Для нас способ оплаты определяет то, каким образом будет построен весь процесс разработки (а также процесс коммуникации), насколько свободно будут вноситься изменения, сможет ли сам клиент что-то менять в спецификации (или просто это будет сделать или нет), будут ли сжатыми сроки проекта и т.д.
 
А теперь рассмотрим Fixed Price, Time and Material и Fixed Budget с точки зрения распределения рисков и наличия различных ограничений.

 
Fixed Price
 
Модель Fixed Price в каком-то смысле довольно специфична. Она подразумевает полную оценку всех необходимых работ по проекту исходя из технического задания (ТЗ), предоставленного клиентом.

Устанавливаются цена за проект и сроки, за который он будет сделан. Заказчик получает своего рода гарантию, что его проект будет сделан к указанному времени и за определенную цену. Все это, безусловно, делает для клиента данную модель весьма привлекательным и удобным вариантом.
 
Так как правильно подсчитать весь объем работы (масштаб), рассчитать время (даже приблизительное), необходимое не просто для каждого этапа создания продукта, но и для каждой задачи (!) — вещь, мягко говоря, не простая, то тут на первый план выходит спецификация, предоставляемая заказчиком.

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

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

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

 
Time and Material
 
Time and Material (TM) означает почасовую работу оплаты нанятых специалистов по принципу “you pay as we go”.

Оценка объема работ, масштаба проекта и сроков его завершения проводится, но приблизительная, так при TM часто происходят различные изменения, а главным становится конечный результат и его качество, а не время и цена, в которые необходимо уложиться любыми средствами. Это и определяет его преимущества перед другими способами оплаты (в частности, Fixed Price).
 
Отсутствует контракт с установленной ценой, границ которой нельзя (или очень, очень нежелательно) пресекать, так как любые изменения в спецификации, увеличение объема работы (например, ввиду реализации новых функций) неизбежно приведут к изменению контракта и поднятию цены, что не прибавляет оптимизма.

Также при Time and Material нет строгих дедлайнов, так как главным при ней является нацеленность на лучший результат.
 
Таким образом, на команду разработчиков нет такого давления, как при модели Fixed Price. Растет их мотивация везде искать самое эффективное решение.

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

 
Когда Time and Material будет эффективным решением:
 

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

 
Таким образом, TM определяют нацеленность на лучший результат (практически всегда дает лучший продукт), готовность к изменениям, гибкость рабочего процесса и прозрачная коммуникация.

 
Fixed Budget
 

Fixed Budget — отличная альтернатива Time and Material и Fixed Price, некий усредненный вариант этих двух моделей.

При данном способе оплаты заказчик определяет бюджет и расставляет приоритеты, предоставляя разработчикам максимально подробную спецификацию. Исходя из полученной информации они говорят, что можно сделать за указанную цену и когда будет готов результат.
 
Разработка продукта с минимальным функционалом (minimum viable product — MVP) как раз происходит при модели Fixed Budget. Суть MVP в том, что запуск приложения происходит максимально быстро, с экономией средств и ресурсов.

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

Таким образом, клиент гарантированно получает качественное приложение за короткий срок, c возможностью протестировать его в действии (в том числе и на пользователях) и развивать продукт далее (при желании или необходимости). Модель Fixed Budget особенно эффективна в тех случаях, когда нужно как можно раньше выпустить приложение.
 
Следует отметить, что при Fixed Budget объем работ может меняться в зависимости от приоритетов, выставляемых заказчиком.
 
Главными преимуществами данной модели является то, что заказчик всегда знает, за какое время будет сделан проект, за какую цену (которую устанавливает он), а также то, что он получит качественное рабочее решение.
 
Теперь вы знаете, какие существуют модели оплаты, в чем их преимущества и недостатки. Часто бывает так, что какие-то компании привыкли работать по конкретной из них, но, тем не менее, для каких-то проектов лучше остановиться на чем-то ином. Мы же всегда готовы помочь вам определиться с выбором.