Договор Time & Material

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

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

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

Чем качественнее договор, тем меньше вероятность оказаться в суде по спору с разработчиком.

Виды договоров с разработчиками ПО:

1. Договор оказания услуг по разработке программного обеспечения.

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

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

При заключении договора на услуги с физическим лицом или индивидуальным предпринимателем помните о рисках переквалификации такого договора в трудовой.

>>> Как выиграть спор о признании договора трудовым?

2. Договор Time&Material.

По своей сути, договор T&M – разновидность договора оказания услуг. Почвой для появления этого особого договора послужили проекты в сфере IT, для которых на начальном этапе невозможно определить точный перечень задач. В целом, выделяют четыре случая, когда договор Time&Material будет оптимальной моделью для работы над программным обеспечением: 1) проект направлен на испытание программы, 2) договор заключается с целью обновления ПО на постоянной основе, 3) мини-проекты, рассчитанные на команду из 2 – 5 человек, со сроком выполнения до полугода, 4) напротив, проекты-гиганты, рассчитанные на команду минимум из 25 человек, со сроком выполнения более года.

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

>>> Заказать разработку договора Time&Material

3. Договор подряда.

От услуг этот договор отличается наличием овеществленного результата. В сфере IT обнаружить овеществленный результат крайне трудно. Максимум –  информационный носитель. Но очевидно, что сама по себе флешка или диск не представляют ценности для заказчика. Однако и стороны, и суды используют «подрядные» формулировки. Это абсолютно правомерно, так как закон прямо допускает смешанные договоры (услуги + подряд). Если это делает отношения сторон более понятными, почему нет?

4. Лицензионный договор.

Данный договор регулирует вопросы передачи исключительного (интеллектуального) права на ПО. Сама программа разрабатывается по вышеперечисленным соглашениям. В некоторых случаях договор на услуги и лицензионный договор идут в связке. Например, в деле № А40-45539/2013 IT-компания разрешила использовать свое ПО заказчику по лицензионному договору, а также обязалась внедрить это ПО в систему заказчика. Суды квалифицировали эту связку как договор на разработку нового ПО путем переработки исходного. Важный вывод из этого дела: передача прав на продукт по лицензии не считается состоявшейся без передачи самого продукта. Поэтому заказчику удалось взыскать с разработчика аванс.

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

На практике встречаются различные названия договоров на разработку ПО, даже сам их текст иногда не содержит слово «услуги» (к примеру, «договор на внедрение информационной системы»). Но все они по своей сути, квалифицируются как договоры возмездного оказания услуг (гл. 39 ГК РФ) или подряда (гл. 37 ГК РФ). Например, Арбитражный суд г. Москвы рассматривал спор из договора, по которому «продавец обязуется передать в собственность Комплект Системы, а также право на пользование сервисом «Горячая Линия», а Покупатель обязуется принять этот Комплект Системы и оплатить в соответствии с условиями настоящего Договора». Суд подчеркнул, что собственность – это последнее, что могут придумать заказчик разработчик; договор на самом деле представляет собой договор на информационные услуги.

Если стороны не потрудились заключить письменный договор, то их будущие отношения по поводу создания программы будут регулироваться непосредственно Гражданским кодексом РФ. А если соглашение подписано, то положения Гражданского кодекса будут применяться к вашим отношениям только в той части, в которой они не урегулированы договором. В силу прямой нормы закона к услугам применяются правила о подряде (ст. 702 – 729, ст. 779- 782 ГК РФ). Если по какой-то причине заказчик и разработчик не заключают письменный договор, они должны иметь в виду, что закон допускает немотивированный отказ от договора услуг как со стороны заказчика, так и со стороны разработчика. Договором нельзя лишить этого права, но можно регламентировать порядок и сроки отказа, определить размер убытков за отказ от контракта. Закон также предполагает личное исполнение договора разработчиком; в то время как на практике используются договоры с правом привлечения субисполнителей. Кроме того, закон закрепляет обязанность заказчика предоставить всю необходимую документацию для создания ПО. В данном случае формулировка «вся необходимая информация» является крайне неопределенной, а разработчик может воспользоваться ей, чтоб максимальной продлить срок выполнения заказа. В договоре можно прямо перечислить, какие сведения понадобятся заказчику, тем самым исключить подобные риски.

Акт приемки

При избрании любого договора фактическое выполнение задания подтверждается отдельным документом – акт приемки. Заказчик подписывает этот важнейший документ только в том случае, если его полностью устраивает программа. Если в ПО есть недочеты, то акт возвращается разработчику неподписанным вместе с письмом, где изложен мотивированный отказ от подписания акта. Неправильный вариант действий со стороны заказчика: проигнорировать акт, то есть не направить мотивированный отказ от подписания. Обычно в договоры включается пункт по поводу последствий неподписания акта, например: «если по истечении N дней от заказчика не поступило мотивированного отказа от подписания акта, услуги считаются оказанными в полном объёме с надлежащим качеством». Даже если такой пункт не включен в договор, суды придерживаются того же мнения: бывает достаточно доказать, что акт направлен заказчику по правильному адресу.

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

Однако даже при наличии подписанного акта заказчик может доказывать суду, что услуги оказаны в меньшем объеме, чем зафиксировано в акте (п. 12 Информационного письма ВАС № 51 от 24.01.2000).

Претензия к разработчику

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

Если между сторонами нет письменного договора или их договор не регламентирует вопросы разрешения споров, то необходимо руководствоваться нормой закона: претензия направляется по юридическому адресу контрагента заказным письмом; срок ответа на претензию – 30 календарных дней с момента ее направления.

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

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

Отказ от договора с разработчиком

Договор оказания услуг дает право любой стороне на безусловный и немотивированный отказ от его исполнения. Единственное условие – другой стороне возмещаются все ее затраты на исполнение договора. Закон запрещает включать в такие договоры условия о недопустимости одностороннего отказа или устанавливать штраф за отказ. Но допускается устанавливать в договоре денежную компенсацию за отказ (п. 3 ст. 310 ГК РФ).

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

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

Иски разработчиков и заказчиков: вариации судебных споров

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

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

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

Обиженные партнеры IT-компаний уже накопили кое-какой опыт. Наши юристы проанализировали споры в этой области и готовы дать несколько советов, как выиграть суд с разработчиком.

1. Активная позиция заказчика

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

На случай пассивного поведения стороны в АПК РФ есть п. 3.1 ст.70: если одна сторона ссылается на определенные факты, а вторая сторона ничего не высказывает против этих фактов, то они считаются признанными.

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

Иначе получится, как в деле № А07-4176/2019. Разработчик вышел с иском об оплате  лендинга для сайта. В качестве доказательства выполненных работ он представил неподписанный заказчиком акт, который однако последним получен. Заказчик не явился ни в одно судебное заседание и даже не потрудился написать коротенький отзыв. В результате суд полностью удовлетворил иск программистов, расценив процессуальное бездействие заказчика как признание обстоятельств дела.

2. Настаивайте на экспертизе некачественного ПО

Экспертиза – почти единственный способ отыскать правду, так как судьи и представители – это правоведы, а не специалисты в сфере IT.

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

>>> Как составить качественное ходатайство об экспертизе в арбитраж?

Ходатайство нужно заявлять своевременно и в соответствии со всеми процессуальными требованиями. Иначе в его удовлетворении могут отказать, сочтя позднее заявление ходатайства, да еще и без согласия эксперта и  внесения денег на депозит, затягиванием судебного процесса (дело № А47-17870/2019).

Для начала нужно определить, какие вопросы задать эксперту. Вопросы должны касаться сути спора, то есть качества ПО. В то же время, нельзя ставить перед экспертом вопросы права, к примеру «оказал ли разработчик услуги надлежащим образом?».

Примеры вопросов можно увидеть в деле № А57-4773/2020, которое разрешилось в пользу заказчика благодаря экспертному заключению:

– Установить, пригоден ли для использования по назначению в соответствии с условиями договора и техническим заданием функционал программного продукта?

– Соответствует ли результат выполненных работ условиям договора, а также требованиям норм и правил, описанным в техническом задании?

– Каковы объем и стоимость качественно выполненных разработчиком  работ в соответствии с условиями договора?

– Имеет ли потребительскую ценность для заказчика результат выполненных работ и возможно ли его дальнейшее использование?

В деле № А40-91171/2015 исход тоже определила экспертиза. Разработчик вплоть до кассации пытался оправдать свои разработки по двум этапам и просил заплатить хотя бы за них. Но эксперт заключил, что объем выполненных работ лишь 23,4%, но программное обеспечение не способно корректно выполнять операции. Поэтому внесенный заказчиком аванс был полностью ему возвращен.

3. Доказывайте, что отдельные этапы выполнения разработки не имеют потребительской ценности для заказчика

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

В деле № А40-121450/2016 суды неправильно истолковали договор на разработку сайта и пришли к неверному выводу о необходимости оплаты каждого этапа. Московская кассация отправила дело на пересмотр, обязав суды провести экспертизу по делу, чтобы установить, имеет ли часть работ потребительскую ценность для заказчика. Другими словами, можно ли использовать результат выполненных исполнителем работ вне результата работ, на достижение которого был направлен договор в целом. К слову, это дело завершилось победой разработчика тоже благодаря экспертизе, которая установила, что эскизы страниц, дизайн-макеты и верстка сайта могут быть использованы заказчиком, хотя только с привлечение другого IT-специалиста.

4. Используйте нестандартные доказательства.

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

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

Можно заявить об обеспечении доказательств судом (ст. 72 АПК РФ). Это требуется в тех случаях, когда контрагент после подачи иска в суд может внести изменения в программу или удалить ее. Суд своим определением запрещает разработчику совершать такие действия. Если запрет будет нарушен, то это будет расцениваться против разработчика.

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

Договор 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, вы получите качественный документ в короткие сроки и по выгодной цене. На основании специально разработанной нашими юристами анкеты мы детально выясним ваше видение будущих отношений с заказчиком/ исполнителем. Все Ваши рекомендации будут услышаны и увидены. Мы работаем в онлайн-формате, поэтому наши услуги доступны не только в Москве, но и по все России.