Почему 80% договоров на разработку ПО опасны для заказчика: чек-лист IT-юриста по проверке договора разработки программного обеспечения
Договор на разработку программного обеспечения — один из самых недооцененных документов в IT-бизнесе.
На практике большинство конфликтов между заказчиком и разработчиком возникают не потому, что кто-то действовал недобросовестно, а потому что договор изначально не отвечал на главный вопрос:
получит ли заказчик продукт, который рассчитывал получить.
В сфере разработки ПО типичная ситуация выглядит так: договор большой, “юридический”, в нем много страниц, приложений и формулировок. При анализе не понятно на что обратить внимание и какие риски закрыть.
Но при этом остается неясно:
что именно создается;
когда это будет готово;
кому принадлежат права;
что происходит при конфликте;
можно ли продолжить разработку без подрядчика.
В результате заказчик может потратить миллионы рублей и остаться без работающего продукта.
Разберем, как IT-юристу проверять договор разработки ПО и на какие риски обращать внимание в первую очередь.
Что такое договор на разработку программного обеспечения
Договор разработки ПО — это соглашение, по которому исполнитель создает для заказчика:
программное обеспечение;
мобильное приложение;
SaaS-платформу;
API;
внутренние модули;
интеграции;
информационные системы.
Ключевая ошибка — воспринимать его как обычный договор оказания услуг.
В IT результат всегда важнее процесса.
Поэтому хороший договор должен отвечать на вопрос: что именно создается и как заказчик поймет, что работа выполнена.
Правило № 1: никогда не анализируйте договор в отрыве от контекста. Обязательно обсудите с бизнес заказчиком какой программный продукт создается, как его планируют использовать,
Почему договоры разработки ПО часто опасны для заказчика
На практике мы регулярно видим одни и те же проблемы:
размытое описание результата;
отсутствие ТЗ;
непонятная приемка;
неоформленные права на код;
зависимость от разработчика;
отсутствие доступа к репозиторию;
использование open source без ограничений;
отсутствие ответственности за срыв сроков.
Именно эти ошибки потом становятся причиной:
судебных споров;
срыва запуска продукта;
проблем с инвестициями;
невозможности продажи бизнеса;
провала due diligence.
Чек-лист проверки договора разработки ПО (проверьте свой договор)
1. Понятно ли, что именно создается
Первый красный флаг:
«Исполнитель оказывает услуги по разработке программного продукта».
Какого продукта?
Что считается результатом?
Что должно работать?
Проверьте:
есть ли описание продукта;
есть ли техническое задание;
понятен ли конечный результат;
разделен ли проект на этапы.
Если в договоре нет понятного результата — спор почти неизбежен.
2. Понятно ли, когда заказчик получит результат
Частая ошибка:
в договоре есть общий срок, но нет этапов.
В итоге:
исполнитель считает, что всё идет по плану;
заказчик не понимает статус проекта.
Проверьте:
есть ли календарный план;
зафиксированы ли промежуточные этапы;
есть ли ответственность за нарушение сроков.
3. Есть ли механизм изменения требований
В разработке программного обеспечения продукт почти никогда не остается неизменным.
Меняется:
логика;
интерфейс;
функциональность;
интеграции.
Проверьте:
как согласуются изменения;
влияют ли они на сроки;
как меняется стоимость;
что считается согласованным изменением.
4. Есть ли доступ к коду и инфраструктуре
Один из самых опасных рисков: код находится только у исполнителя.
А потом заказчик слышит: «Передадим после завершения».
Проверьте:
есть ли доступ к репозиторию;
кому принадлежат аккаунты;
есть ли доступ к инфраструктуре;
как передаются доступы.
Сильный IT-юрист всегда задает вопрос: сможет ли бизнес продолжить разработку без подрядчика.
5. Как устроена приемка результата
Очень частая проблема — отсутствие критериев приемки.
В итоге:
исполнитель считает, что работа выполнена;
заказчик считает, что продукт не работает.
Проверьте:
этапную приемку;
финальную приемку;
критерии тестирования;
основания для отказа в приемке.
6. Кому принадлежат права на код
Это самая дорогая ошибка.
Если цепочка прав не оформлена:
инвестор может отказаться от сделки;
M&A может сорваться;
компания может не владеть своим продуктом.
Проверьте:
кому принадлежат исключительные права;
когда происходит переход прав;
как оформлена передача прав от подрядчиков;
Особенно важно для:
SaaS;
AI-продуктов;
маркетплейсов;
mobile app;
B2B-платформ.
7. Используется ли open source
Open source — не проблема.
Проблема — когда никто не понимает, какие лицензии используются.
Некоторые лицензии могут создать риск раскрытия исходного кода.
Проверьте:
допустимо ли использование open source;
какие лицензии разрешены;
должен ли исполнитель раскрывать состав библиотек.
8. Что будет, если исполнитель уйдет
Очень частый сценарий в IT.
Разработчик уходит.
И вместе с ним:
доступы;
логика продукта;
архитектура.
Проверьте:
есть ли документация;
передаются ли доступы;
есть ли зависимость от конкретной команды.
9. Есть ли гарантийная поддержка
Проверьте:
есть ли гарантийный срок;
что считается ошибкой;
в какие сроки устраняются баги;
есть ли ответственность за нарушение гарантий.
10. Что будет при конфликте
Самый важный вопрос.
Проверьте:
можно ли расторгнуть договор;
получит ли заказчик промежуточный результат;
как определяется стоимость фактически выполненных работ;
есть ли ответственность за срыв сроков и непередачу прав.
Сильный IT-юрист всегда задает вопрос:
Что произойдет, если завтра отношения закончатся?
Если ответа нет — договор опасен.
Какие навыки нужны IT-юристу для проверки договоров разработки ПО
Проверка договора разработки — это уже давно не просто “посмотреть риски”.
IT-юрист должен понимать:
как устроен продукт;
как зарабатывает бизнес;
кому принадлежит IP;
как работает разработка;
что важно инвестору и due diligence.
Именно поэтому рынок всё чаще ищет не “юриста по договорам”, а IT-юриста, который понимает цифровой бизнес.
Если хотите разобраться глубже, рекомендуем изучить:
FAQ по договору разработки программного обеспечения
Нужен ли договор на разработку ПО, если разработчик “свой”?
Да.
Большинство конфликтов возникает именно между знакомыми, партнерами и “проверенными” подрядчиками.
Можно ли работать без ТЗ?
Технически — да.
Практически — это один из самых частых источников конфликтов.
Когда должны переходить права на код?
Зависит от модели проекта.
Но сильный договор должен минимизировать риск зависимости заказчика и предусматривать понятный механизм передачи прав.
Можно ли использовать open source?
Да.
Но важно понимать лицензии и риски их использования.
Что важнее: сроки или права?
Оба вопроса критичны.
Но если права не оформлены — заказчик может заплатить за продукт, который ему юридически не принадлежит.
Как научиться проверять договоры разработки ПО как IT-юрист
Большинство юристов умеют читать договор.
Но этого недостаточно.
Важно научиться:
видеть продукт;
понимать бизнес;
оценивать IP-риски;
понимать архитектуру сделки;
работать с реальными кейсами.
Именно поэтому в Практикуме «Юрист IT-компании» мы разбираем реальные кейсы разработки ПО, передачу прав, SaaS, AI-продукты, платформы и запуск цифрового бизнеса.
Студенты работают с договорами, кейсами и логикой принятия решений, с которой сталкивается in-house IT-юрист и консультант.