Перевіряємо, чи все ок в IT-контракті. Чек-ліст від юристів

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

Багато ІТ-бізнесів основу для документа взяли у колег або скачали з інтернету. Комусь контракт розробляли юристи, але “допилювали” його вже сам фаундер з бухгалтером чи ейчаром. І все це непогано працює якийсь (іноді досить тривалий) час. Але одного разу роботу не оплачують, найкращі розробники перейшли працювати до клієнта, замовник постійно просить замінити когось з Dedicated Team, а вже витрачено на це купу часу і грошей. 

IT-адвокат, СЕО юркомпанії Tretten Lawyers Максим Носарев розказав, на що варто звернути увагу до підписання контракту та захиститися від неоплати робіт та конфліктів через терміни. Він пропонує компаніям користуватися коротким чек-листом для первинної перевірки якості цього документу.

Які місця в IT-контракті найвразливіші

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

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

Проте часто буває так, що в контракт Time&Material потрапляють положення з Fixed Price. Або я вже не раз бачив, коли компанія по суті домовляється про Dedicated Team, а підписує Time&Material. В результаті вони не завантажують виділену команду іншими проектами, але замовник при цьому оплачує тільки фактично витрачений час. А години простою (які найчастіше і стаються з вини замовника) оплачує сама компанія.

Таких “намішаних” IT-контрактів зараз в Україні безліч. Найчастіше вони мають перекіс в сторону більш широкого захисту інтересів саме замовника, і роблять вразливою компанію-виконавця. Аби у вашій роботі ставалося якомога менше таких прикрих ситуацій, розробили з колегами чек-лист. З ним ви самі зможете перевіряти контракти на відповідність реальним домовленостям з потенційними партнерами.

Чек-лист для перевірки IT контракту

1. Перевіряємо положення, спільні для всіх видів контрактів

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

Переконайтеся, що цей пункт дає однозначну відповідь на питання “що ми робимо?” Оновлюємо вже існуючий продукт, розробляємо новий сайт, додаток і т.д.

#2. Умова оплати — undisputed інвойс

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

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

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

Найкраще для вас рішення — зафіксувати, що немайнові права на IP переходять до замовника після всіх розрахунків за даним контрактом. Це найочевидніша підстраховка для виконавця на випадок, якщо замовник з якихось причин вирішує не платити.

#4. Вимоги до чистоти IP

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

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

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

#5. Непереманювання персоналу

Цей пункт точно повинен бути в контракті з замовником. Але просте “заборонено переманювати персонал” ніяк вас не захищає. Додавайте серйозну відповідальність за порушення — хоча би $50-100k. Якщо клієнт не погоджується з такою умовою, варто замислитися. Чи готові ви потенційно втратити когось з команди заради можливості працювати з цим клієнтом? І взагалі, якщо замовник так сильно переживає через велику суму штрафу за переманювання співробітників, чи не означає це, що він насправді і планує їх переманити?

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

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

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

#7. Неконкуренція

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

Якщо вас завантажать роботою на цей період, або якщо для вас конкретна ніша не така вже й важлива — можна погоджуватися. Але якщо ваша ситуація близька до наведеного прикладу — варто зважити всі “за” і “проти”.

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

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

#9. Форс-мажор

Переконайтеся, що положення про нього сформульовані максимально конкретно. Особливо в умовах реальної війни в Україні. В наш непростий час потрібно прямо дуже прискіпливо виписувати цей розділ контракту. Бо до війни ніхто з нас взагалі його не читав, правда? А ще необхідно піклуватись про те, щоб ви на практиці змогли довести причинно-наслідковий зв‘язок між тим, що написали в цьому розділі, і неможливістю виконати свої обов’язки за контрактом. Для багатьох буде сюрпризом, але форс-мажор не працює в автоматичному режимі. Тобто неможливо послатися на форс-мажор і зафейлити дедлайни перед замовником просто тому, що у нас йде війна. Треба довести, яким конкретно чином війна вплинула саме на ваш дедлайн саме за цим проєктом. Інакше нічого не вийде.

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

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

Отже, що має бути в контракті:

Time & Material:

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

Dedicated Team:

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

Outstaff:

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

Fixed Price:

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

Як перевірка контракту за чек-листом працює на практиці

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

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

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

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

Автор: Максим Носарев, СЕО Tretten Lawyers