Metriche utili (e inutili) per capire se il team sta migliorando

(ovvero: come misurare senza diventare schiavi dei numeri)

C’è stato un periodo in cui pensavo che le metriche fossero la soluzione.

Avevamo un team in crescita, il backlog pieno, la sensazione costante di rincorrere qualcosa.
Come spesso succede, la domanda era sempre la stessa:

“Stiamo migliorando oppure stiamo solo correndo di più?”

E come spesso succede… quando non sai rispondere, inizi a misurare.

All’inizio sembra tutto bellissimo: dashboard, grafici, trend mese su mese, report che fanno molto “azienda seria”.
Poi succede la prima cosa strana:

• il numero di ticket chiusi sale
• la velocità sembra migliorare
• le release aumentano

…eppure i clienti iniziano a lamentarsi di più.
In produzione compaiono regressioni.
Il supporto diventa nervoso.
Il team è sempre più “stanco”.

È stato lì che ho capito una cosa molto semplice (e un po’ fastidiosa):

Le metriche non mentono.
Ma possono raccontarti la storia sbagliata.

Le metriche non sono la verità: sono una lente

Una metrica non è una sentenza.
È una prospettiva.

Ti fa vedere qualcosa meglio… e allo stesso tempo ti rende cieco su qualcos’altro.
Ed è per questo che molte organizzazioni finiscono per farsi male con i numeri:
non perché misurano troppo, ma perché credono troppo.

Se tratti una metrica come “la realtà”, prima o poi andrai contro un muro.

La trappola invisibile: misurare cambia il comportamento

Qui arriva la parte che molti ignorano:
una metrica non serve solo a misurare.

Una metrica è anche un incentivo.

Appena inizi a misurare una cosa, stai dicendo al team:

“Questa cosa conta.”

E il team – giustamente – inizierà a ottimizzarla.

È normale. È umano.
Ed è anche il motivo per cui succedono fenomeni tipo:

• misuri “ticket chiusi” → aumentano i ticket micro-spezzati
• misuri “velocity” → aumentano scorciatoie e debito
• misuri “commit” → aumentano commit inutili
• misuri “ore” → aumentano le ore, non il valore

Non perché il team ti vuole fregare.
Perché le persone sono intelligenti: capiscono cosa vuoi prima ancora che tu lo dica.

E qui si incastra una regola famosa (e crudele):

Quando una misura diventa un obiettivo, smette di essere una buona misura.

Il mio primo errore: cercare “la dashboard perfetta”

A un certo punto avevamo “tutto”:

• grafici su Jira
• report su Git
• numeri su CI
• percentuali ovunque

Eppure… non riuscivamo a prendere decisioni migliori.

Era come guardare i parametri del motore mentre la macchina si spegne,
e pensare che il problema sia “non abbastanza dati”.

In realtà il problema era un altro:

Avevamo metriche.
Non avevamo diagnosi.

È la differenza tra:

• osservare il termometro
• capire perché hai la febbre

Il punto non è “misurare”: è leggere nel contesto

Le metriche senza contesto sono come una radiografia senza medico:
può essere utile, ma può anche spaventarti per niente.

Esempio pratico: “stiamo andando più veloci”

Scenario:

• ticket chiusi: +30%
• velocità “apparente”: +20%
• tempo medio per task: scende

Sembra miglioramento, no?

Poi guardi la realtà:

• incidenti in produzione aumentati
• regressioni più frequenti
• supporto in allarme
• persone che lavorano “sempre un po’ troppo”

Quello che stai osservando non è performance.
È pressione.

E la pressione in ingegneria ha un effetto sempre uguale:

• nel breve periodo ti fa sembrare veloce
• nel medio periodo ti rende fragile
• nel lungo periodo ti rompe

Il trucco anti-falsi segnali: segmenta il lavoro

Uno degli errori più comuni è misurare tutto nello stesso calderone.

“Cycle time medio” su cosa?

• feature?
• bugfix?
• refactor?
• incident?

Sono universi diversi.

Misurarli insieme produce una statistica che sembra utile…
ma in realtà è solo una media fra mele e camion.

Quindi, se vuoi evitare di mentire a te stesso senza volerlo:

Segmenta sempre le metriche per tipologia di lavoro.

Le metriche sane misurano il sistema, non le persone

Se dovessi riassumere il criterio “CTO senior” in una frase:

Le metriche utili non dicono “chi è lento”.
Dicono “dove il sistema crea attesa”.

Le metriche che funzionano bene sono quasi sempre metriche di flusso e stabilità.

Perché?
Perché la maggior parte dei problemi non è “la produttività”.
È il sistema che produce attrito:

• troppe dipendenze
• code lunghissime (queue time)
• review lente
• scope instabile
• priorità che cambiano ogni 2 giorni
• deploy difficili
• CI fragile
• incidenti ripetitivi

E tutto questo non lo vedi con “quanti ticket hai chiuso”.

Lo vedi osservando il flusso.

Il vero miglioramento ha un suono preciso

Un team che migliora davvero non è quello che “fa di più”.
È quello che:

• termina le cose con meno attesa
• rilascia con meno paura
• recupera più velocemente quando sbaglia
• accumula meno debito
• non dipende dagli eroi
• resta sostenibile nel tempo

Questa è la differenza tra correre e diventare migliori.

La tirannia delle metriche: quando tutto diventa controllo

Questo è il punto più delicato, perché è qui che si rompe la fiducia.

Succede quando le metriche vengono usate così:

• come arma in un meeting
• come confronto fra persone
• come KPI individuale
• come “motivazione” (leggi: pressione)

Da quel momento, il gioco è finito.

Perché appena una metrica diventa giudizio:

• i dati diventano falsi
• il team diventa difensivo
• le conversazioni diventano politiche

E il paradosso è questo:

Più usi metriche per controllare, meno diventano affidabili.

La via sana invece è l’opposto:

Metriche come strumenti di coaching e miglioramento continuo.

Le metriche devono generare domande, non verdetti.

• “Dove perdiamo tempo?”
• “Dove il flusso si blocca?”
• “Che cosa rende rischiosa una release?”
• “Cosa ci costringe sempre a fare hotfix?”
• “Che tipo di lavoro ci consuma di più?”

Una mini-playbook per introdurre metriche senza fare danni

Se vuoi farlo in modo pragmatico (e senza ansia da dashboard):

1. Parti da una domanda reale
   “Perché rilasciamo lentamente?”
   “Perché i bug arrivano sempre tardi?”

2. Scegli 2-3 metriche max
   Poche, osservabili, con effetto immediato

3. Guardale come trend, non come target
   Il numero assoluto conta poco. Conta la direzione.

4. Discutile con il team
   Le metriche non sono un report per il management.
   Sono un linguaggio comune per migliorare.

5. Se non ti aiutano a decidere: buttale
   Una metrica inutile è rumore e distrazione.

Lista di metriche consigliate (quelle che consiglio davvero)

Qui sotto trovi una lista divisa per obiettivo.
Non serve usarle tutte: scegli quelle che rispondono alle tue domande.

1) Flow / Delivery (stiamo consegnando meglio?)

Metriche principali

• Lead Time (da idea a produzione)
• Cycle Time (da work started a done)
• WIP (Work in Progress) (quante cose aperte contemporaneamente)
• Queue Time (tempo in attesa tra gli step)
• Throughput (quante cose finiscono in una finestra)

Come interpretarle

• Cycle time alto spesso = task grandi, review lente, dipendenze
• Queue time alto spesso = attese di processo (handoff, priorità instabili)
• WIP alto quasi sempre = multitasking e context switching

2) Qualità / Stabilità (stiamo rilasciando in modo sicuro?)

Metriche principali

• Change Failure Rate (quante release causano incident/rollback)
• MTTR (tempo medio di recovery)
• Incident Frequency (frequenza incidenti)
• Rework Rate (quante cose tornano indietro / si rifanno)

Come interpretarle

• se rilasci più spesso e failure rate non sale → stai maturando
• MTTR è una delle metriche più “vere”: misura resilienza, non solo qualità

3) CI/CD (il sistema di delivery è sano?)

Metriche principali

• Build Time (durata pipeline)
• Pipeline Failure Rate (quanto spesso fallisce la CI)
• Time to Green (tempo medio per riparare una pipeline rotta)
• Time Merge → Deploy (quanto tempo passa tra codice e produzione)

Come interpretarle

• pipeline lenta = batch più grandi = più rischio
• pipeline fragile = team che perde fiducia nel processo

4) Sostenibilità (miglioriamo senza bruciare la squadra?)

Metriche (spesso qualitative)

• carico on-call
• interruzioni / context switching (anche stimato)
• onboarding time
• dipendenza da singole persone (bus factor)
• lavoro “non pianificato” vs pianificato

Come interpretarle

• se l’urgenza domina, il sistema non è sotto controllo
• se pochi “salvano sempre la giornata”, stai costruendo un’organizzazione fragile

5) Customer impact (stiamo facendo cose che contano?)

Qui non esistono metriche universali, ma puoi misurare:

• bug segnalati dai clienti / ticket supporto
• adozione funzionalità (quando misurabile)
• tempo di risposta a problemi reali
• volume di “work non previsto” causato dal prodotto

Principio guida

Output non è valore.
Valore è ciò che resta quando il lavoro è finito e l’utente lo usa davvero.

Bonus: metriche che eviterei quasi sempre

• story points completati
• commit count
• righe di codice
• ore lavorate
• “produttività” individuale
• velocity come obiettivo

Non perché sono “sempre sbagliate”, ma perché quasi sempre:

• creano comportamento sbagliato
• diventano teatro
• ti danno una sicurezza falsa

Il modo corretto di usarle

Le metriche non servono per controllare le persone.
Servono per osservare un sistema complesso da più angolazioni.

Quando le usi bene succede una cosa bellissima: smetti di inseguire colpe, e inizi a migliorare leve.

E alla fine, l’unica cosa che conta è questa:

Un team sta migliorando quando rilascia con più fiducia,
recupera più velocemente quando sbaglia,
e costruisce valore senza consumarsi.