Dedicated Team: обов’язкові пункти для дійсно взаємовигідного контракту

Dedicated Team — одна з найпоширеніших форм взаємодії між IT-компаніями та їх замовниками в Україні. І ніби всі вже знають та розуміють специфіку таких контрактів. Але в юристів в роботі майже постійно є кейси, де між замовником та компанією-виконавцем виникають суперечності під час реалізації проєктів за цією моделлю співробітництва.  

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

Обов’язковий мінімум для контракту Dedicated Team

За своєю суттю контракт Dedicated Team — це той самий Time&Material (далі T&M), але з певною специфікою. Класичний T&M передбачає оплату не за конкретні види робіт або досягнення якогось критерію якості, а за людино-години, які потрібні на реалізацію проєкту. Таку форму співробітництва (і контракта, відповідно) застосовують, коли замовник має кінцеве бачення продукту, але конкретне ТЗ на весь проєкт розробити неможливо.

Я при кожній нагоді застерігаю українських айтівців: у T&M ні в якому разі не може бути оплати робіт за досягнення критеріїв якості. Виключно людино-години в обумовлені заздалегідь терміни!

А вже специфіка Dedicated Team — це коли замовник просить виділити на певний час команду з конкретними фахівцями — аби саме вони працювали над втіленням його проєкту. Тобто тут важливі не суто кваліфікація чи досвід розробників — замовник не просить вас знайти якихось PHP-девелоперів рівня Middle або Senior. Йому важливі конкретні Катя і Діма. І саме з ними замовник проводить співбесіди та затверджує їх. Зазвичай організаційне й технічне керівництво виділеною командою здійснює компанія-виконавець.

Отже, підсумовуючи, в контракті Dedicated Team обов’язково мають бути положення, що фіксують наступне:

Нетипові положення в контракті Dedicated Team, які захистять IT-компанію

Розглянемо кілька випадків, щодо яких треба прописати окремі умови в контракті.

№1. Якщо не було задач для Dedicated Team, замовник все одно платить по контракту

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

Розумію, що зазвичай таких питань не виникає. Більш типова ситуація, коли замовник бере Dedicated Team і намагається витиснути з них по максимуму. Саме тому в контракті зазвичай вказують, що люди з виділеної команди мають працювати не більше, ніж 8 годин на день, наприклад. Тобто всі розуміють, що є сенс обмежити максимальну завантаженість розробників — аби їм не довелося працювати по 20 годин на добу.

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

Тепер, спираючись на досвід, ми рекомендуємо і всім іншим IT-компаніям враховувати цей момент. Тому доповню попередній перелік вимог до контракту Dedicated Team ще одним пунктом:

№2. Передбачена процедура скорочення команди за вимогою замовника

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

Звісно, є випадки, коли ми бачимо: на перші півроку нам потрібно 10 людей, а на наступні три місяці — 20. Тоді прописуємо це в контракті.

Але тут я хочу поговорити саме про випадки, коли такої ясності немає. І тоді важливо контрактом передбачити процедуру скорочення кількості працівників з Dedicated Team. Для початку проговоріть з замовником, як ви будете це робити так, аби для обох cторін то було справедливо і вигідно.

Інакше є ризики стикнутися з ситуацією, коли в один день замовник говорить: «все, 10 з 20 розробників прибираємо з наступного тижня». А це ж живі люди. Якщо ми їх взяли спеціально на цей проєкт, то маємо дотриматися місячного нотісу, щоб їх звільнити (тобто платити їм ще місяць зарплату). Якщо це ваші постійні працівники, вони теж підуть на бенч, поки ви не знайдете для них проєкти. В результаті — IT компанія матиме збитки.

Розмір такої компенсації — це вже предмет ваших перемовин. В ідеалі — 100% за місяць роботи скорочених працівників. Але так на практиці буває рідко. Зазвичай це 70% або і 50%. 

Отже, ще один важливий пункт, який ми наполегливо рекомендуємо вносити до контракту Dedicated Team:

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

Коли всім вже гаряче — домовлятися складніше

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

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

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

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