До якої міри законодавство вимагає реалізації функцій, яких немає в технічному завданні на розробку системи?

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

Правові питання, пов’язані з реалізацією незапланованих елементів

Від виконавця вимагається дискреційне право

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

Пов’язана стаття: Обов’язки управління проектами при розробці систем[ja]

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

Пов’язана стаття: Різниця та відмінності між контрактами на виконання робіт та делегування в розробці систем[ja]

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

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

Пов’язана стаття: Як керувати змінами в розробці систем з юридичної точки зору[ja]

Що слід робити як фахівець, не зациклюючись на специфікаціях?

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

Юридичні обов’язки визначаються відповідно до “суті” специфікацій та договорів

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

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

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

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

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

Рішення Токійського окружного суду від 18 лютого 2009 року (Heisei 21)

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

Судові випадки, коли було підтверджено обов’язок впровадження, навіть якщо він не вказаний

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

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

Пов’язана стаття: Юридичні проблеми, пов’язані з переходом від старої системи при розробці системи[ja]

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

Рішення Токійського суду від 18 листопада 2010 року (Heisei 22)

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

Що ми можемо зрозуміти з обох рішень

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

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

Пов’язана стаття: Обов’язок співпраці з боку користувача, який замовляє розробку системи[ja]

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

Як ставитися до винагороди за розробку, яка не вказана в технічному завданні?

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

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

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

Підсумки

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