productivity_cover.png
Gestione di Progetti

domenica, 09 febbraio 2025

Come misurare la produttività del tuo team e come migliorarla

Una domanda che molti leader hanno in mente è: come misurare la produttività del mio team e, soprattutto, come aiutarlo a essere più produttivo senza creare una pressione eccessiva? In questo testo condividerò alcuni concetti e pratiche che utilizzo per organizzare meglio i team di sviluppo, aumentare la prevedibilità delle consegne e raggiungere buoni risultati in meno tempo.

Prima di iniziare, ridurrò un po’ l’ambito di questo articolo — e questo sarebbe già il mio primo consiglio: la produttività deve essere analizzata all’interno di un contesto chiaro. Qui lavorerò con le storie utente all’interno di una board Scrum, perché il mio focus è sui team di sviluppo software, dove board come Jira, Azure DevOps, ClickUp, Monday.com e Asana sono ampiamente utilizzate. È proprio in questo punto che una piattaforma come Saint Jude può aiutare: collegandosi a questi strumenti e trasformando i dati della board in indicatori di produttività, colli di bottiglia, rischi e performance di delivery. Allora iniziamo:

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.

Per iniziare a misurare la produttività, dobbiamo confrontare la performance del team con un riferimento, sia quantitativo sia qualitativo. Alcuni esempi che utilizzo spesso sono:

  • L’obiettivo dello sprint è stato raggiunto?
  • L’obiettivo della PI è stato rispettato?
  • Quali KPI sono stati raggiunti e quali sono rimasti sotto le aspettative?

A partire da questi confronti, possiamo capire la produzione reale del team rispetto a ciò che era previsto. Questo è il primo passo per identificare se siamo in linea con il piano, sopra le aspettative o al di sotto di quanto necessario. Con Saint Jude, questa analisi può essere fatta in modo consolidato, confrontando progetti, team e periodi diversi per mostrare con maggiore chiarezza dove la produttività sta evolvendo e dove esistono punti di attenzione.

Aspettativa vs realtà
Aspettativa vs realtà

Disclaimer: fai attenzione all’eccesso di pressione per migliorare metriche che sono già sane. È meglio completare un viaggio a 100 km/h piuttosto che andare a 180 km/h e rompere il motore a metà strada.

Auto rotta - istockphoto
Auto rotta - istockphoto

Fatto il disclaimer, presenterò alcuni metodi che utilizzo per misurare la produttività di un team:

Misurare il tuo team

Misurazione della divisione delle attività per tipo: storie utente, manutenzione ed enabler

Questa misurazione consiste nel confrontare la proporzione tra i diversi tipi di attività presenti nella board. Le storie utente rappresentano normalmente l’avanzamento funzionale del prodotto. Le attività di manutenzione aiutano a correggere problemi o a preservare l’esperienza dell’utente. Gli enabler, invece, creano la base tecnica necessaria per scalare il prodotto, migliorare architettura, infrastruttura o processi interni.

Quando analizziamo questo equilibrio, possiamo capire se il team sta davvero facendo avanzare il prodotto oppure se sta spendendo troppa energia nel correggere problemi, risolvere dipendenze tecniche o mantenere qualcosa che dovrebbe essere più stabile. Di seguito lascio un esempio di come verificare questa distribuzione:

Distribuzione del flusso
Distribuzione del flusso

Gestione delle attività nella board e velocità con cui vengono consegnate

Il punto qui è confrontare le consegne all’interno di periodi chiusi, come sprint, PI, mese o trimestre. In questo modo possiamo capire quanto il team tende a consegnare utilizzando l’unità di misura adottata: ore, punti Fibonacci, giorni o qualsiasi altro riferimento usato dal team. Con questo storico, diventa più semplice stimare le consegne successive, anche sapendo che stimare il software avrà sempre un certo grado di incertezza.

Una soluzione come Saint Jude può aiutare proprio in questo monitoraggio, consolidando la velocità di delivery tra diverse board, progetti e strumenti. Così la leadership non dipende solo da report manuali per capire se il team sta guadagnando prevedibilità o se esistono variazioni importanti tra ciò che è stato pianificato e ciò che è stato consegnato.

Velocità del flusso
Velocità del flusso

Tempo impiegato – dall’ingresso della task fino alla sua uscita

Con questa misurazione possiamo capire quanto tempo una task o una feature impiega dal momento in cui inizia a essere lavorata fino alla sua consegna. Questa analisi diventa ancora più importante quando viene collegata al tipo di attività. Per esempio: le attività di manutenzione richiedono in media 5 giorni per essere concluse, mentre le storie utente richiedono 3 giorni.

Questo tipo di confronto aiuta a identificare dove il team sta perdendo tempo, quali tipi di richieste consumano più effort e dove esiste un’opportunità per migliorare il flusso di delivery. Di seguito, un esempio della relazione tra quantità di storie utente eseguite e quantità di giorni.

Flusso medio
Flusso medio

Quantità di elementi attivi

Questa metrica mostra quanti elementi sono attivi nella board. La considero una delle misurazioni più importanti per un leader. Se hai 5 persone nel team e 10 elementi attivi, probabilmente esistono attività ferme, mal distribuite o in attesa di informazioni per avanzare.

Inoltre, osservando correttamente la board, possiamo capire in quale fase del processo si trova ogni elemento: analisi, sviluppo, test, revisione o completamento. Con Saint Jude, questo tipo di visione può essere consolidato in dashboard per mostrare eccesso di WIP, colli di bottiglia per fase e possibili rischi di ritardo prima che diventino un problema più grande.

Carico del flusso
Carico del flusso

Efficienza nell’esecuzione delle attività

In termini semplici, questa metrica aiuta a capire quanto tempo una task rimane realmente in esecuzione e quanto tempo resta ferma tra una fase e l’altra del processo. Per esempio: una task può uscire dallo sviluppo, ma rimanere per giorni in attesa dei test. Questo tempo di attesa riduce l’efficienza del flusso e impatta direttamente la prevedibilità della consegna.

Di seguito c’è il calcolo utilizzato per comprendere questa metrica. Quando il risultato è vicino a 1, significa che c’è poco spreco di tempo nel flusso.

Tempo del flusso = tempo attivo – tempo in attesa

Efficienza del flusso = tempo attivo / tempo del flusso

E come migliorare la produttività del team

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

Manutenzione del sistema VS Storie utente VS Enabler

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

  • La storia utente significa andare avanti
  • L’enabler significa andare di lato
  • La manutenzione significa andare indietro

Mi spiego meglio:

Le attività di manutenzione spesso compaiono quando il processo non è stato ben definito, quando mancavano informazioni o quando la consegna precedente non aveva abbastanza chiarezza. Qui entra un altro testo che ho scritto: “Perché una solida Definizione di Ready e Definizione di Done porta chiarezza alle tue attività”. Le correzioni nascono spesso da una mancanza di comprensione di scenari, personas, regole di business o criteri di accettazione. Per risolvere questo problema, è necessario migliorare processi, comunicazione e chiarezza delle attività, anche se all’inizio questo può sembrare richiedere più tempo.

Task con una chiarezza incredibile!
Task con una chiarezza incredibile!

Gli enabler sono molto importanti, perché creano la struttura tecnica del prodotto. Tuttavia, in generale, rappresentano fondamenta, ambienti, architettura, integrazioni e miglioramenti interni. A seconda del contesto, parte di questo lavoro può anche essere accelerata con supporto esterno, così che il team principale possa mantenere il focus sulle consegne del prodotto.

Le storie utente, invece, sono le attività che generalmente fanno avanzare il prodotto in modo visibile per il cliente e per il business. Più chiara è la storia e più rapidamente viene conclusa con qualità, maggiore sarà l’evoluzione del progetto.

Quanto il team sta consegnando per periodo di tempo

Qui entriamo nel confronto tra stima e realtà. Personalmente, apprezzo molto il planning poker perché non aiuta solo ad arrivare a una stima, ma aumenta anche la chiarezza su ciò che deve essere fatto. A partire da questo, possiamo analizzare i punti, le ore o i giorni consegnati negli sprint, nelle PI, nei mesi o nei trimestri precedenti e usare questo storico come base per comprendere la reale capacità del team.

Questa è una delle analisi in cui Saint Jude può generare valore per PMO e leadership, perché permette di confrontare pianificato versus realizzato, monitorare variazioni di produttività e identificare quali team o progetti sono più prevedibili nel tempo.

Tempo di consegna di un tipo specifico di attività

Qui, la divisione delle attività per tipo è essenziale: storia utente, manutenzione ed enabler. Possiamo usare il tempo medio di ogni tipo di attività per pianificare meglio uno sprint, una PI, un mese o un trimestre e stimare quanto il progetto tenderà a evolvere.

In determinati periodi, può avere senso concentrarsi maggiormente su un tipo di attività. Per esempio: uno sprint più orientato a ridurre la manutenzione, una PI focalizzata sugli enabler tecnici o un ciclo con una maggiore concentrazione di storie utente per accelerare una consegna strategica.

Sprint con attività di tipi diversi
Sprint con attività di tipi diversi

Tempo di attesa per il passaggio delle attività all’interno del team

L’obiettivo qui è semplice: identificare in quale fase del processo le attività stanno rimanendo ferme e correggere questo collo di bottiglia. Tuttavia, questa analisi porta spesso a una decisione esecutiva importante:

Spendo tempo o denaro?

In generale, le attività rimangono ferme perché non ci sono abbastanza persone per dare continuità al flusso. In questo caso, stiamo risparmiando denaro, ma perdendo tempo. Aggiungendo più persone, lo scenario può invertirsi: aumentiamo il costo, ma riduciamo il tempo di attesa. Anche così, se il flusso non è ben equilibrato, alcuni professionisti possono restare fermi in attesa della conclusione delle fasi precedenti. Esempio: il QA in attesa che lo sviluppo termini.

Disclaimer: le persone sono monotask. Se sposti qualcuno su un’altra attività, quella persona tornerà allo sprint solo dopo aver concluso la nuova domanda, generando più tempo di attesa e perdita di focus.

Quanti elementi attivi esistono nella board?

Quando non c’è chiarezza su ciò che deve essere fatto, molte attività iniziano ad apparire come attive nella board. Questo accade perché il professionista prende una task, non capisce cosa deve essere fatto, inizia a chiedere ad altre persone e, mentre aspetta una risposta, comincia un’altra attività.

Torno di nuovo al testo che ho scritto: “Perché una solida Definizione di Ready e Definizione di Done porta chiarezza alle tue attività”. La regola dovrebbe essere semplice: hai preso la task e non l’hai capita? Chiedi al team. Se nessuno sa spiegarla, probabilmente quella task non dovrebbe essere nello sprint.

Con dashboard di carico di lavoro ed elementi attivi, Saint Jude aiuta a visualizzare questo problema in modo più esecutivo, mostrando quando la board ha un eccesso di attività aperte, dove c’è accumulo di lavoro e quali progetti possono perdere produttività per mancanza di chiarezza, focus o prioritizzazione.

Soltanto con 3 persone!
Soltanto con 3 persone!

Arrivo alla fine di questo articolo e spero che ti abbia aiutato a pensare alla produttività in modo più strutturato. Misurare un team non significa solo chiedere più consegne, ma comprendere contesto, flusso, capacità, colli di bottiglia e qualità delle informazioni che arrivano nella board.

Con le metriche corrette — e con strumenti che trasformano i dati in visibilità, come Saint Jude — leader, PMO e team possono prendere decisioni migliori, migliorare la prevedibilità e aumentare la produttività senza dipendere solo da percezioni o report manuali.

Vuoi continuare questa conversazione? Metti like al testo, commenta su LinkedIn o condividilo sui tuoi social.

A presto!

Erik Scaranello