Які заходи слід вжити, якщо після приймання системи виявлено несправності?

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

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

Не дивно, що помилки залишаються навіть після прийняття та тестування

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

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

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

Зазвичай вважається, що борг сам по собі вже виконаний

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

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

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

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

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

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

Шлях до відстеження відповідальності на основі відповідальності за дефекти

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

Спочатку перевірте серйозність та глибину багів та неполадок

Коли баги або неполадки виявляються після того, як вони стають юридичними “дефектами”, і ви вимагаєте якусь гарантію, серйозність багів та неполадок стає проблемою. Проблема юридичних дефектів, в основному, розподіляється на три категорії:

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

Що розділяє можливість відстеження відповідальності на основі відповідальності за дефекти, це межа між 1 та 2, а що розділяє можливість розірвання договору на основі відповідальності за дефекти, це межа між 2 та 3.

Стаття 634

1. Коли в об’єкті роботи є дефект, замовник може вимагати від виконавця виправлення дефекту протягом відповідного періоду. Однак, це не стосується випадків, коли дефект не є важливим, а виправлення вимагає надмірних витрат.

2. Замовник може вимагати відшкодування збитків замість або разом з виправленням дефекту. У цьому випадку застосовується положення статті 533.

Стаття 635

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

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

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

Далі визначте, що вимагати від постачальника

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

Крім розірвання договору, ви також можете вимагати відшкодування збитків або виправлення дефектів як частину відповідальності за дефекти.

Інші важливі моменти

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

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

Бажано вирішувати проблеми шляхом переговорів, а не судових тяжб

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

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

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

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

Підсумки

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