Misurare senza illusioni 📏

Le metriche AI più facili da raccogliere sono spesso le meno utili: prompt, token, suggerimenti accettati. Misurano attività. Il valore richiede una baseline e due famiglie di segnali: risultato operativo e capacità che il sistema conserva dopo il pilot. Il resto è estetica da dashboard. Molti pilot senza ritorno misurabile nascono da qui: non si misura perché non si è mai deciso cosa guardare.

Sistema di metriche duali ⚖️

Le Four Keys DORA sono una buona lingua franca per una pipeline software: non attribuiscono automaticamente ogni variazione all’AI, ma mostrano se il flusso è davvero migliorato. Aggiungi sempre un guardrail: velocità senza qualità è solo un incidente programmato.

    flowchart LR
    A[Baseline] --> B[Pilot delimitato]
    B --> C[Metriche operative]
    B --> D[Guardrail qualità]
    C --> E[Decisione]
    D --> E
  

Le Four Keys non bastano più 🧩

Con il codice a generazione economica, deployment frequency e lead time diventano ingannevoli: crescono anche quando il sistema peggiora. I dati di Faros AI sono il caso di scuola: più task completati, ma anche più bug, più incidenti per PR, review molto più lunghe e molto più codice riscritto. Se misuri solo la velocità di consegna, vedi un successo. Se misuri il flusso intero, vedi un debito che si sta accumulando.

Tra le Four Keys, MTTR resta la più affidabile. DORA da solo, però, non basta: va completato con framework come SPACE (soddisfazione, performance, attività, comunicazione, efficienza) o DX Core 4, e con metriche specifiche per l’AI come la quota di codice scritto da agenti, il code churn e l’attribuzione dei bug tra AI e umani (con tagging in CI, non a sensazione). La regola resta: poche metriche, ben definite, che guidano una decisione.

Le forme del valore 💶

Conta costi evitati, ore riallocate, lavoro eliminato, errori e rischi prevenuti, tempo al valore e ricavo incrementale. I token sono un costo da governare, non una prova che il pilot abbia funzionato: una quota non trascurabile del consumo è spreco (contesti ridondanti, retry inutili, output mai usato) e va ottimizzata separatamente dal business case.

Il costo totale va calcolato su un orizzonte pluriennale e deve includere ciò che di solito si dimentica: token ricorrenti, infrastruttura di retrieval, osservabilità, revisione umana e rework. La licenza è la parte più visibile e meno decisiva: ciò che sposta il costo vero è la qualità di ciò che produci.

Baseline, controllo e decisione anticipata 🎯

La baseline pre-AI è l’elemento più critico e più spesso mancante. Senza di essa non esiste risultato: esiste un prima e dopo senza punto di partenza. Tre regole pratiche:

1. Gruppo di controllo, non solo prima/dopo. Confronta un gruppo che usa l’AI con uno che non la usa (o che la usa poco). È l’unico modo per filtrare variabili di contesto.
2. Misura a livello di team, mai ranking individuali. Le metriche individuali con l’AI diventano giochi al ribasso: chi non delega sembra lento, chi delega troppo sembra veloce. Il team è l’unità di misura.
3. Decisione scritta prima di vedere i risultati. I criteri di espansione, correzione o stop si fissano a inizio pilot. Cherry-picking significa definire le metriche a posteriori: vietarlo è materia di governance, non di buona volontà.

Anche l’orizzonte conta: valore immediato e capability building sono due ordini di discorso. Misurare la formazione del primo anno con metriche di ROI di anni dopo è un modo sicuro per chiudere un’iniziativa che stava costruendo il futuro.

Anti-metriche e “phantom productivity” 🚫

• Tool-usage fetish: “quasi tutti i team usano l’AI” non è un risultato, è un costo. Metti metriche d’impatto sul value stream.
• Phantom productivity: ore risparmiate ma mai ricatturate. Se non specifichi dove vanno le ore, il tempo risparmiato evapora.
• Cognitive debt neglect: ore di review e refactoring dell’output AI che non finiscono in bilancio.
• TCO incompleto: calcolare solo la licenza e scoprire dopo i costi di token, retrieval e osservabilità.
• Cherry-picking e assenza di baseline: le due facce della stessa medaglia — la metrica definita dopo il risultato.

Una scorecard ragionevole mantiene poche metriche attive, cinque o sette al massimo: delivery (DORA, tenendo d’occhio rework e churn), esperienza (SPACE/DX), AI-specifiche (come la quota di PR senza review, da tenere a zero), costo separato e un outcome di business legato a OKR o P&L. Regola d’oro: ogni KPI deve guidare una decisione — se non cambia l’azione, rinuncia al KPI: è teatro.

Checklist ✅

• Baseline raccolta prima del rollout.
• Una metrica di outcome e un guardrail di qualità.
• Costo totale, inclusi revisione e rework.
• Decisione scritta prima di vedere i risultati.
• Gruppo di confronto o stima esplicita delle variabili.
• Poche metriche, ciascuna collegata a una decisione.

Collega il quadro a FOCUS e alla governance leggera: misurare non sostituisce il giudizio, gli impedisce di diventare narrativa.