Чи можливе збільшення оцінюваної вартості розробки системи після факту?

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

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

Коли можна говорити про додаткову розробку та виправлення функцій?

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

Детальніше про різницю між контрактами підряду та квазі-дорученнями описано в окремій статті.

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

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

• Якщо вам наказано додати додаткові функції після того, як специфікації були визначені,
• Якщо вам наказано виправити програму після того, як її реалізація була завершена,

В таких випадках, ваші вимоги можуть мати певну законність.

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

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

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

Розробка програмного забезпечення включає в себе процеси розробки, такі як ① визначення вимог, ② зовнішній дизайн, ③ внутрішній дизайн, ④ створення вихідного програмного коду (дизайн програми, кодування), ⑤ різні тести (модульні тести, комбіновані тести, системні тести) … Початкові специфікації … реалізуються через роботу, що виконується після внутрішнього дизайну, і це вважається обсягом роботи, що відноситься до відносин вартості та вимоги за винагороду на основі цього контракту на розробку. Зміна специфікацій, з юридичної точки зору, вважається заявкою на новий контракт на доручення роботи, що перевищує обсяг роботи, заснований на початковому контракті, від замовника, і якщо виконавець не надає додаткову суму за додаткову роботу і завершує роботу, пов’язану з додатковим дорученням, без узгодження додаткової суми, вважається, що було укладено новий контракт без визначення суми між замовником і виконавцем, і виникає зобов’язання сплатити відповідні додаткові витрати на розробку.

Рішення Осаки від 29 серпня 2002 року (Heisei 14)

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

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

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

Рішення Осаки від 29 серпня 2002 року (Heisei 14)

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

• Випадок, коли щось, що вже було визначено, було змінено пізніше
• Випадок, коли щось, що можна було визначити в процесі роботи, було навмисно не визначено і продовжувалося

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

Інші позитивні приклади

Крім того, серед справ, які були визнані як додаткова розробка та корекція функцій, є:

• Випадок, коли кількість програм, що були поставлені, збільшилася приблизно вдвічі в порівнянні з початковим планом (Рішення Токійського окружного суду від 22 квітня 2009 року (2009 рік за Григоріанським календарем))
• Випадок, коли термін виконання робіт збільшився приблизно втричі (Рішення Токійського окружного суду від 22 січня 2010 року (2010 рік за Григоріанським календарем))

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

“Угода про додаткову розробку та збільшення винагороди” та “Укладення початкового договору” – це різні питання

Важливо зазначити, що ці питання включають:

1. “Чи був офіційно укладений договір про розробку системи (початковий договір) між двома компаніями?”
2. “Чи був укладений додатковий договір про додаткову розробку системи, яка була офіційно укладена?”

Судові органи мають різні критерії оцінки в цих ситуаціях. Щоб сказати прямо, суди:

• Схильні бути строгими щодо пункту 1 (вони не часто визнають укладення договору без договору)
• Схильні бути більш лояльними щодо пункту 2 (навіть без договору про додаткову розробку, вони гнучко визнають збільшення винагороди)

Можна сказати. Детальніше про пункт 1 я розповідаю в іншій статті.

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

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

Суть справи полягає в наступному: (1) який був зміст роботи, яку позивач виконав за цим договором, (2) чи була досягнута угода між позивачем та відповідачем про розширення масштабу та збільшення плати за цю роботу, (пропуск)…

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

Як було визнано вище, робота, яку позивач виконав за цим договором, була змінена 25 лютого 1987 року (Showa 62), і вона обмежувалася лише частиною системного управління, розрахунком вартості підрядних робіт та утилітами, а решту виконував відповідач. Робота позивача після зміни все ще входить в межі роботи з розробки, відповідно до початкового договору, і винагорода за цю роботу покривається сумою плати, яка була узгоджена як визначена плата на початку цього договору.

Рішення Токійського окружного суду від 12 червня 1995 року (Heisei 7)

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

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

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

Як визначається винагорода за додаткову розробку та виправлення функцій?

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

Стаття 512 Японського торгового закону (Japanese Commercial Code), яку я цитую нижче, може бути корисною в таких випадках (підкреслення зроблено мною).

Стаття 512 Японського торгового закону (Japanese Commercial Code): Коли торговець діє від імені іншої особи в межах свого бізнесу, він може вимагати відповідну винагороду.

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

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

Випадок 1: Приклад, коли було визнано додаткову винагороду, пропорційну збільшенню робочого часу

Розробницький час, зумовлений зміною специфікацій у даному випадку, є відповідним, якщо його розглядати як загальну суму вищезазначеного часу, що становить 257,5 людина/день. Якщо перетворити це на вартість розробки за людину/день, використовуючи ту ж саму суму в 32 500 єн (в додатку А ціна становить 650 000 єн за людину/місяць, і якщо врахувати, що кількість робочих днів у місяці становить 20 днів, вартість розробки за людину/день становить 32 500 єн.), додаткова вартість розробки, зумовлена запитом на зміну специфікацій, відповідно становить 8 368 750 єн.

Рішення Осаки від 29 серпня 2002 року (14 рік ери Хейсей)

Ключове слово тут – “за людину/день”. Це вказує на те, що для обчислення додаткової винагороди використовується робочий час.

Випадок 2: Випадок, коли було визнано додаткову винагороду, пропорційну кількості програм

Розглядаючи суму відповідної винагороди, включаючи додаткову частину у цьому випадку, більшість витрат на розробку комп’ютерної системи становлять витрати на технічних спеціалістів, і ці витрати на персонал в основному пропорційні обсягу програм, які вони створюють. Враховуючи це, ми ділимо початкову суму контракту в 23 250 000 єн на кількість програм – 206, які були завершені до другого прийому, і множимо цю ціну за одну програму на кількість програм – 414, які пройшли третій прийом. Це дає суму 46 725 728 єн (23,250,000 ÷ 206 × 414 = 46,725,728), яку ми вважаємо відповідною.

Рішення Токійського окружного суду від 22 квітня 2005 року (17 рік ери Хейсей)

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

Випадок 3: Приклад визнання додаткової винагороди, пропорційної тривалості періоду

Так, у контракті “А3” визначено, що винагорода за роботу, виконану відповідно до підзавдання в період з січня по березень 2005 року (平成17年), становить 60 мільйонів єн. Однак, починаючи з квітня того ж року, робота включала безкоштовні послуги. Так само, як і в попередньому році, очікувалося, що обсяг роботи збільшиться після початку нового навчального року в квітні, коли система реєстрації курсів і т.д. стане активною. Враховуючи ці обставини, справедливо встановити винагороду за роботу в період з квітня по вересень 2005 року (平成17年) на рівні 120 мільйонів єн, виходячи з базової суми в 60 мільйонів єн, встановленої за роботу протягом попередніх трьох місяців.

Рішення Токійського окружного суду від 22 січня 2010 року (平成22年)

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

Підсумки

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

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