Договор Time & Material получает все больше и больше признания со стороны предпринимателей, особенно в IT-индустрии. Составление договора T & M лучше поручить юристам, которые специализируются на таких договорах.

С английского договор Time & Material буквально переводится как «договор времени и материалов». Название отражает саму суть такого договора: оплата зависит от того, сколько затрачено времени и ресурсов (материальных, человеческих и других). Вы можете встретить и другие названия этого контракта – «оплата по факту», «почасовая ставка».

Заказать договор Вы можете на нашем сайте по ссылке.

Еще у нас есть подкаст на эту тему «Договор с разработчиком: зачем и какой?» → 
Подпишитесь сейчас, чтобы не потерять.

Иностранные слова в названии не означают, что договор Time & Material не известен российскому праву. Хотя в Гражданском кодексе такое название, действительно, не встречается. На самом деле, такой договор – это разновидность договора возмездного оказания услуг, глава 39 ГК РФ. Поэтому все императивные правила нашего старого доброго договора на услуги относятся и к договору T & M. Обновим их в памяти и будем двигаться дальше (а если вы постоянно читаете наш блог и хорошо усвоили, как регулируются услуги, то переходите сразу за горизонтальную черту):

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

б) по общему правилу, поручать работу кому-то другому (субисполнителю) нельзя.

в) все выплаты в пользу исполнителя облагаются налогами (НДФЛ/ НДС и др.)

г) предоставление всей необходимой информации со стороны заказчика в соответствии с принципом содействия.

_______________________________________________________________________

А теперь – сущность и особенности договора Time & Material.

Если вы вспомните, как в настоящее время структурируются «стандартные» договоры, например, поставка или подряд, вы поймете, что модель иная по сравнению с договором Time & Material. Заключая договор подряда, стороны рассчитывают получить конечный материальный результат – новое здание, отремонтированную дорогу и подобное. Все характеристики объекта фиксируются в техническом задании. Заказчик желает получить результат, полностью соответствующий техническому заданию. Поскольку объект определен и его проектные характеристики не будут изменяться с течением времени, то и цена определяется по принципу «твердой сметы». То есть в таких договорах цена определяется на старте проекта, так как она находится в прямой зависимости от определенного конечного результата, а фактические временные и материальные затраты исполнителя на нее не влияют (влияют только прогнозируемые затраты, оговоренные на старте). Твердая смета может быть изменена только по соглашению сторон. Но в таких случаях очень трудно прийти к консенсусу, так как интересы сторон прямо противоположны. Заказчик не хочет ничего доплачивать, мол, цены итак были выше рынка. Исполнитель же не готов сделать лишнюю работу. Но так как эта работа все-таки необходима, весь проект останавливается на неопределенный срок. Описанная выше модель называется fixed price. Как видите, у нее есть плюс – заказчик четко понимает, что он получит и сколько за это заплатит. Но и минус у этой модели тоже существует – учесть изменения условий, влияющих на проект, очень сложно.

В целом, модель fixed price подходит для «стандартных» договоров, предметом которых является овеществленный результат. Но в XXI веке большую долю рынка занимают «цифровые» сферы: разработка программного обеспечения, мобильных приложений.  Договор на разработку ПО нежелательно структурировать по принципу fixed price. Как указано выше, у fixed price есть две основные особенности: 1) заказчик и исполнитель четко и одинаково представляют себе конечный результат, 2) цена договора находится в прямой зависимости от характеристик этого конечного результата.

Но договор с разработчиком требует куда большей гибкости. Ведь часто заказчик понимает функцию, которую должно выполнять ПО, или проблему, которую оно помогает решить. Но каким в итоге должно быть приложение понять на старте очень трудно. Более того, компьютерные технологии нуждаются в постоянном обновлении. Поэтому зачастую договоры с создателями софта подписываются не только для создания программы, но и для ее обновления. Это влечет длительное сотрудничество сторон, обычно более года. А регулировать такие долгосрочные отношения обычными инструментами очень трудно. Таким образом, на ряду с договорами fixed price возникает договор Time & Material. Он применяется в тех сферах, где договор с фиксированной ценой неэффективен.

Конкретики в вопросе, когда нужно выбрать Time & Material нет. Но в общем подходящими считаются следующие проекты:

— испытание программы

— постоянное обновление уже готового приложения

— «маленькие» проекты: требуется команда до пяти человек, срок проекта – до 6 месяцев

— «масштабные проект»: требуется команда от 25 человек, срок проекта превышает год

Далее подробно расскажем об особенностях договора Time & Material.

1. Итак, первая особенность – объект договора настолько сложен, что сформулировать его характеристики на начальном этапе работы невозможно. Описание продукта выглядит максимально общим образом. Движение к конкретике осуществляется маленькими шажками. «Шажки» — это задачи. На начальном этапе их мало. По мере поступления результатов исследований, круг задач расширяется. К середине проекта большое количество мелких задач уже решено. А к моменту выхода программы в свет мы видим весь спектр задач, которые нужно было решить. В этом смысле работа по договору с разработчиком похожа на то, как растет дерево. Сначала только отросток, потом на нем все больше и больше появляются ветки, и вот перед нами большое дерево с массивной кроной. Вот пример формулировки основной обязанности по договору на разработку ПО. Мы видим, что эта обязанность сформулирована максимально пространно:

2. Размытость договора с разработчиком имеет свои границы. Все-таки примерный план работ у сторон имеется. Он отражается в исходной спецификации. Но ключевой момент здесь – «исходная». В зависимости от внешних условий, действий конкурентов или запросов потребителей в эту спецификацию без проблем могут быть внесены изменения. Это вторая важная особенность договора T & M.

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

Допустимость изменений снимает с исполнителя необходимость закладывать в цену риски, связанные с непредвиденными затратами. Такие риски характерны для fixed price. Причина – цена определяется на старте и не корректируется, даже если в этом появилась нужда (только через процедуру подписания доп.соглашений). Поскольку в договоре Time and Material новые задачи появляются без каких-либо сложностей, то и цена по нему не нагромождается за счет подобных рисков.

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

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

3. В договоре T & M работа поделена на этапы. Но в отличие от обычного подряда здесь этапы гораздо менее продолжительные, так как направлены на решение более узких задач. Поэтому в договоре T and M этапы называются спринтами. Эта третья особенность нашего соглашения.

Результат каждого спринта может быть выражен в наработке, выполняющей отдельно взятую функцию в будущей программе. По итогам каждого спринта подписывается акт приемки услуг. Подписание такого акта означает, что разработчик передал объект интеллектуальной собственности заказчику, а последний должен заплатить за него. После этого заказчик получает реальный доступ к функции ПО, например через Облако. Есть второй вариант: заказчик не получает доступ к наработкам после спринтов, а ПО передается после завершения проекта и подписания итогового акта приема-передачи. Но для заказчика это не выгодный вариант, так как сроки в договоре T and M «плавающие», и неизвестно когда проект будет успешно завершен.

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

4. Означает ли все это, что заказчик никогда не знает, сколько он должен платить по договору с разработчиком? Переходим к четвертой особенности договора Time & Material – отсутствие фиксированной оплаты. На практике подписываются договоры на разработку ПО с почасовой оплатой. Стоимость часа оговаривается с самого начала. Чтобы устранить неопределенность в вопросе оплаты, разработчик перед каждым спринтом обязан информировать заказчика о том, сколько часов ему понадобится для выполнения каждой конкретной задачи. Определить временные затраты разработчику помогут time-tracking-приложения. За этот лимит, по общему правилу, выходить нельзя. Иначе сложилась бы невыгодная для заказчика ситуация: исполнитель специально затягивает время, чтоб получить побольше денег. Но можно предусмотреть более гибкий вариант. Например, отразить в договоре максимальное количество часов, на которые может отклониться исполнитель. Вся эта процедура называется прогнозированием часов.

Еще одна деталь – это изменение стоимости часа. Обыкновенная ситуация – сотруднику IT-компании, который задействован в проекте, поднимают зарплату. Так уж сложилось в бизнес-среде, что, как правило, повышение зарплаты ударит по карману заказчика. Но это лишь общее правило: в договоре можно переложить этот риск на самого разработчика. Кроме того, заказчик еще перед началом следующего спринта узнает о повышении цены часа. Такое изменение декларируется в прогнозных часах. Если заказчик не готов к росту цены, то вопрос можно решить многочисленными способами. Например, распределить повышение зарплаты между сторонами (50 % — заказчик, 50 % — подрядчик) или заменить сотрудника.

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

5. Поскольку оплата по договору Time & Material зависит от затраченного времени, нужно четко фиксировать часы – это пятая особенность нашего договора. Форма фиксация произвольная и обычно является приложением к договору. Но есть позиции, которые обязательно должны быть отражены в вашей таблице. Во-первых, это перечень работ, другими словами комплекс задач, необходимый для реализации проекта. Второе – список специалистов, которые будут трудиться над проектом. И третье – отразить, сколько времени потратил каждый сотрудник. Ставка оплаты у каждого сотрудника может быть своя. Умножив количество часов на почасовую ставку, получим стоимость услуг разработчика за конкретный период.

Очевидно, что при такой модели заказчик платит только за «эффективные» часы. Мы привыкли, что по трудовому договору оплачиваются все часы с 09:00 до 18:00. Даже те, когда работник никакую полезную для работодателя функцию не выполнял. Здесь же стороны подсчитывают, сколько часов потратил бы квалифицированный сотрудник на выполнение спринта. Время на «попить чаек» сюда не входит.

Но закручивать гайки в отношении программистов, чтобы стимулировать их работать интенсивней, не стоит. Немалую роль в успехе всего проекта играют заинтересованные, увлеченные и не «загнанные» сотрудники. Лучше включить в контракт пункт, запрещающий исполнителю привлекать членов команды, работающих над проектом, к другой работе. Так работник все свое рабочее время потратит на Ваш проект, что сократит итоговые сроки создания программы.

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

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

Договоры на разработку ПО с почасовой оплатой в большинстве своем заключают те заказчики, которые заинтересованы в качестве продукта. С одной стороны, новшества нужны для повышения качества продукта и конкуренции с другими производителями. С другой стороны, эти новшества нужно будет дополнительно оплатить. И каждый раз нужно будет положить на чаши весов одно и другое, и все-таки выбрать какой-то вариант. Отсюда шестая особенность — договор T & M стимулирует заказчиков детально обдумывать планируемые задачи и изменения. Поскольку и заказчик, и исполнитель вовлечены в процесс создания программы, можно заранее утверждать, что результат превзойдет все ожидания. Эта особенность выгодно отличает Time & Material от fixed price.

_______________________________________________________________________

Некой альтернативой сразу двум подходам Time & Material и fixed price выступает fixed budget. Такой проект является двухэтапным. Первый этап нацелен на разработку ядра проекта. Он структурируется по принципу fixed price. Ядро проекта описывается достаточно четко, возможность внесения изменений почти отсутствует. Фиксируются сроки разработки этого «ядра». И самое главное – оплата будет фиксированной. Таким образом, заказчик быстро получает квази-конечный продукт, который на начальном этапе будет смотреться достаточно неплохо. Но чтобы поддерживать конкурентоспособность в долгосрочной перспективе, надо переходить к этапу номер 2. На втором этапе fixed price уступает место T & M. Разработчик формирует команду, чтобы осуществлять техническую поддержку программы, постоянно обновлять и корректировать ее работу. В итоге качество приложения растет. Пользователи оценивают, что их рекомендации учитываются. При этом, заказчик платит только за «эффективные» часы. Таким образом, fixed budget учитывает плюсы ранее рассмотренных подходов и может служить хорошим способом структурирования договоров в сфере IT.

В заключение хотелось бы сформулировать основные выводы по рассмотренной модели контракта. Именно выводы, а не пресловутые «плюсы» и «минусы». Ведь что кажется невыгодной одной стороне, для другой стороны представляется преимуществом. Самое главное – соблюсти баланс, чтобы сотрудничество было взаимовыгодным:

— по договору Time & Material вы платите не за итоговый результат, как в fixed price, а за согласованные затраты времени и материальных ресурсов. Поэтому риски недостижения конечного результата лежат на заказчике.

 — по статистике, цена по договору T & M в несколько раз меньше, чем по модели fixed price.

— выбор модели зависит от конкретного проекта: используйте T & M там, где fixed price неэффективен.

— модель T & M придаст проекту гибкость и актуальность.

— немалую часть в сотрудничестве по модели T & M занимает доверие сторон друг к другу. Но не в том смысле, что такой договор заключается только между контрагентами, которые доверяют друг другу. Скорее, результатом сотрудничества по принципу Time & Material становится взаимное уважение и доверие сторон. Заказчик, получивший хорошее приложение, придет еще и еще.

— заключать договоры T & M выгодно с начинающими разработчиками либо с IT-компаниями, не потерявшими умение ценить и, в хорошем смысле, «охотиться» на клиента. Стартапы стремятся зарекомендовать себя на рынке и создать безупречную репутацию. Такие компании не будут «накручивать» часы или завышать их стоимость.

— не только договор на разработку ПО можно структурировать по типу договора T & M. Удобно заключать такие сделки с целью правового (юридического) сопровождения проектов и в других сферах бизнеса.

— альтернативой T & M и fixed price считается fixed budget. По этой модели можно структурировать проекты от самого начала и до функционирования приложения на рынке, включая тех.поддержку и постоянные обновления.

Мы рады создавать для Вашего бизнеса удобные инструменты работы. Обратившись к нам за составлением контракта  Time & Material, вы получите качественный документ в короткие сроки и по выгодной цене. На основании специально разработанной нашими юристами анкеты мы детально выясним ваше видение будущих отношений с заказчиком/ исполнителем. Все Ваши рекомендации будут услышаны и увидены. Мы работаем в онлайн-формате, поэтому наши услуги доступны не только в Москве, но и по все России.