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

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

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

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

У цьому довіднику ми детально описуємо структуру повного прикладу 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. Критерії прийняття: як перевірити кожну доставку?

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

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

| Доставка | Критерій прийняття | |---|---| | Модуль автентифікації | Функціональний вхід/вихід на Chrome, Firefox, Safari (версії N-1). Час відповіді < 800 мс. Модульні тести з охопленням ≥ 80% коду. | | Воронка конверсії | Частота помилок JavaScript = 0 під час симульованого навантаження (200 одночасних користувачів via Lighthouse). | | Панель адміністратора | Функціональний експорт CSV. Правильне відображення при дозволі 1280 × 720 px мінімум. | | Технічна документація | Повний файл README.md, схема архітектури, задокументовані змінні середовища. |

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 повинен бути перевірений:

1. Технічним керівником проекту з боку клієнта (перевірка функціональної області)
2. Юристом або CFO (перевірка фінансових статей, IP та штрафів)
3. 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 замовляє власний модуль виставлення рахунків

Scale-up B2B, видавець програмного забезпечення для управління HR, з близько 40 співробітниками та 500 активними клієнтами, бажає аутсорсувати розроблення модуля автоматичного виставлення рахунків, інтегрованого в його основний продукт. Бюджет на фіксованій ставці становить 35 000 € за 4 місяці розроблення.

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

З структурованим SOW, що включає таблицю доставок, точні критерії приймання та список явно включених інтеграцій третіх осіб, цей тип конфлікту уникається. Стаття Change Order зобов'язує підписати поправку для будь-якого додавання до області. Результат, спостережений у подібних контекстах: 70-85% скорочення спорів в ході проекту та 2-3 тижні прибутку на час запуску в виробництво, згідно з даними, опублікованими SYNTEC Numérique у своєму баромері 2023.

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

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

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

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

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

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

Висновок

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

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