Ce înseamnă finalizarea unui contract de prestări servicii în dezvoltarea de sisteme

Dezvoltarea de sisteme este de obicei un proces care se întinde pe o perioadă lungă de timp, iar în plus, pot exista situații în care se solicită în mod repetat modificări ale specificațiilor sau implementarea de funcții suplimentare. Pentru furnizorii care preiau aceste sarcini, pot exista momente în care se pot afla într-o situație dificilă, fără o ieșire vizibilă. Pentru astfel de furnizori, problema “Ce trebuie să facem și până unde trebuie să mergem pentru a considera că ne-am îndeplinit sarcina?” poate deveni uneori o sursă de îngrijorare serioasă.

Și, deși dezvoltarea de sisteme este adesea realizată prin contracte de subcontractare, aceste contracte vizează “finalizarea lucrării”.

În acest articol, vom explica din punct de vedere juridic “la ce moment și până unde trebuie să se realizeze dezvoltarea sistemului pentru a fi considerată finalizată”.

Finalizarea dezvoltării sistemului

Finalizarea dezvoltării sistemului din perspectiva unui inginer

În cadrul dezvoltării unui sistem, dacă am întreba “când este finalizată dezvoltarea sistemului”, răspunsul general ar fi “când etapa de testare este finalizată și produsul final este livrat”. Într-adevăr, fluxul general al dezvoltării unui sistem începe cu definirea cerințelor, care implică identificarea funcțiilor care trebuie implementate, urmată de crearea diverselor documente de proiectare, implementarea programului și, în final, finalizarea etapei de testare pentru a verifica dacă sistemul funcționează corect. Procesul se încheie cu acceptarea de către utilizator.

Prin urmare, din perspectiva unui inginer implicat direct în activitățile specifice, este comună înțelegerea că “finalizarea dezvoltării sistemului = acceptarea finală”.

Finalizarea dezvoltării sistemului din perspectiva juridică

Pe de altă parte, dacă am întreba din punct de vedere juridic când este finalizată dezvoltarea unui sistem, discuția se va concentra în mod natural asupra momentului în care obligațiile legale pe care furnizorul le-a asumat în contract sunt îndeplinite. În primul rând, contractele de dezvoltare a sistemelor sunt în general clasificate fie ca contracte de prestări de servicii, fie ca contracte de mandat.

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

Explicația diferențelor dintre aceste două tipuri de contracte este lăsată în articolul de mai sus, dar dacă vorbim despre finalizarea dezvoltării sistemului, adică îndeplinirea obligațiilor pe care le are furnizorul, criteriile de judecată sunt date astfel:

Contract de prestări de servicii: Articolul 632 din Codul Civil
Articolul 632
Contractul de prestări de servicii ia naștere atunci când una dintre părți se angajează să finalizeze o anumită muncă, iar cealaltă parte se angajează să plătească o remunerație pentru rezultatul acestei munci.
Contract de mandat: Articolul 648 din Codul Civil
Articolul 648
1. În absența unui acord special, mandatarul nu poate solicita o remunerație de la mandant.
2. Mandatarul, în cazul în care trebuie să primească o remunerație, nu poate solicita aceasta decât după îndeplinirea mandatului. Cu toate acestea, dacă remunerația a fost stabilită în funcție de durată, se aplică prevederile articolului 624 alineatul (2).
3. Dacă mandatul se încheie în timpul îndeplinirii din cauze care nu pot fi imputate mandatarului, acesta poate solicita o remunerație proporțională cu îndeplinirea deja realizată.

Finalizarea dezvoltării sistemului este o problemă în contractele de prestări de servicii

În orice caz, problema “când este finalizată munca” este, în principiu, o problemă în contractele de prestări de servicii, nu doar în contextul dezvoltării sistemelor. În cazul contractelor de mandat, mai degrabă decât a considera îndeplinirea obligațiilor ca aducând un anumit rezultat sau produs, acestea sunt contracte care presupun că o persoană cu expertiză va acționa cu o anumită discreție și va face ceea ce trebuie făcut, indiferent de rezultat. În contractele de mandat, chiar și în textul legii, chiar dacă produsul final nu este conform așteptărilor, dacă procesul de gestionare a fost realizat corect, se poate solicita o remunerație (articolul 648 alineatul (2)), iar dacă îndeplinirea se încheie în timpul procesului din cauze care nu pot fi imputate mandatarului, se poate solicita o remunerație proporțională cu îndeplinirea deja realizată (articolul 648 alineatul (3)). Contractele de prestări de servicii sunt “orientate spre rezultat”, în timp ce contractele de mandat sunt “orientate spre proces”.

Prin urmare, în contractele de mandat, problema legală tinde să fie mai degrabă “obligația de a fi atent” în procesul de îndeplinire a mandatului. Adică, când se presupune că există o încredere mare, problema este când se poate urmări încălcarea obligației de a fi atent în baza contractului de mandat.

Pe de altă parte, în contractele de prestări de servicii, ceea ce este important este “finalizarea muncii”. Dacă ceea ce trebuie finalizat nu este finalizat, furnizorul nu poate îndeplini obligațiile pe care le are și, în principiu, nu poate solicita o remunerație. Cu toate acestea, dacă este finalizat, nu există niciun motiv să se pună problema asupra părților intermediare ale procesului. Prin urmare, problema “când este finalizat proiectul de dezvoltare a sistemului” poate fi, în principiu, reexprimată ca o problemă de interpretare legală a expresiei “finalizarea muncii” în contractele de prestări de servicii.

Când se consideră finalizată o lucrare în dezvoltarea de sisteme?

Deci, când ar trebui să considerăm că o “lucrare este finalizată”? Să examinăm unele cazuri de judecată din trecut cu privire la acest punct.

Cazuri de judecată privind finalizarea lucrărilor

În cazul de judecată citat mai jos, au apărut probleme cu privire la viteza de procesare și costurile de comunicare ale sistemului livrat de furnizor. Chiar dacă au fost identificate aceste probleme, toate etapele de dezvoltare au fost finalizate, așa că s-a dezbătut dacă se poate spune că “lucrarea este finalizată”. Rezultatul a fost că finalizarea lucrării a fost recunoscută.

Articolele 632 și 633 din Codul Civil Japonez stabilesc că momentul plății remunerației către contractant este atunci când acesta a finalizat lucrarea și a predat obiectul muncii către comandant, în timp ce articolul 634 stabilește că, dacă obiectul muncii are defecte, contractantul are o responsabilitate de garanție față de comandant (paragraful 1), iar comandantul are dreptul de a se opune la plata remunerației până când contractantul își îndeplinește responsabilitatea de garanție pentru defectele obiectului muncii (paragraful 2). Potrivit acestor prevederi ale Codului Civil Japonez, legea distinge între cazurile în care rezultatul muncii este imperfect, adică între cazurile în care obiectul muncii are defecte și cazurile în care munca nu este finalizată, și se înțelege că, chiar dacă există defecte în obiectul muncii, fie că acestea sunt evidente sau ascunse, aceasta nu înseamnă că munca nu este finalizată.
Prin urmare, în ceea ce privește dacă contractantul a finalizat sau nu munca, ar trebui să se judece pe baza faptului dacă munca a fost finalizată până la ultima etapă planificată în contractul inițial, și se înțelege că este rezonabil ca comandantul să nu poată refuza plata prețului contractului doar pe motiv că obiectul muncii are defecte, atunci când contractantul a finalizat ultima etapă a muncii și a predat obiectul muncii.

În decizia de mai sus, s-a stabilit că “finalizarea lucrării” este îndeplinită dacă toate etapele de dezvoltare a sistemului au fost finalizate. Ca măsură de remediere atunci când există deficiențe în sistemul creat de furnizor (în termeni legali, acestea sunt adesea numite “defecte”), există deja un sistem separat de responsabilitate pentru garanția defectelor.

Prin urmare, chiar dacă interpretăm conceptul de “finalizare a lucrării” într-un sens mai larg, în final nu va rezulta în impunerea unei nedreptăți asupra utilizatorului. În rezumat, situația este următoarea:

【Obligația în contractul de prestări servicii = Finalizarea lucrării = Finalizarea tuturor etapelor】
＝＝＝＝＝＝＝＝＝＝＝
Dacă lucrarea nu este finalizată…
↓
【Responsabilitatea pentru neexecutarea obligațiilor】
＝＝＝＝＝＝＝＝＝＝＝
Dacă lucrarea este finalizată, dar există deficiențe…
↓
【Recunoașterea executării obligațiilor, cu problema responsabilității pentru garanția defectelor】

Exemplul de mai sus arată cum să separăm problemele.

Desigur, în legătură cu “finalizarea lucrării”, putem examina și din perspectiva “acceptării de către utilizator”. Problemele legale care apar atunci când acceptarea de către utilizator nu progresează sunt explicate într-un alt articol.

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

Ce înseamnă finalizarea unei lucrări din punct de vedere juridic

În dezvoltarea de sisteme, dacă “finalizarea lucrării” este recunoscută, înseamnă că datoria a fost îndeplinită, astfel încât nu mai există riscul de a fi urmărit pentru “neîndeplinirea datoriei”. În cazul unui contract de prestări servicii, dacă nu se poate spune că munca este finalizată, nu se poate solicita plata, iar dacă s-a convenit în mod special plata unui avans, acesta trebuie în principiu returnat. Pe de altă parte, dacă este recunoscut faptul că lucrarea este finalizată, furnizorul trebuie să își asume problemele legate de garanția pentru defecte și garanția de calitate a contractului.

Faptul că furnizorul este eliberat de responsabilitatea pentru neîndeplinirea datoriei înseamnă că spațiul pentru rezilierea contractului din partea utilizatorului se micșorează brusc. Acest lucru se datorează faptului că rezilierea contractului pe baza responsabilității pentru garanția defectelor este limitată la cazurile în care nu se poate atinge obiectivul contractului. Dacă contractul este reziliat, furnizorul pierde și dreptul de a solicita plata (adică, în termeni simpli, nu mai primește nicio plată), astfel că în practică, există o tendință de a avea mai multe dispute în jurul “finalizării lucrării”.

De asemenea, o explicație detaliată despre “rezilierea” contractelor în dezvoltarea de sisteme este disponibilă în articolul de mai jos.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Considerații legate de finalizarea muncii

Cum să abordăm modificările de specificații și dezvoltarea suplimentară

De asemenea, pentru furnizor, este posibil să se confrunte cu situații în care “am putut deja să îndeplinim specificațiile așa cum au fost inițial comunicate, dar suntem solicitați să facem modificări la specificații sau să adăugăm funcții, și, deși încercăm să încheiem lucrările, nu putem găsi un punct de încheiere”. În astfel de cazuri, probleme precum “momentul de încheiere a dezvoltării sistemului” vor apărea. Explicațiile pentru astfel de cazuri sunt detaliate în articolul de mai jos.

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

Atenție la modificările Codului Civil

În plus, prevederile privind răspunderea pentru garanția defectelor bazate pe contractul de lucrări sunt un domeniu care a fost puternic influențat de modificările Codului Civil, având în vedere că legăturile dintre articolele anterioare erau adesea complicate și greu de înțeles. În contextul modificării Codului Civil, modul în care ar trebui interpretat termenul “defect” este explicat în detaliu în articolul de mai jos.

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

Concluzie

În acest articol, am explicat calea către conceptul juridic de “finalizare a muncii” pentru proiectele de dezvoltare a sistemelor, care pot fi adesea împinse în situații în care “nu se vede o ieșire”. Ieșirea fiecărui proiect poate varia în funcție de cerințele de dezvoltare, dar când apar dispute în jurul acestor aspecte, conceptul juridic de “finalizare a muncii” poate adesea servi ca un ghid.