Ce legi sunt legate de 'flambarea' proiectelor de dezvoltare a sistemelor?

Un proiect de dezvoltare a sistemului nu este ceva ce se poate realiza peste noapte, ci necesită investirea unei cantități mari de resurse, inclusiv numeroase persoane și organizații, fonduri substanțiale și o perioadă lungă de dezvoltare. În acest articol, vom explica cum poate fi structurat fenomenul de “ardere” al unui proiect în cadrul dezvoltării sistemului într-un cadru legal, și vom prezenta o serie de soluții posibile.

De ce “arde” proiectele?

Un sistem IT, chiar dacă nu este un proiect de o scară excepțional de mare, funcționează corect doar datorită acumulării unei cantități mari de fișiere de program și cod sursă. Adesea, acestea sunt mult mai complexe și detaliate decât ne-am putea imagina din perspectiva interfeței utilizatorului (sau, mai degrabă, cu cât sistemul IT pare mai simplu și mai concis din perspectiva interfeței utilizatorului).

• Termenul de livrare este stabilit în avans, în timp ce specificațiile și cerințele rămân neclare pe măsură ce timpul trece
• Membrii sunt preocupați doar de problemele politice interne, iar mulți dintre ei renunță pe parcurs din cauza stresului relațiilor interumane
• Există o lipsă de abilități de negociere la nivelul de management, inclusiv la PM, și nu se solicită membrilor să raporteze, să comunice și să consulte în mod adecvat

Motivele specifice pentru “arderea” unui proiect pot varia de la un proiect la altul. Cu toate acestea, din punct de vedere juridic, motivele pentru “arderea” unui proiect pot fi organizate destul de simplu în câteva tipuri diferite.

Tipul 1 de incendiu: Când un proiect se oprește în mijloc

În cadrul dezvoltării unui sistem, un motiv tipic pentru care acesta se poate opri în mijloc este lipsa de comunicare între partea de utilizatori și partea de furnizori. În primul rând, un proiect de dezvoltare a sistemului necesită nu numai expertiza tehnică și organizatorică a furnizorului, dar și cooperarea părții utilizatorului care va utiliza în cele din urmă sistemul.

Prin urmare, dacă un proiect avansează cu rolurile fiecărei părți nedefinite, și se naște o situație de “împingere a responsabilităților”, progresul fără probleme al proiectului poate fi împiedicat. Pentru o examinare juridică a obligațiilor părții utilizatorului și a părții furnizorului, vă rugăm să consultați articolele de mai jos.

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

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

Detaliile despre responsabilitățile pe care fiecare parte le are pot fi verificate în articolele de mai sus, dar punctul cheie aici este că în cadrul unui singur proiect de dezvoltare a sistemului, atât utilizatorii cât și furnizorii au anumite responsabilități. În termeni generali, instanțele și cazurile de judecată din trecut recunosc obligația de cooperare a părții utilizatorului pentru aspecte care nu pot fi finalizate fără cooperarea părții utilizatorului, cum ar fi definirea cerințelor, proiectarea aspectului exterior, cum ar fi ecranele (adică proiectarea de bază), și acceptarea.

Pe de altă parte, partea furnizorului, după ce a primit cooperarea părții utilizatorului în aspectele menționate mai sus (și în același timp, după ce a făcut eforturi de comunicare pentru a solicita această cooperare), are o obligație cuprinzătoare de a asigura progresul fără probleme al proiectului și de a identifica și elimina factorii care îl împiedică.

Sub această abordare, instanțele arată că atât partea utilizatorului, care are obligația de a exercita guvernanța internă, cât și partea furnizorului, care, ca expert extern, își exercită expertiza și competențele tehnice în activitatea sa, au obligația de a trata toate conflictele în mod echitabil.

De asemenea, momentul în care aceste “întreruperi” sunt cel mai probabil să apară este momentul acceptării. Detalii despre acceptare pot fi găsite în articolul de mai jos.

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

În astfel de cazuri, odată ce devine un conflict, se acordă o mare importanță dovezilor care pot fi verificate obiectiv, cum ar fi evoluția proiectelor anterioare și conținutul discuțiilor de la întâlniri. Prin urmare, documentele înregistrate în prealabil au adesea o mare importanță. Pentru a nu vă dezavantaja poziția, este esențial să gestionați cu strictețe documentele. Pentru o discuție detaliată despre importanța gestionării documentelor în dezvoltarea sistemelor, vă rugăm să consultați articolul de mai jos.

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

Tipul de flacără 2: Când utilizatorul anulează din motive proprii

De asemenea, este posibil ca un proiect să fie oprit la jumătatea drumului din cauza dorințelor utilizatorului. De exemplu, să presupunem că o companie a început să dezvolte un sistem IT care să gestioneze toate resursele umane, inclusiv cele din străinătate, dar strategia de extindere a pieței prin expansiunea în străinătate a fost retrasă. În astfel de cazuri, dezvoltarea sistemului care a început ar putea deveni inutilă pentru utilizator.

În primul rând, problema modului în care ar trebui construit un sistem IT utilizat într-o companie nu poate fi separată de problema “ce tip de activități există în cadrul companiei”. Prin urmare, este posibil ca cerințele sistemului necesar (sau inutil) să se schimbe după faptul că a fost afectat de schimbări majore în structura organizațională, reorganizarea departamentelor de afaceri, revizuirea fundamentală a strategiei, etc.

În astfel de circumstanțe, dacă un proiect este întrerupt la jumătatea drumului, pot apărea diverse probleme legale. În astfel de cazuri, de obicei, din cauza circumstanțelor proprii ale utilizatorului, furnizorul are dreptul legal de a solicita o remunerație proporțională cu procentul de finalizare. În funcție de tipul de contract adoptat, există diferențe în articolele de bază, dar conținutul este organizat după cum urmează:

・În cazul unui contract de lucrări: Articolul 641 al Codului Civil Japonez
Articolul 641 al Codului Civil Japonez
→În timp ce lucrătorul nu a terminat munca, comandantul poate anula contractul în orice moment, despăgubind daunele.
・În cazul unui contract de mandat: Articolul 648 alineatul (3) al Codului Civil Japonez (în funcție de circumstanțe, poate fi solicitată și despăgubirea pentru daune în baza articolului 651 al Codului Civil Japonez)
Articolul 648 al Codului Civil Japonez
→Dacă mandatul se încheie în mijlocul executării din cauza unor motive care nu pot fi atribuite mandatarului, mandatarul poate solicita o remunerație proporțională cu performanța deja realizată.
Articolul 651 al Codului Civil Japonez
→1. Mandatul poate fi anulat în orice moment de către fiecare parte.
→2. Dacă una dintre părți anulează mandatul într-un moment defavorabil pentru cealaltă parte, acea parte trebuie să despăgubească daunele celeilalte părți. Cu toate acestea, acest lucru nu se aplică dacă există motive inevitabile.

Tipul 3 de criză: Când deficiențele sistemului livrat sunt descoperite ulterior

Deși utilizatorii înțeleg adesea performanța unui sistem prin intermediul experienței de utilizare a interfeței, din perspectiva celor care prestează serviciul, aspectele mai complexe sunt legate de proiectarea bazei de date și de identificarea elementelor de testare, luând în considerare toate metodele posibile de operare.

Prin urmare, chiar și în cazul unui sistem care pare să funcționeze fără probleme la început, pot apărea situații precum:

• Pe măsură ce volumul de date înregistrate crește, viteza de procesare începe să scadă;
• Chiar dacă sistemul pare să funcționeze fără probleme în operațiunile de bază zilnice, se poate descoperi că apar erori în operațiunile speciale care au loc o dată la câteva luni sau ani;
• Chiar dacă rezultatele par să fie corect generate la suprafață, logica reală poate fi greșită. De exemplu, chiar dacă răspunsul corect “2” este generat pentru intrarea “1+1” din partea utilizatorului, nu este garantat că procesarea calculului este corectă. Dacă orice formulă de calcul introdusă returnează “2”, această eroare de logică nu poate fi adesea descoperită doar prin operarea ecranului. În acest sens, se poate spune că o anumită “abilitate tehnică” este necesară în procesul de testare.

Acestea sunt situații care pot apărea în realitate. Dacă analizăm aceste cazuri dintr-un punct de vedere juridic, putem considera posibilitatea unei încălcări a obligațiilor de management al proiectului din partea furnizorului, adică o problemă de îndeplinire incompletă în conformitate cu Codul Civil.

În acest caz, dacă nu există nicio regulă specială stabilită în contract, se aplică în mod normal prevederile referitoare la contractele de prestări servicii.

Punctele care ar trebui luate în considerare în acest caz sunt organizate după cum urmează:

https://monolith.law/corporate/defect-warranty-liability[ja]

Așa cum este organizat mai sus.

Rezumat

Fiecare proiect de dezvoltare a sistemului va avansa prin diverse și variate întorsături. Cu toate acestea, atunci când vine vorba de “incendierea” unui proiect din punct de vedere legal, cadrul prezentat în acest articol poate servi ca o hartă. Problemele legale legate de dezvoltarea sistemului includ, într-adevăr, o varietate foarte mare de teme.

Însă, așa cum dezvoltarea sistemului necesită o gândire constructivă, gestionarea riscurilor asociate cu aceasta poate fi, de asemenea, realizată într-un mod mai constructiv, fără a pierde imaginea de ansamblu a domeniului. Nu este așa?