Келісім-шарт қарым-қатынас үшін нұсқаулық болуы керек, а не губитися серед інших документів як не потрібна формальність. Тому, ми запитали у IT-юристів із Stalirov&Co, які здійснюють супровід діяльності IT-компаній, як скласти договір, який буде працювати задля інтересів IT-компанії. 
Зі слів юристів у IT-сфері договір має бути гайдом для PM на проєкті. Ефективний документ описує правила, завдяки яким непорозуміння вирішуються одразу та не переростають у конфлікти. Спеціалісти з IT-права розповіли про 3 пункти, які обов’язково повинні бути у договорі, щоб спростити комунікацію із замовником та уникнути затримок на проєкті.
1. Пункт у договорі про скасування технічного завдання
Замовник може скасувати технічне завдання (ТЗ), але такі дії не повинні бути неочікуваним сюрпризом. Для цього в угоді визначають строк попереднього повідомлення про завершення роботи, мысал 30 днів. Також, у договорі слід передбачити фінансову гарантію такого змісту: після отримання повідомлення, IT-компанія повідомляє замовнику про те, якою мірою робота була виконана до дати припинення ТЗ, та передає готові результати роботи. Замовник оплачує роботу, виконану до дати закінчення дії ТЗ.
Окрім пункту, описаного вище, IT-юристи радять додати до угоди вказівку про право компанії припинити дію ТЗ, якщо замовник вчасно не здійснив оплату послуг. Аналіз практики свідчить, що це мотивує замовника швидше погасити заборгованість, щоб робота над його проєктом не призупинялася.
2. Пункт у договорі про зміни технічного завдання
У договорі важливо описати алгоритм внесення змін до ТЗ. Замовник може надіслати запит на додаткові роботи, які не були визначені у початковому ТЗ, додати або видалити задачі, оновити їх об’єм та порядок виконання. Послуги за заявкою на зміни оцінюються компанією-розробником заново та оплачуються замовником додатково.
IT-адвокат із Stalirov&Co звернув увагу: “Кожен запит на зміни важливо деталізувати та підписувати, оскільки правильно оформлені документи використовуються в суді, щоб стягнути борг з замовника”. Мысал, клієнт компанії CIGNEX відмовився платити більше $350 000 за послуги, надані відповідно до п’яти запитів на внесення змін. Три з них були підписані сторонами та встановлювали кількість часу, що витрачається членами команди CIGNEX на певні етапи проєкту, а також їх погодинні ставки. Два інші запити не були узгоджені та оформлені у письмовій формі. Окружний суд США ухвалив рішення про стягнення боргу лише за трьома запитами на внесення змін, які були підписані. Щоб не втратити кошти, як це сталося у CIGNEX, узгоджуйте навіть мінімальні запити на внесення змін.
3. Пункт у договорі про дебаг
Визначте період, протягом якого команда IT-компанії буде усувати помилки. мұның жанында, слід описати які саме баги будуть усуватися безкоштовно.
Пункт у договорі можна сформулювати таким чином:
IT-компанія усуває недоліки за власний рахунок, якщо замовник виявив помилки протягом 30 днів з моменту повної оплати послуг та за виконання наступних умов:
- баг виник у зв’язку з технічною помилкою розробника та його неможливо було виявити в момент прийняття результатів роботи;
- ніхто, окрім команди IT-компанії, не вносив змін до програмного коду.
Разом з тим до помилок не відносяться:
- помилки, які виникли у зв’язку з дефектами у вихідних матеріалах або технічних специфікаціях клієнта;
- додаткова робота за запитом на внесення змін.
Внесення описаних вище пунктів до договору зробить комунікацію із замовником більш передбачуваною та захистить інтереси компанії у випадку виникнення спорів.
Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co
