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

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

Если на рынке нет готового программного продукта, который покрывают нужды клиента, нужно заказывать разработку уникального софта

Если на рынке нет готового программного продукта, который покрывают нужды клиента, нужно заказывать разработку уникального софта

Как минимизировать риски в процессе исполнения обязательств и сделать сотрудничество сторон максимально комфортным?

 

Юридические конструкции при создании договора на разработку программного обеспечения

Договор на создание программного продукта может быть сконструирован в двух вариантах:

  • по модели договора подряда;
  • по модели договора оказания услуг.

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

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

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

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

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

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

Если разработка программного продукта – длительный процесс (а чаще всего так и бывает), разумно составить календарный план

Если разработка программного продукта – длительный процесс (а чаще всего так и бывает), разумно составить календарный план

Договор оказания услуг

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

На старте не всегда можно в полной мере сформулировать характеристики и функционал готового проекта

На старте не всегда можно в полной мере сформулировать характеристики и функционал готового проекта

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

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

Можно ли как-то минимизировать финансовые риски? Одним из вариантов решения этой проблемы является установление предельной величины вознаграждения исполнителя.

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

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

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

Как это происходит на практике?

В действительности все складывается не так просто. Схема может быть следующей.

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

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

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

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

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

Если в проект вносились изменения, которые были даны устно, заказчик может не принять работу

Если в проект вносились изменения, которые были даны устно, заказчик может не принять работу

Какой можно сделать вывод?

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

Как распределяются права на разработанное программное обеспечение?

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

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

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

Передача исключительного права на программное обеспечение

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

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

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

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

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

Читайте также:

Напишите нам и наши специалисты обязательно с Вами свяжутся!

Контактные данные
не будут переданы третьим лицам

Спасибо за заявку! Мы обязательно с Вами свяжемся.
Спасибо за вопрос! Мы свяжемся с вами в ближайшее время.

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

Принять