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

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

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

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

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

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

Щоб уникнути конфліктів у майбутньому

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

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

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

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

Як заходи у випадку виникнення конфліктів

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

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

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

Що особливо важливо в протоколах засідань з розробки системи?

Типи засідань при розробці систем

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

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

Особливо важливо звернути увагу на стеринговий комітет

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

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

Можна навести такі приклади.

Судова практика, пов’язана з протоколами засідань керівного комітету

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

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

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

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

Які конкретні пункти слід записувати в протоколі засідання

Протокол засідання має важливе значення як доказ, навіть у випадку судового розгляду (а також для плавного проведення подальших переговорів між сторонами, навіть якщо судовий розгляд не відбувається). Отже, що конкретно слід документувати та записувати в протоколі засідання? Давайте розберемося нижче.

Пункти, які слід записувати з позиції вендора

Вендори несуть обов’язки управління проектом як експерти з розробки систем. Детальний опис цих обов’язків наведено в наступній статті.

https://monolith.law/corporate/project-management-duties[ja]

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

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

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

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

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Пункти, які слід записувати з позиції користувача

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

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

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

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

Підсумки

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

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