Як проводити управління змінами в розробці систем з юридичної точки зору

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

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

Чому проекти розробки систем часто “змінюються” після завершення?

Розробка системи – спільна робота вендора та користувача

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

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Незважаючи на обов’язок співпраці, користувачі часто вимагають змін

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

Що таке документ змін

Ситуації, в яких використовується документ змін

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

Наприклад, документ змін може бути необхідним, якщо:

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

Це лише декілька прикладів.

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

https://monolith.law/corporate/increase-of-estimate[ja]

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

Відомості, які слід включити до документа змін

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

(Процедура управління змінами)
Стаття 37. Якщо А або Б отримає пропозицію про зміну відповідно до статті 34 (Зміна специфікації системи тощо), статті 35 (Затвердження проміжних матеріалів користувачем) або статті 36 (Обробка невизначених питань), вони повинні надати іншій стороні документ (надалі – “документ змін”), який включає наступні відомості, протягом ○ днів після дати отримання, і А та Б повинні обговорити можливість такої зміни на засіданні контактної ради, визначеної в статті 12.
① Назва зміни
② Відповідальний за пропозицію
③ Дата
④ Причина зміни
⑤ Деталі зміни, включаючи специфікації, пов’язані зі зміною
⑥ Якщо потрібні витрати для зміни, то їх сума
⑦ Графік роботи зі змінами, включаючи період розгляду
⑧ Інший вплив зміни на умови цього контракту та окремого контракту (термін виконання роботи або термін поставки, винагорода, контрактні умови тощо)

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

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

Що варто знати про управління змінами

Управління змінами, як правило, слід проводити разом з управлінням проблемами

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

Краще також встановити правила для обговорення змін

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

Обговорення змін та обов’язок чесності

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

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

Пункт 3 статті 4. Під час обговорення змін, обидві сторони повинні чесно обговорити предмет змін, можливість змін, вплив змін на вартість та терміни доставки.

Положення про методи змін

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Підсумки

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

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