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

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

Как мы работали по контрактам с фиксированной стоимостью

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

В тот период мы только начинали погружение в мир IT‑бизнеса и делали достаточно стандартизированные вещи. Поэтому работа по контрактам с фиксированной ценой была идеальным решением:

• Наши Заказчики четко понимали, каков бюджет проекта

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

Однако уже в проектах по созданию продуктовых конструкторов для маркетплейсов и мы, и наши Заказчики стали замечать недостатки данной бизнес‑модели.

В частности, участились случаи вариативности решений, но модель не позволяла быстро реагировать на изменения в проекте. Гибкость практически отсутствовала.

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

Хуже обстояли дела, когда нужно было произвести замену по внутреннему функционалу или интерфейсу, и при этом изначальная и новая задачи отличались по трудоемкости выполнения. Соответственно, нужно было делать пересчет проекта. И объяснять заказчику, почему стоимость увеличилась при замене одной задачи на другую. (Дело в том, что кажется, что, фраза «фиксированная цена» должна означать гарантию отсутствия каких‑либо изменений в стоимости проекта. Поэтому, естественно, психологически некомфортно узнать, что, заменяя одну функцию на другую, необходимо доплатить. Возникает ситуация как в анекдоте: ложечки то мы нашли, а вот осадочек все‑равно остался.)

Ну и, наконец, по мере того, как проекты, которые мы брали на разработку, укрупнялись и усложнялись, Заказчики стали высказывать заинтересованность в возможности мониторинга над проектом, получения контроля над процессом работы над проекта.

К сожалению, работа по контрактам с фиксированной стоимостью не предоставляла Заказчикам желаемых возможностей.

Оплата по фактически затраченному времени: как работаем теперь

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

Как следует из названия, контракт с оплатой по фактически затраченному времени означает выполнение работ на условиях почасовой оплаты. Работая по контрактам с почасовой оплатой, у нас получилось обеспечить Заказчикам следующее.

Гибкость в отношении возможности внесений изменений в проект.

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

Данная бизнес‑модель идеально вписывается в agile‑подход, реализуемый у нас в компании, с его спринтами, многочисленными итерациями, и брифингами:

• Накидали задач

• Приоритизировали задачи на текущую неделю

• И сосредоточились на их выполнении

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

Прозрачность и полнота контроля.

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

1. Прописываем в договоре максимальное количество человеко‑часов в неделю.

2. Реализуем практику трекинга времени и ежедневных отчетов.

Наличие в договоре оговорки о максимальном количестве человеко‑часов в неделю дает Заказчику возможность определить потолок его ежемесячных расходов на проект.

С ежедневными отчетами Заказчики не только могут увидеть, сколько времени было затрачено сегодня на работу над их проектом, но и какие задачи были выполнены, какие шаги предприняты и т. д. То есть, ко всем преимуществам прозрачности добавляется еще для Заказчиков и возможность держать руку на пульсе.

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

Ну и, вместо заключения, следует отметить, что при крупных проектах нередки случаи, когда Заказчик выигрывает финансово при отказе от работы по фиксированной стоимости и переходе на почасовую оплату. Как минимум, в результате того, что ему не приходится оплачивать риски, закладываемые при расчете проекта на условиях фиксированной стоимости ????.