Якщо Fixed Price, то тільки такий: особливості і нюанси

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

Сутнісні ознаки контракту Fixed Price

Вважається, що Fixed Price доцільно застосовувати для невеликих проєктів. Проте IT компанії з налаштованими бізнес-процесами і розумінням, як витрачається їхній час, успішно реалізують і більш масштабні проєкти за цією моделлю. В ній, як мінімум, рейт вищий, ніж у тій же Time and Material, за рахунок включення в нього ризиків, пов’язаних з можливими змінами, додатковим часом на узгодження завдань тощо.

Отже, якщо вирішили працювати з замовником по контракту Fixed Price, то в ньому обов’язково мають бути:

• Чітке і докладно сформульоване технічне завдання. Тут мають бути зафіксовані всі критерії якості, яким має відповідати створений вами продукт. Наприклад: “на стартовій сторінці повинна бути кнопка реєстрації синього кольору, ширина – 2 см, довжина – 5. Перехід на форму реєстрації має відбуватися не більше ніж за 2 секунди” і т.д. Ніякої невизначеності — за неї вам доведеться відповідати власним часом і фінансами.

• Термін завершення проєкту. Весь період робіт може бути розбитий на спринти (або майлстоуни) — теж з визначеними датами. Для них повинні бути прописані контрольні точки: зазначено, що саме на кінець кожного спринту має бути вже зроблено.

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

• Визначено, яким буде етап прийняття робіт: кінцевий і за кожним спринтом, якщо вони є. Юридично це можуть бути акти прийому-передачі, або підтвердження прийняття робіт по імейлу. Для другого випадку варто прямо в договорі зазначити офіційні імейли сторін. Коли замовник приймає роботу, з його офіційної скриньки на офіційну скриньку розробника має надійти електронний лист з підтвердженням, що, умовно роботи по спринту 3 прийняті.

• Зрозумілі процедури усунення недоліків або внесення змін поза ТЗ. Часто виникають ситуації, коли всі завдання по ТЗ виконані, але продукт не відповідає баченню або бізнес цілям замовника. Тоді він може попросити вас щось змінити або додати. Договір Fixed Price однозначно має фіксувати, що все, що не відповідає ТЗ в готовому продукті, ви переробляєте в рамках існуючого бюджету, а все, що не було передбачено ТЗ, — за додаткову оплату.

Ми в Tretten Lawyers впевнені, що права розробника мають бути захищені не менше, ніж права замовника. Тому розробляємо і допомагаємо узгодити договори, якими задоволені всі сторони. Хочете поговорити про це з нашим юристом – переходьте за посиланням.

Нюанси контракту, на які варто звернути увагу до підписання

Перераховані нижче деталі можуть ”пробратися” і в інші контракти, не тільки в Fixed Price. Та обравши цю модель для роботи з замовником, стежте за ними особливо пильно.

1. Фраза в тексті контракту “Кінцевий продукт має задовольняти обгрунтованим вимогам до подібних продуктів на ринку”. Це небезпечне для розробників положення, яке дозволяє замовнику про будь-що говорити “це не те, не відповідає вимогам, не будемо оплачувати”. Адже по суті не існує ніяких “обгрунтованих вимог” — під ці слова можна притягнути що завгодно. Побачите це в договорі — наполягайте на чітких формулюваннях щодо якісних ознак продукту.

2. Положення про те, що право інтелектуальної власності на продукт в момент його створення переходить до замовника. Воно захищає інтереси замовника і обмежує можливості для вас. Ми радимо документально фіксувати прямо протилежне: “право інтелектуальної власності на продукт переходить до замовника після остаточних розрахунків за цим договором”. Так ви залишите собі хоча б якийсь важіль впливу на замовника, якщо він порушить домовленості щодо оплати роботи.

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

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

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

4. Забагато вимог до IT компанії в розділі договору про неконкуренцію. Часто замовник намагається на певний термін обмежити діяльність IT компанії у певній сфері або заборонити робити щось схоже на те, що ви розробляли для нього. Це може суттєво обмежити можливості розвитку вашого бізнесу. Особливо, якщо у вас є експертиза саме за певним напрямом: робота з медичними даними, розробка маркетплейсів чи мобільних додатків тощо.

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

Або залучайте нас до переговорів з замовником – допоможемо відстояти ваші бізнес-інтереси. Деталі за посиланням. 

5. Положення про непереманювання ваших працівників обов’язково має бути в договорі з замовником. Воно повинно містити:

• заборону на такі дії (переманювання людей з вашої команди),
• вагомі штрафні санкції (50 тис євро і більше) для контрагента, якщо це відбулося.

Ці пункти очікувано викликають незадоволення замовника: чому суми такі великі? Але ж якщо він не планує у вас хантити людей, то вони і загрози йому ніякої не нестимуть. Радимо це прямо обговорити. Так ви зрозумієте, наскільки добрі наміри має ваш потенційний контрагент.
І остання, але дуже важлива порада. Не ставтеся до контракту як до формальності і уважно вичитуйте кожне його речення. Контракт із замовником – це ваші “правила дорожнього руху”, які захистять вас у випадку конфлікту чи інших криз у стосунках із замовниками. Потрібна допомога у роботі з контрактами і договорами – переходьте за посиланням, допоможемо –   щоб ваші справи були в порядку.