ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 136
Abonament PDF

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:

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

Î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.

Resurse

  1. Peter Stevens (2009), 10 agile contracts

  2. https://www.agilesoftwaredevelopment.com/posts/10-agile-contracts/

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

  4. https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/1163540/Contracting_for_Agile_Guidance_Note.pdf

  5. 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

  6. https://agilecontracts.org

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects