Cât de mult ar trebui implementate funcțiile care nu sunt în specificațiile de dezvoltare a sistemului din punct de vedere legal?

Proiectele de dezvoltare a sistemelor IT utilizate în companii sunt, în principiu, create în conformitate cu specificațiile definite în prealabil. Cu toate acestea, dacă ne gândim la sensul faptului că furnizorul este încredințat cu dezvoltarea sistemului ca expert, așteptările părții utilizatorului s-ar putea să nu fie atât de scăzute încât să fie suficient doar să implementeze mecanic ceea ce este scris în specificații. În acest articol, vom discuta până unde ar trebui să își asume obligația de a implementa un program care, deși nu este menționat în specificații, este necesar în lumina scopului dezvoltării.

Problemele legale asociate cu implementarea elementelor care nu sunt specificate

Discreția este cerută în activitatea furnizorului

Una dintre caracteristicile majore ale contractelor și problemelor legale asociate cu proiectele de dezvoltare a sistemelor este că furnizorul care preia lucrarea are o mare discreție.

Articolul corelat: Ce înseamnă obligațiile de management al proiectelor în dezvoltarea de sisteme[ja]

Desigur, “discreția” menționată aici nu se aplică neapărat tuturor etapelor de dezvoltare a sistemelor. După ce se identifică fiecare etapă și se avansează în detalierea sarcinilor, pot apărea multe lucrări care se apropie de operațiuni simple. Cu toate acestea, în general, cu cât se avansează mai mult în etapele de amonte ale proiectului, cu atât devine mai dificilă realizarea lucrărilor fără a avea o mare discreție. Motivul pentru care contractele de amonte se potrivesc adesea cu mandatul este, de asemenea, datorat acestui aspect.

Articolul corelat: Diferența și distincția între contractele de lucrări și contractele de mandat în dezvoltarea de sisteme[ja]

Discreția trebuie exercitată și în cadrul unui proces de dezvoltare strict

Chiar dacă furnizorul care dezvoltă sistemul are o mare discreție, acceptarea cerințelor clientului într-o manieră neorganizată poate provoca daune semnificative în etapele ulterioare. Un sistem IT este format dintr-o colecție de componente mici, astfel încât chiar și o schimbare minoră în aspect poate necesita o schimbare semnificativă în timpul de lucru din perspectiva dezvoltatorului. Există, de asemenea, articole care explică modul de gestionare a situațiilor de schimbare a specificațiilor dezvoltării sistemelor dintr-o perspectivă legală. Articolul de mai jos discută modul de gestionare a schimbărilor, dar discută și cât de mult poate afecta schimbarea specificațiilor lucrările din perspectiva inginerilor.

Articolul corelat: Cum se gestionează schimbările în dezvoltarea de sisteme dintr-o perspectivă legală[ja]

Ce ar trebui să facă un expert, fără a fi limitat de specificații?

Pentru a avansa cu succes un proiect de dezvoltare a sistemelor, este important să se definească cerințele de dezvoltare în prealabil și să se avanseze în mod planificat în conformitate cu acestea. Pe de altă parte, există situații în care nu puteți îndeplini pe deplin rolul de expert în dezvoltarea de sisteme doar făcând ceea ce vi se spune în conformitate cu cerințele definite în prealabil. În acest fel, problema “Ce ar trebui să fie implementat, deși nu este indicat în specificații?” devine evidentă.

Obligațiile legale sunt stabilite în conformitate cu ‘scopul’ specificațiilor și contractelor

Conținutul a ceea ce trebuie implementat, chiar dacă nu este menționat în contracte sau specificații, este totuși determinat de ‘scopul’ acestor contracte și specificații, adică, ‘ce sens sau intenție a avut stabilirea acestora în acest mod’. Să examinăm câteva exemple de cazuri judiciare în continuare.

Exemplu de judecată în care obligația de implementare a fost negată din cauza lipsei de mențiuni

În exemplul de judecată citat mai jos, un sistem dezvoltat de un furnizor a ajuns la stadiul de funcționare temporară, dar a izbucnit un conflict când s-a cerut rezilierea contractului pe motiv că nu dispune de funcțiile necesare. Utilizatorul a susținut că funcția de “actualizare automată a datelor” lipsește, și a fost susținut că acesta este un punct de vânzare major pentru sistemul în cauză, dar instanța nu a recunoscut această obligație de implementare.

Conform recunoașterii de mai sus, în contractul și documentele de proiectare de bază și detaliată nu există nicio mențiune care să indice că funcția ③ este un obiectiv de dezvoltare pentru sistemul în cauză.

Reclamantul a susținut că funcția ③ a fost un punct de vânzare major pentru sistemul în cauză față de reclamant, și a subliniat necesitatea acestei funcții, dar dacă aceste afirmații ar fi adevărate, ar fi trebuit să fie menționate în mod clar în contract și în alte documente, și este greu de crezut că dezvoltarea acestei funcții a fost convenită, în absența unei astfel de mențiuni.

Judecătoria Tokyo, 18 februarie 2009 (Anul 21 al erei Heisei)

Desigur, dacă luăm doar concluzia acestui verdict, putem spune că “dacă nu este menționat în documentul de proiectare, nu este necesar să se creeze ceva care nu există”. Cu toate acestea, mai precis, nu este vorba doar de un fapt formal, cum ar fi dacă este sau nu menționat în documentul de proiectare, ci de o decizie luată în considerare “intenția” mențiunilor din documentul de proiectare și contract. Adică, “dacă ne gândim la motivul pentru care nu a fost menționat în documentul de proiectare sau contract, este rezonabil să presupunem că nu a existat niciun acord care să corespundă acelei mențiuni”.

Exemple de caz în care obligația de implementare a fost afirmată chiar dacă nu a fost menționată

Pe de altă parte, există și cazuri în care s-a considerat că ar trebui recunoscută obligația de implementare, chiar dacă nu a fost menționată în contract sau în specificații. Exemplul de caz pe care îl cităm mai jos se referă la dezvoltarea unui sistem pentru gestionarea istoricului de administrare a medicamentelor, în care nu s-a putut realiza transferul de date de la sistemul existent la cel nou, făcând imposibilă utilizarea noului sistem, iar partea utilizatorului a reziliat contractul. Cu toate acestea, partea furnizorului a contestat, susținând că transferul de date nu face parte din domeniul său de activitate.

Dezvoltarea unui nou sistem implică adesea eliminarea sistemului existent și transferul datelor. Importanța acestor activități și problemele juridice asociate cu ele sunt discutate în detaliu în articolul de mai jos.

Articolul corelat: Probleme juridice asociate cu tranziția de la sistemul vechi în dezvoltarea sistemului[ja]

În sistemul existent erau deja stocate datele a peste 50.000 de pacienți, iar plângătorul încerca să eficientizeze operațiunile utilizând aceste date, deci este evident că dacă nu se poate transfera datele pacienților de la sistemul existent la sistemul în cauză, va afecta operațiunile de prescripție la farmacie, și se poate presupune că reprezentantul reclamantului a recunoscut acest lucru. În plus, înainte de încheierea contractului în cauză, reprezentantul reclamantului a întrebat reprezentantul pârâtului despre posibilitatea transferului de date, iar acesta a recunoscut acest lucru (omis), deci este greu de crezut că reprezentantul reclamantului, recunoscând că există o mare probabilitate că va trebui să introducă manual datele a peste 50.000 de pacienți, a decis totuși să introducă sistemul în cauză. În plus, așa cum se menționează mai sus la (1)I, pârâtul, neputând transfera datele de prescripție medicamentoasă de la sistemul existent la sistemul în cauză, a imprimat aceste date pe hârtie și le-a procesat într-un fișier PDF, deci este greu de crezut că pârâtul a efectuat acest lucru ca serviciu, deși transferul de date nu a fost presupus în contractul în cauză.

Hotărârea Tribunalului din Tokyo, 18 noiembrie 2010 (Heisei 22)

Ceea ce este important aici este “scopul” contractului și al elementelor menționate în contract. Dacă ambele părți au încheiat contractul recunoscând că transferul de date nu face parte din domeniul de activitate, atunci instanța a subliniat că atât utilizatorul, cât și furnizorul ar fi încheiat contractul cu intenții neobișnuite. Adică, utilizatorul ar fi acceptat o cantitate enormă de muncă manuală, iar furnizorul ar fi abordat proiectul știind că va cauza probleme în activitatea utilizatorului, ceea ce ar fi o poveste extrem de nerezonabilă.

Ce putem înțelege din ambele hotărâri

În ceea ce privește transferul de date, chiar dacă nu există nicio mențiune în contract sau în specificații, se pare că obligația de implementare a fost afirmată pe fondul faptului că vorbim despre “date”, un aspect care nu apare pe ecran. Lipsa “funcționalității esențiale” menționată anterior este ceva care apare direct pe ecranul sau interfața sistemului. Prin urmare, chiar și pentru un amator în dezvoltarea de sisteme, nu este atât de dificil să descopere omisiuni în specificații. Pe de altă parte, problema transferului de date are caracteristica că este dificil pentru un amator în dezvoltarea de sisteme să recunoască importanța procesului, dificultatea și timpul necesar pentru munca. Prin urmare, se crede că exista și circumstanța că a fost tratat ca un subiect pe care partea furnizorului ar trebui să-l gestioneze în mod eficient cu profesionalism.

Privind astfel, omisiunile din specificații sau contracte pot fi considerate probleme strâns legate de “obligația de cooperare” a utilizatorului. Adică, problema dacă utilizatorul a îndeplinit cu adevărat “obligația de cooperare” în încheierea contractului și în crearea specificațiilor. O explicație generală a obligațiilor legale pe care utilizatorul ar trebui să le îndeplinească în proiectul de dezvoltare a sistemului este tratată în detaliu în articolul de mai jos.

Articolul corelat: Ce implică obligația de cooperare a utilizatorului, ca comanditar al dezvoltării sistemului[ja]

Dacă verificați și articolul de mai sus, veți înțelege de la sine că discuția diferă semnificativ între domeniile în care se solicită o mare cooperare din partea utilizatorului, cum ar fi identificarea ecranului și a funcțiilor esențiale, și omisiunile în considerarea transferului de date.

Cum ar trebui să considerăm recompensa pentru dezvoltarea care nu este în specificații?

Un alt aspect care ar putea fi de interes în legătură cu subiectul acestui articol este dacă este legal să solicităm o recompensă suplimentară pentru crearea a ceva care nu este în specificații. Detalii despre posibilitatea de a adăuga o recompensă și metoda de calcul a prețului estimat în acest caz sunt explicate în detaliu în articolul de mai jos.

Articolul corelat: Este posibilă majorarea prețului estimat pentru dezvoltarea de sistem?[ja]

În articolul de mai sus, explicăm că este important dacă există sau nu sarcini care depășesc domeniul de activitate care este în relație cu recompensa. Adică, în legătură cu acest articol, dacă furnizorul a răspuns la dezvoltarea a ceva care nu a fost inclus în specificațiile inițiale (în acest articol, cazul negativ), atunci este posibil să se solicite o recompensă suplimentară pentru aceasta.

Concluzie

În dezvoltarea de sisteme, rolul pe care un furnizor îl are de îndeplinit este, pe de o parte, determinat în conformitate cu conținutul contractului și al specificațiilor. Cu toate acestea, luând în considerare faptul că sunt încredințate sarcini bazate pe încredere înaltă ca specialiști, este clar că realitatea nu este determinată doar de formă. Cu toate acestea, ar trebui să înțelegem că legea joacă un rol important în înțelegerea acestei realități.