Полное руководство по договору разработки ПО + бесплатный шаблон

Большинство IT-проектов проваливаются не потому, что разработчики плохо кодят. Они проваливаются, потому что никто не записал, что означает "готово". По данным CHAOS Report от Standish Group, доля успешных software-проектов составляет всего 31% — и главными причинами являются разногласия по объёму работ, неясное распределение прав на IP и спорные условия оплаты.

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

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

Договор разработки ПО (SDA) — это юридически обязательный контракт между заказчиком и разработчиком или компанией-разработчиком. В нём прописаны объём работ, порядок оплаты, сроки сдачи, права на интеллектуальную собственность, условия конфиденциальности и порядок расторжения договора.

SDA — это не коммерческое предложение, не техническое задание и не тред в Slack с подтверждением задач. Это формальный юридический документ, фиксирующий, на что согласились обе стороны до начала разработки. После подписания он станет документом, на который вы будете ссылаться при спорах — и который будет читать суд, если дело дойдёт до него.

Что включает SDA

Правильно составленный договор разработки ПО регулирует:

• Объём работ — что разработчик создаст, с такой конкретикой, что сторонний эксперт мог бы оценить выполнение
• Результаты и этапы — что передаётся, в какой форме и когда
• Условия оплаты — общая сумма, график платежей и события, их инициирующие
• Права на IP — кому принадлежит код после написания
• Конфиденциальность — какую проприетарную информацию каждая сторона обязана сохранять в тайне
• Приёмочное тестирование — как заказчик оценивает, соответствует ли ПО требованиям
• Гарантии — что разработчик гарантирует в отношении функциональности ПО
• Условия расторжения — как любая сторона может завершить договор и что происходит с уже выполненной работой

Некоторые заказчики путают SDA с Statement of Work. Есть пересечения, но это разные документы — и различие имеет значение. Взаимосвязь MSA и SOW объясняет, как эти документы работают вместе в долгосрочных взаимоотношениях.

Короткий ответ: всякий раз, когда вы платите кому-то за разработку ПО или получаете оплату за эту работу.

Договор важен независимо от масштаба: будь то найм фрилансера на две недели или привлечение агентства из 20 человек на годовой проект. Масштаб меняется; потребность в письменных условиях — нет.

Договор разработки ПО нужен, когда:

• Вы аутсорсите разработку ПО — особенно удалённым или офшорным командам, где различия в юрисдикции усложняют неформальные договорённости
• Создаётся кастомное ПО — чем более уникальна работа, тем важнее явно зафиксировать права на IP
• Проект состоит из нескольких фаз — поэтапная оплата требует письменных критериев приёмки для перехода к следующему этапу
• Задействованы чувствительные данные или системы — любой проект, касающийся данных клиентов, требует пунктов о конфиденциальности и безопасности
• Вы используете проприетарные фреймворки — интеграция готового кода в кастомные результаты создаёт запутанные вопросы владения без чёткого договора
• Вы работаете через границы — приёмное право и юрисдикция должны быть явно названы, когда разработчик и заказчик находятся в разных странах

Единственная ситуация, где можно обойтись без полноценного SDA: очень короткая, недорогая работа, регулируемая комплексным MSA, который уже покрывает все релевантные условия. Но даже тогда большинство юристов посоветуют оформить документы.

Не существует единого шаблона SDA, подходящего для любого проекта. Структура контракта должна соответствовать способу ценообразования и определения объёма — а выбор неправильной структуры создаёт стимулы, работающие против хорошего результата.

Контракты с фиксированной ценой

Фиксированная цена в SDA работает, когда требования к проекту стабильны и хорошо понятны до начала разработки. Разработчик обязуется сдать определённый объём за согласованную сумму. Главное преимущество для заказчика — предсказуемость бюджета. Риск: если требования окажутся недостаточно детализированными, разработчик либо перекрывает перерасход, либо начинаются споры.

Контракты Time & Materials

T&M-контракты уместны для исследовательских проектов, продуктов на ранней стадии или любых ситуаций, где полный объём невозможно определить заранее. Заказчик платит за фактически отработанные часы по согласованным ставкам. Вы получаете гибкость; компромисс — неопределённость стоимости. Бюджетные ограничения и месячные потолки помогают управлять этим риском.

Договоры с выделенной командой

Для компаний, которым нужна постоянная удалённая команда инженеров, а не разовая поставка проекта, договор с выделенной командой задаёт условия постоянного взаимодействия. Управление договорами для IT-компаний обычно включает эту модель при работе с аутсорсинговыми партнёрами.

Структура MSA + SOW

В крупных проектах часто разделяют базовую правовую рамку (MSA) и проектно-специфичные условия (SOW). MSA покрывает IP, конфиденциальность, ответственность и разрешение споров один раз; каждый SOW определяет конкретные результаты, сроки и оплату для отдельного проекта.

Не все пункты имеют одинаковый вес. Это те, отсутствие или расплывчатость которых приводит к реальным спорам.

1. Объём работ и результаты

Опишите, что создаётся, с такой детализацией, что человек, не участвовавший в проекте, мог бы оценить, было ли это выполнено. Функциональные требования, технические спецификации, поддерживаемые платформы и бенчмарки производительности — всё здесь. Явно назовите, что выходит за рамки проекта.

Расплывчатый объём — самая частая причина software-споров. "Сделать сайт" — не объём. "Создать адаптивное приложение на React/Next.js с функциями из Приложения А, проходящее Lighthouse с показателем 90+ на мобильных" — это объём.

2. Условия оплаты и график этапов

Перечислите каждый платёж: сумму, событие-триггер и способ оплаты. Поэтапные платежи должны привязываться к принятым результатам, а не просто к датам в календаре. Укажите валюту, срок оплаты (Net-15 или Net-30 — стандарт) и штраф за просрочку.

3. Права на интеллектуальную собственность

Это пункт, который большинство заказчиков читают слишком быстро. Кому принадлежит кастомный код? Кому принадлежит готовый код, который разработчик интегрирует? Покрывается ли open-source? Раздел об IP в SDA определяет, кто может использовать, модифицировать, продавать или лицензировать ПО после сдачи. Ошибка здесь обходится дорого — см. дело Cadence v. Avanti в разделе об IP ниже.

4. Конфиденциальность

SDA должен включать взаимные обязательства по конфиденциальности. Разработчик не раскрывает данные заказчика или проприетарную бизнес-логику; заказчик не раскрывает проприетарные процессы и инструменты разработчика. Более надёжные NDA-условия в отдельном соглашении — в нашем гиде по NDA для IT-подрядчиков стоит прочитать параллельно с этим материалом.

5. Приёмочное тестирование

Определите, как заказчик проверяет и принимает каждый результат. Окно для ревью (5–10 рабочих дней — типично), формат обратной связи, критерии прохождения и что происходит, если заказчик не отвечает в течение окна ревью (считается принятым).

6. Гарантии

Разработчик должен гарантировать, что ПО будет работать согласно спецификации, что код является оригинальным (или правильно лицензированным) и что поставка не нарушит права третьих лиц. Гарантийный период на исправление багов после запуска — обычно 30–90 дней — защищает заказчика от дефектов, обнаруженных после релиза.

7. Условия расторжения

Любая сторона должна иметь возможность выйти с разумным уведомлением. Определите период уведомления (30 дней — стандарт), что происходит с незавершённой работой и как рассчитывается итоговый платёж при досрочном расторжении. Расторжение по причине (существенное нарушение, банкротство или неуплата) должно быть отделено от расторжения по соглашению.

8. Применимое право и юрисдикция

Укажите страну и штат/регион, законами которых регулируется договор. Когда разработчик и заказчик находятся в разных странах, этот пункт решает, какие суды будут рассматривать спор. Не пропускайте его, потому что он кажется формальностью — это один из самых практически важных пунктов в международных проектах.

Используйте этот шаблон как основу для вашего договора. Замените все поля в квадратных скобках на свои условия. Для сложных проектов привлеките IT-юриста для проверки финальной версии — особенно разделов об IP и гарантиях.

Для IT-компаний, управляющих контрактами с несколькими партнёрами по разработке, централизация всех SDA в единой системе управления документами — с историей версий и защищёнными от подделки подписями — устраняет хаос пересылки Word-документов.

В шаблоне выше более дюжины полей для заполнения. Вот как подойти к каждому, не оставляя пробелов, которые впоследствии вызовут споры.

Шаг 1: Определите объём работ, прежде чем открывать договор

Не открывайте шаблон, пока не задокументируете, что ПО должно делать на самом деле. Функциональные требования, технические ограничения, поддерживаемые платформы, зависимости интеграций — всё это. Раздел объёма в SDA настолько хорош, насколько хороша спецификация, лежащая в его основе.

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

Шаг 2: Постройте график этапов

Двигайтесь в обратном направлении от даты сдачи. Разбейте проект на фазы — исследование, дизайн, разработка, тестирование, деплой — и назначьте каждой сумму и дедлайн. Платежи по фазам должны примерно соответствовать ценности, создаваемой на каждом этапе.

Честное предупреждение: это занимает дольше, чем ожидает большинство сторон, особенно при первом взаимодействии. Заложите 1–2 часа присутствия обеих сторон, чтобы правильно расписать этапы и платежи.

Шаг 3: Явно пропишите права на IP

Внимательно прочитайте Раздел 3 и заполните все пробелы. Если разработчик использует проприетарные фреймворки или инструменты, созданные до этого проекта, перечислите их в оговорке о предшествующей работе. Если вы используете open-source библиотеки, укажите лицензии.

Передача прав на кастомную работу (Раздел 3.1) — обычно самый важный пункт для заказчиков: именно он передаёт права на переданный код от разработчика к вам. Не оставляйте его расплывчатым.

Шаг 4: Задайте окно для ревью и критерии приёмки

Решите, сколько дней на проверку, прежде чем заполнять это поле. Десять рабочих дней — типично. Две недели дают занятым заказчикам достаточно времени для реального тестирования результата; более короткие сроки обычно порождают споры, когда рецензенты в поездках или заняты.

Для Раздела 5 критерии приёмки принадлежат Приложению А. Пишите конкретные, проверяемые критерии: "Мобильное приложение загружает дашборд менее чем за 3 секунды на соединении 4G" лучше, чем "приложение должно быть быстрым".

Шаг 5: Осознанно выберите применимое право

Для внутренних проектов используйте штат/страну разработчика (ему знакомы местные суды). Для международных проектов любая сторона может предпочесть нейтральную юрисдикцию. Право штата Делавэр часто используется для US tech-контрактов; английское право — часто для международных tech-соглашений. Что бы вы ни выбрали, обе стороны должны явно согласиться — не оставляйте это пустым.

Шаг 6: Подпишите compliant-электронной подписью

Отсканированное изображение рукописной подписи на PDF юридически слабо в большинстве юрисдикций. Электронные подписи, генерирующие хэш документа и сертификат завершения с отметкой времени, гораздо сложнее оспорить. Согласно ESIGN Act и UETA в США, а также eIDAS в Европейском союзе, электронные подписи имеют полную юридическую силу для коммерческих соглашений. Платформа для подписания должна привязывать каждую подпись к криптографическому хэшу документа — чтобы любое изменение после подписания было немедленно обнаружимо.

Большинство шаблонов покрывают основы. Это пункты, которые выпадают из дешёвых или быстро составленных договоров — и которые обычно важнее всего, когда что-то идёт не так.

Приёмочное тестирование с критериями прохождения/непрохождения

Раздел 5 в шаблоне выше определяет, *когда* и *как* заказчик проверяет результаты. То, что большинство договоров пропускают: реальные критерии для прохождения. Без измеримых бенчмарков приёмка превращается в переговоры. Заказчик всегда может заявить, что ПО "недостаточно хорошее". Пропишите объективные критерии в Приложении А до начала разработки.

Эскроу исходного кода

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

Период ответственности после сдачи

Раздел 7 ограничивает общую ответственность, но многие шаблоны не определяют временное окно. Когда заканчивается ответственность? Если дефект приводит к потере данных через 18 месяцев после сдачи, несёт ли разработчик ответственность? Явно определите гарантийный период и период ответственности после гарантии. После гарантийного периода обязанность разработчика обычно ограничивается исправлением дефектов, вызванных им, — а не багов, внесённых модификациями заказчика.

Процесс управления изменениями

Раздел 9 требует подписанного Дополнительного соглашения для изменений объёма. То, что большинство договоров упускают: определение, кто имеет полномочия подписывать Дополнительные соглашения. Если менеджер проекта со стороны заказчика устно запрашивает новую функцию, а разработчик её реализует, должен ли разработчик получить оплату? Только если был соблюдён процесс Дополнительного соглашения. Назовите конкретные роли (не конкретных людей, чьи должности меняются), имеющие полномочия авторизовать изменения.

Соответствие open-source лицензий

Linux Foundation сообщает, что 92% коммерческого ПО содержит open-source компоненты. Каждая лицензия компонента накладывает условия на использование, модификацию и распространение ПО. Например, библиотека под GPL может вызвать обязательства copyleft, вынуждающие вас открыть исходный код вашего проприетарного ПО. SDA должен требовать от разработчика раскрытия всех open-source компонентов и подтверждения их совместимости с предполагаемым использованием заказчика.

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

Дело Cadence v. Avanti: урок на $265 млн

В 2002 году суд Калифорнии установил, что Avanti Corporation использовала украденный исходный код Cadence в конкурирующем продукте. Сумма ущерба достигла $265 млн. Это дело часто цитируется в software-литигах по IP, потому что иллюстрирует, что происходит, когда право собственности на исходный код оспаривается или, что хуже, когда код, который никогда не должен был попасть в продукт, оказывается там. Хорошо составленный IP-пункт определяет не только, кому принадлежит итоговый результат, — он требует от разработчика гарантировать, что чужой IP не был неправомерно интегрирован.

Четыре модели IP

Предшествующая vs. кастомная работа

Большинство разработчиков приносят инструменты, фреймворки и библиотеки, созданные до вашего проекта. Это "предшествующие работы" или "фоновый IP". SDA должен чётко идентифицировать, какая предшествующая работа будет интегрирована, и предоставить заказчику лицензию на её использование как части переданного ПО — без передачи прав собственности на эти базовые инструменты.

Для более глубокого понимания того, как работает передача прав в индивидуальных контрактах разработчиков, наш гид по соглашению о передаче прав для разработчиков объясняет механику передачи и лицензирования прав на код.

Доктрина work-for-hire

В США код, написанный сотрудником в рамках трудовых обязанностей, автоматически считается work-for-hire и принадлежит работодателю. Код, написанный независимым подрядчиком, *не* автоматически является work-for-hire — подрядчик сохраняет авторские права, пока договор явно не передаёт их. Это различие подводит заказчиков, которые предполагают, что владеют кодом, потому что заплатили за него. Нет, без пункта о передаче прав.

Эти три документа постоянно путают. У каждого своя роль, и использование неправильного — или смешение их — создаёт пробелы в ответственности.

Для разовых проектов автономный SDA (как шаблон в этом руководстве) покрывает всё. Для постоянного взаимодействия с партнёром по разработке — когда вы ведёте несколько проектов со временем — структура MSA + SOW эффективнее. MSA выторговывает правовую рамку один раз; каждый проект добавляет новый SOW. Наш полный гид по Statements of Work подробно раскрывает структуру SOW.

Раньше подписание SDA означало печать, сканирование, email и надежду, что версия другой стороны совпадает с вашей. Сегодня нет причин делать это так.

Что делает электронную подпись юридически действительной

Согласно ESIGN Act (США) и eIDAS (ЕС), электронная подпись юридически действительна для коммерческих соглашений, если она:

• Применена человеком с намерением подписать
• Ассоциирована с конкретным подписываемым документом
• Способна быть атрибутирована подписывающему
• Запись хранится в форме, доступной для последующего извлечения

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

Как работает процесс подписания

Управление документами для IT-компаний обычно ведёт несколько SDA, SOW и NDA одновременно. Специализированный рабочий процесс предотвращает кошмар контроля версий, который сопровождает email-подписание:

1. 1.
   Загрузите финализированный SDA в платформу управления договорами
2. 2.
   Добавьте email каждого подписанта и порядок подписания
3. 3.
   Каждая сторона получает безопасную ссылку для подписания — аккаунт для подписания не требуется
4. 4.
   Подписи проставляются; платформа генерирует сертификат завершения с временными метками, IP-адресами и хэшем документа
5. 5.
   Обе стороны автоматически получают полностью исполненный документ
6. 6.
   Аудиторский след хранится неизменно, доступен для будущих справок или разрешения споров

Поэтапные платежи, привязанные к подписанию

Самая полезная функция современной платформы для договоров — не сама подпись, а связь подписи с тем, что происходит дальше. Когда разработчик передаёт этап, а заказчик подписывает акт приёмки, триггер оплаты срабатывает автоматически. Никакого ручного выставления счетов, никакой путаницы "я думал, ты вышлешь счёт отдельно". Для команд, управляющих платежами по договорам, это устраняет разрыв между приёмкой и выставлением счёта.

Полный разбор тарифов на управление договорами — на странице цен Chaindoc.