Misurare i flussi di valore nella consegna del software con lo Schema del Sistema di Valore

Testo completo

1 Introduzione

I team di sviluppo software sono misurati da vicino: velocity, throughput, lead time, frequenza di rilascio e tasso di fallimento delle modifiche vengono raccolti automaticamente. Eppure questi numeri lasciano aperta una domanda: quale valore ha fornito il team, a chi, e a quale costo in termini di perdite?

Questo articolo propone un metodo per rispondere a tale domanda con lo Schema del Sistema di Valore (Value System Schema, VSS), la notazione di modellazione della metodologia Æilus, come implementato nel VSS Editor pubblicato su aeilus.tech. È il quinto articolo della serie "Æilus for Business". Utilizza il vocabolario definito nel primo articolo della serie, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), e non ripete tali definizioni. La trattazione formale del valore come valuta misurabile (Æ) è presentata in "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

L'articolo descrive come un'organizzazione di delivery possa costruire uno schema del proprio sistema di valore, associare il valore pianificato e quello realizzato alle release, individuare la resistenza del flusso e la dispersione, valutare i nodi tecnici condivisi e condurre il ciclo con ruoli e cadenza chiari. Si basa sugli assiomi VMT A1, A2, A4, A5, A6, A7, A11 e A13 e sui teoremi T3, T4, T5, T6, T8, T9, T15, T16 e T17. Non contiene dati misurati. L'esempio svolto nella Sezione 9 è sintetico.

2 Che cosa misurano le metriche di delivery e che cosa non misurano

Le metriche di delivery descrivono il movimento del lavoro. La velocity conta lo sforzo stimato completato; il throughput conta gli elementi terminati. Le quattro metriche chiave rese popolari da Forsgren, Humble e Kim (Accelerate, 2018), ovvero la frequenza di rilascio, il lead time delle modifiche, il tempo di ripristino del servizio e il tasso di fallimento delle modifiche, descrivono la velocità e la stabilità della pipeline di delivery. Tale ricerca collega queste capacità alla performance organizzativa, e questo articolo non la contesta. La sua tesi è più circoscritta: queste metriche descrivono la pipeline, non il valore che la attraversa.

Ne derivano tre lacune.

• Lo sforzo non è valore. Uno sprint con alta velocity può fornire funzionalità che nessuno utilizza. Nel linguaggio della presentazione Product Value System, "le funzionalità non sono valore" e "le metriche non sono valore": una funzionalità è un'ipotesi sul valore, e una metrica ne è un'interpretazione.
• La velocità non è direzione. Un lead time breve consegna più rapidamente un'ipotesi sbagliata.
• La stabilità non è assenza di anti-valore. Un basso tasso di fallimento delle modifiche non dice nulla su ritardi, confusione, rilavorazioni da parte degli utenti o perdita di fiducia causata da una modifica che ha funzionato esattamente come progettato.

Dal punto di vista della Teoria della Gestione del Valore (Value Management Theory, VMT), la lacuna è strutturale. Il valore esiste solo all'interno di un sistema di valore definito ed è interpretato dai suoi attori (A1, A2). Si realizza nel momento del consumo (A6), e il valore pianificato e quello realizzato di solito differiscono (A4, T3). Le metriche della pipeline sono raccolte prima del consumo, dal lato del mittente, quindi descrivono al più la consegna del valore pianificato. Quando tali metriche diventano obiettivi, compare l'effetto descritto da Goodhart (1975): i team ottimizzano il contatore. La VMT esprime lo stesso rischio in termini di sistema: l'ottimizzazione locale non garantisce un miglioramento globale (T5).

3 La notazione dello Schema del Sistema di Valore

3.1 Elementi della notazione

Nella metodologia Æilus, lo Schema del Sistema di Valore è il primo artefatto fondamentale: una descrizione formale del sistema di valore, dei suoi attori, flussi, trasformatori e scambi chiave, usata per stabilire i confini del sistema e per prevenire dipendenze esterne invisibili. Un VSS può essere disegnato a livello di trasformatore o a livello di sistema.

Il VSS Editor, rilasciato su aeilus.tech nel dicembre 2025, è un editor visuale basato su browser per tali schemi. La sua notazione ha un numero ridotto di elementi.

• Convertitori. Un convertitore (converter) è il nome che Æilus dà al ruolo di trasformatore in uno schema: un blocco funzionale, come un team, un servizio o un sottosistema, che riceve elementi di valore, li trasforma e ne produce di nuovi. I convertitori sono i luoghi in cui il valore viene creato, amplificato o distrutto.
• Flussi. Un flusso è una connessione direzionale tra convertitori, o tra un convertitore e il mondo esterno. Trasporta una quantità di valore o di anti-valore in Æ. Un flusso è esterno in ingresso (valore che entra nel sistema), esterno in uscita (valore che lascia il sistema) o interno (valore tra convertitori).
• Ingressi e uscite. I flussi esterni in ingresso e in uscita indicano dove il valore entra ed esce. Insieme definiscono il confine del sistema.
• Elementi di valore. I tipi di elemento descrivono che cosa si muove esattamente attraverso un flusso: valore per il cliente, ricavi, costi, rischi, debito tecnico e simili. In uno schema salvato ogni elemento ha un tipo (valore o anti-valore), un segno, una quantità e un'unità (Æ).
• Anti-valore. L'anti-valore rappresenta perdite ed effetti negativi: ritardi, rilavorazioni, difetti, burocrazia, rischio, burnout, sforzo sprecato. Nello schema è un elemento esplicito con segno negativo, non l'assenza di valore (A5).

3.2 Lo schema come modello leggibile da macchina

L'editor salva uno schema come JSON strutturato con nodi (convertitori), flussi ed elementi. Lo schema può quindi essere versionato insieme al prodotto e letto successivamente da strumenti di analisi che confrontano le quantità pianificate e realizzate per ciascun flusso. Tali analisi sono annunciate come lavoro futuro e non sono presupposte qui.

3.3 Che cosa lo schema non è

Il VSS Editor non è esplicitamente una dashboard di KPI, uno strumento di BI, un motore di simulazione né un sostituto della contabilità finanziaria. Pone la chiarezza prima del calcolo. Ne consegue l'ordine di modellazione raccomandato: definire il confine, aggiungere solo i convertitori principali, collegarli con flussi denominati (i nomi prima dei numeri, la direzione prima della precisione), quindi segnalare l'anti-valore, il passo che spesso produce più intuizioni.

4 Il valore di chi: il sistema e il suo confine

Una misurazione del valore è priva di senso finché non indica il valore di chi viene misurato (A1, T1). Anche il confine scelto modifica le conclusioni senza alcun cambiamento nella realtà (T15). Questo articolo fissa quindi il sistema di valore prima di qualsiasi misurazione.

Il sistema di valore qui modellato è il sistema di valore del prodotto di un singolo prodotto software all'interno di un'organizzazione di prodotto. Seguendo la presentazione Product Value System, i suoi attori sono la funzione di prodotto, il team di sviluppo, le operations, il prodotto in produzione, gli utenti e l'azienda come destinataria del valore restituito dagli utenti. La finanza è un flusso abilitante esterno in ingresso (stipendi).

Vengono misurate due interpretazioni realizzate: il valore per gli utenti, interpretato dagli utenti o dal loro comportamento osservabile, e il valore per l'azienda, interpretato dall'azienda come ricevente del flusso di ritorno (ricavi, fidelizzazione, riduzione di costi o rischi). Il valore pianificato è l'interpretazione del mittente prima della release. Il valore della stessa release per un partner o un ente regolatore è al di fuori del confine, a meno che non venga esteso esplicitamente.

5 Dall'ipotesi di prodotto al valore realizzato: il ciclo del valore

La presentazione Product Value System inquadra il lavoro di prodotto come un ciclo in cui le ipotesi di valore vengono create, implementate, validate e sostenute. In termini di schema il ciclo ha i seguenti convertitori e flussi.

1. Investimento verso la funzione di prodotto. La funzione di prodotto converte risorse e segnali degli utenti in ipotesi che portano valore pianificato.
2. Dalla funzione di prodotto allo sviluppo. Le ipotesi diventano elementi di backlog con valore pianificato. La presentazione enuncia due aspettative: il valore pianificato di un'ipotesi non dovrebbe diminuire durante la sua realizzazione, e il valore consegnato non dovrebbe discostarsi molto dal valore pianificato.
3. Dallo sviluppo alle operations. Lo sviluppo consuma sforzo e produce modifiche funzionanti, insieme ad anti-valore (debito tecnico, difetti, ritardi).
4. Dalle operations alla produzione. Le modifiche diventano software in esecuzione; errori di rilascio e downtime compaiono come anti-valore.
5. Dalla produzione agli utenti. Il valore si realizza solo nell'uso (A6), quindi questo è il primo punto in cui il valore realizzato può essere osservato.
6. Dagli utenti all'azienda. Gli utenti restituiscono ricavi, fidelizzazione e fiducia. Il post dell'autore sul canale del gennaio 2022 lo chiama un flusso chiuso: il valore consegnato al cliente è bilanciato dal valore che fluisce di ritorno, spesso ma non solo denaro.

Il ciclo rende concreto l'assioma della trasformazione (A7): ogni convertitore realizza ciò che riceve e produce nuovo valore pianificato per il successivo. Mostra inoltre perché le metriche della pipeline coprono solo i passi 3 e 4. I passi 1, 2, 5 e 6, in cui il valore viene pianificato, realizzato e restituito, si trovano al di fuori della pipeline.

Il deck elenca anche i tipi di elementi osservabili per i prodotti interni ed esterni. Gli elementi di valore comprendono tempo risparmiato, meno errori operativi, flusso di cassa, riduzione del rischio, minore carico cognitivo, prevedibilità, nuove capacità e fiducia. Le controparti di anti-valore comprendono tempo perso, rilavorazioni, costi operativi crescenti, debito tecnico, imprevedibilità, soluzioni manuali di ripiego, perdita di fiducia e degrado del servizio clienti. Questa tipologia è il punto di partenza di un Registro degli Elementi di Valore per la consegna.

6 Valore pianificato e realizzato per release, resistenza e dispersione

6.1 La release come unità di confronto

L'unità di confronto è la release, oppure l'elemento del backlog quando le release sono piccole. Per ciascuna, il metodo registra in Æ:

• valore pianificato: la stima del mittente, registrata prima dell'inizio dello sviluppo e aggiornata solo attraverso una decisione esplicita e registrata;
• valore realizzato e anti-valore realizzato: l'interpretazione del destinatario dopo che la release è stata in uso per un periodo di osservazione concordato;
• valore retrospettivo: una rivalutazione successiva, quando gli effetti di secondo ordine (carico del supporto, abbandono, debito tecnico) sono diventati visibili.

Il deck propone un'introduzione graduale: prima il valore pianificato su ogni elemento del backlog, poi il valore realizzato e l'anti-valore su ogni elemento rilasciato, infine il valore retrospettivo. Senza valore pianificato non c'è uno scostamento da misurare; senza valore realizzato il piano resta un'ipotesi.

6.2 Resistenza del flusso nella consegna

La resistenza del flusso è lo scostamento tra valore pianificato e valore realizzato più l'anti-valore che compare in un flusso. La VMT considera normale uno scostamento diverso da zero (T3), ma sostiene che la resistenza si accumula storicamente (T4) e riduce la capacità di realizzare valore futuro (T6). Nella consegna, il valore si perde nell'implementazione (ambito ridotto, ipotesi fraintesa), nel rilascio (difetti, rollback), nell'adozione (gli utenti non riescono a trovare o a usare la modifica) e a causa del ritardo. Seguendo il concetto di costo del ritardo (Reinertsen, 2009), il ritardo è modellato come anti-valore sul flusso in ritardo, non come metrica separata.

Se ogni flusso porta le proprie quantità pianificate e osservate, lo schema mostra in quale convertitore si è verificata la perdita. Questo è lo scopo del Registro della Resistenza del Flusso e del Report sullo Scostamento tra Valore Pianificato e Valore Realizzato nell'insieme di artefatti di Æilus.

6.3 Dispersione

La dispersione è un eccesso sostenuto di valore realizzato che esce dal sistema rispetto al valore che vi entra (A11). In un sistema di valore di prodotto sono comuni due forme. Nella prima, gli utenti traggono beneficio ma il flusso di ritorno non copre il flusso in ingresso abilitante. Nella seconda, il team consuma investimenti mentre si costruiscono ipotesi che non vengono mai realizzate. In entrambi i casi la produttività può sembrare sana; lo schema mostra entrambe le situazioni perché i flussi in ingresso e in uscita si trovano su un unico confine.

7 Nodi condivisi: valutazione su tutti i flussi

Alcuni convertitori in un sistema software non producono alcun valore che un utente saprebbe nominare, eppure ogni flusso di valore passa attraverso di essi. Il post del canale dell'autore di settembre 2025 e l'articolo correlato su aeilus.tech usano come esempio l'autorizzazione: non genera valore di per sé, ma senza di essa ogni scenario si ferma. Un API gateway o una pipeline CI sono dello stesso tipo.

Valutato in isolamento, un tale nodo mostra costi e nessun risultato e invita al taglio dei costi. Nello schema compare contemporaneamente su molti flussi, e la sua efficienza diventa chiara solo attraverso il valore aggregato di tutti i flussi che supporta. Il metodo assegna quindi a un nodo condiviso:

• l'insieme dei flussi che lo attraversano, ricavato dallo schema;
• l'anti-valore che aggiunge a ciascuno di questi flussi (latenza, interruzioni, accessi falliti, difetti di integrazione);
• il suo valore consumato (impegno del team, infrastruttura).

La sua efficienza è il valore erogato meno l'anti-valore su tutti i suoi flussi, rapportato al valore consumato, seguendo la definizione di efficienza di processo dello stesso articolo. Un degrado in un nodo condiviso non è mai un incidente locale; è resistenza aggiunta a ogni flusso che esso serve. Il teorema T8 aggiunge un argomento di sostenibilità: la stabilità si perde quando un ruolo di trasformazione non può essere svolto, e la ridondanza del ruolo aumenta la stabilità.

8 Che cosa guadagna un responsabile di team

Il post del canale dell'autore di febbraio 2022 elenca ciò che l'approccio offre a un team e al suo responsabile. Riformulato nei termini di questo articolo:

• Il valore erogato come feedback. Per qualsiasi periodo il team vede il valore che ha erogato, in Æ, confermato dai destinatari, invece del segnale indiretto della velocity.
• Una misura di efficacia indipendente dalla metodologia di processo. Qualunque sia la pratica, la misura è il valore realizzato per valore consumato, e le pratiche vengono selezionate o abbandonate in base al loro effetto su di essa (P7).
• Trasparenza per il business. Il lavoro tecnico diventa spiegabile attraverso i flussi che supporta.
• Priorità del backlog derivata dal valore. La priorità può essere ricavata dal valore pianificato, dalla sua affidabilità e dal suo costo del ritardo, invece che dallo stakeholder che alza di più la voce.
• Costo del ritardo ed errori in produzione come anti-valore. Il business può mostrare come il valore cala quando una modifica è in ritardo o difettosa, e il team vede come l'utilità del suo lavoro dipenda dalla tempistica e dalla qualità della produzione.
• Argomenti per le risorse condivise. Dove amministratori e ingegneri DevOps sono condivisi, la priorità basata sul valore spiega perché il lavoro di un team è stato rinviato a favore di quello di un altro, in entrambe le direzioni.

Questi vantaggi valgono solo se il valore realizzato è convalidato dai suoi destinatari. Se il team stima e conferma da sé il proprio valore, la misura diventa un altro contatore autodichiarato, e si applica T17: le interpretazioni provenienti da fonti influenti che non sono confermate dalla realizzazione accumulano anti-valore.

9 Uno schema elaborato di un prodotto sintetico

Questa sezione descrive un prodotto sintetico e illustrativo. Non è un caso di studio, non descrive alcuna organizzazione reale e non contiene numeri misurati.

Il prodotto sintetico è un'applicazione web in abbonamento attraverso cui piccole imprese di servizi accettano le prenotazioni dei clienti. Il suo sistema di valore segue il confine definito nella Sezione 4. Due nodi condivisi, un servizio di autorizzazione e un API gateway, servono tutti i flussi rivolti agli utenti. La funzione Finanza fornisce il flusso in ingresso abilitante. L'azienda riceve ricavi da abbonamento e fidelizzazione come flusso di ritorno.

Lo schema è costruito nel VSS Editor in quattro passaggi: il confine con un flusso esterno in ingresso (investimenti e stipendi) e i flussi esterni in uscita verso gli utenti; sette convertitori; flussi denominati in base agli elementi di valore che trasportano; ed elementi di anti-valore. Le quantità restano vuote fino alla prima sessione di stima.

Consideriamo una release ipotetica: una funzione di promemoria pensata per ridurre gli appuntamenti mancati. Prima dello sviluppo, il product owner registra il valore pianificato per elemento (tempo risparmiato, minori prenotazioni mancate, effetto atteso sulla retention). Dopo un periodo di osservazione concordato, l'analisi di prodotto e un campione di utenti aziendali forniscono il valore realizzato, e il team registra l'anti-valore realizzato: una release in ritardo, un difetto che ha inviato promemoria duplicati, un carico aggiuntivo sull'API gateway. La differenza è la resistenza di questa release. Il difetto e il carico sul gateway si trovano anche su flussi che servono altri scenari, quindi vengono assegnati anche ai nodi condivisi. Un trimestre dopo, il valore retrospettivo registra se la retention sia cambiata davvero. In un'applicazione reale, le quantità proverrebbero dalle sessioni descritte di seguito.

10 Come metterlo in pratica

10.1 Chi stima e chi convalida

La regola di Æilus del post del 2025 è breve: il valore in uscita di un processo deve essere valutato da chi lo consuma, e qualcun altro deve verificare tale valutazione. Applicata alla consegna, essa dà una chiara suddivisione.

• Il valore pianificato è stimato dal mittente. Per le ipotesi è il product owner, che agisce come Responsabile del Trasformatore di Valore (VTO) del trasformatore di prodotto. Per il trasformatore di sviluppo è il team leader come VTO.
• Il valore realizzato è interpretato dal destinatario: gli utenti, osservati tramite l'analisi di prodotto o web, e l'azienda per il flusso di ritorno. La presentazione propone, come misura temporanea, che l'analisi di prodotto rappresenti il lato utente finché non sia stabilita una convalida diretta.
• La convalida dell'interpretazione è svolta da una seconda parte: il Responsabile del Sistema di Valore (VSO), che risponde della sostenibilità a livello di sistema, oppure un Responsabile del Flusso per un flusso critico.
• L'integrità metodologica è sostenuta da un Æilus Master (nella presentazione, un Æilus champion ricoperto da un project manager), che prepara i report sulla consegna del valore, sul piano rispetto al consuntivo e sulla resistenza del flusso.

10.2 Cadenza

Æilus non prescrive un calendario. Una cadenza minima per un team di consegna, coerente con gli eventi raccomandati dalla metodologia, è la seguente.

• Per ogni backlog refinement: il valore pianificato è assegnato ai nuovi elementi, usando il registro degli elementi.
• Per ogni release, dopo il periodo di osservazione: valore e anti-valore realizzati sono registrati e convalidati; una breve retrospettiva sul valore discute lo scarto.
• Mensilmente o ogni trimestre: una Revisione della Resistenza del Flusso sullo schema, inclusi i nodi condivisi; valore retrospettivo per gli elementi rilasciati in precedenza.
• Ogni trimestre o in caso di cambiamento strutturale: una Revisione del Sistema di Valore di confini, trasformatori e dipendenze, con il file dello schema aggiornato e versionato.

10.3 Disciplina

Ogni artefatto richiede un responsabile, un ciclo di aggiornamento e uno scopo decisionale; altrimenti genera anti-valore attraverso il costo di manutenzione e la falsa sicurezza. Per questo metodo gli scopi decisionali sono la priorità del backlog, l'allocazione delle risorse condivise, la tempistica delle release e l'investimento nei nodi condivisi. La crescita del valore pianificato è ammissibile solo quando la capacità del team di realizzarlo è confermata (P9). Scalare il valore pianificato più rapidamente del valore realizzato è la modalità di guasto descritta da T16.

11 Limiti e cosa richiederebbe uno studio empirico

Questo articolo è concettuale e non è stato verificato su dati misurati. Ne derivano diversi limiti.

• Qualità della stima. I valori in Æ sono interpretazioni la cui affidabilità dipende dagli stimatori e dalla loro calibrazione.
• Commensurabilità parziale. Tempo risparmiato, ricavi e fiducia sono solo parzialmente commensurabili (A13). Esprimerli in un'unica valuta richiede una Politica di Aggregazione del Valore, che questo articolo presuppone ma non definisce.
• Attribuzione. Il valore realizzato deriva spesso da più release e da fattori esterni; lo schema mostra la struttura ma non può isolare il contributo di una singola release.
• Flussi nascosti. Se lo schema non riesce a spiegare la stabilità o il declino osservati del sistema, esistono flussi latenti o il confine è sbagliato (T9). Uno schema è un'ipotesi sulla struttura e deve essere rivisto.
• Costo del metodo. Le sessioni che non producono decisioni trasformano il metodo stesso in anti-valore.

Uno studio empirico richiederebbe, come minimo: diversi team di consegna che applichino il metodo per un periodo abbastanza lungo da registrare il valore retrospettivo; un registro degli elementi stabile e una politica di aggregazione concordati prima della raccolta dei dati; una convalida indipendente del valore realizzato da parte dei destinatari anziché dei team; la raccolta parallela delle metriche di consegna convenzionali, in modo da poter esaminare la relazione tra tali metriche e il valore realizzato; e un confronto tra le decisioni prese con e senza lo schema. Solo uno studio simile potrebbe mostrare se la prioritizzazione basata sul valore modifichi il valore consegnato, e a quali condizioni.

12 Conclusione

Le metriche di consegna descrivono come il lavoro si muove in una pipeline, non che cosa abbia cambiato per i suoi destinatari; secondo la VMT non possono farlo, perché il valore è contestuale, si realizza solo nell'uso, e il valore pianificato e quello realizzato divergono. Lo Schema del Sistema di Valore, come implementato nel VSS Editor, permette ai team software di disegnare il ciclo del valore di prodotto dall'ipotesi al valore realizzato e di nuovo all'azienda. Registrare il valore pianificato, realizzato e retrospettivo per ogni release trasforma il ciclo in una misurazione: resistenza e dispersione diventano visibili, i nodi condivisi sono valutati su ogni flusso che servono, e i team leader ottengono come feedback il valore consegnato, la priorità basata sul valore e il costo del ritardo e degli errori. Il metodo resta onesto solo se il confine del sistema è dichiarato, i destinatari convalidano il valore realizzato e ogni artefatto serve a una decisione. Se nella pratica migliori il valore consegnato è una questione empirica che questo articolo imposta ma a cui non risponde.

Riferimenti bibliografici

• 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 (in Russian). 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.