Що таке закон у випадку невиплати винагороди за розробку системи
Для вендорів, які беруть на себе роботу з розробки систем, можливо, найбільшим ризиком є ситуація, коли, незважаючи на поставку, користувач не платить винагороду. Витрати на розробку системи часто пов’язані з висококваліфікованими фахівцями, такими як програмісти, тому часто виникають значні витрати на оплату праці. Затримка у відшкодуванні прибутку може стати питанням життя і смерті. У цій статті ми розглянемо питання, які вендор повинен розглянути з юридичної точки зору, якщо користувач не згоден на виплату винагороди.
Перш за все, перевірте, чи можна вимагати винагороду
- Постачальник, незважаючи на те, що він виконав роботу для користувача, не може отримати підтвердження виконання роботи від користувача, і через це процес вимоги винагороди затримується.
- Незважаючи на те, що відбулася прийомка роботи, існує якась невідповідність між розумінням користувача і постачальника, і користувач не згоден на виплату винагороди.
Ці ситуації можуть виникнути в реальному житті.
В термінології розробки систем, прийомка роботи користувачем, коли він перевіряє специфікації готової системи, називається “прийомка”. Значення цього терміну та питання, які слід розглянути, якщо процес прийомки не йде добре, детально описані в наступній статті.
Пов’язана стаття: Прийомка розробки системи та застосування умов прийомки[ja]
Хоча загальне пояснення прийомки наведено в статті вище, з юридичної точки зору, необхідно розглянути, чи можна вважати, що прийомка користувачем вже відбулася, враховуючи положення про “умови прийомки”.
З урахуванням цього, першим питанням, яке слід розглянути, якщо користувач не здійснює виплату винагороди, будуть наступні пункти:
- Чи була робота виконана, або вона все ще не завершена?
- Чи може бути застосована відповідальність за дефекти (стаття 635 Японського цивільного кодексу)?
Причина, чому першим кроком має бути перевірка цих двох пунктів, полягає в тому, що якщо робота не була завершена, і відповідальність за дефекти (стаття 635 Японського цивільного кодексу) не застосовується, то навіть якщо ви подасте позов, ви не зможете отримати виплату винагороди.
Отже, що конкретно повинен перевірити представник постачальника, щоб розглянути ці два пункти? Давайте подивимося, які документи слід перевірити.
Документи, які слід перевірити для визначення можливості вимоги до винагороди
| Накладна Відсутність накладної може свідчити про те, що поставка ще не була завершена, а робота не була виконана, що підсилює це припущення. |
| Документ, що повідомляє про результати прийому Це найважливіший документ при визначенні, чи можна вважати роботу завершеною. Крім того, якщо прийом був відкладений через обставини, пов’язані з користувачем, варто перевірити, як було сформульовано “умову про прийняття за замовчуванням” в договорі. |
| Таблиця управління завданнями Цей документ допомагає зрозуміти, які завдання були виявлені до цього часу і які заходи були вжиті. Він також служить документом для визначення стану проблем та вад, які виявилися після поставки, та стану їх виправлення. |
| Документи визначення вимог, проектування, управління змінами, протоколи засідань тощо Ці документи допомагають з’ясувати, яке сприйняття мали користувач і виконавець на початку, щоб визначити, що можна вважати проблемою або вадою. |
Детальніше про те, як керувати змінами в специфікаціях системи, яку розробляти, та як створювати документи з управління змінами, читайте в окремій статті.
Пов’язана стаття: Юридичний погляд на управління змінами в розробці систем[ja]
| Повідомлення про розірвання або документ, що відображає наміри користувача Це спосіб дізнатися про наміри користувача, який не хоче продовжувати прийом (або не згоден на оплату винагороди). |
Далі, перевірте, скільки ви можете вимагати в якості винагороди
Як правило, суму, яку можна вимагати, вказують у договорі. Однак, якщо специфікації змінюються після укладення договору, може виникнути ситуація, коли у вас немає відповідного договору (або документа, що йому відповідає). Ми детально розглядаємо спосіб перерахунку оцінки на основі пізніших причин, таких як зміна специфікацій або додавання функцій, у наступній статті.
Пов’язана стаття: Чи можливе збільшення оціненої вартості розробки системи після факту?[ja]
Метод перерахунку оцінки описаний у цій статті, але з точки зору розгляду можливості збільшення суми вимоги, особливо важливо розглянути:
- Наявність та зміст кошторису для додаткової розробки та виправлення функцій
- Реакція користувача на кошторис
- Наявність угоди щодо ситуації, яка призвела до додаткової розробки та виправлення функцій, записаних у таблиці управління проблемами, та її суми
В основному, вам потрібно буде дослідити, чи була згода між вами та користувачем щодо замовлення роботи за цю суму (тобто, чи був укладений договір).
Нарешті, розглянемо проблеми, що виникають при проведенні судового розгляду
Будьте уважні до можливості подання відповідного позову
У сфері розробки систем, коли одна із сторін (користувач або постачальник) подає позов проти іншої сторони, часто виникає ситуація, коли відповідний позов подається з боку опонента. Тобто, є певні аргументи з боку користувача щодо ситуації, коли він відмовляється від оплати.
На початку розробки системи, користувач також має різні обов’язки співпраці, але передусім не слід забувати, що постачальник, як спеціаліст у сфері розробки систем, має широкий діапазон дискреційних прав та велику відповідальність. Детальніше про обов’язки постачальника щодо управління проектом у сфері розробки систем описано в наступній статті.
Пов’язана стаття: Обов’язки управління проектом у сфері розробки систем[ja]
Отже, необхідно ретельно розглянути питання, чи можна звинуватити користувача, який односторонньо відмовляється від оплати. Дивлячись на минулі судові рішення, багато випадків, коли початковий позов був поданий постачальником для вимоги оплати, але користувач, навпаки, вимагав відновлення первісного стану або відшкодування збитків.
Також необхідно розглянути, чи дійсно є комерційні переваги
Навіть якщо позиція постачальника прийнята і визнана можливістю вимоги оплати в судовому порядку, якщо ситуація доходить до судового розгляду, продовження торгівлі в майбутньому, як правило, стає проблематичним. Крім того, навіть якщо вашу позицію визнано в судовому порядку, вам слід бути готовим до того, що отримання оплати може зайняти значний час. Враховуючи, що витрати та зусилля на проведення судового розгляду не є незначними, часто краще знайти компроміс.
Підсумки
Якщо користувач не здійснює платежів за винагороду, юридичне розглядання цієї проблеми вимагає перевірки документів різних типів. Крім того, не достатньо просто добре управляти документами, також потрібно розглянути такі питання, як ризики та недоліки, з якими організація може стикнутися, якщо вона вирішить подати позов.
Напевно, ретельне управління документами є звичайною роботою на рівні місця роботи. Однак, якщо ви вирішите подати позов на основі збережених документів та матеріалів, це може стати важливим управлінським рішенням. Варто зрозуміти весь цей процес, враховуючи, що саме в таких нерегулярних ситуаціях випробовується солідарність та організаційна здатність керівництва та персоналу.
Category: IT
Tag: ITSystem Development
