Time&Material (далі T&M) – найпоширеніший вид контракту в українському IT. Більшість впевнені, що добре розуміються на цій моделі співробітництва. Але практичний досвід юристів Tretten Lawyers показує, що у застосуванні саме T&M є низка поширених помилок, через які IT-компанії втрачають або недоотримують свої гроші, часто не помічаючи цього. Що це за помилки та як їх уникати — у колонці для AIN.UA розповідає ІТ-адвокат, засновник і СЕО Tretten Lawyers Максим Носарев.

Основні складові T&M як форми співробітництва і контракту

Класичний контракт T&M передбачає модель співробітництва, за якої замовник оплачує не досягнення певного результату (так звані критерії якості), а години, витрачені фахівцями на розробку і впровадження продукту. Найчастіше застосовується у масштабних тривалих проєктах, коли на старті складно визначити конкретне ТЗ і точні затрати часу. 

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

Отже, суть контракту T&M полягає в наступному:

1. Замовник не має чіткого ТЗ, а тільки загальне розуміння, яким має бути результат.
2. Контракт не містить критеріїв якості в будь-якому вигляді.
3. Оплата робіт здійснюється за години, витрачені підрядником в певний період роботи за проєктом.
4. Переробки, усунення багів оплачуються замовником додатково за таким же принципом підрахунку витрачених годин.

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

Як перестати втрачати кошти, працюючи за T&M

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

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

Нижче – найпоширеніші положення, які є потенційно ризикованими.

1. Домовилися про T&M, а підписали Fixed Price

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

Напочатку вони доводили мені, що це T&M і «Що значить ми не повинні відповідати за якість? Ми ж робимо якісну роботу!» При цьому сама специфіка їхнього проєкту не може передбачати детального ТЗ — тобто критеріїв якості. Як тоді вони можуть брати на себе зобов’язання в контракті досягти цих критеріїв якості? 

Тобто по суті вони опинилися в ситуації, коли їхні домовленості з клієнтом виглядали так: «Критеріїв якості немає (як і передбачає T&M), але ми погоджуємося, що ви нам заплатите тільки тоді, коли ми досягнемо критеріїв якості». Для компанії це було сюрпризом.

Ми переконали їх спробувати новий (для них) підхід в роботі за T&M — оплата робіт виключно за людино-години в одному їхньому невеличкому проєкті вартістю $15 000. В результаті за переробку багів вони виставили клієнту $1500. Це небагато, але якщо порахувати їхні втрати за період, коли вони цього не робили, виходить чимала сума, яку вони не доотримали.

2. Оплата undisputed інвойсів

Ще один з наших клієнтів, який звернувся з типовою проблемою – «не заплатили», – був здивований, що, підписавши контракт, сам погодився на те, що їм оплачуватимуть лише undisputed інвойси [тобто ті, що не оскаржуються сторонами – ред.]. Він просто не звернув увагу на це слово у величезному британському контракті замовника на 50 сторінок.

Там було вказано на перший погляд правильні для T&M речі: на конкретну дату має бути виконаний визначений обсяг робіт. А от вже уточнення щодо «undisputed інвойсу» там виявилося зайвим.

Тобто, навіть якщо потрібний обсяг робіт виконаний, але клієнт чимось незадоволений (а незадоволений він може бути чим завгодно — критеріїв же якості в договорі немає), то він отримує право не оплачувати роботу IT-компанії, поки не зроблять так, щоб він був задоволений. А оплата часу, витраченого на внесення змін, контрактом не передбачалася.

3. Гарантійний термін на результат

Положення з такою вимогою періодично зустрічається в контрактах, які замовник пропонує укласти IT-компанії. Це теж досить нелогічна штука для T&M, яка може обернутися для компанії-розробника купою неприємностей.

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

4. Заборона працювати з іншими замовниками в цій бізнес-ніші

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

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

Тому тут я рекомендую, якщо і погоджуватися на таку умову, то не більше, ніж на 1 рік, і якщо напрям, в якому вас обмежують, не є вашою основною нішею.

5. Немає non-solicitation clause

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

Та все ж я рекомендую включати положення про непереманювання до T&M. З одного боку, тут є місце для психологічного ефекту. Більшість наших замовників, особливо з розвинених країн, законослухняні. Тобто, якщо є таке правило, то люди намагатимуться його не порушувати.

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

Саме тому цей пункт має передбачати серйозну відповідальність за порушення, хоча б $50 000-100 000. Якщо замовник відмовляється вносити такі суми в контракт, варто замислитись, чи готові ви втратити когось із співробітників заради того, щоб попрацювати з цим клієнтом.

6. Надмірні вимоги конфіденційності щодо проєктів, важливих для портфоліо

Чотири роки тому один з наших клієнтів підписав контракт з дуже важливим замовником. Зробив ту роботу і розмістив інформацію про це в своєму портфоліо. Крім репутаційних плюсів, зазначення того, що компанія зробила цей проєкт, дає йому притік 20-30% нових клієнтів. Компанія-замовник офіційно дозволила йому це зробити. 

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

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

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