Strumenti come Jira, Azure DevOps, ClickUp, Monday.com e Asana contengono già gran parte dei dati necessari. Il problema è che avere i dati nella board non significa necessariamente riuscire a trasformarli in informazioni utili per prendere decisioni.

È proprio qui che Saint Jude può aiutare: collegandosi agli strumenti di gestione e trasformando i dati operativi in indicatori di produttività, capacità, rischi, costi, colli di bottiglia e prevedibilità dei progetti.

Cosa sono gli indicatori di produttività?

Gli indicatori di produttività sono metriche utilizzate per confrontare i risultati ottenuti con il tempo, le risorse e la capacità disponibili.

In un progetto software possono aiutarci a rispondere a domande come:

• Quanto riesce a consegnare il team in uno sprint o in un mese?
• Quanto tempo impiega una task per essere completata?
• Quante attività vengono gestite contemporaneamente?
• Quanto tempo una task rimane realmente in lavorazione?
• Quanto tempo rimane invece in attesa tra una fase e l’altra?
• Quanto il pianificato è vicino al realizzato?
• La prevedibilità del team sta migliorando o peggiorando?

Non esiste un solo KPI di produttività capace di raccontare tutta la situazione. Per questo preferisco utilizzare diversi indicatori insieme, così da comprendere il comportamento complessivo del team e del processo.

Essere produttivi sì, ma rispetto a cosa?

Il mio primo argomento inizia con una conversazione tratta dal libro Alice nel Paese delle Meraviglie, di Lewis Carroll:

- Quale strada devo prendere?

- Dove vuoi andare?

- Non lo so.

- Allora non importa.

Lo stesso ragionamento vale per la produttività: prima di scegliere un indicatore, dobbiamo capire rispetto a quale riferimento vogliamo misurare il risultato.

Per iniziare a misurare la produttività del team, possiamo utilizzare riferimenti quantitativi e qualitativi. Alcuni esempi che utilizzo spesso sono:

• L’obiettivo dello sprint è stato raggiunto?
• L’obiettivo della PI è stato rispettato?
• Il pianificato è vicino al realizzato?
• Quali KPI sono stati raggiunti?
• Quali indicatori sono rimasti sotto le aspettative?
• La capacità di delivery sta aumentando, diminuendo o rimanendo stabile?

Attraverso questi confronti iniziamo a capire la produttività reale del team rispetto a ciò che ci aspettavamo.

È il primo passo per capire se siamo in linea con il piano, sopra le aspettative oppure al di sotto di quanto necessario.

Con Saint Jude questa analisi può essere consolidata tra progetti, team e periodi differenti. Invece di osservare una singola board, PMO e leadership possono capire quali team stanno migliorando, dove la prevedibilità sta diminuendo e quali progetti richiedono attenzione.

Una precisazione importante: attenzione alla pressione eccessiva per migliorare metriche che sono già sane.

È meglio arrivare alla fine di un viaggio a 100 km/h piuttosto che andare a 180 km/h e rompere il motore a metà strada.

Un indicatore dovrebbe aiutare il team a lavorare meglio, non diventare semplicemente uno strumento per chiedere sempre di più.

Quali indicatori di produttività utilizzare?

Esistono molti KPI e indicatori di performance. Nei team di sviluppo software, però, alcune metriche sono particolarmente utili perché possono essere ricavate direttamente dal flusso di lavoro.

Queste sono alcune delle metriche che considero più interessanti:

• Distribuzione del lavoro per tipo di attività;
• Numero di consegne per periodo;
• Throughput;
• Cycle time;
• WIP - Work in Progress;
• Tempo di attesa;
• Efficienza del flusso;
• Pianificato rispetto al realizzato.

1. Distribuzione del lavoro per tipo di attività

Una delle prime metriche di produttività che mi piace osservare è come viene distribuita la capacità del team.

In un progetto software possiamo, per esempio, dividere il lavoro tra:

• User story;
• Manutenzione e correzioni;
• Enabler e attività tecniche.

Le user story rappresentano normalmente l’avanzamento funzionale del prodotto. Le attività di manutenzione servono a correggere problemi o preservare l’esperienza dell’utente. Gli enabler, invece, creano le fondamenta tecniche necessarie per architettura, infrastruttura, sicurezza, integrazioni o evoluzioni future.

Analizzando questa distribuzione possiamo capire dove viene realmente utilizzata la capacità del team.

Un team può sembrare estremamente occupato e, allo stesso tempo, far avanzare molto poco il prodotto perché gran parte della capacità viene utilizzata per correggere errori, gestire debito tecnico o mantenere sistemi esistenti.

Per questo motivo, contare semplicemente quante task vengono completate non è sufficiente per misurare la produttività.

2. Throughput e velocità di delivery

Un altro indicatore importante è capire quanto il team riesce a consegnare all’interno di periodi comparabili, come sprint, PI, mese o trimestre.

Possiamo utilizzare story point, numero di elementi, ore o un’altra unità adottata dal team. La cosa importante è mantenere una misura coerente nel tempo.

Questo storico ci permette di rispondere a una domanda fondamentale:

Qual è la reale capacità di delivery di questo team?

Dopo alcuni sprint iniziamo a vedere dei pattern e possiamo utilizzare lo storico per migliorare le previsioni future.

Una precisazione: eviterei di confrontare semplicemente la velocity o gli story point di team differenti. Ogni team può stimare e organizzare il lavoro in modo diverso. È molto più interessante osservare l’evoluzione dello stesso team nel tempo.

Saint Jude può aiutare proprio in questo tipo di analisi, consolidando dati provenienti da diverse board e diversi periodi per mostrare variazioni tra pianificato e realizzato e rendere più visibili capacità e prevedibilità.

3. Cycle time: quanto tempo serve per completare una task?

Il cycle time indica quanto tempo passa dal momento in cui un’attività inizia a essere lavorata fino alla sua conclusione.

È uno degli indicatori di produttività più utili per comprendere la velocità reale del flusso.

L’analisi diventa ancora più interessante quando separiamo le attività per tipologia.

Per esempio:

• Le attività di manutenzione richiedono mediamente 5 giorni;
• Le user story richiedono 3 giorni;
• Gli enabler tecnici richiedono 8 giorni.

Queste differenze ci aiutano a capire quali tipi di lavoro consumano più tempo e quali hanno maggiore impatto sul cronoprogramma.

Possiamo anche scoprire che una determinata attività non richiede molto tempo perché è complessa, ma perché rimane ferma per diversi giorni tra una fase e l’altra.

4. WIP: quante attività sono attive contemporaneamente?

WIP significa Work in Progress e rappresenta la quantità di attività che vengono lavorate contemporaneamente.

Lo considero uno degli indicatori più importanti per un leader.

Se hai cinque persone nel team e dieci, quindici o venti attività risultano attive, è molto probabile che alcune siano ferme, bloccate, distribuite male oppure in attesa di informazioni.

Più lavoro iniziato non significa necessariamente maggiore produttività.

Spesso significa esattamente il contrario: maggiore cambio di contesto, perdita di focus e aumento del tempo necessario per terminare ogni attività.

Oltre al numero totale, è importante capire dove si stanno accumulando gli elementi:

• Analisi;
• Sviluppo;
• Code review;
• Test;
• Validazione;
• Completamento.

Con Saint Jude questo tipo di informazione può essere consolidato in dashboard capaci di evidenziare eccesso di WIP, colli di bottiglia e rischi di ritardo prima che diventino visibili nel cronoprogramma esecutivo.

5. Efficienza del flusso: quanto tempo è lavoro e quanto è attesa?

Una task può richiedere dieci giorni per essere consegnata senza che qualcuno abbia lavorato su quella task per dieci giorni.

Potrebbe, per esempio, trascorrere:

• 2 giorni in sviluppo;
• 3 giorni in attesa di code review;
• 1 giorno in correzioni;
• 4 giorni in attesa dei test.

In questo scenario, gran parte del tempo totale non è stato utilizzato per produrre qualcosa: è stato tempo di attesa.

Per questo motivo, l’efficienza del flusso ci aiuta a distinguere tempo attivo e tempo totale.

Tempo totale del flusso = tempo attivo + tempo di attesa

Efficienza del flusso = tempo attivo / tempo totale del flusso × 100

Più alta è la percentuale di tempo attivo, più efficiente tende a essere il flusso. Un valore basso può invece indicare code, dipendenze, blocchi o colli di bottiglia tra le diverse fasi.

Questo è anche un buon esempio del perché misurare la produttività non dovrebbe significare semplicemente misurare le persone. Molto spesso il problema è nel processo.

Come migliorare la produttività del team

Dopo aver misurato, arriva la parte più importante: capire cosa fare con gli indicatori.

Nel corso degli anni nella gestione di progetti ho notato alcuni schemi che, quando vengono corretti, aumentano la velocità delle consegne, migliorano la prevedibilità e riducono il time-to-market.

Analizza quanto lavoro diventa prodotto, manutenzione o enabler

Il mio punto di vista — forse un po’ polemico — è:

• Una user story significa andare avanti;
• Un enabler significa preparare il percorso;
• La manutenzione significa recuperare terreno.

Questo non significa che manutenzione ed enabler siano negativi. Entrambi sono necessari.

Il problema inizia quando consumano una parte eccessiva della capacità disponibile.

Le attività di manutenzione possono nascere perché un processo non è stato definito bene, mancavano informazioni o la consegna precedente non aveva abbastanza chiarezza.

Qui entra un altro articolo che ho scritto: “Definition of Done e Definition of Ready: cosa sono, differenze ed esempi”.

Molte correzioni nascono da una comprensione incompleta di scenari, personas, regole di business, dipendenze o criteri di accettazione.

Investire più tempo nella chiarezza prima dello sviluppo può sembrare più lento all’inizio, ma spesso evita giorni di rilavorazione successivamente.

Gli enabler sono altrettanto importanti perché creano la struttura tecnica necessaria all’evoluzione del prodotto: architettura, infrastruttura, sicurezza, ambienti, integrazioni e miglioramenti interni.

L’obiettivo è capire quale percentuale della capacità viene utilizzata in ogni tipologia di lavoro e se questa distribuzione è coerente con gli obiettivi del progetto.

Confronta pianificato e realizzato

Uno dei migliori KPI di produttività non è semplicemente quanto è stato consegnato, ma quanto di ciò che era stato pianificato è stato realmente consegnato.

Personalmente apprezzo molto il planning poker perché non serve soltanto a produrre una stima. La discussione necessaria per arrivare alla stima aumenta anche la chiarezza su ciò che deve essere fatto.

Successivamente possiamo analizzare story point, ore, task o giorni consegnati negli sprint, nelle PI, nei mesi o nei trimestri precedenti e utilizzare questo storico per comprendere la reale capacità del team.

Un team che pianifica 100 e consegna 95 in modo costante può essere molto più sano e prevedibile di un team che pianifica 150, consegna 70 in un ciclo e 140 in quello successivo.

Per PMO e leadership, questa è una delle analisi in cui Saint Jude può generare particolare valore: confrontare pianificato e realizzato, monitorare le variazioni tra periodi e identificare quali progetti stanno guadagnando o perdendo prevedibilità.

Analizza il cycle time per tipologia di attività

Non tutte le attività sono uguali.

User story, manutenzione ed enabler hanno caratteristiche differenti. Confrontare il cycle time di ogni categoria aiuta a migliorare le stime e identificare problemi specifici.

In alcuni periodi può anche essere utile modificare consapevolmente la distribuzione del lavoro.

Per esempio:

• Uno sprint dedicato maggiormente alla riduzione della manutenzione;
• Una PI concentrata sugli enabler tecnici;
• Un ciclo con più user story per accelerare una consegna strategica.

Riduci il tempo di attesa tra le fasi

Se una task richiede due giorni di sviluppo e cinque giorni di attesa prima dei test, probabilmente il principale problema di produttività non si trova nello sviluppo.

Si trova nella coda.

Per questo motivo misurare il tempo di attesa è importante quanto misurare il tempo di esecuzione.

Questa analisi porta spesso a una decisione esecutiva molto semplice:

Spendo tempo o denaro?

Le attività rimangono frequentemente ferme perché una determinata fase non possiede abbastanza capacità per accompagnare il resto del flusso.

Se abbiamo molti sviluppatori e pochi professionisti QA, per esempio, possiamo creare una coda crescente di lavoro in attesa di test.

Aggiungere capacità costa denaro. Non aggiungerla costa tempo.

L’obiettivo dell’indicatore è rendere questo trade-off visibile, così che la decisione sia consapevole.

Un altro punto importante: le persone non lavorano realmente su cinque attività complesse contemporaneamente. Quando qualcuno abbandona un’attività per rispondere a un’altra priorità, esiste un cambio di contesto. Più cambi di contesto abbiamo, maggiore tende a essere il tempo necessario per terminare il lavoro originale.

Controlla quante attività sono contemporaneamente attive

Quando manca chiarezza su ciò che deve essere fatto, il numero di attività attive tende ad aumentare.

Una persona prende una task, incontra un dubbio, chiede informazioni e rimane in attesa di una risposta. Nel frattempo, inizia un’altra attività.

Poi compare un’altra dipendenza e ne inizia una terza.

In poco tempo abbiamo molte attività “in progress”, ma poche che stanno realmente avanzando.

Torno ancora una volta a questo articolo: “Definition of Done e Definition of Ready: cosa sono, differenze ed esempi”.

La mia regola è semplice: hai preso la task e non è chiaro cosa bisogna fare? Chiedi al team. Se nessuno riesce a spiegare chiaramente cosa deve essere consegnato, forse quella task non è ancora pronta per entrare nello sprint.

Attraverso dashboard di carico di lavoro, WIP ed elementi attivi, Saint Jude aiuta a trasformare questo problema operativo in una visione manageriale: dove si sta accumulando il lavoro, quali progetti stanno perdendo fluidità e dove mancano chiarezza, focus o capacità.

Quali sono i principali KPI di produttività?

Se dovessi riassumere gli indicatori di produttività più utili per un team di sviluppo software, inizierei da questi:

• Pianificato vs realizzato: misura la prevedibilità del team;
• Throughput: indica quanti elementi vengono completati in un determinato periodo;
• Cycle time: misura quanto tempo serve per completare un’attività;
• WIP: indica quante attività vengono gestite contemporaneamente;
• Tempo di attesa: mostra quanto del flusso rimane fermo;
• Efficienza del flusso: confronta tempo attivo e tempo totale;
• Distribuzione per tipo di lavoro: mostra dove viene utilizzata la capacità;
• Variazione della capacità nel tempo: aiuta a capire se la produttività sta aumentando o diminuendo.

Nessuna di queste metriche dovrebbe essere analizzata isolatamente.

Un team può aumentare il throughput e contemporaneamente aumentare il rework. Può ridurre il cycle time semplicemente consegnando task più piccole. Può migliorare la velocity modificando il proprio metodo di stima.

Per questo motivo la produttività deve essere letta come un insieme di segnali.

Come Saint Jude aiuta a misurare la produttività dei progetti

Molte aziende possiedono già i dati necessari per calcolare questi indicatori.

Sono distribuiti tra Jira, Azure DevOps, ClickUp, Monday.com, Asana e gli altri strumenti utilizzati dai team.

La vera difficoltà è trasformare centinaia o migliaia di task in informazioni utili per chi deve prendere decisioni.

Saint Jude funziona come un livello di intelligence sopra questi dati e aiuta manager, PMO e leadership a monitorare:

• Produttività e capacità dei team;
• Pianificato rispetto al realizzato;
• Velocità e tempi di consegna;
• WIP e attività attive;
• Colli di bottiglia e task ferme;
• Rischi di ritardo;
• Costi e consumo delle risorse;
• Prevedibilità dei progetti.

L’obiettivo non è utilizzare i dati per controllare le persone.

È dare ai manager abbastanza visibilità per capire dove il progetto sta perdendo produttività, tempo e margine prima che il problema diventi visibile nei risultati finali.

Misurare la produttività significa capire il sistema, non soltanto il team

Arrivo alla fine di questo articolo con un concetto che considero più importante di qualsiasi formula.

Misurare la produttività non dovrebbe significare chiedere continuamente:

“Perché questa persona non ha consegnato di più?”

Molto spesso esistono domande migliori:

• Perché questa task è rimasta ferma?
• Perché abbiamo così tanto lavoro in progress?
• Dove si trova il collo di bottiglia?
• Perché pianifichiamo molto più di quanto riusciamo a consegnare?
• Quanto della nostra capacità viene utilizzato per la manutenzione?
• Dove stiamo generando rilavorazione?

È qui che gli indicatori di produttività iniziano realmente a generare valore.

Con le metriche corrette — e strumenti capaci di trasformare dati in visibilità, come Saint Jude — leader, PMO e team possono prendere decisioni migliori, aumentare la prevedibilità e migliorare la produttività senza dipendere soltanto da percezioni o report manuali.

Se il tuo team lavora da remoto o in modalità ibrida, ho scritto anche un articolo dedicato a questo problema: “Come monitorare la produttività dei team da remoto senza micromanagement”.

Vuoi continuare questa conversazione? Metti like al testo, commenta su LinkedIn oppure condividilo con qualcuno che sta cercando di capire meglio la produttività dei propri progetti.

A presto!

Erik Scaranello