Munca de dezvoltare a sistemelor implică implicarea unui număr mare de persoane, atât din partea utilizatorilor care comandă, cât și din partea furnizorilor care primesc comanda, astfel încât nu este ușor să avansezi cu proiectul într-un ritm coordonat cu toată lumea. Nu este nevoie să spunem că planificarea este extrem de importantă în această muncă, dar în același timp, nu este întotdeauna cazul ca utilizatorul care comandă să poată să adune informațiile adecvate și să le transmită în mod concis furnizorului. Într-un stadiu în care procesul de dezvoltare a avansat într-o anumită măsură, dacă se solicită modificarea specificațiilor sau adăugarea de funcții după fapt, dacă este posibil să se factureze un cost suplimentar față de estimarea inițială, este o preocupare majoră pentru cei care primesc comanda.
Cum sunt recunoscute aceste drepturi în conformitate cu legea și în ce circumstanțe? De asemenea, cum se determină suma recompensei pentru dezvoltarea suplimentară și corecția funcțiilor? Acest articol va clarifica aceste și alte întrebări similare.
Când putem vorbi despre dezvoltare suplimentară sau modificarea funcționalităților?
În proiectele de dezvoltare a sistemelor, tipurile de contracte pe care le încheiem atunci când acceptăm o lucrare sunt, de obicei, contracte de antrepriză sau contracte de mandat. În ambele cazuri, ceea ce trebuie să facă partea care acceptă lucrarea (adică obligația) și recompensa asociată cu aceasta (adică dreptul) sunt prezentate împreună în contract. Prin urmare, dacă se adaugă ulterior o activitate care nu este inclusă în activitatea care stă la baza sumei recompensei, putem spune că este vorba despre o dezvoltare suplimentară sau o modificare a funcționalităților. Pe de altă parte, dacă este inclusă, va fi tratată ca fiind conform specificațiilor inițiale (adică în cadrul contractului existent).
De asemenea, am explicat în detaliu diferențele dintre contractul de antrepriză și contractul de mandat într-un alt articol.
Totuși, dacă spunem că toate, inclusiv ajustările minore ale fonturilor afișate pe ecran, sunt dezvoltări suplimentare dacă nu sunt specificate în prealabil în specificații, acest lucru ar putea împiedica semnificativ desfășurarea fără probleme a tranzacțiilor comerciale. Prin urmare, nu este ușor să tragem o linie uniformă atunci când luăm în considerare aceste discuții detaliate despre specificații. Cu toate acestea, dacă ar trebui să oferim un ghid general, putem spune că este foarte probabil să existe o anumită validitate legală pentru argumentele în următoarele cazuri:
După ce specificațiile au fost stabilite o dată, ni s-a ordonat să adăugăm mai multe funcții
După ce implementarea programului a fost finalizată, ni s-a ordonat să o modificăm
În astfel de cazuri, putem spune că argumentul are o anumită validitate legală.
Exemple de proces în care s-a dezbătut dacă se poate vorbi despre dezvoltare suplimentară sau modificarea funcționalităților
Ce înseamnă “schimbarea specificațiilor” în dezvoltarea de software?
Exemplu afirmativ: Cazul în care specificațiile designului de bază au fost modificate ulterior
Următorul exemplu se referă la un caz în care specificațiile au fost modificate ulterior.
Dezvoltarea software-ului implică următoarele etape: ①definirea cerințelor, ②designul extern, ③designul intern, ④crearea programului sursă (designul programului, codificarea), ⑤diverse teste (teste unitare, teste combinate, teste de sistem). (omis) Specificațiile inițiale (omis) sunt realizate prin activități de design intern și ulterioare, și aceasta este sfera de activitate care se află în relație cu dreptul de a solicita remunerație în baza contractului de dezvoltare în cauză. Solicitările de modificare a specificațiilor sunt, din punct de vedere juridic, considerate o nouă solicitare de contract de delegare a muncii care depășește sfera de activitate bazată pe contractul inițial, și dacă contractorul nu prezintă un preț suplimentar pentru lucrările suplimentare și își finalizează activitatea legată de delegarea suplimentară fără a se ajunge la un acord asupra prețului suplimentar, se consideră că a fost încheiat un nou contract de prestări servicii fără un preț stabilit, și este rezonabil să se considere că există o obligație de a plăti costurile de dezvoltare suplimentare.
Judecătoria Osaka, 29 august 2002 (Heisei 14)
Cuvinte cheie precum “relația de preț” și “noul contract” vor fi esențiale pentru a înțelege mai bine această decizie.
De asemenea, este demn de menționat că decizia menționată mai sus a indicat un alt punct foarte interesant. Acesta este faptul că ajustările foarte detaliate, cum ar fi poziționarea butoanelor sau fontul literelor, nu sunt considerate modificări ale specificațiilor așa cum sunt definite aici. Partea relevantă este după cum urmează.
Totuși, în dezvoltarea software-ului, datorită naturii sale, nu este normal ca detaliile, cum ar fi fontul în care sunt afișate literele pe ecran sau poziționarea butoanelor, să fie stabilite în etapa de design extern, și este normal ca detaliile să fie ajustate într-o anumită măsură prin discuții între părți chiar și după stabilirea specificațiilor. Prin urmare, ar trebui să spunem că nu este rezonabil să considerăm cererile de detaliere a specificațiilor ca modificări ale specificațiilor.
Judecătoria Osaka, 29 august 2002 (Heisei 14)
În textul deciziei, a fost folosit un termen interesant, “detalierea specificațiilor”.
Cazul în care ceva care ar fi trebuit să fie stabilit a fost schimbat ulterior
Cazul în care ceva care ar fi putut fi decis pe parcurs a fost lăsat nerezolvat și a fost continuat
Se poate spune că aceasta indică ideea că tratamentul juridic ar trebui să fie diferit în funcție de caz.
Alte exemple afirmative
În plus, în cazurile în care s-au recunoscut dezvoltări suplimentare și corecții de funcționalitate, avem:
Exemplul în care numărul de programe livrate a crescut de aproximativ două ori față de planul inițial (Hotărârea Tribunalului din Tokyo, 22 aprilie 2005)
Exemplul în care perioada de lucru s-a triplat (Hotărârea Tribunalului din Tokyo, 22 ianuarie 2010)
Se poate observa că, în urma acestei organizări, extinderea perioadei de lucru este considerată o dezvoltare suplimentară în sens larg și este adoptată o abordare care permite o anumită protecție legală.
“Acordul și creșterea remunerației pentru dezvoltarea suplimentară” și “Încheierea contractului inițial” sunt probleme separate
Un punct important de menționat în legătură cu aceste probleme este că,
Scena în care “în primul rând, dacă un contract privind dezvoltarea de sistem (contractul inițial) a fost încheiat oficial între cele două companii”
Scena în care “o dată ce dezvoltarea sistemului a fost oficializată, dacă un contract privind dezvoltarea suplimentară a fost (de asemenea) încheiat suplimentar”
standardele de judecată ale instanței sunt diferite. Pe scurt, instanța are tendința de a fi,
strictă în ceea ce privește 1 (nu recunoaște ușor încheierea unui contract în absența unui contract)
relativ indulgentă în ceea ce privește 2 (chiar dacă nu există un contract pentru dezvoltarea suplimentară, recunoaște flexibil creșterea remunerației etc.)
se poate spune. Detalii despre 1 sunt explicate într-un alt articol.
Exemplu negativ: Cazul în care a fost tratat ca fiind inclus în conținutul similar al contractului din punct de vedere legal
Pe de altă parte, există și cazuri în care nu s-a permis o creștere a remunerației. În cazul sentinței citate mai jos, după încheierea unui contract de prestări servicii pentru dezvoltarea unui sistem, conținutul lucrării a fost modificat, iar dacă se permite o creștere a remunerației a fost un subiect de dispută.
Problema în acest caz este, (1) care a fost conținutul lucrării pe care reclamantul l-a preluat în acest contract, (2) dacă a existat un acord între reclamant și pârât pentru a extinde scala și a crește prețul pentru această lucrare preluată, (omis), etc. (omis)
În primul rând, acest contract este un contract de prestări servicii în care s-a convenit că suma de bani este un preț fix pentru lucrarea preluată (contractată) de reclamant, iar numărul de pași, prețul unitar, etc., sunt doar documente interne folosite pentru a calcula suma contractului în cadrul reclamantului, iar circumstanțele, cum ar fi creșterea numărului de pași, nu au nicio legătură cu suma contractului (omis).
Conform recunoașterii de mai sus, lucrarea preluată de reclamant a fost modificată pe 25 februarie 1987 (Showa 62), și a fost limitată doar la administrarea sistemului, calculul costurilor de contract și o parte a utilităților, restul fiind preluat de pârât. Lucrarea reclamantului după modificare este încă în cadrul lucrării de dezvoltare conform contractului inițial, iar prețul pentru această lucrare este acoperit în totalitate de suma contractului care a fost convenită ca preț fix la începutul contractului.Hotărârea Tribunalului Districtual Tokyo, 12 iunie 1995 (Heisei 7)
În această hotărâre, chiar dacă conținutul lucrării preluate de furnizor a fost modificat, s-a decis că acest conținut de dezvoltare este încă în cadrul conținutului contractului inițial și ar trebui să fie acoperit de remunerația promisă inițial.
În final, se consideră că se va permite o cerere de remunerație suplimentară pentru lucrările care nu sunt incluse aici, luând în considerare ce fel de muncă a fost presupusă când s-a stabilit suma remunerației.
Și, în primul rând, dacă remunerația a fost un preț pentru ce fel de muncă, nu va fi judecată doar pe baza contractului, ci și a proceselor verbale, etc. Detalii despre importanța proceselor verbale sunt explicate în articolul de mai jos.
Cum se stabilește suma recompensei pentru dezvoltarea suplimentară și corecția funcțiilor?
În cadrul dezvoltării de sisteme, nu este deloc neobișnuit ca specificațiile care păreau stabilite la un moment dat să se schimbe ulterior. De fiecare dată când se întâmplă acest lucru, nu este realist să pregătiți un nou contract scris și să avansați cu procedurile contractuale. În cazul în care puteți stabili din nou conținutul specificațiilor pentru elementele care trebuie adăugate sau modificate și puteți încheia un memorandum sau ceva similar într-un singur loc, ce se întâmplă dacă proiectul se întrerupe fără a putea efectua aceste proceduri? Cum ar trebui să calculăm suma recompensei?
Articolul care ar trebui să fie referință în astfel de cazuri este articolul 512 din Legea Comercială Japoneză (sublinierea este făcută de autor).
Articolul 512 din Legea Comercială Japoneză: Când un comerciant acționează în numele altcuiva în cadrul afacerii sale, poate solicita o recompensă rezonabilă.
Problema cu “recompensa rezonabilă” în acest articol este cât va fi în cele din urmă în funcție de situația concretă. Privind la precedentele judiciare, se pare că a fost adoptată ideea că costurile ar trebui suportate proporțional cu numărul de ore de muncă, cantitatea sau perioada de timp. Acest lucru se datorează probabil faptului că dezvoltarea sistemului este în esență un serviciu și costul de bază este costul forței de muncă.
Prin urmare, în ciuda gradului de abstractizare a termenului “recompensă rezonabilă” în legea comercială, calcularea prețului de piață pentru recompensa suplimentară în acest context nu necesită calcule prea dificile. Să ne uităm la câteva exemple de cazuri judiciare.
Cazul 1: Exemplu în care a fost recunoscută o recompensă suplimentară proporțională cu creșterea numărului de ore de muncă
Numărul de ore de muncă pentru dezvoltarea bazată pe schimbarea specificațiilor în acest caz este de 257,5 persoane/zi în total, iar dacă acesta este convertit la costul de dezvoltare pe persoană/zi, care este același cu contractul de dezvoltare în acest caz, de 32.500 de yeni (în documentul A3, prețul unitar este de 650.000 de yeni pe persoană/lună, iar dacă numărul de zile de lucru pe lună este de 20 de zile, costul de dezvoltare pe persoană/zi este de 32.500 de yeni), costul de dezvoltare suplimentară bazat pe cererea de schimbare a specificațiilor este de 8.368.750 de yeni.
Judecătoria din Osaka, 29 august 2001 (anul 13 al erei Heisei)
Cuvântul cheie este “pe persoană/zi”. Acesta indică faptul că numărul de ore de muncă este utilizat ca bază pentru calculul recompensei suplimentare.
Cazul 2: Exemplu în care a fost recunoscută o recompensă suplimentară proporțională cu numărul de programe
În ceea ce privește suma recompensei rezonabile, inclusiv partea suplimentară în acest caz, având în vedere că majoritatea costurilor de dezvoltare a sistemelor de calculatoare sunt costurile forței de muncă a inginerilor și că aceste costuri sunt în general proporționale cu cantitatea de programe care trebuie create, se consideră rezonabil să se împartă suma contractului inițial de 23.250.000 de yeni cu numărul de programe finalizate până la a doua inspecție, 206, și să se înmulțească acest preț unitar pe program cu numărul de programe care au trecut de a treia inspecție, 414, rezultând suma de 46.725.728 de yeni.
Judecătoria din Tokyo, 22 aprilie 2005 (anul 17 al erei Heisei)
Există multe numere, dar dacă citiți cu calm, veți vedea că nu faceți calcule dificile. Pe baza conținutului contractului inițial, verificați “cât a fost estimat prețul unitar pe program” și faceți doar o simplă înmulțire de “preț unitar × cantitate”.
Cazul 3: Exemplu în care a fost recunoscută o recompensă suplimentară proporțională cu durata
În contractul A3, s-a stabilit că recompensa pentru munca ca agent semi-delegat pentru perioada de trei luni de la ianuarie până în martie 2005 este de 60.000.000 de yeni, iar pentru munca de la aprilie înainte, deși include munca gratuită, se așteaptă ca volumul de muncă să crească după începerea noului an școlar în aprilie, când sistemul de înregistrare a cursurilor etc. este pus în funcțiune, la fel ca în anul anterior, comparativ cu perioada până în martie. Prin urmare, pe baza celor 60.000.000 de yeni stabilite ca recompensă pentru munca de trei luni, se consideră rezonabil ca recompensa pentru munca de șase luni de la aprilie până în septembrie 2005 să fie de 120.000.000 de yeni.
Judecătoria din Tokyo, 22 ianuarie 2010 (anul 22 al erei Heisei)
Decizia de mai sus indică faptul că recompensa suplimentară este calculată prin simpla proporție pentru perioada extinsă.
Rezumat
După cum se poate observa din exemplele de cazuri juridice prezentate mai sus, se pare că există o anumită regularitate și puncte comune în ceea ce privește tratamentul legal al remunerației suplimentare pentru munca programatorilor și inginerilor. În principiu, se poate observa o tendință de a calcula această remunerație într-un mod cât mai simplu, bazându-se pe indicatori relativ obiectivi, cum ar fi timpul de muncă investit, volumul formal de muncă (cum ar fi programele livrate) și durata muncii.
Având în vedere că aceste dezvoltări suplimentare și modificările de funcționalitate apar tocmai din cauza eșecului în estimarea precisă a timpului de muncă sau a procedurilor, s-ar putea să pară o poveste lipsită de savoare faptul că remunerația suplimentară este generată doar în funcție de timpul investit, de volumul formal de muncă sau de timpul de muncă. Cu toate acestea, chiar și din perspectiva celui care prestează serviciul, chiar dacă scopul este de a pune în prim plan interesele clientului, faptul că aceste drepturi sunt probabil recunoscute legal este semnificativ, chiar și ca o discuție de gestionare a crizelor.
An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.
