Юридичні аспекти проектних угод

Що таке проектна угода

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

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

Проектна угода не те саме, що загальний договір на надання послуг. Договір на послуги може охоплювати багато завдань упродовж певного часу, тоді як проектна угода прив’язана до одного чітко визначеного результату. Фриланс-дизайнер, який підписав проектну угоду на бренд-пакет, не має потім безкоштовно додавати моушн-графіку. Розробник не повинен чути після погодження, що мобільна версія «очевидно входила» в роботу.

Є й практична причина тримати угоду вузькою. Невеликі проєкти рухаються швидше, коли обсяг робіт визначений точно, і 5-сторінкова угода часто працює краще за 20-сторінкову, якщо обидві сторони справді її читають. Нікому не подобається юридичний туман. Чіткі умови кращі за хитромудрі формулювання, а розуміння юридичні аспекти проектної угоди допомагає узгодити обсяг і очікування.

Чому юридична перевірка важлива до підписання

Підписання без перевірки може створити три поширені проблеми: нечіткий обсяг робіт, спори щодо оплати та ризик відповідальності. Усе це трапляється в реальній роботі, а не лише в судових історіях. Клієнт може думати, що «сайт» означає 12 сторінок, автор контенту — що «пакет для блогу» це 4 статті, а фрилансер може виявити, що жодне з цих припущень не зафіксоване письмово.

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

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

Юридична перевірка також допомагає, коли клієнт використовує шаблон з іншої країни або іншої галузі. Пункт, скопійований із будівельного контракту, може майже не мати сенсу для дизайну чи копірайтингу. А пункт із програмного проєкту може припускати питання права власності на код, які взагалі не стосуються редакторської роботи. Якісна перевірка виявляє це ще до того, як з’являться підписи.

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

Ключові положення, які варто включити

Першим іде обсяг робіт. Його слід описати простою мовою й перелічити як те, що входить, так і те, що не входить. Якщо клієнту потрібно 10 описів товарів, так і вкажіть: 10. Якщо пости для соцмереж не входять у завдання, це теж потрібно зазначити. Формулювання на кшталт «пов’язані завдання» може стати пасткою.

Результати роботи слід називати настільки конкретно, щоб стороння людина могла їх однозначно ідентифікувати. Пакет логотипу може включати PNG, SVG і вихідні файли. Звіт може включати PDF і редаговану версію. Розробнику можуть знадобитися доступ до staging-середовища, нотатки щодо розгортання та одна передача знань у форматі дзвінка. Числа допомагають.

Термінів недостатньо, якщо вони подані розмито. «Якнайшвидше» — це не дедлайн. «До 18 квітня» — це дедлайн. Якщо у проєкті 3 етапи, кожен із них має мати дату або умову, яка запускає наступний крок. Це запобігає типовому «Я думав, ви мали на увазі наступний тиждень».

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

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

Права на розірвання важливі, тому що проєкти справді завершуються достроково. В угоді слід визначити, чи може кожна зі сторін розірвати її після повідомлення, що стається з уже виконаною роботою і чи належить часткова оплата. Якщо клієнт скасовує проєкт після виконання 70% роботи, угода має пояснити, як оцінюються ці 70%. Без цього спір зазвичай швидко стає емоційним.

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

Інтелектуальна власність і право власності

Положення про інтелектуальну власність визначають, хто чим володіє після завершення роботи. Авторське право часто є першим питанням. У багатьох проектних угодах фрилансер створює роботу, а потім передає права після оплати. Така передача має бути прописана чітко, а не натякнута.

Формулювання work-for-hire може змінити результат, але лише якщо відповідна правова система його визнає. Деякі клієнти просять повну передачу прав. Інші хочуть ліцензію, тобто можуть використовувати роботу на визначених умовах, не володіючи всім повністю. Ліцензія може бути вузькою або широкою. Передача прав може бути негайною або відкладеною до моменту, коли рахунок буде оплачено.

Це має практичне значення. Проєкт із бренд-ідентики може вимагати, щоб клієнт володів фінальними файлами. Фотограф може хотіти зберегти право на портфоліо. Підрядник із розробки може прагнути зберегти бібліотеки повторно використовуваного коду. В угоді слід зазначити, чи входять чернетки, вихідні файли, сирі матеріали та редаговані файли. Одна ця деталь може заощадити тиждень подальшого листування.

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

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

Конфіденційність і захист даних

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

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

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

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

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

Відповідальність, гарантії та відшкодування

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

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

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

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

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

Застосовне право та вирішення спорів

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

Місце розгляду теж має значення. Угода може вимагати, щоб спори розглядалися в певному суді або місті. Це може зменшити невизначеність, але також може збільшити витрати, якщо інша сторона знаходиться далеко. Фрилансер в одній країні не має дізнатися після підписання, що всі спори доведеться вирішувати за 2 000 миль.

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

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

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

Практичні кроки перед підписанням

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

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

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

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

І нарешті, підписуйте лише тоді, коли обидві сторони розуміють ті самі умови. Попросіть одне просте пояснення найбільшого ризику, одне уточнення щодо графіка платежів і одне речення про право власності. Якщо ці 3 відповіді все ще нечіткі, проектна угода ще не готова.