Фраза «разработчик сделает сайт» почти не защищает заказчика. Не дает достаточной ясности и обещание «исполнитель передаст все права». При споре суд будет смотреть не на общие ожидания из переписки, а на согласованные условия: какой результат должен быть создан, когда он считается принятым, кому принадлежат исключительные права, какие компоненты можно использовать и что происходит при нарушении сроков.
В IT-проекте договор — не формальность, которую подписывают после согласования бюджета. Он определяет порядок работы с продуктом, доступами, изменениями и интеллектуальной собственностью. Далее речь идет преимущественно о российском праве. В трансграничных проектах отдельно нужно проверять применимое право, подсудность, валютные и санкционные ограничения.
Начинать нужно с правильной договорной конструкции
Название документа само по себе не решает спор, однако выбранная конструкция влияет на обязанности и риски сторон. Разработку на заказ часто оформляют договором подряда, оказания услуг или смешанным договором. Если создаются программное обеспечение, интерфейс, документация либо иной охраноспособный результат, особое внимание нужно уделить интеллектуальным правам.
Для регулярной технической поддержки, администрирования инфраструктуры, консультаций или работы выделенной команды обычно требуются условия об услугах и уровне сервиса. Для доступа к готовой платформе подходит лицензионная модель или договор SaaS. Один короткий шаблон для разработки, внедрения, поддержки и лицензирования часто порождает противоречия. Например, договор обещает «передачу прав» на продукт, в котором используются сторонние сервисы и компоненты с открытым исходным кодом.
Зафиксируйте предмет через измеримый результат
Предмет договора должен позволять отличить выполненную работу от процесса работы. Вместо формулировки «разработать CRM-систему» лучше определить состав модулей, роли пользователей, интеграции, поддерживаемые браузеры и платформы, требования к производительности, безопасности и документации.
Техническое задание не обязано быть многотомным. Но его статус следует определить прямо: является ли оно приложением к договору, кто вправе менять требования, как согласуются новые версии и с какого момента они становятся обязательными. В гибкой разработке можно описывать бэклог и спринты, но устные договоренности не должны заменять понятную процедуру управления изменениями.
- опишите функциональные и при необходимости нефункциональные требования;
- укажите интеграции, API, внешние сервисы и границы ответственности;
- определите, кто предоставляет доступы, контент, тестовые данные и инфраструктуру;
- разделите проект на этапы, определите результаты каждого этапа и сроки;
- закрепите приоритет документов, если договор, ТЗ, смета и переписка расходятся.
Приемка: точка, где проект превращается в доказуемый результат
Без понятной процедуры приемки заказчик может долго считать продукт «не готовым», а исполнитель — настаивать, что работа завершена. В договоре стоит определить, как передается результат, сколько времени отводится на проверку, в какой форме направляются замечания и какие последствия имеет молчание заказчика.
Критерии приемки должны быть привязаны к ТЗ. Замечания вроде «неудобный интерфейс» трудно оценить, если требования к интерфейсу не были согласованы. Практичнее разделить дефекты по критичности, установить сроки их устранения и отделить ошибки от новых пожеланий. Функция, которой не было в согласованном объеме работ, должна запускать процедуру изменения объема, а не автоматически признаваться дефектом.
Полезная процедура изменения требований
Заявка на изменение особенно важна, если разработка длится больше нескольких недель. В ней фиксируют суть изменения, его влияние на цену и сроки, технические последствия, а также дату, с которой команда приступает к работе. До письменного согласования исполнитель не обязан выполнять дополнительную работу, а заказчик не должен получать счет за неутвержденный объем.
Электронное согласование допустимо, если стороны определили каналы связи и способ подтверждения полномочий. В корпоративных проектах стоит заранее указать адреса электронной почты, аккаунты в системе управления задачами или порядок использования усиленной электронной подписи. Общие правила электронного документооборота нужно соотнести с реальными процессами команды.
Права на код и материалы: не ограничивайтесь одной строкой
Исключительное право на созданный результат не всегда переходит к заказчику автоматически только потому, что разработка оплачена. Условия о правах должны охватывать исходный и объектный код, дизайн, документацию, базы данных, графику, тексты, тесты, технические решения и другие результаты, если они создаются в рамках проекта.
Обычно стороны выбирают одну из трех моделей:
- отчуждение исключительного права — заказчик становится правообладателем в отношении согласованного объема результатов;
- лицензия — исполнитель сохраняет исключительное право, а заказчик получает разрешение использовать продукт определенными способами;
- смешанная модель — уникальная часть передается заказчику, а типовые модули, фреймворки или библиотеки исполнителя предоставляются по лицензии.
Для каждой модели необходимо определить момент перехода права или предоставления лицензии: например, после полной оплаты конкретного этапа и подписания акта. Отдельно оговаривают территорию, срок, способы использования, возможность модификации, передачу прав аффилированным лицам и привлеченным подрядчикам. Если лицензионные условия по российскому праву сформулированы неполно, фактический объем разрешенного использования может оказаться уже, чем стороны предполагали.
Отдельный риск связан с предшествующими разработками исполнителя и компонентами третьих лиц. Исполнитель не может передать то, чем не владеет. Заказчику важно получить перечень таких компонентов, применимые лицензии и сведения об ограничениях. Открытый код требует отдельной инвентаризации: некоторые лицензии предусматривают условия о раскрытии исходного кода при распространении производного продукта.
Гарантии, ответственность и пределы обещаний
Фраза «исполнитель гарантирует отсутствие нарушений прав третьих лиц» выглядит убедительно, но без уточнений мало полезна. Лучше определить, какие гарантии дает исполнитель, какие материалы предоставляет заказчик и кто отвечает за контент, товарные знаки, данные и инструкции заказчика.
Если заказчик передает фотографии, музыку, тексты, брендбук или базу контактов, он обычно подтверждает наличие необходимых прав и законных оснований. Исполнитель, со своей стороны, может гарантировать, что созданная им оригинальная часть результата не нарушает чужих прав в пределах согласованного использования. Порядок работы с претензиями третьих лиц стоит закрепить отдельно: сроки уведомления, право стороны участвовать в защите, предел возмещения и запрет самостоятельно признавать требования без согласования, если это допустимо с учетом обстоятельств.
Ограничение ответственности должно быть соразмерным и не противоречить императивным нормам. На практике стороны устанавливают верхний предел ответственности, исключают упущенную выгоду либо предусматривают ее взыскание только для отдельных нарушений, вводят неустойку за задержку этапа. Однако такая оговорка не дает абсолютной защиты: суд оценивает ее с учетом закона, характера нарушения и конкретных обстоятельств дела.
Конфиденциальность, персональные данные и доступы
NDA полезен, но сам по себе не решает вопрос доступа к рабочим данным. В основном договоре или приложении следует определить, какие сведения считаются конфиденциальными, как долго действует этот режим, кому данные можно передавать внутри проектной команды и какие меры применяются после завершения работ. Это могут быть исходный код, дорожные карты, финансовые условия, учетные данные, клиентские базы и внутренняя аналитика.
Если исполнитель получает персональные данные, необходимо разграничить роли участников обработки, цели, состав данных, разрешенные действия, требования к безопасности, порядок уведомления об инцидентах, возврата или уничтожения данных. Формулы «соблюдать законодательство о персональных данных» недостаточно: для повседневной работы нужны конкретные инструкции и организационные меры.
Доступы лучше выдавать персонально, по принципу минимально необходимых прав, с возможностью быстрого отзыва. В договоре полезно предусмотреть передачу репозиториев, доменов, облачных аккаунтов, ключей API, учетных записей в магазинах приложений и документации. Иначе продукт, формально принадлежащий заказчику, после расторжения договора может оказаться технически недоступным.
Поддержка, SLA и выход из проекта
Разработка не равна дальнейшей эксплуатации. Если продукт требует исправления ошибок, мониторинга, обновлений и реакции на инциденты, эти услуги стоит вынести в отдельный раздел или договор. SLA обычно определяет часы поддержки, каналы обращений, категории критичности, время первого ответа и целевой срок восстановления. Важно отличать обязанность отреагировать от гарантии устранить сложную проблему в конкретный срок: последнее не всегда зависит только от исполнителя.
Не менее важен сценарий прекращения сотрудничества. В нем определяют срок передачи дел, состав материалов, формат экспорта данных, помощь при миграции, оплату переходных работ и порядок отключения доступов. Для критичного сервиса можно заранее установить, что, например, в течение 10 рабочих дней после прекращения договора исполнитель передает по акту актуальный исходный код, инструкции по развертыванию, список зависимостей и административные доступы. Тогда «передача проекта» становится проверяемой обязанностью, а не неопределенным обещанием.
Перед подписанием договора полезно отдельно сверить ТЗ, порядок приемки, права на результаты, перечень сторонних компонентов и сценарий выхода из проекта. Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию: содержание договора зависит от продукта, состава участников, модели использования ПО и применимого права.