MONOLITH LAW OFFICE+81-3-6262-3248Zilele săptămânii 10:00-18:00 JST[English Only]

MONOLITH LAW MAGAZINE

IT

Ce legi se referă la retragerea membrilor unui proiect de dezvoltare a sistemului?

IT

Ce legi se referă la retragerea membrilor unui proiect de dezvoltare a sistemului?

În proiectele de dezvoltare a sistemelor, este de obicei esențial să descompunem fiecare etapă și sarcină și să le abordăm cu cât mai multă planificare. Cu toate acestea, indiferent cât de mult ne concentrăm pe planificare, există probleme care nu pot fi prevenite, cum ar fi cele legate de “oameni”. În special, riscurile precum absența neașteptată sau demisia unui membru al proiectului sunt dificil de prevenit, indiferent cât de mult ne străduim să le gestionăm. În acest articol, vom explica cum se implică legea în legătură cu retragerea membrilor unui proiect.

Retragerea membrilor este o discuție detaliată a obligațiilor de management al proiectelor

În primul rând, se presupune că în cadrul unui proiect de dezvoltare a sistemului, furnizorul are o obligație cuprinzătoare de a asigura o desfășurare fără probleme. Acesta are obligația de a estima personalul, durata, bugetul și efortul necesar pentru o desfășurare fără probleme a proiectului, solicitând cooperarea utilizatorului după cum este necesar și gestionând progresul proiectului. Aceste obligații sunt cunoscute sub numele de “obligații de management al proiectelor” și existența lor a fost subliniată în repetate rânduri în cazurile de judecată anterioare.

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

Apariția bruscă a unui membru care se retrage din partea furnizorului poate fi considerată o problemă a obligațiilor de management al proiectelor din partea furnizorului.

  • Probleme de sănătate cauzate de orele suplimentare excesive și munca în zilele libere a persoanei responsabile
  • Stresul psihologic cauzat de relațiile interumane tensionate

Există diverse motive pentru care un membru se poate retrage brusc dintr-un proiect. Cu toate acestea, acestea sunt în principiu probleme de management al muncii din partea furnizorului. Prin urmare, chiar dacă aceste circumstanțe duc la întârzieri în livrare, posibilitatea de a fi scutit de încălcarea obligațiilor este scăzută. Adică, se așteaptă ca furnizorul să aibă o atitudine de gestionare a progresului proiectului cu planificare, luând în considerare și apariția bruscă a unui membru care se retrage.

Exemple importante de jurisprudență legate de retragerea membrilor

Vom prezenta exemple de cazuri generate de retragerea membrilor în dezvoltarea proiectelor.

Cazul în care plecarea unui membru a dus la întârzierea termenului de livrare

Cazul de jurisprudență citat mai jos se referă la o situație în care, după plecarea bruscă a unui membru, progresul proiectului nu a mai decurs conform planului, ceea ce a dus la întârzierea termenului de livrare. În acest caz, reprezentantul utilizatorului a adoptat o atitudine intimidantă față de reprezentantul furnizorului, ceea ce a creat o presiune psihologică suplimentară.

Conflictul a escaladat între utilizatorul care dorea să urmărească răspunderea pentru neexecutarea obligațiilor datorate întârzierii și furnizorul care dorea să urmărească încălcarea obligației de cooperare din partea utilizatorului care a adoptat o atitudine agresivă și intimidantă.

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

Însă, instanța a decis că circumstanțele nu exonerează furnizorul de obligația sa de gestionare a proiectului și a susținut punctul de vedere al utilizatorului (sublinierile și textul îngroșat au fost adăugate de autor).

Furnizorul susține că reprezentantul utilizatorului a adoptat o atitudine agresivă și intimidantă față de reprezentantul furnizorului, insultându-l, ceea ce a făcut ca reprezentantul furnizorului să fie nevoit să se retragă din proiect.

Este adevărat că reprezentantul utilizatorului a folosit un ton dur într-o întâlnire din noiembrie 2003 (Heisei 15), spunând “Nu ai chef de muncă?” și “Ce se întâmplă, acest contract se termină. Dacă plec din această cameră, se termină.” Cu toate acestea, aceasta se datorează faptului că, deși perioada prototipului a fost stabilită în acordul de bază până la sfârșitul lunii octombrie 2003 (Heisei 15), funcționalitatea suplimentară a scopului dezvoltării nu a fost inclusă în documentul de definire a cerințelor, iar răspunsul la comentariile adăugate la documentul de definire a cerințelor nu a fost primit, ceea ce indică întârzierea și răspunsul inadecvat al furnizorului. Nu se poate spune că a fost un comportament excesiv.

De asemenea, nu este clar motivul pentru care C s-a retras din proiect din cauza bolii, dar chiar dacă stresul cauzat de proiect a fost cauza, acesta este în principal o problemă de gestionare a muncii de către furnizor și nu poate fi atribuită utilizatorului.

Hotărârea Tribunalului din Tokyo, 4 decembrie 2007 (Heisei 19)

În cazul de jurisprudență de mai sus, instanța a luat în considerare faptul că utilizatorul a adoptat un “ton dur” față de furnizor, dar în cele din urmă nu a exonera furnizorul de responsabilitate. Se poate presupune că în spatele acestei decizii se află considerația că ar fi incorect să se atribuie responsabilitatea utilizatorului care a adoptat un “ton dur”, având în vedere răspunsul inadecvat al furnizorului. În acest context, instanța a adoptat schema potrivit căreia un proiect de dezvoltare de sistem este realizat prin îndeplinirea obligației de gestionare a proiectului de către furnizor și îndeplinirea obligației de cooperare de către utilizator, și a decis că nu ar trebui să se recunoască încălcarea obligației de cooperare de către utilizator. Această interpretare poate fi văzută în expresia “nu se poate spune că a fost un comportament excesiv”.

Ce putem înțelege din cazul juridic menționat mai sus

De asemenea, putem trage următoarele învățăminte importante:

  • În cazul în care un membru al proiectului se retrage din cauza unei boli, dacă se consideră că utilizatorul este de vină, se cere ca partea furnizorului să demonstreze o relație de cauzalitate cu privire la faptul că retragerea este vina utilizatorului → Cu toate acestea, se consideră că, de obicei, nu este ușor să se demonstreze că există o relație de cauzalitate.
  • Chiar dacă se poate dovedi că sarcina de muncă a crescut din cauza utilizatorului și că membrul a îmbolnăvit, în mod normal, în cele din urmă, se consideră că este o problemă de gestionare a muncii din partea furnizorului → Dacă ne concentrăm asupra faptului că în hotărârea judecătorească se folosește o exprimare puternică, cum ar fi “comportament excesiv”, ar trebui să considerăm că situațiile în care responsabilitatea de gestionare a muncii a furnizorului este exonerată sunt destul de limitate.

Pentru a ne pregăti de riscul de plecare a membrilor

Care sunt măsurile de prevenire a problemelor de plecare a membrilor proiectului?

Ca și cum am menționat mai sus, chiar dacă se produce o situație în care există un deficit brusc de personal, este extrem de dificil să atribuiți acest lucru părții utilizatorului. Este posibil să se întâmple în realitate să fiți forțați să faceți o dezvoltare suplimentară masivă sau să fiți forțați să faceți o schimbare de specificații forțată mai târziu, dar nu este ușor să dovediți relația de cauzalitate între disfuncția mentală și fizică și diverse sarcini de muncă. Având în vedere aceste circumstanțe, este mai degrabă important să avansezi cu pregătirea sistemului de personal presupunând apariția problemelor, cum ar fi absența bolii sau starea proastă a sănătății a membrilor proiectului.

Dacă acest punct este contestat în instanță, este clar că partea furnizorului va fi într-o situație foarte dezavantajoasă. Prin urmare, ceea ce este important este mai degrabă măsurile pentru a preveni astfel de conflicte. Măsurile posibile includ următoarele:

Organizați un sistem care să nu izoleze persoana responsabilă

Se crede că prevenirea situațiilor în care persoana responsabilă participă la întâlniri singură și crearea unui sistem în care mai multe persoane participă la întâlniri va preveni situațiile de izolare psihologică.

Încercați să aveți un personal suficient

Este important să aveți un personal suficient. Asigurarea personalului cu o marjă va duce cu siguranță la o creștere a costurilor. Cu toate acestea, dacă luați în considerare costurile de despăgubire pentru daunele cauzate de întârzierea termenului limită și faptul că există îngrijorări cu privire la apariția mai multor persoane care părăsesc în situația de gestionare a problemelor, poate fi rațional să asigurați personalul cu o anumită marjă de la început.

Revizuiți plasarea înainte de agravarea stării de sănătate

Există îngrijorări că dacă o persoană părăsește, sarcina de muncă a altor personal va crește, ceea ce va provoca un cerc vicios care va genera mai multe persoane care părăsesc. Pentru a preveni acest cerc vicios, se crede că este important să revizuiți plasarea înainte de a provoca o deteriorare gravă a stării de sănătate.

Implementați în mod riguros gestionarea schimbărilor și gestionarea documentelor proiectului

Este dificil să dovediți relația de cauzalitate între plecarea membrilor echipei și încălcarea obligației de cooperare din partea utilizatorului, dar este totuși important să implementați în mod riguros gestionarea schimbărilor și gestionarea documentelor. Acest lucru se datorează faptului că, chiar dacă nu puteți dovedi cauza plecării membrilor echipei, dacă există o situație de suprasolicitare care provoacă absența bolii a persoanei responsabile, există o posibilitate suficientă că aceasta include elemente care susțin încălcarea obligației de cooperare din partea utilizatorului. Aceste circumstanțe pot fi un element care susține justiția, cum ar fi compensarea neglijenței, chiar dacă se ajunge la o situație în care responsabilitatea pentru neexecutarea datoriei sau responsabilitatea pentru garanția defectelor este urmărită în cazul unui “incendiu” al proiectului.

În următorul articol, oferim o explicație despre importanța gestionării documentelor în proiectele de dezvoltare a sistemelor.

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

În plus, în special în ceea ce privește schimbarea specificațiilor, oferim o explicație detaliată în următorul articol.

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

Rezumat

Am prezentat mai sus o explicație juridică a fenomenului “plecarea membrilor echipei”. Pentru furnizor, a urmări responsabilitatea utilizatorului pentru plecarea membrilor este, fără îndoială, extrem de dificil din punct de vedere juridic.

Chiar și cu astfel de circumstanțe, este important să nu înțelegem greșit că “discuțiile juridice nu sunt utile în problema plecării membrilor echipei”. Procesul de gândire al cazului prezentat în sine ridică problema de a defini granițele între “obligația de management a proiectului a furnizorului” și “obligația de cooperare a utilizatorului”, și nu numai, dar măsurile de prevenire a conflictelor sunt adesea derivate prin retrocalcularea din situațiile de conflict anticipate.

Este important să înțelegem că “este dezavantajos să te lupți în instanță” nu înseamnă că “legea nu este utilă”, ci mai degrabă că “perspectiva juridică preventivă este importantă”.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

?napoi la ?nceput