Распространенные ошибки в договорах на разработку ПО

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

Не понятно, что разрабатывается

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

Не определен порядок работы

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

Выполнение работы силами субподрядчиков

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

Непонятно определена стоимость работ

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

Некорректно указаны сроки

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

Отсутствие регулирования дополнительных работ

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

Отсутствие порядка действий в особых ситуациях

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

Отсутствие порядка приемки результата

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

Переход прав на объекты интеллектуальной собственности

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

Отсутствие условия по работе с персональными данными

Если заказчик в рамках проекта передает исполнителю персональные данные (например, базу данных) либо предоставляет к ним доступ – в договоре с таким исполнителем должны быть указаны условия из ст. 7 Закона «О защите персональных данных». При отсутствии этих условий увеличивается риск утечек.

Не включены пункты про ответственность

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

Не определен порядок обмена документами

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

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

Статья актуальна по состоянию на 24 ноября 2023 года.