Права і обов'язки: як вибрати модель оплати за послуги в IT

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

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

Які моделі договорів з ІТ-фахівцями існують та яку з них краще вибрати, розповіли Mind керуючий партнер Stron Legal Services Олег Дерлюк і юрист компанії Альона Перепелична.

Раніше експерти дали рекомендації щодо правил укладення договорів з нерезидентами у сфері IT-аутсорсингу.

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

Для більшої наочності пропонуємо розглянути принцип роботи найзатребуваніших моделей фінансової взаємодії сторін.

Fixed Price

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

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

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

Time and Material

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

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

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

Fixed Budget

Альтернативним рішенням є система Fixed Budget.

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

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

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

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

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

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