Договір розробки програмного забезпечення: повний гайд + безкоштовний шаблон

Більшість програмних проєктів провалюються не тому, що розробники погано кодять. Вони провалюються, тому що ніхто не прописав у договорі розробки ПЗ, що означає «готово». Звіт CHAOS Group Standish оцінює рівень успішності програмних проєктів усього в 31% — і основні винуватці: розбіжності щодо обсягу робіт, нечітке визначення прав на ІС та спірні умови оплати.

Договір розробки ПЗ виправляє все це ще до початку робіт. Це контракт між замовником і розробником (чи агентством), який визначає, що саме буде створено, хто цим володітиме, скільки це коштує, і що станеться, якщо щось піде не так. Без нього ви покладаєтеся на добру віру та пам'ять — а суди не приймають жодного з цих аргументів.

Цей гайд охоплює все: коли потрібен договір розробки програмного забезпечення, чотири типи контрактів і коли використовувати кожен, кожне положення, яке дійсно має значення, та безкоштовний шаблон для завантаження, який ви можете адаптувати під свій проєкт. Якщо ви вже знаєте основи і хочете одразу перейти до шаблону, прокрутіть до відповідного розділу. В іншому разі контекст важливий — особливо розділ щодо ІС, де більшість договорів непомітно дає збій. Для ширшого розгляду того, чим угоди відрізняються від контрактів, наш гайд щодо контрактів vs угод розкриває юридичні відмінності, варті знання.

Договір розробки ПЗ (SDA) — це юридично обов'язковий контракт між замовником і розробником програмного забезпечення чи компанією-розробником. Він визначає обсяг робіт, структуру оплати, терміни доставки, володіння інтелектуальною власністю, умови конфіденційності та порядок дій, якщо одна зі сторін вирішить розірвати угоду.

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

Що охоплює SDA

Правильно складений договір розробки програмного забезпечення має регулювати:

• Обсяг робіт — що саме розробник створить, із достатньою конкретикою, щоб стороння особа могла оцінити виконання
• Результати та етапи — що передається, у якій формі та до якого терміну
• Умови оплати — загальна вартість, графік платежів і що запускає кожен платіж
• Володіння ІС — хто володітиме кодом після його написання
• Конфіденційність — яку пропрієтарну інформацію кожна сторона має зберігати в таємниці
• Приймальне тестування — як замовник оцінює, чи відповідає готове ПЗ вимогам
• Гарантії — що розробник гарантує щодо функціональності ПЗ
• Умови розірвання — як кожна сторона може завершити договір і що станеться з уже виконаною роботою

Деякі замовники плутають SDA зі Statement of Work. Між ними є спільне, але це не одне й те саме — і ця різниця має значення. Взаємозв'язок між MSA та SOW пояснює, як ці документи працюють разом у довгостроковій співпраці.

Коротка відповідь: щоразу, коли ви платите комусь за створення ПЗ, або отримуєте плату за його створення.

Контракт важливий, чи то ви наймаєте фрілансера на два тижні, чи залучаєте 20-осібне агентство на річну розробку продукту. Масштаб змінюється; потреба в письмових умовах — ні.

Вам потрібен договір розробки ПЗ, коли:

• Ви аутсорсите розробку ПЗ — особливо офшорним або віддаленим командам, де різниця в юрисдикції ускладнює неформальні домовленості
• Створюється кастомне ПЗ — чим індивідуальніша робота, тим більше потрібна явна документація щодо володіння ІС
• Існує кілька етапів розробки — виплати за етапами потребують письмових критеріїв прийняття для активації кожного етапу
• Задіяні конфіденційні дані чи системи — будь-який проєкт, що стосується даних клієнтів, потребує положень про конфіденційність та безпеку
• Ви будуєте на пропрієтарних фреймворках — використання вже наявного коду в кастомних результатах створює заплутані питання володіння без чіткого договору
• Ви працюєте через кордони — право, що регулює договір, і юрисдикція мають бути вказані, коли розробник і замовник у різних країнах

Єдина ситуація, коли ви можете обійтися без повноцінного SDA: дуже коротка, недорога робота, що регулюється всеосяжним master service agreement, який уже охоплює всі відповідні умови. Але навіть тоді більшість юристів порадять оформити документи.

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

Контракти з фіксованою ціною

SDA з фіксованою ціною працює, коли вимоги до проєкту стабільні та чітко зрозумілі до початку розробки. Розробник зобов'язується виконати визначений обсяг робіт за погоджену загальну вартість. Визначеність бюджету — головна перевага для замовників. Ризик: якщо вимоги виявляться недостатньо деталізованими, розробник або поглинає перевитрати, або починаються суперечки.

Контракти T&M

T&M-контракти доречні для дослідницьких проєктів, продуктів на ранній стадії або будь-яких ситуацій, де повний обсяг неможливо визначити заздалегідь. Замовник платить за фактично відпрацьовані години за погодженими ставками. Ви отримуєте гнучкість; компроміс — у невизначеності вартості. Ліміти бюджету та щомісячні стелі допомагають керувати цим ризиком.

Договори про виділену команду

Для компаній, яким потрібна стала віддалена інженерна команда — а не разова поставка проєкту — договір про виділену команду встановлює умови постійних відносин. Управління договорами для ІТ-компаній типово передбачає цю модель при роботі з аутсорсинговими партнерами.

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

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

Не всі положення мають однакову вагу. Ось ті, де відсутність або розпливчаста мова спричиняють реальні суперечки.

1. Обсяг робіт і результати

Опишіть, що саме створюється, із достатньою деталізацією, щоб людина, не залучена до проєкту, могла оцінити, чи було це виконано. Функціональні вимоги, технічні специфікації, підтримувані платформи та бенчмарки продуктивності — все це має бути тут. Явно назвіть те, що не входить у обсяг.

Розпливчастий обсяг — найпоширеніше джерело програмних суперечок. «Зробити сайт» — не обсяг. «Збудувати адаптивний додаток React/Next.js із функціями, переліченими у Додатку А, що проходить бенчмарки Lighthouse 90+ на мобільних» — це обсяг.

2. Умови оплати та графік етапів

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

3. Володіння інтелектуальною власністю

Це положення, яке більшість замовників читають занадто швидко. Хто володіє кастомним кодом? Хто володіє вже наявним кодом, який використовує розробник? Чи охоплюється відкритий код? Розділ ІС у SDA визначає, хто може використовувати, модифікувати, продавати чи ліцензувати ПЗ після поставки. Якщо тут помилитися, наслідки дорогі — див. справу Cadence v. Avanti у розділі щодо ІС нижче.

4. Конфіденційність

SDA має містити взаємні зобов'язання щодо конфіденційності. Розробник не може розкривати дані замовника чи пропрієтарну бізнес-логіку; замовник не може розкривати пропрієтарні процеси чи інструменти розробника. Для більш надійних умов NDA в окремій угоді варто прочитати гайд щодо NDA для підрядників у сфері ПЗ паралельно з цим.

5. Приймальне тестування

Визначте, як замовник переглядає та приймає кожен результат. Вікно перегляду (5–10 робочих днів — поширена практика), формат зворотного зв'язку, критерії проходження та наслідки, якщо замовник не відповість упродовж вікна перегляду (вважається прийнятим).

6. Гарантії

Розробник має гарантувати, що ПЗ функціонуватиме як зазначено, що код є оригінальним (або належним чином ліцензованим) і що поставка не порушуватиме права ІС третіх осіб. Період гарантії на виправлення дефектів після запуску — типово 30–90 днів — захищає замовника від дефектів, виявлених після запуску.

7. Умови розірвання

Кожна сторона має мати можливість вийти з розумним попередженням. Визначте період попередження (30 днів — стандарт), що станеться з роботою в процесі та як розраховуватиметься остаточний платіж при достроковому розірванні. Положення про розірвання з причини (що охоплює суттєве порушення, банкрутство чи неоплату) має бути відокремленим від розірвання за зручністю.

8. Право, що регулює договір, і юрисдикція

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

Використовуйте цей шаблон як основу для вашого договору. Замініть усі поля в дужках на свої конкретні умови. Для складних проєктів залучіть юриста з ПЗ для перевірки фінальної версії — особливо розділів щодо ІС та гарантій.

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

У шаблоні вище більше десятка полів для заповнення. Ось як підійти до кожного, не залишаючи прогалин, що спричиняють суперечки згодом.

Крок 1: Визначте обсяг, перш ніж відкривати контракт

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

Для складних проєктів додайте повну специфікацію як Додаток А і зробіть на нього посилання з положення про обсяг. Це зберігає читабельність основного контракту й водночас гарантує, що повна технічна деталізація юридично долучена.

Крок 2: Побудуйте графік етапів

Рухайтеся у зворотному напрямку від дати поставки. Розбийте проєкт на фази — дослідження, дизайн, розробка, тестування, розгортання — і призначте суму та термін виконання для кожної. Платежі за фази мають приблизно відповідати цінності, що доставляється на кожному етапі.

Справедливе попередження: це займає довше, ніж очікують більшість сторін, особливо на перших співпрацях. Закладіть 1–2 години за присутності обох сторін, щоб правильно розрахувати етапи та платежі.

Крок 3: Явно визначте володіння ІС

Уважно прочитайте Розділ 3 і заповніть усі прогалини. Якщо розробник використовує пропрієтарні фреймворки чи інструменти, створені до цього проєкту, перелічіть їх у винятку для вже наявних робіт. Якщо ви використовуєте бібліотеки з відкритим кодом, назвіть ліцензії.

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

Крок 4: Встановіть вікно перегляду та критерії

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

Для Розділу 5 критерії прийняття мають бути в Додатку А. Записуйте конкретні, тестовані критерії: «Мобільний додаток завантажує дашборд менш ніж за 3 секунди на з'єднанні 4G» — краще, ніж «додаток має бути швидким».

Крок 5: Свідомо оберіть право, що регулює договір

Для внутрішніх проєктів використовуйте штат/країну розробника (вони краще знайомі з місцевими судами). Для транскордонних проєктів будь-яка сторона може віддати перевагу нейтральній юрисдикції. Право штату Делавер поширене для технологічних контрактів у США; англійське право часто використовується для міжнародних технологічних угод. Що б ви не обрали, обидві сторони мають явно погодитися — не залишайте це поле порожнім.

Крок 6: Підписуйте відповідним електронним підписом

Відскановане зображення рукописного підпису на PDF є юридично слабким у більшості юрисдикцій. Електронні підписи, що генерують хеш документа й сертифікат завершення з часовою міткою, набагато важче оскаржити. Згідно з ESIGN Act та UETA у Сполучених Штатах і eIDAS в Європейському Союзі, електронні підписи мають повну юридичну силу для комерційних угод. Платформа для підписання має прив'язувати кожен підпис до криптографічного хешу документа — тож будь-яка зміна після підписання одразу виявляється.

Більшість шаблонів охоплюють основи. Ось положення, які випадають із дешевих чи швидко складених договорів — і які зазвичай мають найбільше значення, коли щось іде не так.

Приймальне тестування з критеріями проходження/невдачі

Розділ 5 у шаблоні вище визначає, *коли* і *як* замовник переглядає результати. Що більшість договорів пропускає: фактичні критерії для проходження. Без вимірюваних бенчмарків проходження/невдачі прийняття стає переговорами. Замовник завжди може стверджувати, що ПЗ недостатньо «хороше». Записуйте об'єктивні критерії в Додатку А до початку розробки.

Ескроу вихідного коду

Якщо ваш бізнес залежить від кастомного ПЗ, а розробник збанкрутує, вам потрібен доступ до вихідного коду. Положення про ескроу вихідного коду зобов'язує розробника депонувати вихідний код у нейтрального ескроу-агента. Якщо розробник припиняє діяльність або суттєво порушує договір, ескроу передає код замовнику. Більшість замовників ніколи не думають про це попросити — доки не знадобиться.

Період відповідальності після поставки

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

Процес контролю змін

Розділ 9 вимагає підписаного Change Order для зміни обсягу. Що більшість договорів пропускає: визначення того, хто має повноваження підписувати Change Orders. Якщо менеджер проєкту з боку замовника усно просить нову функцію, а розробник її реалізує, чи має розробник право на платіж? Лише якщо був дотриманий процес Change Order. Назвіть конкретні ролі (не осіб, чиї посади змінюються), які мають повноваження ухвалювати зміни.

Відповідність ліцензій відкритого коду

Linux Foundation повідомляє, що 92% комерційного ПЗ містить компоненти з відкритим кодом. Ліцензія кожного компонента накладає умови щодо того, як ПЗ можна використовувати, модифікувати та розповсюджувати. Бібліотека під ліцензією GPL, наприклад, може активувати copyleft-зобов'язання, що змушують вас відкрити код вашого пропрієтарного ПЗ. SDA має вимагати від розробника розкриття всіх компонентів з відкритим кодом і підтвердження їхньої сумісності з передбачуваним використанням замовника.

Володіння ІС — положення, яке більшість замовників переглядають побіжно — і те, де наслідки помилки найбільші.

Справа Cadence v. Avanti: урок на $265 млн

У 2002 році суд Каліфорнії встановив, що Avanti Corporation використала вкрадений вихідний код Cadence у конкуруючому продукті. Сума відшкодування досягла $265 млн. Ця справа часто цитується в судочинстві щодо ІС у сфері ПЗ, тому що ілюструє, що відбувається, коли оскаржується володіння вихідним кодом або, що гірше, коли код, який ніколи не мав бути інтегрований у продукт, там опиняється. Правильно складене положення про ІС визначає не лише того, хто володіє кінцевим результатом — воно вимагає від розробника гарантувати, що жодна ІС третіх осіб не була неправомірно інтегрована.

Чотири моделі ІС

Вже наявна робота vs кастомна робота

Більшість розробників приносять інструменти, фреймворки та бібліотеки, створені ними до початку вашого проєкту. Це «вже наявні роботи» або «фонова ІС». SDA має чітко визначати, яка вже наявна робота буде інтегрована, і надавати замовнику ліцензію на використання її як частини готового ПЗ — без передачі володіння цими базовими інструментами.

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

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

У Сполучених Штатах код, написаний працівником у рамках трудових обов'язків, автоматично є work-for-hire і належить роботодавцю. Код, написаний незалежним підрядником, *не* є автоматично work-for-hire — підрядник зберігає авторські права, доки договір явно не передасть їх. Ця відмінність підводить замовників, які вважають, що володіють кодом, бо заплатили за нього. Без положення про присвоєння — ні.

Ці три документи постійно плутають. У кожного з них є своя роль, і використання неправильного — або ототожнення їх — створює прогалини в підзвітності.

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

Раніше підписаний SDA означав друк, сканування, надсилання електронною поштою й сподівання, що версія іншої сторони збігається з вашою. Зараз немає жодної вагомої причини робити так.

Що робить електронний підпис юридично дійсним

Згідно з ESIGN Act (США) та eIDAS (ЄС), електронний підпис є юридично дійсним для комерційних угод, якщо він:

• Нанесений особою з наміром підписати
• Пов'язаний із конкретним документом, що підписується
• Може бути атрибутований підписувачу
• Запис зберігається у формі, що дозволяє подальше відтворення

Криптографічні підписи йдуть далі: кожен підпис математично прив'язаний до хешу документа. Зміна одного символу після підписання змінює хеш, і підробка одразу виявляється. Ця невідмовність робить договір захищеним у суді — жодна сторона не зможе пізніше стверджувати, що документ було змінено.

Як працює процес підписання

Управління документами для ІТ-компаній типово передбачає одночасне ведення кількох SDA, SOW та NDA. Спеціалізований робочий процес запобігає кошмару контролю версій, який супроводжує підписання електронною поштою:

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

Платежі за етапами, прив'язані до підписання

Найкорисніша функція в сучасній платформі контрактів — не сам підпис, а зв'язок підпису з тим, що відбувається далі. Коли розробник доставляє етап і замовник підписує форму прийняття, тригер платежу спрацьовує автоматично. Ніякого ручного виставлення рахунків, ніякої плутанини «я думав, ви надішлете рахунок окремо». Для команд, що керують платежами, прив'язаними до контрактів, це усуває розрив між прийняттям і виставленням рахунку.

Для повного розбивки тарифів на плани управління контрактами, сторінка ціноутворення Chaindoc охоплює, що включено на кожному рівні.