Proiectele agile moderne și contractele T&M tradiționale nu se înțeleg bine. O alternativă

Emanuel Martoncă
Founder @ Soft Fight

MANAGEMENT

Citind despre "Colaborarea cu clientul înaintea negocierii contractuale" am putea ajunge să credem, în mod eronat, că nu este necesară existența unui contract pentru proiectele de dezvoltare software. Accentul pus pe relațiile oneste și de încredere între echipele de dezvoltare software și clienții lor este o abordare sănătoasă, care crește șansele obținerii de rezultate cât mai bune. Această realitate nu oferă însă o scuză pentru a ignora aspectele principale ale contractării, din perspective juridice, financiare și ale managementului de proiect.

În contextul industriei serviciilor software, contractele reprezintă un element de bază în distribuirea riscurilor și profiturilor între vânzători și clienții acestora. Din această perspectivă, există cinci tipuri diferite de contracte ce pot fi folosite pentru un proiect software, vezi Tabelul 1.

În cazul centrelor de dezvoltare offshore, precum și în cazul echipelor și resurselor specializate, furnizorul nu are niciun control sau contribuție asupra modului în care sunt organizate echipele pentru livrarea de software. Indiferent dacă aceste echipe lucrează într-o manieră Agile sau nu, acest lucru nu influențează în niciun mod structura contractului și modelul de facturare.

Contractele Pain Share/Gain Share sunt extrem de rar întâlnite în industria software și, în mod similar, ele nu sunt o funcție a metodologiei utilizate pentru livrare, fie ea Agile sau nu.

În cazul contractelor Scop Fix, Bugetul Fix și a celor bazate pe Timp și Resurse, structura contractului și modelul de facturare intră în conflict cu paradigma Agile pentru livrarea de software.

Acest conflict structural este unul dintre principalele cauze ce determină provocările pe care le înfruntă organizațiile în eforturile lor de a adopta și scala metode și practici Agile. Sugestiv în acest sens este afirmația extrasă din cartea Agile Contracts:

"Înțelegerea metodologiei nu este cel mai mare obstacol în a realiza conversia la modelul Agile. Mai degrabă, provocarea o reprezintă cultura organizațională internă și potențialele modificări pe care le presupune la nivelul proceselor interne".

În teorie, funcțiile de suport într-o companie de software, cum ar fi departamentul financiar ori juridic nu ar trebui să constituie un obstacol sau să adauge costuri și cheltuieli generale inutile pentru livrarea de software. Însă în practică, acest lucru se întâmplă adesea.

Procesul de bugetare lent, complicat, precum și nevoia de predictibilitate financiară și minimizare a riscurilor determină ca cele mai bune practici Agile să fie de multe ori ignorate atunci când contractele sunt scrise și negociate.

O variantă pe care o aleg multe companii este să o ascundă. Ei semnează contracte standard cu clienții lor și utilizează tehnici Agile în livrare, fără a face acest lucru vizibil.

Alte companii își asumă riscurile semnării de contracte Fixed Scope, Fixed Budget pentru proiecte software care încep cu un grad relativ ridicat de incertitudine, deoarece scopul proiectului nu este nici pe departe bine definit. Deși nu este realistă așteptarea ca un proiect software care durează mai mult de trei sau patru săptămâni să fie livrat cu un scop fix, stabilit de la început, multe companii au avut de suferit după ce au semnat astfel de contracte.

În cazul contractelor standard de timp și resurse pentru proiecte software Agile, facturarea bazată pe timp este benefică pentru furnizor câtă vreme vând servicii la prețuri mai mici, care sunt văzute de clienți ca servicii ușor comparabile și înlocuibile cu alți furnizori de pe piață.

Odată ce furnizorul încearcă să vândă servicii de calitate superioară în dorința de urca pe scara valorii, utilizarea contractelor standard de timp și materiale devine mai degrabă o problemă decât o soluție.

Alternativa este utilizarea unui model hibrid de prețuri, și anume facturarea bazată pe Sprint pentru orice proiecte livrate folosind Scrum.

Pentru a vedea de ce și cum poate funcționa această abordare, trebuie să luăm în considerare una dintre legile fundamentale ale managementul prețurilor, conform căreia prețul optim este atins atunci când metricele de valoare, utilizare și facturare sunt aliniate. În mod ideal, toate cele trei metrice ar trebui să folosească aceeași unitate de măsură.

Amazon Web Services (AWS), atunci când este folosit de un website de comerț electronic, este exemplul perfect în acest sens. Utilizarea este măsurată în unități de CPU (putere de calcul). Facturarea este legată de utilizarea puterii de calcul (CPU, GPU, stocare și altele).

Valoarea pentru client este corelată cu traficul website-ului, care este direct legat de puterea de calcul necesară. Cu cât sunt mai mulți vizitatori în magazinul online, cu atât sunt mai mari veniturile pentru website; cu cât folosește mai mult resursele AWS, cu atât mai mult trebuie să plătească. Când traficul este scăzut (în afara sezonului, pe timpul nopții), veniturile vor fi mai mici, dar la fel sunt și costurile aferente, dat fiind că se utilizează capacitatea de calcul redusă.

În această situație, interesele furnizorului (AWS) și ale clientului (website-ul de comerț electronic) sunt aliniate și modelul de prețuri funcționează bine pentru ambele părți.

Această regulă poate fi aplicată și pentru dezvoltarea Agile de software în contextul proiectelor de outsourcing. Story Points este valoarea tipică pentru utilizare sau progres. Orele sunt cele mai folosite metrici pentru facturare. Clienții își doresc să primească și sunt interesați să primească "software funcțional", ceea ce, de cele mai multe ori, înseamnă module și funcționalități.

Astfel, metricele nu doar că nu sunt aliniate, sunt complet desincronizate, chiar contradictorii pe alocuri.

Această contradicție poate fi transformată în probleme financiare pentru managerii furnizorilor de software care aleargă după clienți care nu doresc să-și plătească facturile pentru că sunt semnificativ mai mari decât ceea ce a promis furnizorul în propunerea de buget trimisă inițial. Aceeași contradicție va apărea ca o provocare pentru managerul de proiect care trebuie să sincronizeze orele din rapoartele de timp ale echipei cu story points, și care trebuie să explice clientului la fiecare demo de sprint de ce nu există previzibilitate sau o legătură logică între cele două seturi de numere.

De asemenea, poate duce la conversații dificile cu clienții care au avut un buget limitat, finit pentru a dezvolta un Minimum Viable Product când, chiar dacă bugetul este epuizat, produsul nu este încă gata, este nevoie de mai multă muncă și aplicația nu poate fi lansată.

Toate acestea se vor întâmpla atâta timp cât metricele de utilizare, facturare și valoare sunt nealiniate. Există câțiva parametri alternativi pe care companiile de software le-ar putea utiliza.

Pentru capacitatea de utilizare și efortul depus de echipă, furnizorii ar putea raporta:

Story points,
Sprints,
Epics,
Jobs to be done,
Features,
Backlog items,
Modules,
Timesheets.

De asemenea, pentru facturare, există mai multe opțiuni:

Pure time and materials metrics:
- Man-hours,
- Man-days.
Hybrid: charging for scope and time:
- Weeks,
- Sprints (eg. 2 weeks),
- Calendar months.
Fixed scope metrics:
- Activities,
- Features completed,
- Projects,
- Tasks,
- Activities,
- Deliverables.

În ceea ce privește valoarea, clienții urmăresc mai multe aspecte. Ei vor software funcțional, care pentru mulți oameni reprezintă lista de caracteristici sau funcționalități. Livrarea la timp este, de asemenea, importantă pentru majoritatea. Și mai important ar putea fi faptul că software-ul îi ajută să genereze venituri mai mari sau că îi ajută să reducă costurile ori să atenueze și să scadă riscurile în activitatea lor.

Ceea ce înseamnă că pentru clienți este prioritar impactul financiar și valoarea economică a software-ului, poate chiar mai mult decât ceea ce face software-ul sau modul cum este acesta construit. Cu facturarea bazată pe sprint, companiile de software pot aduce toate acestea împreună, într-un mod care creează interese aliniate pentru client și furnizor.

Este situația în care sprinturile sunt folosite și ca măsură a utilizării și a progresului în proiect.

Prețul pe sprint pentru o echipă cu un anumit număr de FTE (echivalent cu normă întreagă) este metricul de facturare pentru contract. Unii membri ai echipei sunt alocați cu normă întreagă pentru proiect (de obicei, programatorii software). Alte roluri sunt part-time la fiecare sprint și nu contribuie neapărat la fiecare sprint, ci numai atunci când este necesar în ritmul firesc al proiectului (designer, manager de proiect, arhitect software, QA).

Metricul de stabilire a valorii este sprintul finalizat, cu o valoare financiară aferentă fiecăruia dintre ele sau la o grupare de sprinturi din roadmap. Acest metric este folosit pentru a prioritiza roadmapul și backlogul împreună cu clientul.

Epoca facturării pe oră și a vânzării de servicii de dezvoltare software ieftine este depășită pentru multe companii. Oricine dorește să vândă servicii de calitate superioară și să factureze în conformitate cu valoarea creată trebuie să regândească modelul de contractare utilizat pentru proiectele software Agile.