Чек-лист проверки договора на разработку ПО

Первый вопрос, который должен задать IT-юрист: что именно создается?

Очень частая ошибка:
«Исполнитель оказывает услуги по разработке программного продукта».

Какого продукта?
Что должно получиться?
Что считается результатом?

Проверьте:

1. Есть ли описание продукта
2. Есть ли техническое задание (ТЗ)
3. Понятен ли конечный результат
4. Разделен ли проект на этапы
5. Понятно ли, какие материалы входят в результат:

• код
• дизайн
• документация
• базы данных
• API
• интеграции
• контент

Красный флаг: результат описан абстрактно.

Риск: невозможно доказать, что именно должен был получить заказчик

Очень частая ошибка:

• в договоре есть срок действия, но нет сроков этапов.

В результате:

• исполнитель считает, что всё идет нормально
• заказчик не понимает, когда получит результат

Проверьте:

1. Есть ли календарный план
2. Есть ли сроки по этапам
3. Есть ли промежуточные результаты
4. Понятно ли, что считается просрочкой
5. Есть ли ответственность за нарушение сроков
6. Есть ли право заказчика расторгнуть договор при нарушении промежуточных сроков
7. Получает ли заказчик промежуточный результат при расторжении

Красный флаг: сроки указаны только «в целом по договору».

Риск: проект может затягиваться бесконечно без понятных последствий для исполнителя.

В IT-продуктах требования почти никогда не остаются неизменными.

Меняются:

• функциональность;
• интерфейс;
• интеграции;
• логика продукта;
• пользовательский путь.

Если механизм изменений не прописан — конфликт почти неизбежен.

Проверьте:

1. Как согласуются изменения
2. Кто утверждает изменения
3. Влияют ли изменения на сроки
4. Влияют ли изменения на стоимость
5. Что считается согласованным изменением
6. Можно ли использовать переписку как механизм согласования

Красный флаг: «Стороны согласовывают требования в рабочем порядке»
без процедуры.

Риск: каждое изменение превращается в спор о деньгах, сроках и объеме работ.

Один из самых опасных рисков:
код находится только у исполнителя.

А потом заказчик слышит:
«Передадим позже».

Проверьте:

1. Есть ли доступ к репозиторию
2. У кого права администратора
3. Есть ли доступ к инфраструктуре
4. Кому принадлежат аккаунты
5. Есть ли обязанность передать доступы
6. Есть ли обязанность передать документацию

Красный флаг: разработка полностью сосредоточена у подрядчика.

Риск: бизнес становится зависимым от конкретного исполнителя.

Главный вопрос: сможет ли компания продолжить разработку без него?

Частая проблема — отсутствие критериев приемки.

В итоге:

• исполнитель считает, что работа выполнена
• заказчик считает, что продукт не работает

Проверьте:

1. Есть ли этапная приемка
2. Есть ли финальная приемка
3. Есть ли критерии результата
4. Есть ли тестирование
5. Есть ли сроки на замечания
6. Понятно ли, когда работа считается выполненной
7. Есть ли последствия неподписания акта

Красный флаг: акт = единственный критерий качества.

Риск: спор о том, выполнена работа или нет.

Самая дорогая ошибка — отсутствие корректной цепочки прав.

Если права не оформлены:

• инвестор может отказаться от сделки
• M&A может сорваться
• продукт может юридически принадлежать не компании

Проверьте:

1. Кому принадлежат исключительные права
2. Что именно входит в объект передачи
3. Передаются ли права на:

• код
• дизайн
• интерфейсы
• API
• базы данных
• документацию
• контент

4. Когда переходят права
5. Есть ли зависимость передачи прав от:

• полной оплаты
• подписания акта

6. Есть ли обязанность передать права от третьих лиц
7. Есть ли гарантии чистоты прав

Красный флаг: «Права переходят после полной оплаты» без понятной логики передачи результата.

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

Использование open source — не проблема.
Проблема — когда никто не понимает, какие лицензии используются.

Некоторые лицензии могут ограничивать коммерческое использование продукта или создавать риск раскрытия кода.

Проверьте:

1. Разрешено ли использование open source
2. Какие лицензии допустимы
3. Должен ли исполнитель раскрывать состав библиотек
4. Есть ли ограничения на copyleft-лицензии
5. Есть ли обязанность предупредить о рисках

Риск: невозможность безопасно масштабировать продукт или пройти due diligence.

Во многих проектах код пишет не один исполнитель, а команда.

Проверьте:

1. Может ли исполнитель привлекать третьих лиц
2. Есть ли обязанность раскрывать субподрядчиков
3. Есть ли гарантии передачи прав от команды
4. Кто отвечает за действия привлеченных лиц

Риск: часть прав может принадлежать неизвестным подрядчикам.

После запуска почти всегда появляются ошибки.
Вопрос — как они будут устраняться.

Проверьте:

1. Есть ли гарантийный срок
2. Что считается ошибкой
3. В какие сроки устраняются баги
4. Есть ли SLA
5. Есть ли ответственность за нарушение гарантий

Красный флаг: «Исполнитель исправляет ошибки в разумный срок».

Риск: «разумный срок» превращается в бесконечный.

Самый важный блок.

Проверьте:

1. Можно ли расторгнуть договор досрочно
2. Получает ли заказчик промежуточный результат
3. Есть ли механизм оценки фактически выполненных работ
4. Есть ли ответственность за:

• срыв сроков;
• нарушение гарантий;
• непередачу прав;
• отказ передать исходный код.

5. Есть ли обязанность передать документацию и доступы

Главный вопрос, который должен задавать сильный IT-юрист:

• Что произойдет, если завтра отношения закончатся?

Если ответа нет — договор опасен.

Ответьте на 5 вопросов:

1. Понятно ли, что именно создается?
2. Понятно ли, когда это будет готово?
3. Сможет ли бизнес продолжить разработку без исполнителя?
4. Очевидно ли, кому принадлежат права?
5. Понятно ли, что произойдет при конфликте?

Если хотя бы на 2 вопроса ответ «нет» — договор требует доработки.

Проверка договора разработки программного обеспечения — это уже давно не просто «посмотреть риски».

Сильный IT-юрист должен понимать:

• как устроен продукт
• как зарабатывает бизнес
• кому принадлежит IP
• как устроен процесс разработки
• что важно инвестору и due diligence

Если хотите глубже разобраться в профессии:
Компетенции IT-юриста: что должен уметь сильный специалист

Если вам не хватает IT-терминов для общения с разработчиками и продуктовой командой:
Глоссарий IT-юриста: ключевые IT-термины и понятия

Нужен ли договор на разработку ПО, если разработчик «свой»?
Да.
Большинство конфликтов возникает именно между знакомыми, бывшими коллегами, друзьями и партнерами.

Можно ли работать без ТЗ?
Технически — да.
Практически — это один из самых частых источников конфликтов.

Когда должны переходить права на код?
Зависит от модели проекта.
Но договор должен минимизировать риск зависимости заказчика и предусматривать понятный механизм передачи прав.

Можно ли использовать open source?
Да.
Но важно понимать лицензии и их последствия.

Что важнее: сроки или права?
Оба вопроса критичны.
Но если права не оформлены — заказчик может заплатить за продукт, который ему юридически не принадлежит.

Большинство юристов умеют читать договор. Но этого недостаточно.

Важно научиться:

• понимать продукт
• видеть бизнес-логику
• оценивать IP-риски
• понимать архитектуру сделки
• принимать решения в условиях неопределенности

Именно поэтому в Практикуме «Юрист IT-компании» мы разбираем реальные кейсы разработки ПО, передачу прав, SaaS, AI-продукты, платформы и запуск цифрового бизнеса.
Студенты работают с договорами, кейсами и логикой принятия решений, с которой сталкивается in-house IT-юрист и консультант.

Практикум «Юрист IT-компании»

Материал будет полезен:

• IT-юристам
• in-house юристам
• юристам digital и tech-компаний
• фаундерам IT-проектов
• CEO и product owner
• всем, кто работает с разработкой программного обеспечения