Що таке обов'язки управління проектами при розробці систем?

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

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

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

Обов’язки вендора щодо управління проектом

Почнемо з розгляду обов’язків вендора щодо управління проектом.

Згідно з судовою практикою, обов’язки управління проектом включають:

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

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

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

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

Обов’язок користувача співпрацювати

Однак, у розробці систем не лише вендор має взяти на себе всі обов’язки. Оскільки це IT-система, яка буде використовуватися в компанії замовника, проект розробки системи не може бути “чужим” для замовника.

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

Обов’язки користувача щодо співпраці включають наступне:

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

② Перевіряє результати.

③ Відповідає на запити про співпрацю від вендора.

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

Управління проектом не є простим

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

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

Що може статися у випадку порушення обов’язків з управління проектами

Отже, що конкретно може статися, якщо було порушено обов’язки з управління проектами?

У цьому питанні немає якогось конкретного пункту, який би говорив: “Обов’язки з управління проектами – це таке”.

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

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

З іншого боку, якщо користувач порушив обов’язок співпраці, вендор може вимагати від користувача відповідну суму винагороди, якщо робота не була завершена через це, на підставі ризику несення відповідальності (японський Цивільний кодекс, стаття 536, пункт 2), або невиконання зобов’язань.

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

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

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

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

Рішення Токійського окружного суду від 10 березня 2004 року (Heisei 16)

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

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

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

Крім того, відносно вищезазначених трьох пунктів,

• Необхідно також докладати зусиль щодо комунікації, наприклад, вимагати відповідної співпраці від користувача, а не просто робити все самостійно з боку вендора

Можна узагальнити це як обов’язки управління проектами.

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

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

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

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

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

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

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

Верховний суд Токіо, 26 вересня 2013 року (рік 25 ери Хейсей)

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

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

Стаття 1, пункт 2 Цивільного кодексу Японії
Виконання прав та обов’язків повинно бути здійснено добросовісно та чесно.

Ключове слово “принцип добросовісності” у вироку вище відображає вищезазначене.

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

Підсумок: у разі проблем з порушенням обов’язків управління проектами, звертайтеся до адвоката

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

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

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

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