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