Договор на разработку ПО: подводные камни для заказчика и студии

Договор на разработку ПО: подводные камни для заказчика и студии

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

Ключевые выводы:

• ТЗ — это юридический документ, а не просто «вводные от продакта»
• Приёмка ПО без чётких критериев = вечный спор о «готовности»
• Права на интеллектуальную собственность не переходят автоматически
• Гарантийные обязательства нужно ограничивать заранее, а не после сдачи

Техническое задание как юридически обязывающий документ

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

Если ТЗ не подписано обеими сторонами и не указано в договоре как неотъемлемое приложение — оно юридически ничего не значит. Студия сдаст то, что поняла, заказчик ожидал другого. Кто прав? Никто, потому что договор не даёт ответа.

Что обязательно должно быть в ТЗ с правовой точки зрения:

• Функциональные требования в измеримых формулировках («система обрабатывает не менее X запросов в секунду», а не «работает быстро»)
• Технический стек — хотя бы рамочно, если он критичен для заказчика
• Среда эксплуатации: браузеры, ОС, мобильные платформы
• Что явно выходит за рамки объёма работ (out of scope)
• Порядок согласования изменений — без этого любое «а давайте добавим» превращается в бесплатную работу для студии или в претензию от заказчика

Три модели договора: что выбрать

Советую сразу прописывать в договоре механизм change request: любое изменение объёма — письменный запрос, оценка студии, акцепт заказчика. Без этого студии работают бесплатно, а заказчики платят за то, чего не просили.

Приёмка ПО: где ломается большинство договоров

Приёмка ПО — самый конфликтный этап. Типичная формулировка «заказчик принимает работы в течение N дней» без критериев приёмки — это мина замедленного действия.

Ошибки заказчика:

• Затягивание приёмки без письменных мотивированных возражений (в большинстве правовых систем молчание после истечения срока = принятие)
• Отсутствие тест-плана или чеклиста приёмки — спор о том, «баг это или фича», будет бесконечным
• Приёмка частями без фиксации того, что именно принято

Ошибки студии:

• Сдача без акта и подписи — устное «ок, работает» не защищает
• Отсутствие протокола тестирования как приложения к акту
• Нечёткий порядок устранения замечаний: сколько итераций, за чей счёт, в какие сроки

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

Интеллектуальная собственность: кому принадлежит код

По умолчанию в большинстве юрисдикций права на созданный код остаются у автора — то есть у разработчиков студии. Заказчик получает лицензию на использование, но не становится правообладателем.

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

Отдельный вопрос — open-source компоненты. Если в продукте используются библиотеки с лицензиями типа GPL, это может ограничить коммерческое использование. Студия обязана раскрывать состав используемых компонентов — зафиксируйте это требование в договоре.

Гарантии и ответственность: как не платить дважды

Гарантийный период — ещё одна точка конфликта. Заказчики хотят бесконечную гарантию, студии — никакой. Разумный компромисс: чётко определённый период (обычно несколько месяцев после приёмки) с конкретным перечнем того, что покрывается гарантией.

Гарантия должна распространяться на дефекты, существовавшие на момент сдачи, но не на:

• Изменения, внесённые заказчиком или третьими лицами
• Проблемы, вызванные изменением окружения (обновление ОС, API партнёров)
• Новые требования, которых не было в ТЗ

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

Что сделать на этой неделе

• [ ] Проверить, подписано ли ТЗ как приложение к договору
• [ ] Добавить критерии приёмки: что считается «готово», кто подписывает акт, в какой срок
• [ ] Прописать механизм change request для изменений объёма
• [ ] Уточнить, кому переходят права на код и когда именно
• [ ] Зафиксировать гарантийный период и его границы
• [ ] Проверить наличие пункта об ограничении ответственности

FAQ

Можно ли работать без договора, только по переписке?

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

Что делать, если заказчик не подписывает акт приёмки и не даёт письменных возражений?

Если в договоре прописан срок приёмки и последствия его нарушения (например, «при отсутствии мотивированного отказа работы считаются принятыми»), студия может ссылаться на это. Без такой формулировки — судебный спор с неопределённым исходом.

Нужно ли нотариально заверять договор на разработку ПО?

В большинстве случаев — нет. Простая письменная форма с подписями достаточна. Уточните требования своей юрисдикции, если сделка крупная или трансграничная.

Что такое escrow исходного кода и когда это нужно?

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

Как юридически оформить доработки после сдачи проекта?

Лучший вариант — дополнительное соглашение (допсоглашение) к основному договору с новым ТЗ и стоимостью. Устные договорённости о доработках — гарантированный источник будущих споров.

---

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

Если хотите проверить действующий договор на разработку или подготовить шаблон под ваш проект — запишитесь на консультацию. Мы в Pactum специализируемся именно на IT-договорах и знаем, где обычно прячутся проблемы.