Фрілансери не завжди укладають договір на розробку сайту із замовниками, покладаючись на домовленості, озвучені усно чи сформульовані в переписці. Адже сам процес узгодження і підписання документів займає певний час і потребує зусиль. Втім, співпраця на довірі доволі ризикована для обох сторін. Крім того, що один із учасників може безкарно відмовитися від виконання своїх обов’язків, є чимало ньюансів, які ускладнюють співпрацю в разі відсутності документально завірених алгоритмів роботи. Навіть коли обидві сторони мають намір добросовісно виконати всі домовленості, їх може підвести банальне непорозуміння.
Договір не лише гарантує захист як виконавця, так і замовника. Він є певною дорожньою картою, яка описує кожен етап робіт, кожну можливу ситуацію, дії партнерів у разі форсмажорів та алгоритм врегулювання спірних питань.
Навіть підписання типового договору частково зменшує ризики, але ми все ж радимо створювати окремий контракт для кожного замовника.
Хостинг-провайдер та реєстратор доменних імен Cityhost.ua пропонує читачам нашого блогу матеріал, створений спільно з IT-юристами, щоб розібратися в усіх аспектах створення договору на розробку сайту.
Етапи узгодження та укладання договору
Укладання договору починається в той момент, коли замовник та виконавець обговорюють та узгоджують всі деталі проєкту. Тому цей етап також має бути задокументований у вигляді брифу. Крім того, потрібно скласти детальне ТЗ та сформувати сам договір. Давайте розглянемо кожен крок на цьому шляху.
Заповнення брифу
Замовники дуже не люблять заповнювати бриф і намагаються пропустити цей етап, обговоривши всі деталі по телефону або в чаті. Часто відбуваються ситуації, коли замовник каже «Ви професіонал, подивіться самі, що там потрібно зробити і викладіть свої пропозиції». Така позиція нерідко виливається у результат: «Ні, це не те, що потрібно, запропонуйте щось інше».
Насправді ж бриф дуже потрібен для співпраці, бо в ньому містяться відповіді на важливі для виконавця запитання. Кожен розробник укладає свій бриф, який може виглядати подібним чином:
- Назва та галузь роботи компанії.
- Цільова аудиторія.
- Локація (місцева, всеукраїнська, міжнародна).
- Цінності, місія.
- Корпоративний стиль — слоган, корпоративні кольори, стиль промо-матеріалів (бажано надіслати ці матеріали на пошту).
- Тип сайту, який бажаєте замовити (візитка, інтернет-магазин, корпоративний сайт, наявність/відсутність блогу тощо).
- Орієнтовна структура сайту, назви розділів.
- Побажання щодо оформлення сайту.
- Приклади сайтів, на які ви б хотіли орієнтуватися.
Можна розробити типовий бриф, але все ж варто вносити в нього додаткові запитання, призначені для конкретного замовника.
Складання технічного завдання
Після заповнення брифу замовник уточнює питання та вносить пропозиції, яким він бачить майбутній сайт — основну концепцію, кількість розділів, візуальний стиль. На основі цих перемовин складається технічне завдання і одночасно з тим починається розробка договору.
У техзавданні прописується конкретний результат і всі послуги, які надає розробник. Це дуже важливо, оскільки «зробити сайт» — доволі розмите поняття. Може трапитися, що власники фірми звернулися до фрілансера, який тільки пише код, і не займається дизайном і контентом. Тож він буде чекати від замовника макет, тексти та фото. Інші ж фрілансери можуть зробити сайт «під ключ» і мають розгалужену мережу субпідрядників — дизайнерів, копірайтерів, фотографів тощо.
Техзавдання прописується максимально детально і включає в себе вимірювані параметри, на кшталт: «Сайт має складатися з 5 розділів: головна сторінка, сторінка «Про нас», сторінка контактів, сторінка для представлення товару, розділ для блогу».
Якщо у сайту є блог або розділ новин, у ТЗ також пишеться, чи має виконавець заповнити цей розділ 2-3 новинами, чи робить тільки структуру блогу.
Чим докладніше буде описано кожен нюанс розробки сайту, тим менше залишиться простору для непорозумінь.
Обговорення та узгодження тексту договору
Для початку потрібно визначитися з типом договору. Існують два типи — договір на надання послуги та договір підряду. Вони відрізняються тим, що у першому випадку ключовим є сам процес роботи, а у другому — результат. Наприклад, SEO-просування не має кінцевого результату і триває завжди, доки існує сайт — тоді заключається договір на співпрацю. Для розробки сайту більше підходить договір підряду, оскільки замовнику потрібен сайт, його цікавить завершена робота та її плоди.
Далі потрібно прописати почергово всі головні етапи співпраці:
- Надання замовником матеріалів розробнику. Це можуть бути тексти, фото, відео, логотип тощо.
- Створення та затвердження макету.
- Розробка сайту.
- Внесення правок.
- Перевірка та прийом роботи.
- Підписання актів про виконання робіт.
- Оплата виконаної роботи.
Це орієнтовний перелік, бо у кожного сайту можуть бути свої етапи. Наприклад, виконавець не лише розробляє сайт, а й проводить маркетингові дослідження, вивчає ринок, аналізує конкурентів та на основі отриманої інформації дає рекомендації замовнику щодо концепції сайту — це окремий етап, який також потребує зусиль та впливає на формування вартості замовлення.
Основні правила складання договору
Є елементи договору, без яких він не зможе стати чітким документом, що дисциплінує сторони в процесі роботи.
Терміни
Обов’язково потрібно прописати терміни виконання кожного етапу. Якщо уважно придивитися до порядку дій, ви побачите, що частина роботи залежить від виконавця (створення сайту, внесення правок), а друга частина — від замовника (надання матеріалів, перевірка, прийом роботи). Якщо в договорі прописана тільки фінальна дата, коли розробник повинен здати сайт, він може потрапити у часову пастку — строки затягнуті, але не з його вини.
Також потрібно прописати дії сторін в разі, якщо хтось із партнерів виконує свої обов’язки неналежним чином. Наприклад, якщо замовник не здійснив прийом роботи протягом семи днів, вона автоматично вважається прийнятою.
Прописуйте не конкретні дати, а час між етапами, наприклад: «Розробник зобов’язується надати початковий макет сайту протягом 4 днів з моменту отримання матеріалів».
Вимірюваність
Всі пункти в договорі мають бути описані таким чином, щоб їх можна було виміряти якимось конкретним параметором — часом, дією, результатом. Наприклад, обговорення та внесення правок відбувається протягом тижня після того, як розробник надішле електронною поштою посилання на готовий сайт на таку-то адресу (конкретну). Таким чином знижується вірогідність плутанини, коли одна сторона чекає результат у Вайбері, інша пише повідомлення у Фейсбуці, а час спливає.
Конкретика
Дуже важливо прописувати чіткі формулювання. До прикладу, «надати макет сайту» — це нечітке формулювання. А ось «надати макет сайту у вигляді проекту в Figma з доступом редактора» — це вже щось конкретне. Так само потрібно прописувати, на які матеріали очікує розробник — фотографії у форматі .png з розширенням не менше 600 пікселів по ширині, тексти у форматі Google Docs з відкритим коментуванням.
Далеко не всі замовники орієнтуються в комп’ютерних технологіях. Якщо ваш клієнт — невелике будівельне підприємство чи ФОП, який ремонтує велосипеди, для нього не існує ніяких опцій за замовчанням. Тому конкретний і детальний опис всіх вимог та етапів — це скоріше необхідність, інакше на клієнта і розробника може чекати багато сюрпризів.
Відео курси за схожою тематикою:
Збалансованість
У договорі мають бути рівномірно дотримані права та обов’язки обох сторін. Не має бути такого, що в усьому винен замовник або вся відповідальність лежить на виконавцеві. Якщо якийсь етап роботи залежить від дій певної сторони — вона несе відповідальність за його реалізацію або сплачує неустойку (чи підпадає під інші санкції) в разі невиконання обов’язків з власної вини.
Пункти договору, які потребують уваги
У цей розділ винесемо ті аспекти співпраці, про які фрілансери-початківці можуть не знати чи не вміти правильно їх врегулювати.
1) Кількість та порядок поправок, внесення змін у ТЗ
Важливим є питання кількості можливих правок та внесення змін у технічне завдання.
Найкращий і перевірений метод — коли замовник надсилає всі правки в одному документі, а виконавець вносить їх всі одразу. Оптимально робити три кола правок; якщо у клієнта з’являються додаткові правки, це має оплачуватися. Така політика в першу чергу захищає виконавця від десятків переробок і дисциплінує замовника, який з більшою уважністю вирішує, чи потрібна ця правка.
Правки мають бути конкретними та аргументованими, без формулювань на кшталт «зробіть якось інакше, але не так, як є».
Щодо ТЗ — всі зміни, які замовник хоче внести в нього вже під час роботи, мають також додатково оплачуватися. В разі потреби можна прописати, які зміни та якого масштабу можна вносити, скільки коштує кожна з них. Одна справа поміняти фотографію, і зовсім інша, коли замовник на фінальній стадії вирішує замінити CMS (по факту це означає робити все наново).
2) Авторські та майнові права
Питання авторських прав стосується як матеріалів, які використовуються на сайті під час розробки, так і використання матеріалів сайту після завершення робіт.
Важливо відстежувати, чи є унікальним контент, який надає замовник або пропонує виконавець. Для убезпечення обох сторін потрібно прописати порядок дій для запобігання ситуаціям, коли можуть бути порушені авторські права третіх оосіб або одного з учасників проєкту. Наприклад, сторона, яка надає матеріали, має долучити документи, які підтверджують право власності на них — квитанції на придбання фото- та відео-матеріалів чи інший контент. Або для спрощення процедури можна просто зазначити, що відповідальність за порушення авторського права несе сторона, яка надала матеріали.
До об’єктів авторського права відносяться назва сайту, тексти, фото, відео, дизайн та код. У договорі має бути вказано, кому належать майнові та авторські права на всі елементи проєкту після його завершення та чи може розробник використовувати якісь із матеріалів для подальшої роботи.
Для орієнтиру використовуйте Закон про авторське право і суміжні права.
3) Співпраця з іншими підрядниками
Сайт складається з багатьох компонентів, і не всі роботи підрядник може виконати самостійно. Якщо він звертається до субпідрядників для створення дизайну чи текстів, це також має бути зафіксовано у договорі. Але в будь-якому разі за якість кінцевого результату відповідає виконавець.
4) Відповідальні особи за комунікацію з виконавцем
Цей момент особливо вартий уваги, якщо компанія-замовник велика, в ній є багато різних відділів та працівників. Скоріш за все, виконавець не працюватиме напряму з директором, а спілкуватиметься з кимось із менеджерів. В такому разі договір має містити ПІБ, посаду та контакти особи, відповідальної за комунікацію. Не завадить також вказати, які канали спілкування вважаються офіційними — ними можуть бути не лише пошта, а й акаунт у Телеграмі чи сторінка у Фейсбуці.
В разі, якщо різні аспекти будуть узгоджуватися з різними людьми, це також має бути вказано. Наприклад, за фінансові питання відповідає бухгалтер, за узгодження макету — дизайнер компанії, всі інші питання — до менеджера. Але все ж краще, коли проект курує одна конкретна людина і несе відповідальність за своєчасну та ефективну комунікацію.
5) Форсмажорні обставини
Бувають ситуації, коли хтось не може виконати свої обов’язки з причин, які не залежать від нього. На цей випадок потрібно винести окремим пунктом подолання форсмажорних обставин: що можна вважати такими обставинами та порядок дій в разі їхнього виникнення (наприклад, відстрочка для виконавця для завершення робіт або відстрочка оплати для замовника). Зазвичай в цей перелік входять пожежі, стихійні лиха, бойові дії, страйки, введення карантину та інші обставини, які не можна передбачити та підготуватися до них.
6) Фінансові питання
В цю категорію входить не лише порядок оплати за виконану роботу (аванс, гонорар) а й супутні витрати. Сюди можна віднести оплату домена та хостинга, замовлення текстів, дизайну, фотозйомки тощо. Виконавець може ці витрати включити в суму гонорару, але можна і покласти їх на замовника. Це все обговорюється і прописується. Також у договорі мають бути зафіксовані такі моменти як порядок оподаткування, розрахункова валюта, рахунки для отримання коштів, порядок перерахунку та спосіб підтвердження отримання коштів виконавцем.
Безкоштовні вебінари за схожою тематикою:
7) Прийом роботи або відмова від нього
На перевірку та прийом роботи виділяється певний термін, протягом якого замовник може висунути обгрунтовані зауваження та вимоги щодо доопрацювання сайту або відмовитися прийняти роботу, надавши чіткі аргументи. Відмовитися від прийому роботи можна тільки в разі, якщо сайт не відповідає технічному завданню, виконаний з порушенням законів або має інші об’єктивні недоліки, які унеможливлюють його використання і які можна довести. Не можуть бути враховані суб’єктивні аргументи, коли сайт виконаний за всіма домовленостями, але розробник уявляв собі його якось інакше. Якщо розробник виконав всі пункти ТЗ і договору, клієнт не може відмовитися від підписання акту.
В разі, якщо йдеться про масштабні проєкти з великою сумою оплати, радимо звернутися за консультацією до юриста, який допоможе прописати договір максимально чітко та уникнути «шпарин» для подвійного трактування.
Статті за схожою тематикою
