Ship and Stick: come misurare se l'IA funziona davvero

La tua organizzazione ha appena implementato assistenti di codifica AI. Il CTO chiede i numeri del ROI. La dashboard del fornitore dice che l'adozione è al 70%. Gli sviluppatori riferiscono di sentirsi più produttivi. Tutto sembra perfetto.

Tranne che nessuno può effettivamente dimostrare che qualcosa sia cambiato.

Il DORA 2024 State of DevOps Report ha rilevato che i team che utilizzano assistenti di codifica AI hanno registrato una diminuzione dell'1,5% nel throughput e una diminuzione del 7,2% nella stabilità¹. Non miglioramento. Diminuzione. Nel frattempo, uno studio METR ha scoperto che gli sviluppatori esperti che utilizzano l'AI completavano i task il 19% più lentamente — pur credendo di essere il 20% più veloci².

Rileggilo. Si sentivano più veloci. Erano più lenti.

Questo non è un attacco all'AI. L'AI è trasformativa. Ma l'infrastruttura di misurazione che la maggior parte delle organizzazioni sta utilizzando per valutare l'AI — e ogni altro cambiamento che stanno implementando — è fondamentalmente difettosa.

"Vai Veloce e Rompi Tutto" Non È una Strategia

C'è una narrativa seducente nel software in questo momento: l'AI rende gli sviluppatori più veloci, più veloce è meglio, quindi l'AI è meglio. Rilascia di più. Committa di più. Chiudi più ticket.

Questa è la mentalità da fabbrica applicata al lavoro intellettuale. E crea lo stesso problema che le fabbriche hanno scoperto decenni fa: la velocità senza controllo qualità è spreco.

L'analisi 2024 di Uplevel su circa 800 sviluppatori ha rilevato un tasso di bug superiore del 41% tra i team che utilizzano assistenti di codifica AI³. Faros AI ha riportato team che chiudono il 21% di task in più ma con code review più lunghe del 91% e il 9% di bug in più⁴. Il codice viene rilasciato più velocemente e si rompe di più.

Non gestiresti una fabbrica senza controllo qualità. Non celebreresti una linea di produzione che raddoppia l'output triplicando i difetti. Eppure è esattamente ciò che accade quando le organizzazioni di engineering misurano il successo dell'AI solo attraverso il throughput.

Il problema non è l'AI. Il problema è misurare la velocità senza misurare la durabilità. Stai controllando la frequenza cardiaca ma ignorando la pressione sanguigna.

E le organizzazioni stanno spendendo soldi veri su questo punto cieco. Licenze per strumenti AI, costi infrastrutturali, programmi di formazione — tutti valutati su tassi di adozione e sondaggi soggettivi sulla soddisfazione degli sviluppatori. Nessun ciclo di feedback. Nessuna misurazione dei risultati. Nessun modo per sapere se l'investimento sta dando i suoi frutti o sta peggiorando le cose.

Cosa Significa Realmente "Rilascia e Resta"?

"Rilascia e resta" è la domanda che taglia attraverso il rumore: il lavoro è stato rilasciato, ed è rimasto?

Non "è stato rilasciato velocemente". Non "ha chiuso un ticket". Ha creato valore duraturo? È sopravvissuto in produzione? Ha risolto il problema che doveva risolvere senza crearne tre nuovi?

"Rilascia e resta" è un concetto semplice con segnali concreti e misurabili. Pensali come i segni vitali della salute del cambiamento della tua organizzazione di engineering — come un medico che controlla pressione sanguigna, livelli di ossigeno e frequenza cardiaca insieme, non solo uno in isolamento.

I Segni Vitali

Questi non sono teorici. Sono misurabili dai dati che il tuo team genera già — issue completate, commit mergiati, PR reviewate, bug segnalati.

L'intuizione chiave è che nessun singolo segnale racconta la storia. Un team può avere velocità eccellente e rework terribile. Può avere bassi conteggi di bug ma prevedibilità in calo. I segni vitali funzionano insieme, come un pannello diagnostico.

Un team che rilascia e resta appare così: consegna consistente, qualità stabile o in miglioramento, rework gestibile, ritmo sostenibile. Questo è l'aspetto della vera produttività — che stiano usando l'AI o no.

Un team che "va veloce e rompe tutto" appare così: alta velocità più alto rework. Molto codice mergiato, molto ripristinato. Output dello sprint che oscilla selvaggiamente. Densità dei bug che aumenta. Velocità che crea più lavoro di quanto ne elimini.

Il Principio AI-Neutral

Ecco una posizione che mette a disagio alcune persone: non ci interessa quali strumenti usi.

Non tracciamo se uno sviluppatore ha usato Copilot, Claude o una tastiera meccanica e pura forza di volontà. Non misuriamo i tassi di adozione dell'AI. Non contiamo le righe di codice generate dall'AI.

Misuriamo ciò che viene rilasciato. Misuriamo ciò che resta.

Il principio AI-neutral è misurare i risultati senza tracciare quali strumenti li hanno prodotti. È importante perché è l'unico modo onesto per valutare qualsiasi cambiamento nel modo in cui lavora il tuo team.

Pensa a come appare realmente "l'uso efficace dell'AI" nei risultati:

• Throughput più alto con qualità stabile o migliorata
• Tempo di ciclo ridotto senza aumento del rework
• Più lavoro rilasciato che rimane rilasciato

E come appare "l'uso scarso dell'AI":

• Velocità più instabilità — commit veloci seguiti da fix frequenti
• Più codice prodotto ma più ripristinato
• Tempo più breve per il merge ma tempo più lungo per stabilizzare

Il gap di percezione dello studio METR è il manifesto del perché hai bisogno di misurazione dei risultati, non sondaggi di opinione. Gli sviluppatori si sentivano il 20% più veloci. Erano il 19% più lenti². Senza dati sui risultati, celebreresti l'adozione e perderesti la regressione.

Questo principio si estende oltre l'AI. Nuovi processi, ristrutturazioni del team, cambiamenti metodologici — ogni cambiamento organizzativo promette miglioramento. La domanda è sempre la stessa: i risultati sono effettivamente migliorati, o è solo sembrato che lo fossero?

Le organizzazioni che vincono non sono quelle che adottano più velocemente. Sono quelle che possono dimostrare che i loro cambiamenti stanno funzionando.

I segnali che il tuo team si sta davvero adattando

Ecco qualcosa che viene trascurato nella conversazione sulle metriche: i numeri "duri" raccontano solo metà della storia. L'altra metà è il lato umano — se il team si sta davvero adattando al cambiamento o sta silenziosamente crollando sotto di esso.

I team di ingegneria che affrontano il cambiamento — adozione dell'AI, nuovi processi, riorganizzazioni — generano segnali che predicono se il cambiamento avrà successo molto prima che le metriche di consegna lo confermino. Li consideriamo i segni vitali della salute del team.

Traiettoria dell'umore

La direzione conta più del livello assoluto. Un team il cui umore sta salendo da 3 a 4 è più sano di un team fermo a 7. Un livello alto e piatto può significare compiacenza. In salita significa slancio.

Un umore in calo dopo un cambiamento importante — diciamo, il lancio di uno strumento AI — è un segnale d'allarme precoce che qualcosa non sta funzionando bene. Lo vedrai nei dati sull'umore settimane prima che appaia nelle metriche di consegna.

Franchezza nelle retrospettive

Un team che pubblica solo card positive nelle retro non è un team felice. È un team che non si sente sicuro di essere onesto.

I team sani hanno un equilibrio tra feedback positivo e orientato al miglioramento. La ricerca sulla sicurezza psicologica mostra costantemente che i migliori team fanno emergere i problemi apertamente⁵. Un rapporto di franchezza che pende troppo verso il positivo — tutti dicono che è andato tutto bene quando chiaramente non è così — è un segnale d'allarme per preoccupazioni represse.

I tassi di card anonime raccontano una storia simile. Se più della metà delle card della retro sono anonime, le persone potrebbero non sentirsi sicure di associare il proprio nome a un feedback onesto. Questo è un problema di salute del cambiamento, non solo un problema di processo.

Realizzazione delle azioni

Questo è quello che separa i team che imparano dai team che parlano soltanto. Un sondaggio della community PMI ha rilevato che quasi due terzi dei team hanno implementato meno del 25% delle azioni delle loro retrospettive⁶. Il pattern: identificare problemi, impegnarsi a risolverli, non fare nulla, ripetere.

La realizzazione delle azioni è il segnale più concreto che un team si sta davvero adattando. Risponde alla domanda: quando il team si impegna a un cambiamento, il cambiamento avviene? Se stai monitorando l'impatto dell'adozione dell'AI e il team continua a identificare attriti di integrazione nelle retro ma non li risolve mai, nessuna quantità di strumenti aiuterà.

Resilienza

Ogni team ha sprint difficili. Ciò che conta è cosa succede dopo.

Un team che scende dall'85% al 60% di completamento e rimbalza all'80% nello sprint successivo sta mostrando una vera adattabilità. Un team che scende e rimane giù sta mostrando che il cambiamento ha sopraffatto la sua capacità di assorbirlo.

La resilienza — la capacità di riprendersi dalle battute d'arresto — è uno dei predittori più forti del fatto che un team affronterà con successo il cambiamento nel tempo. I team che si riprendono stanno imparando. I team che non lo fanno sono bloccati.

Indipendentemente da come — il valore è l'unica metrica che conta

Facciamo un passo indietro.

Che il cambiamento sia strumenti AI, una nuova cadenza di sprint, una ristrutturazione del team o un cambio di metodologia — la domanda è sempre la stessa: sta funzionando?

Non "l'abbiamo adottato?" Non "piace alle persone?" Non "la dashboard del fornitore sembra buona?"

Il team sta consegnando lavoro che resta? La qualità è stabile o in miglioramento? Il ritmo è sostenibile? Le persone si stanno davvero adattando, o stanno solo seguendo la routine?

Questo è ciò che intendiamo con "ciò che viene consegnato e resta conta di più, indipendentemente da come". Gli strumenti, i processi e le strutture sono input. La creazione di valore è l'output. Se non puoi misurare l'output, stai volando alla cieca — ottimizzando gli input e sperando per il meglio.

Il ciclo di feedback

Le organizzazioni che lo fanno bene costruiscono un ciclo di feedback continuo:

1. Fai un cambiamento — adotta uno strumento, aggiusta un processo, ristruttura un team
2. Misura il risultato — la consegna è migliorata? La qualità ha tenuto? Il team si sta adattando?
3. Aggiusta in base alle evidenze — raddoppia ciò che funziona, correggi ciò che non funziona
4. Ripeti — ogni sprint, ogni trimestre, continuamente

Sembra ovvio. Quasi nessuno lo fa. La maggior parte delle organizzazioni è bloccata al passo 1 — fare cambiamenti e presumere che abbiano funzionato perché sembrano giusti.

Il gap di misurazione non è un problema tecnologico. È un problema di disciplina organizzativa. I dati esistono. I tuoi strumenti di gestione progetti, repository di codice e cerimonie del team generano già i segnali di cui hai bisogno. La domanda è se li stai guardando — e se stai guardando quelli giusti.

Gli score di salute come livello di misurazione

Abbiamo costruito Simyl Flow attorno a questa idea: un singolo score di salute che sintetizza consegna, qualità, sostenibilità e dinamiche del team in un unico numero che risponde "stiamo migliorando?"

Non una metrica di vanità. Non uno strumento di sorveglianza. Un segno vitale — come la cartella clinica di un paziente che dice al medico se il trattamento sta funzionando, senza microgestire quali pillole il paziente ha preso e a che ora.

Lo score di salute sale quando i risultati migliorano: più lavoro viene consegnato e resta, la qualità tiene, il team si sta adattando. Scende quando i risultati peggiorano: il rework aumenta, la prevedibilità cala, il team mostra segni di affaticamento da cambiamento.

È il ciclo di feedback che manca alla maggior parte delle organizzazioni. Non un'altra dashboard di metriche di attività. Una singola risposta basata su evidenze alla domanda che ogni leader di ingegneria deve avere risposta: quello che stiamo facendo sta davvero funzionando?

La linea di fondo

Ogni organizzazione sta facendo cambiamenti. Nuovi strumenti, nuovi processi, nuove strutture. Quasi nessuna di loro può dimostrare se quei cambiamenti stanno funzionando.

I team che vincono — quelli che migliorano davvero invece di limitarsi a cambiare — condividono tre caratteristiche:

1. Misurano i risultati, non l'attività. Non commit, non tassi di adozione, non story point. Il valore è stato consegnato? È rimasto?
2. Osservano i segnali umani. Traiettoria dell'umore, franchezza, realizzazione delle azioni, resilienza. I segni vitali che predicono se il cambiamento terrà.
3. Costruiscono cicli di feedback. Cambia, misura, aggiusta, ripeti. Ogni sprint. Senza eccezioni.

Consegna e resta. Questo è lo standard. Tutto il resto è rumore.

Fonti