Як впоратися, якщо розробка системи була призупинена через обставини, пов'язані з користувачем?

Робота, пов’язана з розробкою систем, часто приймає форму довготривалих проектів. Що ж робити, якщо, почавши розробку системи, ви односторонньо почуєте від користувача: “Ця система вже не потрібна, тому не потрібно її створювати”? Що може зробити вендор, який прийняв роботу?

У цій статті ми розглянемо особливості договору про розробку системи та обговоримо можливі варіанти дій у такому випадку.

Значення розгляду перервання через обставини користувача

У договорі про розробку системи є декілька особливостей, якщо розглядати його як договір. По-перше, термін його виконання зазвичай тривалий, і відповідно до обов’язку керування проектом, постачальник також несе великі обов’язки разом з великими повноваженнями. Загальний зміст обов’язків постачальника щодо управління проектом детально описано в наступній статті.

https://monolith.law/corporate/project-management-duties[ja]

По-друге, навіть якщо користувач є клієнтом, він несе широкі обов’язки співпраці з постачальником. Це не є система, яку можна просто “кинути” постачальнику, оскільки вона використовується всередині компанії. Є обов’язок співпрацювати з постачальником, щоб він міг використовувати свою професійність у своїй роботі, навіть з внутрішньої сторони компанії. Детальний опис цього наведено в наступній статті.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Якщо коротко підсумувати вищенаведене, між постачальником і користувачем існує відносини “зовнішнього виконавця”, який розробляє систему, і “клієнта”, який платить винагороду, а також, водночас, вони повинні співпрацювати, як “партнери”, щоб досягти спільної мети – завершення проекту. Ця складність відносин зазвичай відсутня у простих кравців, які шиють костюми на замовлення, і є великою особливістю договорів, пов’язаних з розробкою систем. Спори, пов’язані з розробкою систем, часто ускладнюються через цю складність відносин, і коли вони заплутуються, виникає складне питання, як правильно врегулювати відносини між сторонами з юридичної точки зору.

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

Спочатку розглянемо причини, які спонукали до розірвання договору

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

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

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

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

Перевірка основних положень для вимоги винагороди та відшкодування збитків

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

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

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

І у випадку договорів про надання послуг, і у випадку договорів підряду, Цивільний кодекс встановлює наступні положення:

a.) У випадку договору про надання послуг
Вимога про винагороду: Цивільний кодекс, стаття 648, пункт 3
Якщо виконання було припинено на середині через причини, які не можуть бути пов’язані з виконавцем, виконавець може вимагати винагороду, пропорційну вже виконаній роботі.
Вимога про відшкодування збитків: Цивільний кодекс, стаття 651
1. Кожна сторона може в будь-який час розірвати договір.
2. Якщо одна зі сторін розірвала договір у невигідний для іншої сторони час, ця сторона повинна відшкодувати збитки іншої сторони. Однак, це не стосується випадків, коли були непереборні обставини.

b.) У випадку договору підряду
Вимога про відшкодування збитків: Цивільний кодекс, стаття 641
Поки підрядник не завершив роботу, замовник може в будь-який час відшкодувати збитки та розірвати договір.

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

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

Подальше доведення обсягу робіт та збитків

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

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

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

Що ж варто розглянути з боку користувача?

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

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

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

https://monolith.law/corporate/system-development-contract[ja]

Підсумки

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

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