Перевірка чотирьох видів IT контрактів — чек-лист для СЕО

Більшість проблем, з якими до нас звертаються клієнти, виникли саме через недоліки і особливості їхніх контрактів з замовниками.

За 7 років роботи в IT галузі я бачив багато бізнесів, де контракт “дав друг”, “скачали з інтернету” або “у клієнта був свій, і він не хотів вносити зміни”. І все це навіть працювало! 

Але з часом одні помічали, що гроші з бізнесу, “як вода крізь пальці”. Інші стикнулися з відмовою оплачувати їхню роботу. Треті — потрапляли в пастку невигідних умов про неконкуренцію і т.д.

Щоб доходи вашого бізнесу були більш захищені, пропоную невеличкий чек-лист по підписанню контрактів з замовниками.

Крок 1. Перевіряємо вимоги до всіх видів контрактів

1. Предмет договору.

Впевніться, що цей пункт сформульований правильно і однозначно. Він має давати чітку відповідь на питання: “що ми робимо?” Сайт, додаток, оновлення до існуючого продукту чи щось інше.

2. Перехід прав на Intellectual Property (IP)

Найбезпечніший для IT компанії варіант, коли в контракті зафіксовано, що “немайнові права на IP переходять до замовника після всіх розрахунків за даним контрактом”.

Це положення вже не раз рятувало наших клієнтів, коли замовники (з різних причин) відмовлялися платити.

3. Вимоги до чистоти IP

Якщо воно звучить приблизно так “Компанія-розробник гарантує абсолютну чистоту інтелектуальних прав” — докладіть зусиль, щоб прибрати його із контракту.

Воно передбачає, що створюючи щось в рамках даного проєкту, ви не порушуєте нічиїх у всьому світі прав на IP.

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

А якщо у когось будуть претензій до вашого замовника з приводу IP на код чи продукт, зроблені вами, вам доведеться за це відповідати.

4. Undisputed інвойс як умова оплати.

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

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

5. Положення про непереманювання працівників.

Важливо, щоб цей пункт в принципі був. Якщо немає — пропонуйте додати. Він також повинен передбачати серйозну відповідальність за порушення — орієнтовно $50-100k.

Якщо в контракті буде просто вказано, що заборонено переманювати персонал, на практиці це вас не захистить.

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

6. Зависокі вимоги до конфіденційності.

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

У випадку типового для вас проєкту, виконати цю вимогу не буде складно.

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

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

7. Положення про неконкуренцію.

Воно точно не повинно обмежувати розвиток вашого бізнесу на практиці.

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

Менеджменту IT компанії важливо оцінити недоліки і переваги такої угоди для свого бізнесу, зрозуміти ризики її підписання. І остаточно вирішити для себе, як  діяти далі: підписуємо і виконуємо / підписуємо, але будемо порушувати / не підписуємо і ведемо подальші переговори.

8. Форс-мажор.

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

Замість розмитого “форс-мажором вважається пандемія COVID-19”, краще прописати “форс-мажором вважається ситуація, коли компанія-замовник понесла прямі і невідновні збитки через пандемію COVID-19”. І так по кожному з пунктів цього розділу.

В той же час переконайтеся, що і ваша команда може посилатися на форс-мажор для виправданого переносу дедлайнів чи інших обставин.

9. Юрисдикція розгляду спорів.

Важливо, щоб вона була доступною для вашої компанії (географічно і матеріально). Це питання щоразу варто вирішувати індивідуально. І на нього точно варто звертати увагу.

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

Бажаєте перевірити свої контракти або потрібні нові – зробимо, переходьте за цим посиланням. 

Крок 2. Перевіряємо вимоги до контрактів за видами

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

Тому, коли читаєте контракт певного виду, ви маєте розуміти: 1) що в ньому точно має бути, 2) чого там точно бути не повинно.

Отже, перевіряємо на відповідність контракти за видами:

Fixed Price:

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

Time & Material:

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

Dedicated Team:

• всі вимоги, що і для Time & Material, а також
• врегульовано питання оплати лікарняних і відпусток для людей з dedicated team,
• вказані імена спеціалістів, що входять до dedicated team,
• є процедура заміни працівників,
• вказано допустиму кількість замін працівників.

Outstaff:

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

Як це працює в реальному житті

В чек-листі ми зафіксували ідеальні вимоги до контрактів, які принесуть вам максимальну вигоду. Це те, до чого будь-який IT підприємець має прагнути.

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

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

Щоб ваші справи були в порядку, ми в Tretten Lawyers, будемо раді допомогти вам вичитати існуючий або розробити новий контракт для роботи з замовником. Звертайтеся до нас за посиланням.