Що означає завершення роботи за договором підряду у розробці системи

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

Більшість проектів з розробки системи виконуються на основі договорів підряду, які передбачають “завершення роботи”.

У цій статті ми розглянемо з юридичної точки зору питання “Коли і що ми повинні зробити, щоб вважати розробку системи завершеною?”.

Що таке завершення розробки системи

Завершення розробки системи з точки зору інженера

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

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

Завершення розробки системи з юридичної точки зору

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

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

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

Договір підряду: Цивільний кодекс, стаття 632
Стаття 632
Підряд виникає, коли одна сторона договору зобов’язується завершити певну роботу, а інша сторона зобов’язується заплатити за результат цієї роботи.
Договір доручення: Цивільний кодекс, стаття 648
Стаття 648
1.Якщо не передбачено інше, виконавець не може вимагати винагороду від довірителя.
2.Виконавець може вимагати винагороду тільки після виконання дорученого завдання. Однак, якщо винагорода визначена за період, застосовується положення пункту 2 статті 624.
3.Якщо виконання завдання припинено на середині через причини, які не можуть бути пов’язані з виконавцем, виконавець може вимагати винагороду пропорційно виконаній роботі.

Завершення розробки системи стає проблемою в договорах підряду

Однак, не тільки в контексті розробки систем, але і в загальному контексті, питання “коли робота завершена” стає проблемою в основному в договорах підряду. У випадку договорів доручення, замість того, щоб вважати виконання зобов’язань за досягнення певного результату або продукту, цей тип договору має сильніше значення “робити те, що потрібно зробити, незалежно від результату, з певним розсудом як професіонал”. Згідно з положеннями договору доручення, навіть якщо очікуваний продукт не був створений, винагороду можна вимагати, якщо було належно проведено обробку справ (пункт 2 статті 648), і якщо виконання було припинено на середині з причин, які не можуть бути пов’язані з виконавцем, винагороду можна вимагати пропорційно виконаній роботі (пункт 3 статті 648). Договір підряду “орієнтований на результат”, договір доручення “орієнтований на процес”.

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

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

Коли можна вважати роботу завершеною в системному розробництві?

Отже, коли конкретно ми можемо вважати “завершенням роботи”? Давайте розглянемо це питання на прикладі минулих судових рішень.

Судові рішення щодо завершення роботи

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

Статті 632 та 633 Цивільного кодексу Японії встановлюють, що платник має заплатити винагороду замовнику, коли він завершує роботу та передає предмет роботи замовнику. З іншого боку, стаття 634 того ж кодексу встановлює, що якщо предмет роботи має дефекти, платник несе гарантійну відповідальність перед замовником (пункт 1), і замовник має право відмовитися від сплати винагороди, поки платник не виконає свою гарантійну відповідальність за дефекти предмета роботи (пункт 2). Згідно з цими положеннями Цивільного кодексу, закон розрізняє випадки, коли результат роботи неповний, а саме коли предмет роботи має дефекти, і коли робота не завершена, і вважається, що навіть якщо предмет роботи має дефекти, незалежно від того, чи були вони приховані, чи очевидні, це не означає, що робота не завершена.
Отже, щодо питання, чи завершив платник роботу, слід вирішувати на основі того, чи завершено останній етап роботи, запланований у початковому договорі про виконання робіт, і вважається, що замовник не може відмовитися від сплати винагороди просто тому, що предмет роботи має дефекти, коли платник завершив останній етап роботи та передав предмет роботи.

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

Тому, навіть якщо “завершення роботи” тлумачиться дещо ширше, в кінцевому підсумку це не призведе до неправедливості для користувача. Підсумовуючи, це виглядає так:

【Зобов’язання в контракті = Завершення роботи = Завершення всіх етапів】
＝＝＝＝＝＝＝＝＝＝＝
Якщо робота не завершена…
↓
【Необхідно нести відповідальність за невиконання зобов’язань】
＝＝＝＝＝＝＝＝＝＝＝
Навіть якщо робота завершена, але є недоліки…
↓
【Визнання виконання зобов’язань, але є проблема з гарантійною відповідальністю за дефекти】

Це приклад судового рішення, яке показує, як розподілити проблеми.

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

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Що означає завершення юридичної роботи

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

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

Детальний опис процесу “розірвання” контракту в сфері розробки систем ви знайдете в наступній статті.

Уважність щодо завершення роботи

Як ми ставимося до зміни специфікацій та додаткової розробки

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

https://monolith.law/corporate/increase-of-estimate[ja]

Зверніть увагу на зміни в Цивільному кодексі

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

https://monolith.law/corporate/defect-warranty-liability[ja]

Підсумки

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