Măsurarea fluxurilor de valoare în livrarea de software cu Schema sistemului de valoare

Text integral

1 Introducere

Echipele de software sunt măsurate îndeaproape: viteza (velocity), debitul (throughput), timpul de livrare (lead time), frecvența implementărilor și rata de eșec a modificărilor sunt colectate automat. Totuși, aceste cifre lasă deschisă o întrebare: ce valoare a livrat echipa, cui și cu ce cost în pierderi?

Această lucrare propune o metodă de a răspunde la această întrebare cu ajutorul Schemei sistemului de valoare (Value System Schema, VSS), notația de modelare a metodologiei Æilus, așa cum este implementată în VSS Editor, publicat pe aeilus.tech. Este a cincea lucrare din seria "Æilus for Business". Folosește vocabularul definit în prima lucrare a seriei, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), și nu repetă aceste definiții. Tratarea formală a valorii ca monedă măsurabilă (Æ) este dată în "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

Lucrarea descrie cum o organizație de livrare poate construi o schemă a propriului sistem de valoare, poate atașa valoarea planificată și pe cea realizată la versiuni (release), poate localiza rezistența la flux și scurgerile, poate evalua nodurile tehnice comune și poate derula ciclul cu roluri și cadență clare. Se bazează pe axiomele VMT A1, A2, A4, A5, A6, A7, A11 și A13 și pe teoremele T3, T4, T5, T6, T8, T9, T15, T16 și T17. Nu conține date măsurate. Exemplul detaliat din Secțiunea 9 este sintetic.

2 Ce măsoară metricile de livrare și ce nu măsoară

Metricile de livrare descriu mișcarea muncii. Viteza (velocity) numără efortul estimat finalizat; debitul (throughput) numără elementele terminate. Cele patru metrici cheie popularizate de Forsgren, Humble și Kim (Accelerate, 2018), anume frecvența implementărilor, timpul de livrare al modificărilor, timpul de restabilire a serviciului și rata de eșec a modificărilor, descriu viteza și stabilitatea fluxului de livrare. Această cercetare leagă aceste capabilități de performanța organizațională, iar lucrarea de față nu o contestă. Afirmația ei este mai restrânsă: aceste metrici descriu fluxul de livrare, nu valoarea care trece prin el.

Din aceasta rezultă trei lacune.

• Efortul nu este valoare. Un sprint cu viteză mare poate livra funcționalități pe care nimeni nu le folosește. În limbajul prezentării Product Value System, "funcționalitățile nu sunt valoare" și "metricile nu sunt valoare": o funcționalitate este o presupunere despre valoare, iar o metrică este o interpretare a ei.
• Viteza nu este direcție. Un timp de livrare scurt livrează mai repede o ipoteză greșită.
• Stabilitatea nu este absența antivalorii. O rată scăzută de eșec a modificărilor nu spune nimic despre întârzieri, confuzie, refacerea muncii de partea utilizatorilor sau pierderea încrederii cauzată de o modificare care a funcționat exact așa cum fusese proiectată.

Din punctul de vedere al Teoriei managementului valorii (Value Management Theory, VMT), lacuna este structurală. Valoarea există doar în interiorul unui sistem de valoare definit și este interpretată de actorii acestuia (A1, A2). Ea este realizată în momentul consumului (A6), iar valoarea planificată și cea realizată diferă de obicei (A4, T3). Metricile fluxului de livrare sunt colectate înainte de consum, de partea expeditorului, deci descriu cel mult livrarea valorii planificate. Când astfel de metrici devin ținte, apare efectul descris de Goodhart (1975): echipele optimizează contorul. VMT formulează același risc în termeni de sistem: optimizarea locală nu garantează îmbunătățirea globală (T5).

3 Notația Schemei sistemului de valoare

3.1 Elementele notației

În metodologia Æilus, Schema sistemului de valoare este primul artefact de bază: o descriere formală a sistemului de valoare, a actorilor, fluxurilor, transformatorilor și schimburilor cheie ale acestuia, folosită pentru a stabili limitele sistemului și pentru a preveni dependențele externe invizibile. O VSS poate fi desenată la nivel de transformator sau la nivel de sistem.

VSS Editor, lansat pe aeilus.tech în decembrie 2025, este un editor vizual în browser pentru astfel de scheme. Notația sa are un număr mic de elemente.

• Convertoare. Un convertor este denumirea din Æilus pentru rolul de transformator dintr-o schemă: un bloc funcțional, cum ar fi o echipă, un serviciu sau un subsistem, care primește elemente de valoare, le transformă și produce altele noi. Convertoarele sunt locurile în care valoarea este creată, amplificată sau distrusă.
• Fluxuri. Un flux este o conexiune direcțională între convertoare sau între un convertor și lumea exterioară. Poartă o cantitate de valoare sau de antivaloare în Æ. Un flux este extern de intrare (valoare care intră în sistem), extern de ieșire (valoare care părăsește sistemul) sau intern (valoare între convertoare).
• Intrări și ieșiri. Fluxurile externe de intrare și de ieșire marchează locul unde valoarea intră și pleacă. Împreună definesc limita sistemului.
• Elemente de valoare. Tipurile de elemente descriu ce anume se mișcă printr-un flux: valoare pentru client, venituri, costuri, riscuri, datorie tehnică și altele similare. Într-o schemă salvată, fiecare element are un gen (valoare sau antivaloare), un semn, o cantitate și o unitate (Æ).
• Antivaloare. Antivaloarea reprezintă pierderi și efecte negative: întârzieri, refaceri, defecte, birocrație, risc, epuizare profesională, efort irosit. În schemă este un element explicit cu semn negativ, nu absența valorii (A5).

3.2 Schema ca model care poate fi citit de mașină

Editorul salvează o schemă ca JSON structurat, cu noduri (convertoare), fluxuri și elemente. Schema poate fi astfel versionată împreună cu produsul și citită ulterior de instrumente de analiză care compară cantitățile planificate și cele realizate pe fiecare flux. Astfel de instrumente de analiză sunt anunțate ca lucrări viitoare și nu sunt presupuse aici.

3.3 Ce nu este schema

VSS Editor nu este, în mod explicit, un panou de indicatori KPI, un instrument BI, un motor de simulare sau un înlocuitor al contabilității financiare. El pune claritatea înaintea calculului. Ordinea recomandată de modelare este următoarea: se definește limita, se adaugă doar convertoarele principale, se conectează prin fluxuri denumite (numele înaintea cifrelor, direcția înaintea preciziei), apoi se marchează antivaloarea, pas care produce adesea cele mai multe informații utile.

4 Valoarea cui: sistemul și limita lui

O măsurare a valorii nu are sens până când nu precizează valoarea cui este măsurată (A1, T1). Limita aleasă modifică, de asemenea, concluziile fără nicio schimbare în realitate (T15). Această lucrare fixează, prin urmare, sistemul de valoare înainte de orice măsurare.

Sistemul de valoare modelat aici este sistemul de valoare al produsului (product value system) pentru un singur produs software dintr-o organizație de produs. Conform prezentării Product Value System, actorii săi sunt funcția de produs, echipa de dezvoltare, operațiunile, produsul în producție, utilizatorii și compania ca receptor al valorii returnate de utilizatori. Finanțele sunt un flux extern de intrare care asigură resursele (salariile).

Sunt măsurate două interpretări realizate: valoarea pentru utilizatori, interpretată de utilizatori sau de comportamentul lor observabil, și valoarea pentru companie, interpretată de companie ca receptor al fluxului de întoarcere (venituri, retenție, cost sau risc redus). Valoarea planificată este interpretarea expeditorului înainte de lansare. Valoarea aceleiași versiuni pentru un partener sau pentru un autoritate de reglementare se află în afara limitei, cu excepția cazului în care aceasta este extinsă în mod explicit.

5 De la ipoteza de produs la valoarea realizată: bucla valorii

Prezentarea Product Value System încadrează munca de produs ca pe o buclă în care ipotezele de valoare sunt create, implementate, validate și susținute. În termenii schemei, bucla are următoarele convertoare și fluxuri.

1. Investiția către funcția de produs. Funcția de produs convertește resursele și semnalele utilizatorilor în ipoteze care poartă valoare planificată.
2. De la funcția de produs la dezvoltare. Ipotezele devin elemente de backlog cu valoare planificată. Prezentarea enunță două așteptări: valoarea planificată a unei ipoteze nu ar trebui să scadă în timpul construirii ei, iar valoarea livrată nu ar trebui să difere mult de cea planificată.
3. De la dezvoltare la operațiuni. Dezvoltarea consumă efort și produce modificări funcționale, împreună cu antivaloare (datorie tehnică, defecte, întârzieri).
4. De la operațiuni la producție. Modificările devin software în execuție; erorile de lansare și timpii de nefuncționare apar ca antivaloare.
5. De la producție la utilizatori. Valoarea este realizată doar în utilizare (A6), deci acesta este primul punct în care valoarea realizată poate fi observată.
6. De la utilizatori la companie. Utilizatorii returnează venituri, retenție și încredere. Postarea autorului pe canal din ianuarie 2022 numește aceasta un flux închis: valoarea livrată clientului este echilibrată de valoarea care se întoarce, adesea, dar nu numai, sub formă de bani.

Bucla face concretă axioma transformării (A7): fiecare convertor realizează ceea ce primește și produce o nouă valoare planificată pentru următorul. Ea arată, de asemenea, de ce metricile fluxului de livrare acoperă doar pașii 3 și 4. Pașii 1, 2, 5 și 6, unde valoarea este planificată, realizată și returnată, se află în afara fluxului de livrare.

Prezentarea enumeră, de asemenea, tipuri observabile de elemente pentru produsele interne și externe. Elementele de valoare includ timpul economisit, mai puține erori operaționale, fluxul de numerar, reducerea riscului, o încărcare cognitivă mai mică, predictibilitatea, capabilități noi și încrederea. Contrapartidele de antivaloare includ timpul pierdut, refacerea muncii, costul operațional în creștere, datoria tehnică, impredictibilitatea, soluțiile manuale de ocolire, pierderea încrederii și degradarea serviciului pentru clienți. Această tipologie este punctul de plecare al unui Registru al Elementelor de Valoare pentru livrare.

6 Valoarea planificată și valoarea realizată per lansare, rezistența și scurgerea

6.1 Lansarea ca unitate de comparație

Unitatea de comparație este lansarea (release) sau elementul de backlog atunci când lansările sunt mici. Pentru fiecare dintre ele, metoda înregistrează în Æ:

• valoarea planificată: estimarea expeditorului, înregistrată înainte de începerea dezvoltării și actualizată numai printr-o decizie explicită și consemnată;
• valoarea realizată și antivaloarea realizată: interpretarea receptorului după ce lansarea a fost utilizată pe parcursul unei perioade de observație convenite;
• valoarea retrospectivă: o reevaluare ulterioară, după ce efectele de ordinul doi (încărcarea suportului, pierderea clienților, datoria tehnică) au devenit vizibile.

Prezentarea propune o introducere etapizată: mai întâi valoarea planificată pentru fiecare element de backlog, apoi valoarea și antivaloarea realizate pentru fiecare element lansat, apoi valoarea retrospectivă. Fără valoare planificată nu există un decalaj de măsurat; fără valoare realizată, planul rămâne o ipoteză.

6.2 Rezistența la flux în livrare

Rezistența la flux este decalajul dintre valoarea planificată și cea realizată, plus antivaloarea care apare într-un flux. VMT consideră un decalaj nenul drept normal (T3), dar susține că rezistența se acumulează istoric (T4) și reduce capacitatea de a realiza valoare în viitor (T6). În livrare, valoarea se pierde în implementare (reducerea domeniului, ipoteză înțeleasă greșit), în lansare (defecte, rollback-uri), în adopție (utilizatorii nu pot găsi sau folosi modificarea) și din cauza întârzierii. Urmând conceptul costului întârzierii (Reinertsen, 2009), întârzierea este modelată ca antivaloare pe fluxul întârziat, nu ca o metrică separată.

Dacă fiecare flux poartă propriile mărimi planificate și observate, schema arată în care convertor a apărut pierderea. Acesta este scopul Registrului Rezistenței Fluxurilor și al Raportului Decalajului dintre Valoarea Planificată și Valoarea Realizată din setul de artefacte Æilus.

6.3 Scurgerea

Scurgerea (leakage) este un exces susținut al valorii realizate care părăsește sistemul față de valoarea care intră în el (A11). Într-un sistem de valoare al produsului sunt frecvente două forme. În prima, utilizatorii beneficiază, dar fluxul de retur nu acoperă fluxul de intrare care a făcut posibil acest lucru. În a doua, echipa consumă investiții în timp ce ipotezele sunt construite, dar nu sunt niciodată realizate. Debitul poate părea sănătos în ambele cazuri; schema le arată pe amândouă, deoarece fluxurile de intrare și de ieșire se află pe aceeași frontieră.

7 Noduri comune: evaluarea pe toate fluxurile

Unele convertoare dintr-un sistem software nu produc nicio valoare pe care un utilizator ar numi-o, și totuși fiecare flux de valoare trece prin ele. Postarea autorului pe canal din septembrie 2025 și articolul aeilus.tech aferent folosesc autorizarea ca exemplu: ea nu generează valoare prin sine, dar fără ea fiecare scenariu se oprește. Un API gateway sau un pipeline CI sunt de același fel.

Evaluat izolat, un astfel de nod arată cost și niciun rezultat și invită la reducerea costurilor. În schemă el apare simultan pe multe fluxuri, iar eficiența lui devine clară doar prin valoarea agregată a tuturor fluxurilor pe care le susține. De aceea, metoda atribuie unui nod comun:

• mulțimea fluxurilor care trec prin el, citită din schemă;
• antivaloarea pe care o adaugă fiecăruia dintre aceste fluxuri (latență, întreruperi, autentificări eșuate, defecte de integrare);
• valoarea sa consumată (efortul echipei, infrastructura).

Eficiența sa este valoarea livrată minus antivaloarea pe toate fluxurile sale, raportată la valoarea consumată, urmând definiția eficienței procesului din același articol. O degradare a unui nod comun nu este niciodată un incident local; este rezistență adăugată fiecărui flux pe care îl deservește. Teorema T8 adaugă un argument de sustenabilitate: stabilitatea se pierde atunci când un rol de transformare nu poate fi îndeplinit, iar redundanța rolului crește stabilitatea.

8 Ce câștigă un lider de echipă

Postarea autorului pe canal din februarie 2022 enumeră ce oferă abordarea unei echipe și liderului ei. Reformulat în termenii acestei lucrări:

• Valoarea livrată ca feedback. Pentru orice perioadă, echipa vede valoarea pe care a livrat-o, în Æ, confirmată de destinatari, în loc de semnalul indirect al vitezei (velocity).
• O măsură a eficacității independentă de metodologia procesului. Indiferent de practică, măsura este valoarea realizată per valoare consumată, iar practicile sunt alese sau retrase în funcție de efectul lor asupra acesteia (P7).
• Transparență pentru business. Munca tehnică devine explicabilă prin fluxurile pe care le susține.
• Prioritatea backlogului pornind de la valoare. Prioritatea poate fi derivată din valoarea planificată, din încrederea în ea și din costul întârzierii, în loc să fie dictată de partea interesată cu cea mai puternică voce.
• Costul întârzierii și erorile din producție ca antivaloare. Business-ul poate arăta cum scade valoarea atunci când o modificare este întârziată sau defectuoasă, iar echipa vede cum utilitatea muncii sale depinde de momentul livrării și de calitatea în producție.
• Argumente pentru resursele partajate. Acolo unde administratorii și inginerii DevOps sunt partajați, prioritizarea bazată pe valoare explică de ce munca unei echipe a fost amânată în favoarea alteia, în ambele sensuri.

Aceste câștiguri se mențin doar dacă valoarea realizată este validată de destinatarii ei. Dacă echipa își estimează și își confirmă singură valoarea, măsura devine încă un contor auto-raportat și se aplică T17: interpretările din surse influente care nu sunt confirmate prin realizare acumulează antivaloare.

9 O schemă elaborată a unui produs sintetic

Această secțiune descrie un produs sintetic, ilustrativ. Nu este un studiu de caz, nu descrie nicio organizație reală și nu conține numere măsurate.

Produsul sintetic este o aplicație web cu abonament prin care întreprinderile mici de servicii primesc rezervări de la clienți. Sistemul său de valoare urmează frontiera definită în Secțiunea 4. Două noduri comune, un serviciu de autorizare și un API gateway, deservesc toate fluxurile orientate către utilizator. Departamentul financiar asigură fluxul de intrare care face posibil totul. Compania primește venituri din abonamente și retenție drept flux de retur.

Schema este construită în VSS Editor în patru etape: frontiera cu un flux de intrare extern (investiții și salarii) și fluxurile de ieșire externe către utilizatori; șapte convertoare; fluxuri denumite după elementele de valoare pe care le poartă; și elemente de antivaloare. Mărimile rămân goale până la prima sesiune de estimare.

Să luăm în considerare o versiune ipotetică: o funcționalitate de memento menită să reducă numărul programărilor ratate. Înainte de dezvoltare, proprietarul produsului înregistrează valoarea planificată pentru fiecare element (timp economisit, mai puține rezervări ratate, efectul așteptat asupra retenției). După o perioadă de observare convenită, analiza produsului și un eșantion de utilizatori de business furnizează valoarea realizată, iar echipa înregistrează antivaloarea realizată: o lansare întârziată, un defect care a trimis mementouri duplicate, o încărcare suplimentară a gateway-ului API. Diferența reprezintă rezistența acestei versiuni. Defectul și încărcarea gateway-ului se regăsesc și pe fluxurile care deservesc alte scenarii, așa că sunt atribuite și nodurilor comune. După un trimestru, valoarea retrospectivă arată dacă retenția s-a schimbat deloc. Într-o aplicație reală, cantitățile ar proveni din sesiunile descrise în continuare.

10 Cum se desfășoară

10.1 Cine estimează și cine validează

Regula Æilus din articolul din 2025 este scurtă: valoarea de ieșire a unui proces trebuie evaluată de cel care o consumă, iar altcineva trebuie să verifice această evaluare. Aplicată livrării, aceasta conduce la o împărțire clară.

• Valoarea planificată este estimată de expeditor. Pentru ipoteze, acesta este proprietarul produsului, în rol de Proprietar al Transformatorului de Valoare (Value Transformer Owner, VTO) al transformatorului de produs. Pentru transformatorul de dezvoltare, este liderul echipei, în calitate de VTO.
• Valoarea realizată este interpretată de receptor: utilizatorii, observați prin analiza produsului sau analiza web, și compania pentru fluxul de întoarcere. Prezentarea propune, ca măsură temporară, ca analiza produsului să reprezinte partea utilizatorilor până când se stabilește o validare directă.
• Validarea interpretării este realizată de o a doua parte: Proprietarul Sistemului de Valoare (Value System Owner, VSO), care deține sustenabilitatea la nivel de sistem, sau un Proprietar al Fluxului pentru un flux critic.
• Integritatea metodologică este susținută de un Æilus Master (în prezentare, un campion Æilus deținut de un manager de proiect), care pregătește rapoartele despre livrarea valorii, planificat versus realizat și rezistența fluxurilor.

10.2 Cadență

Æilus nu prescrie un calendar. O cadență minimă pentru o echipă de livrare, în acord cu evenimentele recomandate de metodologie, este următoarea.

• La fiecare rafinare a backlogului: valoarea planificată este atribuită elementelor noi, folosind registrul de elemente.
• La fiecare lansare, după perioada de observare: valoarea și antivaloarea realizate sunt înregistrate și validate; o scurtă retrospectivă a valorii discută diferența.
• Lunar sau trimestrial: o Revizuire a Rezistenței Fluxurilor pe schemă, inclusiv nodurile comune; valoarea retrospectivă pentru elementele lansate anterior.
• Trimestrial sau la schimbări structurale: o Revizuire a Sistemului de Valoare a limitelor, transformatoarelor și dependențelor, cu fișierul schemei actualizat și versionat.

10.3 Disciplină

Fiecare artefact are nevoie de un proprietar, de o buclă de actualizare și de un scop decizional; altfel creează antivaloare prin costul de întreținere și prin falsa încredere. Pentru această metodă, scopurile decizionale sunt prioritatea în backlog, alocarea resurselor comune, momentul lansării și investițiile în nodurile comune. Creșterea valorii planificate este admisibilă doar atunci când capacitatea echipei de a o realiza este confirmată (P9). Scalarea valorii planificate mai rapid decât cea realizată este modul de defectare descris de T16.

11 Limitări și ce ar necesita un studiu empiric

Această lucrare este conceptuală și nu a fost testată pe date măsurate. Rezultă mai multe limitări.

• Calitatea estimării. Valorile din Æ sunt interpretări a căror fiabilitate depinde de estimatori și de calibrarea lor.
• Comensurabilitate parțială. Timpul economisit, veniturile și încrederea sunt doar parțial comensurabile (A13). Exprimarea lor într-o singură monedă necesită o Politică de Agregare a Valorii, pe care această lucrare o presupune, dar nu o definește.
• Atribuire. Valoarea realizată rezultă adesea din mai multe lansări și din factori externi; schema arată structura, dar nu poate izola contribuția unei singure lansări.
• Fluxuri ascunse. Dacă schema nu poate explica stabilitatea sau declinul observat al sistemului, există fluxuri latente sau limita este greșită (T9). O schemă este o ipoteză despre structură și trebuie revizuită.
• Costul metodei. Sesiunile care nu produc decizii transformă metoda însăși în antivaloare.

Un studiu empiric ar necesita, cel puțin: mai multe echipe de livrare care aplică metoda o perioadă suficient de lungă pentru a înregistra valoarea retrospectivă; un registru stabil de elemente și o politică de agregare convenite înainte de colectarea datelor; validarea independentă a valorii realizate de către destinatari, nu de către echipe; colectarea paralelă a metricilor convenționale de livrare, pentru a putea examina relația dintre aceste metrici și valoarea realizată; și o comparație a deciziilor luate cu schema și fără ea. Doar un astfel de studiu ar putea arăta dacă prioritizarea bazată pe valoare schimbă valoarea livrată și în ce condiții.

12 Concluzie

Metricile de livrare descriu modul în care munca se deplasează printr-un flux de lucru, nu ce a schimbat aceasta pentru destinatari; conform VMT, ele nu pot face acest lucru, deoarece valoarea este contextuală, se realizează doar în utilizare, iar valoarea planificată și cea realizată diverg. Schema sistemului de valoare (Value System Schema), implementată în VSS Editor, permite echipelor software să deseneze bucla de valoare a produsului de la ipoteză până la valoarea realizată și înapoi la companie. Înregistrarea valorii planificate, realizate și retrospective pentru fiecare versiune transformă bucla într-o măsurătoare: rezistența și scurgerea devin vizibile, nodurile comune sunt evaluate pe fiecare flux pe care îl deservesc, iar liderii de echipă obțin ca feedback valoarea livrată, prioritatea bazată pe valoare și costul întârzierii și al erorilor. Metoda rămâne onestă doar dacă limita sistemului este declarată, destinatarii validează valoarea realizată, iar fiecare artefact servește unei decizii. Dacă ea îmbunătățește în practică valoarea livrată este o întrebare empirică pe care această lucrare o formulează, dar nu o rezolvă.

Referințe

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (în rusă). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.