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

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

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

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

Якщо це ваша система, ви не можете просто “відкинутися назад”

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

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

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

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

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

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

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

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

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

Спробуймо перекласти вищезазначене рішення на IT-термінологію розробки систем.

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

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

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

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

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

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

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

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

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

Вирок Токійського окружного суду від 10 березня 2004 року (2004 рік за Григоріанським календарем)

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

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

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

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

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

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

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

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

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

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

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