Главная › Проверка договоров › Договор на разработку ПО и IT-услуги
Проверка договора на разработку ПО и IT-услуги
В разработке ПО спорят о двух вещах: принят ли результат и кому принадлежат права на код. Проверка договора показывает, сформулированы ли требования измеримо, как проходит приёмка и что именно заказчик получает по завершении проекта.
Необходимо заказчикам разработки сайтов, мобильных приложений, внутренних систем и интеграций, а также студиям и командам разработчиков, работающим по этапам и с предоплатой.
Проверьте свой договор за 2 минуты
Сервис найдёт невыгодные условия и подготовит протокол разногласий в .docx. Первый договор до 12 страниц — бесплатно.
Типовые ловушки договор на разработку по и it-услуги
1. Требования к результату описаны без критериев приёмки
Формулировка «разработать сайт согласно пожеланиям заказчика» не даёт ни объёма, ни критериев готовности, поэтому спор о приёмке превращается в спор о вкусах. Закрепите техническое задание как приложение, перечень функций, требования к производительности и совместимости, а также порядок изменения объёма через письменные запросы на изменения.
2. Приёмка с автоматическим принятием по молчанию
Пункт «если заказчик не подписал акт в течение трёх рабочих дней, работы считаются принятыми» не позволяет протестировать систему и собрать замечания. Установите срок приёмки, порядок проведения тестирования, форму реестра замечаний, разделение критичных и некритичных дефектов и правило, что некритичные дефекты не препятствуют приёмке с их последующим устранением в срок.
3. Права на код передаются не полностью
Если передаётся только право использования, а исключительное право остаётся у исполнителя, заказчик не сможет дорабатывать продукт силами другой команды и рискует зависимостью от подрядчика. Укажите переход исключительного права в полном объёме либо лицензию с правом доработки, перечень передаваемых компонентов, включая библиотеки и графику, и порядок передачи исходного кода и документации.
4. Отсутствие условий о доступах, инфраструктуре и данных
Без регламента доступов исполнитель размещает проект на своих аккаунтах, использует свои домены и серверы, а при конфликте заказчик теряет и код, и данные. Пропишите, на чьих ресурсах ведётся разработка, кто владеет доменом и хостингом, порядок передачи репозиториев, баз данных, ключей и учётных записей при завершении проекта или расторжении.
5. Поддержка и гарантийные исправления размыты
Условие «исполнитель оказывает поддержку по мере необходимости» не устанавливает ни сроков реакции, ни объёма бесплатных исправлений. Укажите гарантийный период на исправление ошибок, сроки реакции и устранения по уровням критичности, порядок приёмки исправлений и отдельный договор или тариф на дальнейшую поддержку и развитие продукта.
6. Ответственность исполнителя ограничена и не покрывает сбои
Стандартное ограничение ответственности суммой договора может оказаться недостаточным, если сбой в системе останавливает продажи или приводит к утечке данных. Для критичных систем переносите риск через страхование, устанавливайте предельный размер ответственности выше цены договора и отдельно фиксируйте требования к защите персональных данных с учётом 152-ФЗ.
Чек-лист: что должно быть в этом договоре
- Техническое задание с перечнем функций, требований к интерфейсу и интеграциям
- Этапы работ с составом результата, сроками и порядком сдачи каждого этапа
- Порядок приёмки: срок тестирования, форма замечаний, критерии критичности дефектов
- Объём передаваемых прав на код, дизайн, документацию и права на доработку
- Передача исходного кода, репозиториев, доступов, доменов и инфраструктуры
- Требования к защите персональных данных, разграничение ролей оператора и обработчика
- Гарантийный период, сроки реакции и устранения ошибок по уровням критичности
- Ответственность сторон, пределы возмещения убытков, порядок расторжения и расчётов
Проверить всё это вручную по документу на 30 страниц — час работы. Сервис делает то же самое за пару минут и сразу готовит формулировки правок.
Частые вопросы
Кому принадлежат права на код, если в договоре ничего не сказано?
По договору заказа на создание программы исключительное право по общему правилу принадлежит заказчику, если договором не предусмотрено иное, а исполнитель может использовать программу для собственных нужд. Однако формулировки закона диспозитивны, поэтому отсутствие условия о правах почти всегда порождает спор. Прямо укажите переход исключительного права в полном объёме и момент перехода.
Что должно входить в передачу результата работ по IT-проекту?
Исходный код в репозитории, инструкции по сборке и развёртыванию, документация, доступы к серверам и сервисам, домены, базы данных и учётные записи внешних систем. Отдельно передаются права на графику, шрифты и сторонние библиотеки. Составьте акт передачи с перечнем, иначе после смены подрядчика восстановить проект будет невозможно.
Как принимать работу по этапам разработки?
Тестируйте результат в согласованном объёме, ведите реестр замечаний с разделением на блокирующие и незначительные дефекты, фиксируйте срок устранения. Акт подписывайте либо с перечнем замечаний, либо после их устранения, но не оставляйте молчание без ответа. Для крупных проектов используйте демонстрации и промежуточные версии, чтобы контролировать ход работ.
Как быть с персональными данными пользователей в разрабатываемом сервисе?
Определите в договоре, кто является оператором персональных данных, а кто обработчиком по поручению, и закрепите обязанности по защите данных с учётом 152-ФЗ. Исполнитель должен обеспечить конфиденциальность, ограничить доступ и не использовать данные для своих целей. Дополнительно проверьте, где размещаются данные и как обеспечивается их возврат при расторжении договора.
Смотрите также
Материал носит справочный характер и не является юридической консультацией. Проверяйте итоговые документы перед подписанием.