Что должно быть в договоре на разработку ПО

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

Ниже — обзор ключевых условий с точки зрения бизнеса. Это не юридическая консультация: итоговый текст договора стоит проверить с юристом.

Какие разделы должны быть в договоре на разработку?

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

Раздел	Что в нём фиксируют	Типичная ошибка
Предмет и объём	Что разрабатывается, ссылка на ТЗ или описание этапов	«Разработка сайта» без описания
Сдача и приёмка	Как проверяется результат, сроки приёмки, что считать готовым	Нет критериев, приёмка «по ощущениям»
Стоимость и оплата	Модель оплаты, этапы, порядок оплаты изменений	Аванс за весь проект
Права на результат	Кому принадлежит код, дизайн, документация	Права остаются у подрядчика по умолчанию
Гарантии и поддержка	Срок исправления ошибок бесплатно, условия поддержки	Гарантии не упомянуты
Конфиденциальность	Какие данные защищаются и как	Нет условий о данных заказчика
Расторжение	Порядок выхода, передача кода и доступов	Нет условий о передаче проекта

Модели оплаты — фиксированную цену и оплату по времени — мы разбирали в статье fixed price или Time & Materials.

Кому принадлежат права на код?

Права на код должны быть явно прописаны в договоре. По общему правилу российского законодательства, исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если договором не предусмотрено иное, — это установлено статьёй 1296 ГК РФ. Но полагаться только на общее правило не стоит: договор должен прямо описывать, что и когда переходит к заказчику.

Что закрепить:

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

Фото: Unsplash

Как описать сдачу и приёмку результата?

Сдачу и приёмку описывают так, чтобы обе стороны одинаково понимали, что считать готовым: результат проверяется по критериям из ТЗ, у заказчика есть конкретный срок на проверку, а замечания оформляются списком. Без этого приёмка превращается в спор, а оплата — в заложника разногласий.

Что указать:

1. Критерии готовности — сценарии и критерии приёмки из ТЗ.
2. Срок на проверку — например, несколько рабочих дней после демонстрации.
3. Порядок замечаний — письменно, списком, с разделением на ошибки и новые пожелания.
4. Что происходит, если заказчик не ответил в срок — результат считается принятым.
5. Как оформляются изменения требований — дополнительным соглашением с оценкой.

Как описывать сценарии и критерии, мы подробно разбирали в статье как написать техническое задание.

Какие условия защищают заказчика?

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

Условия, на которые стоит обратить внимание

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

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

Какой вид договора выбрать?

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

Что учесть при выборе:

• проектная работа с результатом — договор с подробной приёмкой и переходом прав;
• выделенная команда и поддержка — договор услуг с отчётами о работе и переходом прав на созданное;
• рамочный договор — удобен, когда этапов много: общие условия фиксируются один раз;
• налоговые и валютные особенности — если подрядчик в другой стране.

Коротко

• Ключевые условия: объём, приёмка, оплата, права на код, гарантии и расторжение.
• Права на код прописывайте явно, включая передачу исходников и список сторонних лицензий.
• Приёмка — по критериям из ТЗ, с конкретным сроком и письменными замечаниями.
• Защищают заказчика поэтапная оплата, доступы на его стороне, гарантийный срок и порядок передачи проекта.
• Итоговый текст договора проверьте с юристом, особенно при работе с подрядчиком из другой страны.