Що таке закон, що стосується відходу членів проекту з розробки системи?

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

Відхід членів команди як частина обов’язків з управління проектом

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

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

Несподіваний відхід членів команди з боку вендора можна вважати одним з аспектів обов’язків вендора з управління проектом.

• Фізичні проблеми через надмірну роботу в надгодини або роботу в вихідні дні
• Психологічний стрес через конфлікти в стосунках між людьми

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

Важливі судові рішення щодо виходу членів з команди

Випадок, коли вихід членів команди призвів до затримки виконання проекту

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

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

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

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

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

Справді, представник користувача під час зустрічі у листопаді 2003 року (15 року ери Хейсей) сказав з великою впевненістю: “Ти не хочеш цього робити?“, “Цей контракт закінчується. Якщо я вийду з цієї кімнати, це буде кінець.” Однак, це було пов’язано з тим, що, незважаючи на те, що в основній угоді було встановлено, що жовтень 2003 року (15 року ери Хейсей) був періодом прототипу, додаткова функція, яка була ціллю цього розробки, не була включена в проект вимог, і навіть коли коментарі були додані до проекту вимог, не було відповіді, це було пов’язано з затримкою роботи вендора та його реакцією, і це не можна вважати за виходи за межі.

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

Рішення Токійського окружного суду від 4 грудня 2007 року (19 року ери Хейсей)

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

Що можна зрозуміти з вищезазначеного судового рішення

Крім того, можна отримати такі важливі уроки:

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

Як готуватися до ризику відходу членів команди

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

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

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

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

Забезпечити достатній резерв персоналу

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

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

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

Строго дотримуватися управління змінами в проекті та управління документацією

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

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

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

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

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Підсумки

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

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

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