Приклад SOW веб-розробника: повна фіксована ставка проекту

Чому написати надійний SOW для веб-проекту на фіксованій ставці?

Коли компанія доручає незалежному веб-розробнику або агенції проект на фіксованій ставці, виникає спокуса спиратися на простий кошторис або обмін електронними листами. Однак це одна з головних причин суперечок у відносинах клієнт-постачальник IT: погано визначена область проекту, оскаржувані доставки, невизначені права на вихідний код. Statement of Work (SOW) — це контрактний документ, який дозволяє запобігти всім цим ризикам, формалізуючи пункт за пунктом те, що кожна сторона повинна робити, коли, і за якими критеріями успіху.

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

У цьому довіднику ми детально описуємо структуру повного прикладу SOW веб-розробника для фіксованого проекту, охоплюючи доставки, критерії прийняття, інтелектуальну власність та передачу вихідного коду. Для більш глибокого розуміння основ, див. наш повний довідник SOW: модель, статті та електронна підпис.

---

Типова структура SOW для веб-розробника на фіксованій ставці

Добре структурований SOW дотримується логічної архітектури, яка переходить від загального до конкретного. Ось необхідні розділи для веб-проекту.

1. Заголовок та ідентифікація сторін

Документ починається з точної ідентифікації двох сторін: замовника (клієнтська компанія, яка вказує юридичну форму, номер SIREN, юридичного представника та його посаду) та постачальника (незалежний розробник або компанія). Крім того, вказуються:

• Номер SOW (особливо якщо він входить до MSA — Master Services Agreement)

• Дата набрання чинності

• Прогнозована тривалість проекту

• Контактна особа з боку клієнта та з боку постачальника

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

2. Область та опис доставок

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

Приклад формулювання для веб-додатку електронної комерції:

> Постачальник зобов'язується розробити та доставити адаптивний веб-додаток електронної комерції, побудований на Next.js 14 (фреймворк React), підключений до API REST back-end Node.js/Express, з інтеграцією Stripe для онлайн-платежів. Додаток матиме наступні модулі: каталог продуктів (до 5000 позицій), кошик, воронка конверсії з 3 кроків, захищена область клієнта (JWT), панель адміністратора.

Кожна доставка повинна бути перелічена окремо з:

• Її назвою (наприклад: «Модуль автентифікації користувача»)

• Її функціональним описом (що це робить, а не як це робиться)

• Плановою датою доставки (або розподілом по спринтам/етапам)

• Форматом доставки (репозиторій Git, URL staging, файл ZIP, технічна документація)

Для складних проектів рекомендується додати функціональний технічний опис (CDC) або Agile user stories, на які SOW явно посилається.

3. Критерії прийняття: як перевірити кожну доставку?

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

Приклад критеріїв прийняття для веб-додатку:

SOW також повинен вказувати:

• Процедуру приймання: хто тестує, якими інструментами, в якому часовому межі після доставки (приклад: клієнт має 10 робочих днів для перевірки або мотивованих письмових зауважень)

• Управління зауваженнями: незначні зауваження (косметичні помилки) не блокують платіж; важливі зауваження (неработаюча функціональність) призупиняють платіж до виправлення

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

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

4. Фінансові умови та віхи платежу

На фіксованій ставці структура платежу зазвичай пов'язана з прогресом проекту, а не з витраченим часом.

Приклад графіка платежів для проекту на 24 000 € (без податку):

• 30% при підписанні SOW: 7 200 € (авансовий платіж, охоплює фазу проектування/архітектури)

• 30% при доставці спринту 1 (доставки 1-4 затверджені): 7 200 €

• 25% при доставці спринту 2 (доставки 5-8 затверджені): 6 000 €

• 15% при фінальному прийманні та запуску в виробництво: 3 600 €

SOW уточнює штрафи за затримку з боку постачальника (наприклад: 0,5% від загальної суми за тиждень затримки, обмежені 10%) та штрафи за затримку з боку клієнта за повернення перевірки (наприклад: продовження глобального часу на период затримки перевірки).

5. Інтелектуальна власність та передача вихідного коду

Це юридично найчутливіший розділ будь-якого контракту на веб-розроблення. За замовчуванням, за французьким правом (Кодекс інтелектуальної власності, ст. L. 111-1), автор інтелектуального твору — включаючи програмне забезпечення — зберігає права навіть після доставки та платежу. Іншими словами, без явної статті про передачу клієнт платить за розроблення, але не володіє юридично кодом.

Добре написаний SOW повинен включати повну статтю про передачу. Ось приклад формулювання:

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

SOW також повинен розрізняти:

• Власний код (розроблений спеціально для цього проекту → передається клієнтові)

• Сторонні компоненти (фреймворки, бібліотеки з відкритим кодом → постачальник гарантує відповідність застосовуваним ліцензіям)

• Інструменти та методи постачальника (знання, шаблони → залишаються власністю постачальника)

• Залежності з відкритим кодом: перелічити компоненти та їхні ліцензії (MIT, Apache 2.0, LGPL…) для запобігання порушенню ліцензії

Для проектів з інноваційними розробленнями, які можуть бути запатентовані або захищені як програмне забезпечення, зверніться до нашого центру INPI: підпис, подання та сертифікація для захисту прав на етапі розроблення.

Нарешті, SOW повинен включати статтю про escrow вихідного коду, якщо клієнт бажає захиститися від несправності постачальника: код депонується у довіреної третій стороні та звільняється під визначеними умовами (банкрутство постачальника, невиконання SLA тощо).

---

Додаткові необхідні статті в SOW веб-розробника

Конфіденційність та вбудований NDA

Постачальник матиме доступ до чутливої інформації: технічна архітектура, дані клієнтів, план розроблення продукту. SOW повинен включати статтю конфіденційності (або посилатися на окремо підписаний NDA), що охоплює:

• Тривалість зобов'язання (як правило, 3-5 років після закінчення проекту)

• Визначення конфіденційної інформації

• Винятки (інформація, яка вже є публічною, законно отримана від третьої сторони)

• Зобов'язання повернути або знищити дані після закінчення контракту

Гарантії та постаставіння обслуговування після доставки

На фіксованій ставці гарантія від прихованих дефектів застосовується законом, але SOW уточнює її оперативну область:

• Гарантія правильного функціонування: протягом X місяців після фінального приймання постачальник безплатно виправляє будь-яку помилку, пов'язану з його розробленням (крім функціональних поліпшень)

• SLA виправлення: блокуюча помилка виправляється протягом 24 робочих годин; важлива помилка протягом 72 годин; незначна помилка включається в наступний цикл

• Винятки з гарантії: модифікації внесені клієнтом до коду, оновлення залежностей не затверджені постачальником

Субпідряд та людські ресурси

Клієнт повинен знати, чи може постачальник субпідрядити усе чи частину розроблення. Якщо потрібна стаття про попередній дозвіл (особливо з міркувань конфіденційності або відповідності GDPR), вона повинна бути в SOW. У критичних проектах деякі клієнти навіть вимагають назвати розробників та отримати попередній дозвіл у разі зміни команди.

Для SOW підписаних з іноземними постачальниками або в багатосторонньому контексті, рішення електронного підпису, відповідне eIDAS від Certyneo дозволяє підписувати на відстані з визнаною доказовою силою в 27 державах-членах ЄС.

---

Найкращі практики для завершення та підписання вашого SOW

Процес перевірки та поправок

Перед підписанням SOW повинен бути перевірений:

• Технічним керівником проекту з боку клієнта (перевірка функціональної області)

• Юристом або CFO (перевірка фінансових статей, IP та штрафів)

• CISO якщо обробляються особисті чи конфіденційні дані (відповідність GDPR)

Будь-яка поправка до область в ході проекту повинна бути предметом Change Order (поправки), підписаної обома сторонами, з указанням впливу на час та ціну. Без підписаної поправки будь-який запит на модифікацію вважається поза область.

Електронний підпис SOW

Рукописна підпис SOW передбачає затяжні туди-сюди з папером та помилки (застаріла підписана версія, відсутня підпис). Передова або кваліфікована електронна підпис, відповідна регламенту eIDAS, має декілька вирішальних переваг для такого типу документа:

• Посилена доказова сила: кваліфіковане часова позначка, однозначна ідентифікація підписантів

• Швидкість: SOW може бути підписаний за кілька хвилин, навіть з постачальником у дистанційній роботі або за кордоном

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

• Відстеження версій: запобігає підписанню старої версії

Наш порівняння рішень електронного підпису допомагає вам вибрати рівень підпису, відповідний вартості та чутливості ваших SOW. Для проектів вартістю понад 50 000 € або пов'язаних з розширеними статтями передачі IP, рекомендується кваліфікована підпис (найвищий рівень eIDAS).

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

Законодавча база, застосовна до SOW веб-розробника

Громадянський кодекс та юридична сила контракту

SOW є перш за все контрактом у сенсі статті 1101 Громадянського кодексу Франції: «Контракт — це угода воль між двома чи більше особами, призначена створити, змінити, передати чи припинити зобов'язання». Його юридична сила встановлена в статті 1103: «Контракти, законно сформовані, є законом для тих, хто їх укладав». Як тільки він підписаний обома сторонами, SOW є юридично обов'язуючим, включаючи його додатки та таблиці доставок.

Електронна підпис SOW регулюється статтями 1366 та 1367 Громадянського кодексу, які визнають електронному письму таку ж доказову силу, що й паперовому, за умови, що особистість підписанта надлежно ідентифікована та цілісність документа гарантована.

Регламент eIDAS № 910/2014 та стандарт ETSI

Для SOW, підписаних електронно між європейськими компаніями, регламент eIDAS (№ 910/2014 Європейського парламенту та Ради) визначає три рівні електронного підпису: простий, передовий та кваліфікований. Передова електронна підпис (SEA) базується на стандартах ETSI EN 319 132 (XAdES) та ETSI EN 319 122 (CAdES), що гарантують цілісність документа та ідентифікацію підписанта. Для контрактних зобов'язань з високими фінансовими ставками чи статтями про передачу авторських прав рекомендується кваліфікована підпис (SEQ), заснована на сертифікаті, виданому кваліфікованим постачальником послуг довіри (PSTQ), занесеним до списку довіри ЄС (TSL).

Кодекс інтелектуальної власності (CPI)

Передача прав на вихідний код регулюється Кодексом інтелектуальної власності. Стаття L. 111-1 CPI гарантує моральні та майнові права автора на будь-якому інтелектуальному творі, включаючи програмне забезпечення (ст. L. 112-2, 13°). Передача майнових прав, за статтею L. 131-3 CPI, повинна явно згадувати кожне передане право, територію, тривалість та спосіб експлуатації. Будь-який SOW, що опускає одну з цих умов, ризикує мати статтю передачі визнаною недійсною судом, залишаючи права постачальнику.

Крім того, програмне забезпечення, створене найманцем у ході своїх функцій, належить роботодавцю (ст. L. 113-9 CPI). Це правило не застосовується до незалежних постачальників, звідки нагальна необхідність контрактної статті про передачу.

GDPR (Регламент № 2016/679) та обробка даних

Якщо постачальник обробляє особисті дані від імені клієнта (наприклад: доступ до бази даних клієнтів для розроблення CRM), він кваліфікується як підпроцесор у сенсі статті 28 GDPR. SOW повинен тоді інтегрувати чи посилатися на угоду обробки даних (DPA), що визначає: природу та мету обробки, категорії даних, що стосуються, технічні та організаційні заходи безпеки, та зобов'язання постачальника у разі порушення даних. Без цього клієнт та постачальник піддаються штрафам CNIL, які можуть досягти 4% від річного світового доходу.

Комерційне право та договірна відповідальність

У разі невиконання доставок чи терміни, договірна відповідальність постачальника залучається на основі статей 1231-1 та наступних Громадянського кодексу (старі статті 1147 та далі). Статті, що обмежують відповідальність (поточення на X місяців виставлення рахунків), є дійсними між фахівцями, за умови непорожнювання контракту його сутності (ст. 1170 Громадянського кодексу).

Ілюстративні сценарії використання: SOW для веброзробника

Сценарій 1 — Scale-up SaaS замовляє власний модуль виставлення рахунків

Ці сценарії є ілюстративними: вони описують типові ситуації і не є результатами, виміряними у якогось клієнта. B2B-скейлап, що розробляє програмне забезпечення для управління персоналом, налічує близько 40 співробітників і 500 активних клієнтів, і хоче віддати на аутсорс розробку модуля автоматичного виставлення рахунків, інтегрованого в основний продукт, за заздалегідь визначений фіксований бюджет і термін розробки в кілька місяців.

Без формалізованого SOW перші тижні виявляють суттєві розбіжності: виконавець вважає, що інтеграція з API Stripe виходить за межі обсягу робіт, тоді як клієнт вважає її неявно включеною. Суперечка щодо перевищення бюджету спалахує вже на перших спринтах.

Зі структурованим SOW, що включає таблицю результатів, чіткі критерії приймання та перелік сторонніх інтеграцій, явно включених до обсягу робіт, такий тип конфлікту обмежується. Умова щодо Change Order зобов'язує підписувати додаткову угоду при будь-якому розширенні обсягу робіт. Таким чином, суперечки під час проєкту та затримки введення в експлуатацію мають зменшитися. Масштаб вигоди вимірюється на ваших власних проєктах, до і після впровадження структурованого SOW.

Сценарій 2 — Промислова група захищає передачу прав на власний ERP

Промислова група середнього розміру (близько 800 співробітників, 3 виробничі майданчики) замовляє у агенції веброзробки індивідуальну ERP-систему управління виробництвом за значний фіксований бюджет і місію, що триває тривалий період. Наприкінці проєкту агенцію викуповує конкурент. Група тоді виявляє, що пункт про інтелектуальну власність початкового договору не охоплював передачу прав на модулі, розроблені субпідрядниками — двома фрілансерами, залученими до проєкту.

Добре складений SOW передбачав би: пункт про передачу прав, що охоплює всі результати, включно з тими, що створені субпідрядниками, зобов'язання головного виконавця отримувати еквівалентні передачі прав від власних субпідрядників, і механізм ескроу вихідного коду, що активується у разі зміни контролю. У такій ситуації витрати на судові спори та часткову переробку можуть становити значну частку початкового бюджету проєкту. Масштаб розбіжності вимірюється на реальному обсязі проєкту.

Сценарій 3 — Цифрова агенція стандартизує свої SOW для прискорення продажів

Вебагенція з 15 осіб реалізує в середньому 25 проєктів за фіксованою ціною на рік, із різними бюджетами. Керівництво констатує, що переговори та підписання SOW відбирають чимало часу на проєкт з боку комерційного та юридичного відділів, тобто значний обсяг годин на рік.

Впроваджуючи стандартизовану модель SOW, доповнену генератором положень, адаптованих до кожного типу місії (сайт-візитка, веб-застосунок, електронна комерція, API), і розгортаючи електронний підпис для дистанційного завершення документів, агенція може зменшити час, витрачений на кожен SOW. Помножений на кількість проєктів на рік, цей зекономлений час становить вигоду, яку варто оцінити на власному обсязі. Електронний підпис також скорочує термін між надсиланням і фактичним підписанням, що прискорює запуск проєктів і покращує стан грошових потоків. Масштаб вигоди вимірюється на реальному обсязі агенції, до і після пілотного проєкту.

Часто задавані питання

Яка різниця між SOW за фіксованою вартістю та контрактом на основі витрачених ресурсів для веб-розробника?

На основі витрачених ресурсів підрядник виставляє рахунок за кількість відпрацьованих годин або днів, не беручи на себе зобов'язання щодо конкретного результату. За фіксованою вартістю він гарантує передачу визначеного обсягу робіт за фіксовану ціну, незалежно від фактично витраченого часу. Тому SOW за фіксованою вартістю має описувати результати та критерії прийняття з великою точністю, оскільки будь-яка двозначність щодо обсягу робіт може привести до розбіжностей з приводу того, що входило в узгоджену ціну.

Що трапляється, якщо клієнт не затвердить результат у встановлені в SOW строки приймання-передачі?

Більшість SOW передбачають пункт про «мовчазну згоду» — якщо клієнт не висловить письмових зауважень у встановлений строк (часто від 5 до 15 робочих днів), результат вважається автоматично прийнятим. Цей механізм захищає підрядника від нескінченних затримок з затвердженням і дозволяє йому ініціювати платіж за відповідний етап без очікування явної відповіді.

Кому належить вихідний код, розроблений у межах запозиченого проєкту?

За замовчуванням, згідно з французьким правом, автор твору є його власником, навіть якщо він був замовлений клієнтом. Щоб клієнт отримав права на код, SOW має включати чітку пункт про передачу прав інтелектуальної власності, в якому уточнюється обсяг передачі (використання, модифікація, сублліцензування), територія та тривалість. Без такого пункту підрядник зберігає майнові права на свій код навіть після повної оплати проєкту.

Чи має протокол приймання-передачі, підписаний електронно, таку ж юридичну силу, як і рукописний підпис?

Так, за умови що використана система відповідає європейському стандарту eIDAS. Розширений електронний підпис або кваліфікований електронний підпис визнаються юридично еквівалентними рукописному підпису у всіх державах-членах Європейського Союзу, включаючи Францію. Він становить допустиме доказ в торгових судах для підтвердження того, що результат був формально затверджений у визначену дату визначеною особою.

Чи можна змінити обсяг SOW під час проєкту за фіксованою вартістю?

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

Висновок

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

Certyneo супроводжує вас на кожному етапі: від генерування draft через наш генератор контрактів на основі AI до електронного підпису, відповідного eIDAS на нашій платформі, проходячи безпечне архівування ваших підписаних документів. Відкрийте наші пакети на сторінці цін Certyneo та почніть захищати ваші проекти вже сьогодні.