Ce înseamnă obligațiile de cooperare pe care le are utilizatorul ca comanditar al dezvoltării de sisteme

Munca de dezvoltare a sistemelor implică, cu cât sistemul dezvoltat este mai mare, necesitatea de a implica un număr mare de oameni și de a aloca mult timp. Prin urmare, există o obligație de cooperare nu numai din partea furnizorului care preia dezvoltarea, dar și din partea utilizatorului care comandă dezvoltarea sistemului.

Aceasta este diferită de relația obișnuită de comandă și recepție. De exemplu, în cazul în care comandați un costum personalizat de la un croitor, nu există nicio “obligație” specială din partea clientului (utilizatorului). “Obligația” este purtată în principal de croitor (furnizor). Structura este astfel încât, tocmai pentru că este necesar un număr mare de oameni și timp pentru un sistem IT, utilizatorul trebuie să “coopereze” cu furnizorul.

Acest articol explică ce obligații legale are partea care comandă în ceea ce privește dezvoltarea sistemului, care nu poate fi lăsată doar în seama furnizorului.

Fiind sistemul propriu, nu se poate rezolva totul prin ‘delegare totală’

Chiar și în cazul unui singur proiect de dezvoltare a sistemului, adesea sunt implicate multe persoane și organizații. Rolul managerului de proiect este esențial pentru a aduna rezultatele personalului, cum ar fi inginerii și programatorii cu abilități avansate de codare, într-un singur succes.

Însă, indiferent de cât de înalte sunt competențele tehnice și organizaționale ale furnizorului, dezvoltarea sistemului nu poate fi realizată doar prin forțele furnizorului. De exemplu, nu există niciun mod de a cunoaște termenii interni utilizați doar în cadrul companiei sau cunoștințele de afaceri specifice companiei, doar prin eforturile unilaterale ale furnizorului. Cu cât dezvoltarea unui sistem de mare anvergură este mai mare, cu atât este mai probabil ca, în general, compania care utilizează sistemul să fie o corporație mare care are multe persoane și operațiuni. Pentru a conduce succesul proiectului de dezvoltare a sistemului, de fapt, în multe cazuri, organizarea acestei logici de afaceri are o pondere mare, chiar înainte de munca pe computer.

Prin urmare, nu este cazul ca partea utilizatorului să devină pasivă pe motiv că “nu sunt un expert în tehnologia IT”, ci mai degrabă, prin furnizarea activă de informații, progresul proiectului poate decurge fără probleme. În acest sens, rolul pe care îl joacă partea utilizatorului în proiectul de dezvoltare a sistemului nu este deloc mic.

Ce implică obligația de cooperare a utilizatorului, luând în considerare cazurile precedente

Deci, în mod concret, ce implică obligația de cooperare pe care o are partea utilizatorului în cadrul unui proiect de dezvoltare a sistemului? Există multe indicii lăsate de cazurile precedente cu privire la acest aspect.

În instanță, în cazul în care termenul limită al furnizorului (pârâtul) a fost depășit, existența sau nu a obligației de cooperare a utilizatorului (reclamantul) în dezvoltare a devenit un punct de dispută, având în vedere întârzierea deciziei utilizatorului și altele. În acest caz, instanța a recunoscut încălcarea obligației de cooperare din partea utilizatorului și a negat responsabilitatea furnizorului pentru neexecutarea obligațiilor. (Deși rezilierea contractului a fost recunoscută, a fost de asemenea recunoscută o compensare a neglijenței de 60%.)

Acest contract pentru dezvoltarea sistemului de calcul este un contract de dezvoltare de sistem personalizat, în care dezvoltatorul (vendorul) nu poate finaliza sistemul de unul singur. Este necesar ca clientul (utilizatorul) să coordoneze eficient opiniile interne în timpul procesului de dezvoltare, să comunice clar dezvoltatorului ce funcții dorește, să discute împreună cu dezvoltatorul despre funcțiile dorite, să decidă în final funcțiile, să decidă ecranele și rapoartele, și să accepte produsele finale.

Hotărârea Curții Districtuale Tokyo, 10 martie 2004 (Heisei 16)

Această hotărâre nu doar indică faptul că dezvoltarea sistemului în sine este un efort comun cu utilizatorul, dar și clarifică “în ce aspecte ar trebui să colaboreze”, ceea ce pare a fi foarte sugestiv.

Să încercăm să traducem termenii din această hotărâre în limbajul IT al dezvoltării de sisteme.

Acestea pot fi organizate în acest fel. Toate acestea nu pot fi realizate de unul singur, indiferent de cât de avansată este expertiza în sistemele IT, fără cooperarea utilizatorului. Funcțiile dorite și aspectul ecranului sunt în esență lucruri pe care utilizatorul ar trebui să le clarifice, iar dacă produsul final este realizat conform cerințelor, numai utilizatorul poate confirma acest lucru.

De asemenea, la fel cum vendorului i se impune obligația de gestionare a proiectului, utilizatorului i se impune și el o obligație de cooperare. Dacă utilizatorul încalcă această obligație de cooperare în procesul menționat mai sus, există posibilitatea ca vendorul să solicite despăgubiri pentru neexecutarea obligațiilor sau pentru acte ilicite.

Cum sunt interpretate cererile de modificare a specificațiilor după faptul împlinit

De asemenea, presupunând că proiectul de dezvoltare a sistemului este o colaborare între utilizator și furnizor, discuția se va dezvolta în continuare. Problema este “Cine este responsabil dacă, după faptul împlinit, utilizatorul solicită adăugarea sau modificarea unei funcții și, ca urmare, este dificil să se respecte termenul de livrare?”

Dezvoltarea sistemului începe în general cu definirea cerințelor, urmată de proiectarea de bază, proiectarea detaliată, fabricația (implementarea programului), testarea, cu scopul de a evita pe cât posibil revenirea la etapele anterioare (cunoscută în general sub numele de modelul cascada). Cu toate acestea, în realitate, se întâmplă adesea ca, dintr-un motiv sau altul, să apară deficiențe în etapele anterioare, ceea ce duce la revenirea la aceste etape.

Cum ar trebui să gândim în cazul în care nu se respectă termenul de livrare în astfel de cazuri? Interpretând precedentele, se pare că concluzia diferă în funcție de momentul în care apar lucrările suplimentare.

Dacă lucrările suplimentare au avut loc înainte de clarificarea specificațiilor, cum ar fi proiectarea externă

Exemplul de mai sus indică că, în timpul proiectării de bază (înainte de etapa de implementare a programului), nu există nicio încălcare specială a obligației de cooperare în sine atunci când există o cerere de dezvoltare suplimentară primită de la utilizator.

Pentru utilizator să facă diverse cereri către furnizor în timpul lucrărilor de proiectare de bază, este un lucru natural în procesul de dezvoltare a sistemului, așa cum este acest caz, și mai mult, pentru utilizatorul plângător care nu are cunoștințe specializate, este dificil să judece corect dacă cererea necesită un comision suplimentar sau o amânare a termenului de livrare, dacă va cauza probleme în procesul de lucru. Prin urmare, nu se poate spune că utilizatorul plângător ar fi trebuit să se abțină de la a face cereri care ar necesita un comision suplimentar sau o amânare a termenului de livrare. Dimpotrivă, dacă utilizatorul plângător a făcut o cerere care necesită un comision suplimentar sau o amânare a termenului de livrare, atunci inculpatul, care are obligația de gestionare a proiectului, ar fi trebuit să informeze utilizatorul plângător despre acest lucru și să solicite discuții despre retragerea cererii sau amânarea termenului de livrare, astfel încât să nu apară probleme în lucrările de dezvoltare.

Hotărârea Tribunalului din Tokyo din 10 martie 2004 (Heisei 16)

Această hotărâre a indicat că, deși utilizatorul are o anumită obligație de cooperare, nu trebuie să uităm că utilizatorul nu este un expert în dezvoltarea de sisteme. Adică, până când conținutul sistemului care urmează să fie dezvoltat devine clar, nu este neobișnuit ca utilizatorul care comandă (care poate să nu fie obișnuit să comande) să facă comenzi în bucăți mici și, cu atât mai mult, este absurd să spunem că ar trebui să-și dea seama singur că conținutul comenzii necesită o revizuire a termenului de livrare.

În orice caz, obligația impusă aici furnizorului este, în esență, să facă eforturi de comunicare, cum ar fi solicitarea unei amânări a termenului de livrare (sau, dacă termenul de livrare nu poate fi modificat, să propună retragerea cererii suplimentare). Prin urmare, nu se consideră că include obligația de a livra la data inițială după acceptarea tuturor cererilor utilizatorului, așa că este necesar să fim atenți la acest punct.

Dacă lucrările suplimentare au avut loc după stabilirea specificațiilor pentru producție și testare

Dacă ne uităm la conținutul verdictului menționat mai sus, putem prezice într-o oarecare măsură ce concluzie ar fi avut loc dacă dezvoltarea suplimentară ar fi avut loc după ce specificațiile au fost deja stabilite. În acest caz, este probabil ca astfel de cereri să fie mai greu de îndeplinit. Desigur, diferența de înțelegere a lucrărilor de dezvoltare între partea utilizatorului și partea furnizorului nu se schimbă, indiferent dacă este înainte sau după stabilirea specificațiilor.

Însă, schimbarea sau adăugarea conținutului comenzii după stabilirea specificațiilor are o probabilitate mare de a impune refacerea lucrărilor. În astfel de cazuri, este adesea dificil să apărăm întârzierile de livrare care au apărut până la acest punct, spunând “este normal ca clientul să aibă diverse cerințe”. Mai mult, situația în care apar multe schimbări de specificații sau adăugări de funcții după fapt poate ridica întrebări dacă nu a existat o încălcare a obligației de cooperare din partea utilizatorului în etapele de amonte, cum ar fi proiectarea de bază, care ar fi trebuit să fie deja finalizată în prealabil.

Având în vedere aceste aspecte, nu este realist să considerăm că întârzierea livrării cauzată de schimbarea specificațiilor după stabilirea lor este responsabilitatea furnizorului. Din textul verdictului menționat anterior, este rezonabil să interpretăm că are și acest sens.

De asemenea, astfel de decizii tind să fie luate nu doar pe baza contractului, ci și pe baza proceselor verbale care corespund progresului dezvoltării sistemului. Detalii despre procesele verbale sunt explicate în articolul de mai jos.

Articolul corelat: Cum să păstrați procesele verbale în dezvoltarea de sisteme din perspectiva juridică[ja]

Concluzie: Este important să nu uităm că definirea cerințelor este un proces din partea utilizatorului

Definirea cerințelor, deși este un loc unde furnizorii își pot arăta abilitățile, ar trebui să fie conștientă că este în primul rând o activitate din partea utilizatorului. Având în vedere că este un sistem utilizat în propria companie, chiar dacă este construit cu ajutorul experților externi, se presupune că este un domeniu care ar trebui să fie sub guvernanța propriei companii din punct de vedere legal.

În cazul în care partea utilizatorului nu cooperează în procesul de dezvoltare, chiar dacă proiectul ar putea să se înrăutățească, există o mare posibilitate ca instanța să aibă o opinie severă față de partea utilizatorului. Acest lucru ar trebui să fie recunoscut în primul rând.