Заключение договоров с подрядчиками

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

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

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

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

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

Существенными условиями договора подряда, без которого он будет признан незаключенным являются:

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

Важно проверить, что заключаемый договор содержит договоренности сторон по этим вопросам.

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

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

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

Существует и иной способ оформления отношений с подрядчиком — заключение договора возмездного оказания услуг.

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

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

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

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

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

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

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

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

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

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

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

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