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

MONOLITH LAW MAGAZINE

IT

Ce înseamnă obligațiile de management al proiectelor în dezvoltarea de sisteme

IT

Ce înseamnă obligațiile de management al proiectelor în dezvoltarea de sisteme

Dezvoltarea de sisteme este un proces care avansează doar prin cooperarea reciprocă între utilizatorul care comandă serviciul și furnizorul care îl acceptă.

Proiectele de dezvoltare a sistemelor IT utilizate în companii nu progresează adesea conform planului sau așteptărilor. Mai degrabă, este mai frecvent să se întâlnească cu numeroase probleme și provocări, mari sau mici, și să avanseze depășindu-le pe fiecare în parte. În acest context, este important nu doar să se facă eforturi pentru a alinia ritmul între partea utilizatorului și cea a furnizorului, dar și gestionarea crizelor în situații de conflict.

Din punct de vedere juridic, primul pas în gestionarea crizelor este clarificarea obligațiilor reciproce și a drepturilor pe care fiecare parte le poate revendica. În acest articol, vom explica în principal obligațiile legale pe care le are partea furnizorului în cadrul unui proiect, cu accent pe obligațiile de management al proiectului.

Ce înseamnă obligațiile de management al proiectului din partea furnizorului

Imaginea de management al proiectului

Să începem prin a examina conținutul obligațiilor de management al proiectului din partea furnizorului.

Conform jurisprudenței, conținutul obligațiilor de management al proiectului este următorul:

– Obligația de a avansa lucrările de dezvoltare în conformitate cu acordul, de a gestiona în permanență starea de progres și de a încerca să descopere factorii care împiedică lucrările de dezvoltare și de a le aborda în mod corespunzător

Aceasta implică faptul că furnizorul este solicitat să avanseze proiectul în conformitate cu programul stabilit prin contract și, în funcție de situație, să intervină pentru a asigura o dezvoltare lină a proiectului către utilizator.

– Obligația de a gestiona în mod corespunzător implicarea utilizatorului în dezvoltare și de a interveni la utilizator pentru a preveni orice acțiune care ar putea împiedica lucrările de dezvoltare de către utilizatorii care nu au cunoștințe de specialitate în dezvoltarea de sisteme

Aceasta implică indicarea problemelor și a termenelor pentru problemele și preocupările care necesită decizii din partea utilizatorului, indicarea problemelor care pot apărea dacă deciziile utilizatorului sunt întârziate, oferirea de sfaturi de către furnizor pentru a încuraja deciziile utilizatorului și, în cazul în care există cerințe care nu pot fi acceptate în funcție de progresul dezvoltării, explicarea în mod suficient motivele și refuzul cererilor utilizatorului.

Astfel, furnizorul are obligația de a avansa lucrările de dezvoltare și, în același timp, de a încuraja utilizatorul să ia decizii și de a face eforturi pentru ca dezvoltarea sistemului să fie un succes.

Obligația de cooperare a utilizatorului

Desigur, în dezvoltarea de sisteme, nu este cazul ca furnizorul să își asume unilateral toate obligațiile. În primul rând, fiind un sistem IT utilizat în cadrul companiei care a plasat comanda, proiectul de dezvoltare a sistemului nu ar trebui să fie “treaba altcuiva” pentru partea care comandă.

Chiar și atunci când se utilizează experți externi, bazându-se pe abilitățile și capacitatea organizațională de a dezvolta un sistem, guvernanța internă ar trebui să fie aplicată. Fără efortul de a valorifica puterea experților externi, este imposibil să se livreze toate lucrările necesare ca și cum ar fi treaba altcuiva. În acest sens, există și o obligație de cooperare în dezvoltarea sistemului pentru partea utilizatorului.

Obligațiile de cooperare pe care partea utilizatorului ar trebui să le îndeplinească sunt următoarele:

 ①Utilizatorul efectuează în mod proactiv o analiză a riscurilor și coordonează în mod corespunzător opiniile interne pentru a unifica punctele de vedere și a comunica cerințele furnizorului

 ②Verificarea produselor finite

 ③Răspunde la solicitările de cooperare din partea furnizorului

Se așteaptă ca partea utilizatorului să comunice clar funcțiile pe care le dorește de la sistem către partea furnizorului și să coopereze activ în dezvoltare.

Managementul proiectelor nu este o sarcină ușoară

Imagine simbolizând managementul proiectelor
Managementul riscurilor proiectului este o premisă esențială în desfășurarea acestuia.

Poate că nu este ușor de conștientizat pentru utilizatorii care privesc doar ecranul, dar sistemele IT sunt compuse dintr-o multitudine de componente mici. Aceasta este o considerație extrem de importantă atunci când ne gândim la dificultatea managementului unui proiect de dezvoltare a sistemelor IT. Tocmai pentru că sistemele IT sunt astfel construite, de la furnizori se așteaptă atât o atenție meticuloasă, cât și capacitatea de a organiza și a privi în ansamblu imaginea de ansamblu într-un mod concis.

Complexitatea activității poate fi greu de imaginat doar privind ecranul, iar aceasta poate fi, de asemenea, motivul pentru care un proiect “arde”. Înțelegerea acestor aspecte și conștientizarea faptului că “managementul unui proiect de dezvoltare a sistemelor IT nu este deloc o sarcină ușoară” va fi o premisă esențială atunci când învățăm despre managementul riscurilor proiectului.

Ce se poate întâmpla în cazul încălcării obligațiilor de management al proiectului

Deci, ce se poate întâmpla concret în cazul încălcării obligațiilor de management al proiectului?

Nu există niciun articol clar care să spună “acestea sunt obligațiile de management al proiectului”.

Însă, din precedentele judiciare, putem deduce o anumită poziție consecventă cu privire la ce poate face un utilizator în cazul în care furnizorul a încălcat obligațiile.

Dacă furnizorul a încălcat obligațiile, utilizatorul poate solicita daune și rezilierea contractului. Cu toate acestea, dacă utilizatorul are și el probleme, se poate decide că furnizorul nu este responsabil sau se poate aplica o compensare pentru neglijență, ceea ce ar putea reduce suma daunelor.

Pe de altă parte, dacă utilizatorul a încălcat obligația de cooperare, furnizorul poate solicita utilizatorului o sumă echivalentă cu remunerația, pe baza faptului că munca nu a fost finalizată din cauza acestuia (Articolul 536 alineatul (2) al Codului Civil Japonez) sau pe baza neexecutării obligațiilor.

Exemple de jurisprudență care indică obligațiile de management al proiectelor

Ca exemple reprezentative de jurisprudență care explică ce înseamnă obligațiile de management al proiectelor, avem următoarele:

Cazurile de mai jos s-au dezvoltat în litigii din cauza întârzierilor în termenele de livrare în dezvoltarea de sisteme, sau din cauza faptului că furnizorul a cerut o creștere a estimării inițiale. Acestea sunt exemple tipice de cazuri “incendiare”, unde disputa a ajuns până în instanță în legătură cu modul în care ar trebui să se facă delimitarea responsabilităților între utilizator și furnizor.

Defendantul, ca specialist în dezvoltarea de sisteme, avea obligația, pe baza cunoștințelor și experienței sale profesionale avansate, să construiască sistemul descris în contractul și propunerea de dezvoltare a sistemului informatic, și să finalizeze sistemul informatic până la termenul de livrare convenit în etape.
Prin urmare, defendantul ar trebui să înțeleagă că avea obligația de a avansa lucrările de dezvoltare în conformitate cu procedurile, metodele de dezvoltare și procesele de lucru prezentate în contractul și propunerea de dezvoltare a sistemului informatic, să gestioneze în permanență starea de progres, să se străduiască să descopere factorii care împiedică lucrările de dezvoltare și să se ocupe corespunzător de aceștia. În plus, dezvoltarea sistemului se face prin consultări repetate cu comandantul, ținând cont de intențiile acestuia, astfel încât defendantul ar trebui să gestioneze corespunzător și implicarea comandantului, adică reclamantul, în dezvoltarea sistemului, și să aibă obligația de a influența reclamantul, care nu are cunoștințe de specialitate în dezvoltarea sistemelor, pentru a preveni orice acțiune care ar putea împiedica lucrările de dezvoltare (aceste obligații vor fi denumite în continuare “obligații de management al proiectului”).

Judecătoria Tokyo, 10 martie 2004 (Heisei 16)

Nu este important să înțelegem detaliile sau complexitatea cazului din rezumatul sentinței de mai sus. Punctul cheie este că termenul “obligații de management al proiectului” este folosit direct. Deși nu există nicio dispoziție explicită în acest sens, se poate observa o atitudine de stabilire a unor linii directoare pentru delimitarea responsabilităților legale de către instanță.

Să rezumăm și să organizăm conținutul sentinței de mai sus într-o formă simplificată și punctată. Obligațiile de management al proiectului menționate aici includ:

  • Avansarea lucrărilor reale în conformitate cu planul inițial (proceduri de dezvoltare, metode, procese etc.)
  • Monitorizarea progresului pentru a vedea dacă lucrările reale progresează fără probleme
  • Dacă există “factori de obstrucție” care împiedică progresul fără probleme al lucrărilor reale, descoperirea și luarea de măsuri corespunzătoare pe măsură ce apar

În plus, cu privire la cele trei puncte de mai sus,

  • În loc de eforturi de auto-ajutorare unilaterale din partea furnizorului, se face efortul de a comunica, solicitând cooperarea adecvată din partea utilizatorului, dacă este necesar

Putem organiza că acestea sunt ceea ce se înțelege prin “obligații de management al proiectului”.

De asemenea, dezvoltarea sistemului este, în majoritatea cazurilor, încheiată sub forma unui contract de mandat sau unui contract de lucrări. Și contractul de mandat este, simplu spus, un contract care spune “să lucrezi cu o precizie corespunzătoare remunerației pe care o primești”, deci obligațiile de management al proiectului pot fi considerate un concept care este absorbit în “precizia etc.” care ar trebui realizată.

Deși este un subiect de discuție, se consideră că obligațiile de management al proiectului pot apărea și în cazul unui contract de lucrări, care este un contract de “a face ceea ce este cerut”. Motivul este, așa cum am menționat deja, că indiferent dacă este un contract de mandat sau un contract de lucrări, managementul proiectului este important în dezvoltarea sistemului, și se consideră că partea furnizorului ar trebui să o facă.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Exemplu de judecată care indică obligația de management al proiectului impusă chiar înainte de încheierea contractului

De asemenea, se consideră că obligația de management al proiectului poate fi impusă chiar și în etapa preliminară a încheierii contractului. Exemplul de judecată citat mai jos indică faptul că, chiar și în etapa preliminară a încheierii contractului, adică în etapa în care se fac diverse propuneri și planuri, există o obligație de management al proiectului pentru partea furnizorului.

Cazul de mai jos se referă la un proiect care a eșuat în mijlocul procesului, iar faptul că nu s-a putut recunoaște obligația de management al proiectului din cauza deficiențelor în planificare și propuneri în etapa preliminară a încheierii contractului, precum și în estimările și explicațiile pentru utilizatori în etapa de propunere, a fost contestat. În general, problema a fost dacă este legal posibil să se recunoască astfel de obligații, deoarece activitățile de planificare și propunere sunt în etapa preliminară a încheierii contractului, dar instanța a recunoscut acest lucru.

Conceptul de obligație de management al proiectului în exemplul de judecată menționat mai sus se aplică și discuțiilor din etapa preliminară a încheierii contractului, așa cum se poate vedea clar din lectura de mai jos.

În etapa de planificare și propunere, se stabilesc liniile mari ale proiectului, cum ar fi stabilirea obiectivelor proiectului, costurile de dezvoltare, domeniul de dezvoltare și structurarea/durata estimată a dezvoltării, precum și posibilitatea realizării conceptului de proiect. În același timp, riscurile asociate cu proiectul sunt, de asemenea, determinate în conformitate cu acestea. Prin urmare, planificarea proiectului și analiza riscurilor cerute de furnizor în etapa de planificare și propunere sunt esențiale pentru implementarea dezvoltării sistemului. În acest caz, ca furnizor, ar trebui să se considere că există o obligație de a examina și verifica funcționalitatea sistemului propus, gradul de satisfacție a nevoilor utilizatorului, metoda de dezvoltare a sistemului, structura de dezvoltare după primirea comenzii, etc., chiar și în etapa de planificare și propunere, și de a explica riscurile presupuse utilizatorului. Această obligație a furnizorului de a verifica și explica este poziționată ca o obligație legală bazată pe principiul bunei credințe în procesul de negociere pentru încheierea contractului, și se poate spune că apelantul, ca furnizor, are această obligație (obligația de management al proiectului la acest stadiu).

Decizia Curții Superioare din Tokyo, 26 septembrie 2013 (Heisei 25)

De asemenea, ideea că există o anumită obligație legală față de partea opusă chiar și în etapa preliminară înainte de încheierea contractului nu se limitează la discuțiile despre proiectele IT, ci este ceva care a existat inițial în toate tranzacțiile comerciale și negocierile în care sunt implicate legi.

În mod tipic, cu cât tranzacția este mai mare, cu atât procesul de “apropiere” până la obiectivul contractului tinde să fie mai lung. Chiar și în acest proces, ideea că ar trebui să fii sincer față de partea opusă este cel puțin bine înțeleasă ca o poveste morală. Simplu spus, aceste discuții nu se limitează la sentimentele morale emoționale, ci au și un sens legal. (Textul legii este citat mai jos. Sublinierea a fost adăugată de autor.)

Articolul 1 alineatul 2 al Codului Civil Japonez
Exercitarea drepturilor și îndeplinirea obligațiilor trebuie să se facă în conformitate cu buna-credință și sinceritate.

Putem spune că termenul cheie care exprimă în mod concis conținutul de mai sus în deciziile judecătorești este “principiul bunei-credințe”.

De asemenea, exemplele de cazuri judiciare pe care le-am prezentat în acest articol au, într-un anumit sens, semnificația unui “ghid pentru trasarea granițelor între obligațiile de cooperare ale utilizatorilor și obligațiile de management al proiectelor ale furnizorilor”. Pentru obligațiile de cooperare ale utilizatorilor în dezvoltarea sistemelor IT, vă rugăm să consultați articolul de mai jos.

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

Concluzie: În caz de probleme legate de încălcarea obligațiilor de management al proiectului, consultați un avocat

Persoană care consultă legea

În acest articol, am încercat să organizăm în mod general conceptul de obligații de management al proiectului în dezvoltarea de sisteme. Dezvoltarea de sisteme implică diverse provocări și probleme, dar ceea ce pare a fi important atunci când ne confruntăm cu astfel de situații este “fundamentul” care este comun în orice scenă de conflict. Fără îndoială, există o varietate infinită de situații iregulare.

Însă, în fața acestor situații, importanța de a întreba “În primul rând, cine și cât de multe obligații legale a asumat?” are o anumită universalitate care depășește individualitatea cazului în sine.

În loc să ne limităm la rezolvarea problemelor pe loc, când ne propunem să rezolvăm problemele într-un mod constructiv prin divizarea problemelor, indiciile se găsesc, de asemenea, în lege și în precedentele judiciare.

În cazul în care apar probleme legate de încălcarea obligațiilor de management al proiectului, consultați imediat un avocat.



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