Будь-яка IT компанія рано чи пізно стикається з тим, що замовник відмовляється оплачувати її роботу повністю чи частково. Часто це пов’язано зі зміною бачення замовника щодо кінцевого результату, з неточним формулюванням ТЗ, із неврахуванням ризиків і додаткових витрат, які виникають в ході робіт тощо.
Іноді ваш контрагент просто може виявитися непорядною людиною. І ще купа причин може призвести до такої неприємної ситуації. Та всі вони найчастіше стаються тоді, коли замовнику є за що зачепитися в контракті, щоб умовно законно не сплачувати за вашу роботу. Тому сьогодні розглянемо, які положення в контрактах захищають розробників від загрози несплати за вже виконані роботи.
Між продажем і стартом робіт
Продажі в IT – досить складний і часом тривалий процес. Багато хто вважає, що коли сейлз з клієнтом ударили по рукам, залишається тільки підписати контракт – і можна починати працювати. Та це хибна і небезпечна позиція.
Адже вам далі потрібно не просто підписати контракт, а провести ще одну стадію перемовин з потенційним партнером. Адже важливо узгодити також питання вашого співробітництва, які не обговорювали до цього.
Зазвичай сейлзи домовляються про те, що взагалі хоче отримати замовник, про модель співробітництва (Time&Material, Fixed Price чи інш.), бюджет і терміни, про те, які спеціалісти будуть задіяні і які технології вони мають застосовувати.
Але є ще ряд деталей. На них часто не звертають уваги до перших проблем у проєкті. Якщо у вас є якийсь стандартний контракт або замовник пропонує свій, майте на увазі, що зафіксовані в них способи вирішення проблемних ситуацій можуть бути не на вашу користь.
Саме тому, перш ніж підписувати контракт, радимо обговорити з клієнтом наступні питання:
- вимоги до якості продукту (якісні показники, зафіксовані в ТЗ) і чи потрібні вони в даному випадку,
- способи припинення дії контракту,
- позиції сторін щодо переманювання персоналу,
- процес переходу інтелектуальної власності від компанії-розробника до замовника,
- способи прийому-передачі робіт,
- в якому суді за потреби будете вирішувати спірні питання.
Минулого року до нас звернувся фаундер IT компанії, яка опинилася в ситуації, коли замовник не хотів оплачувати перший спринт. Працювали по Time&Material, а замовник вимагав внести зміни у продукт, які не були обумовлені на початку, без оплати додатково витраченого командою часу. В той же час в них вже був законтрактований другий спринт. В контракті було зафіксовано, що з одного боку, вони можуть розірвати стосунки з замовником, попередивши його за три місяці, і не було нічого сказано про те, що вони мають право не виконувати роботи по другому спринту в разі несплати попереднього. З іншого боку, було положення про те, що в разі нанесення збитків замовнику IT компанія змушена їх компенсувати. Невиконання другого спринта замовник розцінював як нанесення йому збитків.
На стадії підписання контракту вони не звернули уваги на ці фрази в ньому, вважаючи їх простою формальністю. Адже не планували ані розривати стосунки з клієнтом, ані наносити йому збитки. Тобто наш клієнт потрапив у пастку, яка була закладена в контракті. Їм довелося вносити зміни, витрачаючи на це неоплачені клієнтом людино-години. Замість очікуваних 3 000$ доходу отримали лише 500$.
Бажаєте перевірити свій контракт з замовником – переходьте за цим посиланням.
Положення контракту, які захищають від несплат
Отже, сподіваюсь, я переконав вас, що контракт з замовником – це не просто формальний документ, який потрібно підписати, щоб зайшли гроші. Контракт – це детальні правила подальшої взаємодії між IT компанією і її клієнтом. Їх важливо обговорити і зафіксувати.
Не те щоб я закликав з підозрою ставитися до кожного нового партнера. Просто ясність і однозначність по деяким ризиковим питанням захистять ваш бізнес від бажання замовника не платити або платити менше.
Адже такі ситуації виникають завжди неочікувано. Тому і важливо, щоб кожен підписаний компанією контракт був максимально безпечним для вашої команди.
Раджу завжди, без будь-яких особливих причин дотримуватися наступних правил:
1. Якщо працюєте по Time&Material уважно простежте, щоб контракт не фіксував якісних вимог до продукту в будь-якому вигляді.
Адже Time&Material передбачає оплату витрачених на роботу людино-годин (спринтів, майлстоунів і т.д.). Його рейт через те і нижчій, що в нього не закладено додаткові кошти на потенційні переробки. Якщо це правило порушено, є великий ризик, що ви будете за власний рахунок якийсь час вносити зміни в продукт, допоки не задовольните замовника.
2. Якщо працюєте по Fixed Price, детально обговоріть з замовником кінцевий результат, щоб максимально правильно зрозуміти його бачення. А також вимагайте чіткого ТЗ без критеріїв, які можна трактувати неоднозначно.
Наприклад, часто бачимо в контрактах вимогу, щоб “кінцевий продукт відповідав обгрунтованим вимогам до подібних продуктів на ринку”. Виглядає як формальна фраза ні про що.
На практиці у випадку непорозумінь клієнт може звернутися до цього положення, щоб не оплачувати виконані вами роботи. Адже цю вимогу суб’єктивно можна трактувати як завгодно.
3. Незалежно від виду контракту зафіксуйте, що права на IP (інтелектуальну власність) переходять до замовника після повної оплати ним робіт по даному контракту.
Це положення – реальний захист для компанії-розробника. З ним, особливо в поєднанні з наступним правилом, ризик неоплати вашої роботи досить низький.
4. Домовтеся про це з клієнтом, а за потреби зафіксуйте в контракті, що під час проєкту функціонал продукту ви будете демонструвати, додавши сам код на ваш репозиторій. А кінцевий результат робіт замовник отримує після того, як остаточно з вами розрахується.
5. Якщо у контракті є положення про те, що “замовник сплачує тільки по undisputed інвойсам”, докладіть максимум зусиль, щоб його позбутися.
Undisputed інвойс – це той, що не оскаржується сторонами. Тобто, якщо замовник буде не згоден з чим завгодно у вашому інвойсі: якістю, термінами, об’ємом чи просто йому суб’єктивно не сподобається результат – він матиме право не оплачувати вашу роботу.
Ця вимога досить часто зустрічається в контрактах іноземних замовників. Зрозуміло, що не завжди до неї доходить діло. Але у випадку конфлікту, ви будете практично не захищені від несплат замовника.
Як це працює на практиці
Кілька місяців тому до Tretten Lawyers звернувся фаундер невеликої української IT компанії з питанням “що робити – клієнт винен нам $45k, не розраховується вже декілька місяців?”
Ми вивчили їхній контракт з цим замовником і побачили в ньому:
- замовник повинен сплачувати лише undisputed інвойси,
- процедура диспьюту не прописана,
- юрисдикція судових спорів – USA,
- IP переходить до замовника лише після остаточних розрахунків за цим договором.
Судитися в USA за $45k було економічно недоцільно. У разі перемоги (яка зовсім не була гарантованою) майже всі отримані кошти пішли б на перельоти і адвокатів. Але положення про IP, яка до замовника переходить тільки після оплати робіт, вселяло надію.
Як з’ясувалося, кінцевим споживачем коду була американська продуктова компанія. А наш замовник взяв українських розробників на субпідряд. Ми звернулися до кінцевого споживача і пояснили йому, що вони користуються кодом, який їм не належить. Адже підрядник передав їм IP, які так не стали їхньою власністю.
Продуктова компанія була важливим замовником, тож вони одразу розрахувалися з українською IT компанією.
Так один рядок в контракті захистив IT бізнес від втрати $45k. Хочете перевірити свої контракти чи розробити нові, більш захищені – пишіть нам за посиланням. Вміємо робити так, щоб ваші справи були в порядку.
Автор
Максим Носарєв
Founder & СЕО Tretten Lawyers, IT адвокат
