Ce înseamnă gestionarea schimbărilor în dezvoltarea de sisteme din punct de vedere juridic?

În proiectele de dezvoltare a sistemelor, se întâmplă adesea ca utilizatorii să schimbe conținutul pe care l-au explicat în prealabil pe măsură ce proiectul avansează. Prin urmare, chiar și ca furnizor care acceptă proiectul, poate fi necesar să se adapteze la modificările contractului, chiar și după ce acesta a fost încheiat o dată.

Acest articol explică cum ar trebui abordat fenomenul “modificării”, care are loc ulterior, din punct de vedere juridic, în ceea ce privește proiectele de dezvoltare a sistemelor care nu progresează întotdeauna conform planului.

De ce sunt “modificate” proiectele de dezvoltare a sistemelor după finalizare?

Dezvoltarea sistemelor este o colaborare între furnizor și utilizator

Dezvoltarea sistemelor, în general, trece prin etapa de planificare și propunere, unde cerințele de dezvoltare sunt definite și contractul este încheiat. După încheierea contractului, procesul urmează diverse etape de proiectare, implementare conform proiectului, și în final, testare. În întregul acest proces, furnizorul care preia sarcina are, desigur, o responsabilitate largă ca expert în dezvoltarea sistemelor, dar și utilizatorul are o anumită obligație de cooperare. În special în etapele de identificare a funcțiilor pe care sistemul ar trebui să le aibă (definirea cerințelor), aspectul și simțul de operare al ecranului (proiectare de bază), și verificarea dacă s-a realizat ceea ce era cerut (testare sau acceptare), cooperarea utilizatorului devine esențială. Pentru o explicație generală a obligațiilor pe care le are utilizatorul în dezvoltarea sistemelor, vă rugăm să consultați articolul de mai jos.

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

Deși există o obligație de cooperare, utilizatorii solicită adesea modificări

Însă, chiar dacă utilizatorii nu sunt experți în dezvoltarea sistemelor, nu înseamnă că pot transmite întotdeauna în mod exhaustiv și fără lacune informațiile necesare dezvoltării sistemelor. În realitate, datorită naturii detaliate și precise a muncii, există multe lucruri pe care utilizatorul nu le poate prezice, cum ar fi ce fapte ar putea avea un impact decisiv în etapele ulterioare. Ironia este că, cu cât un fapt este mai important, cu atât este mai probabil să fie dezvăluit treptat. Din aceste motive, în proiectele reale, deși idealul ar fi “o trecere continuă de la etapele inițiale la cele finale”, se presupune că vor exista diverse modificări după finalizare. Prin urmare, modul în care se gestionează “modificările” devine un aspect crucial.

Ce este un document de gestionare a modificărilor?

Scenarii în care se utilizează documentul de gestionare a modificărilor

Documentul de gestionare a modificărilor este un document folosit atunci când utilizatorul solicită furnizorului să facă modificări ale specificațiilor sau să adauge funcții, diferite de cele descrise inițial. Așa cum am menționat anterior, în faze precum definirea cerințelor sau proiectarea de bază, utilizatorul are și el obligația de a coopera cu activitatea furnizorului, dar este posibil ca în etapele ulterioare să apară cerințe diferite.

Exemple de situații în care este necesar documentul de gestionare a modificărilor ar putea fi, de exemplu:

• Când există omisiuni în discuțiile privind definirea cerințelor sau proiectarea de bază și se solicită adăugarea de funcții ulterior
• Când, în timpul dezvoltării, se revizuiesc politici de afaceri și devine necesară modificarea specificațiilor

Acestea sunt doar câteva exemple.

În legătură cu subiecte precum adăugarea de funcții sau modificarea specificațiilor, ceea ce îi preocupă cel mai mult pe cei care primesc sarcina este dacă modificarea sumei estimate este permisă din punct de vedere legal. Acest aspect este explicat în detaliu într-un alt articol.

https://monolith.law/corporate/increase-of-estimate[ja]

Documentul de gestionare a modificărilor servește ca bază pentru a evalua validitatea unei estimări revizuite ulterior. Crearea acestui document este importantă pentru a evita disputele atunci când se face o cerere pe baza unei estimări majorate ulterior și pentru a adăuga convingere argumentelor proprii în cazul în care apar dispute.

Elemente de notat în documentul de gestionare a modificărilor

Deci, care sunt elementele care ar trebui să fie notate în documentul de gestionare a modificărilor din punct de vedere legal? Mecanismul contractului de a răspunde la schimbările de specificații și adăugarea de funcții prin utilizarea documentului de gestionare a modificărilor este deja larg recunoscut în general. Prin urmare, verificând modelele de clauze contractuale prezentate de agențiile guvernamentale, cum ar fi contractul model al Ministerului Economiei, Comerțului și Industriei (METI) din Japonia, puteți înțelege în general ce elemente ar trebui să fie lăsate ca înregistrare.

(Procedura de gestionare a modificărilor)
Articolul 37. Fie A sau B, atunci când primește o propunere de modificare bazată pe Articolul 34 (Modificarea specificațiilor sistemului etc.), Articolul 35 (Aprobarea utilizatorului pentru documentele intermediare), Articolul 36 (Tratarea elementelor nesigure), trebuie să furnizeze partenerului un document scris care notează următoarele elemente (denumit în continuare “Document de gestionare a modificărilor“) în termen de ○ zile de la data primirii, și A și B vor discuta acceptabilitatea acestei modificări la Consiliul de Comunicare specificat în Articolul 12.
① Numele modificării
② Responsabilul propunerii
③ Data
④ Motivul modificării
⑤ Detalii ale modificării, inclusiv specificațiile legate de modificare
⑥ Dacă este necesar un cost pentru modificare, suma acestuia
⑦ Programul de lucru pentru modificare, inclusiv perioada de examinare
⑧ Alte efecte pe care modificarea le-ar putea avea asupra termenilor contractului și contractului individual (perioada de lucru sau termenul de livrare, taxa de comision, clauzele contractuale, etc.)

Dacă citiți direct textul legii și verificați elementele care sunt recomandate pentru notare, nu este nevoie de mai multe explicații. Pentru a evita problemele de “am spus / nu am spus” mai târziu, ar trebui să înregistrați în detaliu și concret cursul modificării.

Notând aceste elemente și setându-le împreună cu semnăturile sau ștampilele responsabililor și decidenților atât ai furnizorului cât și ai utilizatorului, chiar dacă ar fi să ajungă la tribunal, va avea aceeași semnificație ca și contractul ca dovadă.

Ce ar trebui să știți despre gestionarea schimbărilor

Gestionarea schimbărilor este de obicei realizată împreună cu gestionarea problemelor

Motivul pentru care se creează un document de gestionare a schimbărilor este de a gestiona istoricul schimbărilor, ceea ce poate ajuta la realizarea proiectului (sau, în cazul în care proiectul nu este realizat, poate ajuta la evitarea acuzațiilor nejustificate). În practică, crearea unui document de gestionare a schimbărilor este adesea realizată împreună cu crearea și actualizarea unui tabel de gestionare a problemelor. Adică, odată ce istoricul schimbărilor este gestionat în tabelul de gestionare a schimbărilor, elementele de schimbare convenite sunt incluse ca probleme care trebuie abordate în tabelul de gestionare a problemelor.

Este mai bine să stabiliți reguli și pentru modul în care se desfășoară discuțiile despre schimbări

Nu numai modul de gestionare a schimbărilor, dar și modul în care se desfășoară discuțiile despre schimbări ar trebui să fie reglementate, pentru a se aștepta ca gestionarea schimbărilor să decurgă fără probleme. Acest lucru este deosebit de important atunci când se utilizează metode de dezvoltare precum dezvoltarea agilă, unde se presupune că vor fi făcute diverse schimbări după fapt. În practică, există multe exemple în care se stabilește când partea adversă ar trebui să răspundă la o solicitare de discuție despre gestionarea schimbărilor.

Discuțiile despre schimbări și obligația de bună-credință

Când se schimbă un contract asupra căruia ambele părți au convenit o dată, acesta este practic încheierea unui nou contract. Din punct de vedere teoretic, având în vedere că contractul se bazează pe voința liberă a părților, furnizorul nu are obligația de a accepta contractul de schimbare. Cu toate acestea, dacă acest aspect al drepturilor este prea accentuat, există îngrijorarea că proiectul de dezvoltare a sistemului nu va progresa fără probleme.

Prin urmare, în practică, este adesea stipulat în contract că există o “obligație de a răspunde cu bună-credință la discuțiile despre schimbări”, și există exemple în care este stipulat că dacă furnizorul nu răspunde cu bună-credință la schimbări, poate fi posibil să se solicite despăgubiri pentru daune.

Un exemplu de astfel de stipulare ar fi următorul (citat din “Modelul de contract de bază/individual” creat oficial de Organizația Independentă de Promovare a Procesării Informațiilor).

Articolul 4, alineatul 3: În discuțiile despre schimbări, se vor examina obiectul schimbării, posibilitatea schimbării, impactul schimbării asupra prețului și termenului de livrare, și ambele părți vor discuta cu bună-credință dacă să facă schimbarea.

Regulile privind modul de schimbare

După cum s-a menționat mai sus, atunci când se face o schimbare, este “sigur” din punct de vedere juridic să se organizeze discuții despre schimbări de fiecare dată. Cu toate acestea, în cazul unui proiect de mică anvergură, s-ar putea să nu fie necesar să se stabilească modul în care se desfășoară discuțiile despre schimbări. În acest caz, în loc să se stabilească reguli pentru discuții, se poate considera că schimbarea se face numai atunci când semnăturile/ștampilele responsabililor utilizatorilor și furnizorilor sunt aplicate pe documentul de gestionare a schimbărilor, chiar dacă nu există discuții. Dacă se permite schimbarea doar prin acordul verbal, este adesea neclar dacă s-a făcut sau nu o schimbare, ceea ce poate duce la probleme majore mai târziu. Prin urmare, gestionarea documentelor ar trebui să fie riguroasă.

Desigur, poate fi o povară să se pregătească documente separate pentru gestionarea schimbărilor de fiecare dată, și s-ar putea dori să se acorde prioritate unei abordări flexibile. În astfel de cazuri, o opțiune ar fi să se documenteze problemele legate de schimbări în procesul verbal al ședinței. Modul în care se păstrează procesele verbale ale ședințelor în dezvoltarea sistemelor este explicat în detaliu în articolul de mai jos.

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

Rezumat

Într-un mediu unde schimbările de specificații sunt frecvente, este adevărat că există o tendință de a fi însoțit de probleme și dispute. Cu toate acestea, în astfel de situații unde este necesară o flexibilitate imediată, sublinierea strictă a “importanței gestionării” poate face dificilă implementarea unor măsuri practice.

Problema de a echilibra viteza necesară în afaceri cu pregătirea pentru situații neprevăzute variază adesea în funcție de situația companiei și conținutul proiectului. Având în vedere conținutul acestui articol, considerăm că este important să căutăm fiecare companie și proiect în parte pentru a găsi metoda potrivită.