Як зберегти дохід за Time&Material: 4 реальні кейси

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

Time&Material (далі T&M) найбільш поширений вид контракту в українському IT середовищі. Більшість впевнені, що добре розуміються на цій моделі співробітництва. Але практичний досвід юристів Tretten Lawyers показує, що є ряд поширених помилок у застосуванні саме T&M. Помилок, через які IT компанії втрачають або недоотримують свої гроші, часто — не помічаючи цього. Що це за помилки та як їх уникати — розбираємо далі.

Матеріал опубліковано на сайті ain.ua

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

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

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

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

1. Замовник не має чіткого ТЗ, а тільки загальне розуміння, яким має бути результат.

2. Контракт не містить критеріїв якості в будь-якому вигляді.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Там було вказано, на перший погляд правильні для T&M речі: на конкретну дати має бути виконаний визначений об’єм робіт. А от вже уточнення “по undisputed інвойсу” там виявилося зайвим. Тобто, навіть якщо потрібний об’єм робіт виконано, але клієнт чимось незадоволений (а незадоволений він може бути чим завгодно — критеріїв же якості в договорі немає), то він отримує право не оплачувати роботу IT компанії, поки не зроблять так, щоб він був задоволений. А оплата часу, витраченого на внесення змін, не передбачалася контрактом.

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

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

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

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

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

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

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

5. Немає non-solicitation clause

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

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

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

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

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

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

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

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

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

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