Що таке проблеми з законодавством та договорами, пов'язаними з аджайл-розробкою?

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

Аджайл-модель розробки та юридичні питання

Що таке модель у системній розробці

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

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

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Особливості аджайл-моделі розробки

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

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

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

Важливість управління документами

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

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

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

Створення координаційної ради ефективне для управління документами

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

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

(Створення координаційної ради)

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

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

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

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

(Пункти 5, 6 та 7 пропускаються.)

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

Шлях до використання контактної ради для управління змінами

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

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

(Процедура управління змінами)

Стаття 37. Якщо сторона А або сторона Б отримає пропозицію про зміну від іншої сторони (пропущено)…, вона повинна надати іншій стороні документ, що містить наступні пункти (далі – “документ про управління змінами”) протягом ○ днів від дня отримання, і сторони А та Б повинні обговорити прийнятність такої зміни на контактній раді, визначеній в статті 12. (Деталі опущено)

Основні моменти цього положення можна узагальнити так:

• Метод прийняття пропозиції про зміну є стандартизованим у форматі “пропозиції про зміну”.
• Встановлено термін між отриманням пропозиції та обговоренням її. Навіть якщо це не вказано як “протягом ◯ днів”, можна розглянути заміну на “негайно” або подібні слова.
• Місце для обговорення прийнятності зміни стандартизовано як “контактна рада”.

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

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

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

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

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

Пункт 2 статті 1 Цивільного кодексу Японії (1896)

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

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

Підсумки

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