de Emanuel Martoncă, Fondator Soft Fight

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

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 critice ale contractării, din perspective juridice, financiare și ale management-ului de proiect.

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

În cazul centrelor de dezvoltare offshore, precum și în cazul echipelor și resurselor dedicate, 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 impacteaza î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 determina provocările pe care le înfruntă organizațiile în eforturile lor de a adopta și scala metode și practici Agile. Ca să citez din cartea Agile Contracts, „înțelegerea metodologiei nu este cel mai mare obstacol în amconversia la modelul Agile. Mai degrabă, provocarea este 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 . În practică, însă, acest lucru se întâmplă adesea.

Procesul de bugetare lent, complicat, precum și nevoia de predictibilitate financiară și minimizare a riscurilor determina ca cele mai bune practici Agile sa fie de multe ori ignorate atunci când contractele sunt scrise și negociate.
O varianta 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 3 sau 4 săptămâni sa fie livrat cu un scop fix, stabilit de la început, totuși 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 și 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 careia prețul optim este atins atunci când metricele de valoare, utilizare și facturare sunt aliniate. În mod ideal, toate cele 3 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ă capacitate de calcul redusă.
În acesta 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 cel mai folosit metric 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 de 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 2 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, sau 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-ul, poate chiar mai mult decât ceea ce face software-ul sau 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 sprint 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 roadmap-ul și backlog-ul î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.

MAI MULTE RESURSE

Peter Stevens (2009), 10 agile contracts 

Contracting for Agile, Guidance Note (2023), UK Government Commercial Function

Tom Arbogast, Craig Larman, and Bas Vodde, [White-paper] Agile Contracts Primer, derived from the book… Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum 

1_Andreas Opelt, Boris Gloger, Wolfgang Pfarl, 2013, [Book] Agile Contracts, Creating and Managing Successful Projects with Scrum

2_Rami Sirkiä and Maarit Laanti (2013), [White-paper] Lean and agile financial planning

3_Allan Kelly (2011), [article] Agile Contracts, author of „Changing Software Development: Learning to become Agile”