Giornalismo utile per capire, gestire e far crescere un’impresa.
CercaUna guida per interpretare le metriche di flusso, produttività, qualità e business —e combinarle senza confondere attività con valore— nei team software.
Le metriche di sviluppo servono a rendere visibile il progresso, a individuare i colli di bottiglia e a orientare i miglioramenti. Non esiste un singolo indicatore che descriva le prestazioni di un team: è opportuno combinare misure di flusso, qualità e risultati di business, in base all'obiettivo che si intende comprendere.
Un dato isolato può indurre in errore. Ad esempio, consegnare più codice non dimostra di per sé che sia stato creato più valore, e una maggiore copertura dei test non garantisce che il prodotto sia privo di difetti. Le definizioni, il periodo di misurazione e il contesto devono essere mantenuti coerenti affinché i confronti siano utili.
È il tempo trascorso dal momento in cui viene richiesto o avviato un lavoro fino alla sua consegna. La definizione esatta del punto di inizio e di fine varia tra le organizzazioni; per questo motivo deve essere concordata prima di confrontare i risultati. Monitorare il lead time aiuta a rilevare ritardi tra le fasi e a valutare quanto tempo impiega il team per portare i cambiamenti a chi ne ha bisogno.
Misura quanto tempo impiega un elemento di lavoro dal momento in cui il team inizia a svilupparlo fino al suo completamento. A differenza del lead time, normalmente esclude l'attesa precedente l'inizio. Se si allunga, può essere utile indagare su blocchi, dipendenze o dimensioni dei task, anziché attribuire automaticamente il risultato alla velocità individuale di ogni sviluppatore.
In Scrum e in altri framework agili, la velocità rappresenta solitamente i punti storia o il lavoro stimato che un team completa durante uno sprint. È un riferimento interno per la pianificazione; non è un'unità universale di produttività. I punti dipendono dalla scala di stima di ciascun team, pertanto confrontare la velocità tra team può risultare fuorviante. Una variazione può anche essere dovuta a cambiamenti nell'ambito, nella composizione del team o nel metodo di stima.
Il WIP (work in progress) è la quantità di task avviati che non sono ancora terminati. Osservarlo consente di identificare accumuli e eccesso di lavoro simultaneo. Un volume elevato può coincidere con più cambi di contesto o attese, anche se il numero da solo non spiega la causa. I limiti di WIP, quando utilizzati, devono essere adattati al flusso e alle esigenze del team.
Indica quale percentuale del codice viene eseguita dai test automatizzati, in base allo strumento e al criterio utilizzati. È utile per localizzare aree con scarsa copertura, ma non misura direttamente se i test verificano i comportamenti importanti. Deve essere letta insieme ai risultati dei test, ai difetti rilevati e ai rischi del sistema.
Relaziona i difetti trovati a un'unità di dimensione o ambito, come una versione o un componente. Per interpretarla, è necessario definire cosa si considera un difetto, quale unità si utilizza e in quale periodo vengono raccolti i dati. Senza criteri stabili, confrontare le densità tra prodotti o team può essere poco significativo.
Descrive quanta quantità di codice viene aggiunta, modificata o rimossa durante un periodo. Un churn elevato può segnalare cambiamenti frequenti, lavoro ripetuto o instabilità in determinate aree, ma non dimostra di per sé che esista un problema: può anche riflettere un'evoluzione attiva del prodotto. È opportuno osservarlo insieme a difetti, revisioni e contesto dei cambiamenti.
Stima la quantità di percorsi di esecuzione indipendenti contenuti in una sezione di codice. Può aiutare a localizzare componenti difficili da testare o mantenere. Non sostituisce una revisione del design né offre, da sola, una diagnosi completa della qualità.
Conta le righe di codice —KLOC si riferisce a migliaia di righe— e può servire come riferimento approssimativo della dimensione di una base di codice. È una misura limitata per valutare la produttività: più righe non significano necessariamente più funzionalità o software migliore, e i confronti tra linguaggi e stili di programmazione possono essere ingiusti. A seconda dello scopo, possono essere più informativi indicatori funzionali, come i punti funzione, anche se richiedono anch'essi criteri di misurazione coerenti.
Le metriche finanziarie e commerciali completano quelle tecniche quando il team ha bisogno di capire come il prodotto si relaziona con il business. Non descrivono di per sé la qualità del codice né le prestazioni individuali di chi lo sviluppa.
Il MRR (monthly recurring revenue) rappresenta i ricavi ricorrenti mensili; l'ARR (annual recurring revenue) esprime una misura annualizzata di tali ricavi. Le regole di calcolo —ad esempio, come trattare i cambi di piano o i ricavi non ricorrenti— devono essere uniformi affinché le tendenze siano confrontabili.
La retention misura quale percentuale di clienti o ricavi viene conservata durante un periodo. Il churn esprime la perdita di clienti o ricavi, in base alla definizione scelta. È importante distinguere la retention dei clienti —a volte chiamata retention di loghi— dalla retention dei ricavi: un'azienda può mantenere i conti e, tuttavia, registrare variazioni nell'importo generato.
La NRR confronta i ricavi ricorrenti di una coorte di clienti con i ricavi generati da quella stessa coorte all'inizio del periodo, tenendo conto delle variazioni incluse nella metodologia adottata. La definizione specifica può variare; pertanto, devono essere specificati il periodo e i componenti che entrano nel calcolo.
Il CAC stima il costo per acquisire nuovi clienti, normalmente relazionando le spese di vendita e marketing con le nuove iscrizioni di un periodo. Il periodo di recupero del CAC approssima quanto tempo si impiega a generare un margine lordo sufficiente a compensare tale costo. Entrambi i numeri dipendono da quali spese e clienti vengano inclusi, pertanto non è consigliabile confrontarli senza rivederne i presupposti.
L'LTV stima il contributo economico di un cliente nel corso della sua relazione con l'azienda; il ROI confronta il risultato di un investimento con i suoi costi, secondo la formula e l'orizzonte temporale definiti. Sono indicatori di business, non misure dirette di produttività tecnica. La loro utilità dipende dalla qualità dei dati e dall'esplicitare le ipotesi utilizzate.
Prima di incorporare un indicatore in un dashboard, è opportuno concordare quale domanda debba rispondere, come viene calcolato, chi ha bisogno di consultarlo e con quale frequenza verrà rivisto. Aiuta anche combinare misure che si completino: ad esempio, monitorare il tempo di consegna insieme a difetti e soddisfazione del cliente offre più contesto rispetto a guardare solo la rapidità.
Le metriche dovrebbero supportare conversazioni sul sistema di lavoro e sulle opportunità di miglioramento, non diventare automaticamente quote individuali. Interpretate con contesto, possono aiutare a pianificare, allocare risorse e rilevare rischi; usate come sostituto del criterio tecnico, possono premiare l'attività visibile senza dimostrare che il software sia più utile, affidabile o manutenibile.
Una guida pratica in tre fasi per trasformare la riunione settimanale in uno spazio decisionale. Impara a definire obiettivi, gestire l’agenda e registrare accordi con responsabili e scadenze chiare per evitare la deriva e massimizzare la produttività del team.
Leggi
Il gergo specifico del settore edile può generare malintesi costosi tra i cantieri, l'amministrazione e i clienti. Questo glossario unifica i termini chiave di pianificazione, stima, metodologie agili e vocabolario tecnico per migliorare la comunicazione e l'efficienza nell'esecuzione dei progetti.
Leggi
Una guida pratica per trasformare la pianificazione di contingenza in capacità operativa reale: mappare le dipendenze, definire le soglie di decisione e validare le rotte alternative prima che si verifichi la crisi.
Leggi