Pubblicato originariamente nel novembre 2023. Approfondimento ampliato e aggiornato il 1° novembre 2026.
Per anni abbiamo messo l’accento sul consegnare codice funzionante velocemente e frequentemente. È un obiettivo importante: richiede infrastruttura, processi, cultura e competenze che permettano di cambiare un prodotto senza trasformare ogni rilascio in un’emergenza.
Ma la capacità di rilasciare non risponde, da sola, alla domanda più importante: che cosa è migliorato per qualcuno? Dieci deploy al giorno possono sostenere un prodotto utile oppure distribuire più rapidamente funzionalità che nessuno usa. La frequenza descrive una capacità del sistema; il valore riguarda gli effetti del suo lavoro.
Il rilascio è un passaggio, il risultato va verificato
Immaginiamo un team che consegna una nuova dashboard. Le schermate sono pronte, i test passano e il lavoro previsto è terminato. È un esempio illustrativo: il punto non è una specifica azienda, ma il modo in cui definiamo il successo.
Se la dashboard dovrebbe aiutare un responsabile a decidere quali ordini gestire prima, occorre osservare se quella decisione è diventata più semplice, tempestiva o affidabile. Il fatto che la dashboard esista non dimostra che sia utile. Potrebbe essere poco comprensibile, usare dati incompleti o arrivare nel momento sbagliato del processo.
Questo non rende inutile il lavoro fatto. Significa che abbiamo completato una parte del percorso e dobbiamo ancora verificare l’ipotesi che lo ha giustificato.
Il valore comprende anche ciò che evita problemi
Non tutto il valore si presenta come una nuova funzionalità. Un bug risolto può evitare errori ai clienti. Un intervento di sicurezza può ridurre un’esposizione. Un refactoring può rendere meno rischioso il prossimo cambiamento. Un ambiente di sviluppo più semplice può ridurre le attese di chi deve contribuire al prodotto.
Per questo non chiederei a ogni modifica di produrre immediatamente fatturato o un beneficio visibile all’utente finale. Chiederei invece di spiegare quale capacità, esperienza o rischio stiamo migliorando, per chi e attraverso quale meccanismo. Anche gli utenti interni contano.
Il rischio opposto è usare parole come «scalabilità» o «qualità» per giustificare qualsiasi investimento. Se il beneficio è indiretto, va resa esplicita la catena che collega il lavoro tecnico al risultato atteso. E va riconosciuto ciò che non sappiamo ancora.
Prima del codice: cinque domande
- Per chi stiamo intervenendo? Identifichiamo persone e situazioni d’uso, non soltanto il nome di uno stakeholder.
- Quale problema osservabile vogliamo cambiare? «Serve una dashboard» è già una soluzione; «non riusciamo a individuare gli ordini a rischio» è un problema.
- Qual è il cambiamento minimo utile? Potrebbero bastare una modifica al flusso, dati più accessibili o una funzionalità più piccola.
- Che cosa ci farà capire se funziona? Scegliamo segnali coerenti con il problema, quantitativi e qualitativi.
- Quando e con chi lo verificheremo? Senza un momento di verifica, un’ipotesi rischia di diventare un fatto soltanto perché il progetto è finito.
Misurare senza trasformare il valore in una finzione
Tornando alla dashboard, i segnali potrebbero essere il tempo necessario a individuare un ordine critico, gli errori nella scelta delle priorità e il riscontro delle persone che la usano. Il numero di accessi offre un indizio di utilizzo, ma non prova da solo un miglioramento.
Serve una situazione di partenza con cui confrontarsi. Se mancano dati affidabili, si può iniziare osservando il lavoro e raccogliendo evidenze limitate, dichiarandone i limiti. È meglio una verifica onesta che un indicatore scelto soltanto perché cresce.
Anche l’attribuzione richiede cautela: un risultato commerciale può cambiare per molte ragioni. Il contributo del software va argomentato, non assegnato automaticamente all’ultima funzionalità pubblicata.
Rilasciare spesso aiuta a imparare
Consegnare valore non è un argomento contro i rilasci frequenti. Cambiamenti piccoli e verificabili possono ridurre il rischio e accorciare il tempo necessario a capire se una scelta funziona. La domanda è come usiamo quella capacità.
In una review partirei quindi dal problema, mostrerei il cambiamento e distinguerei ciò che abbiamo verificato da ciò che ci aspettiamo. «Abbiamo completato queste attività» e «abbiamo osservato questo beneficio» sono informazioni diverse, entrambe utili.
Con l’AI, questa distinzione conta ancora di più
Se produrre una proposta di codice diventa più facile, scegliere che cosa costruire, verificarlo e integrarlo nel lavoro reale acquista ancora più importanza. Accelerare una soluzione poco utile non la rende migliore.
Nel talk al Codemotion Milano 2026 con Riccardo Galimberti abbiamo affrontato proprio la distanza tra accelerazione del coding e miglioramento dell’intero percorso di delivery.
Il mio criterio rimane questo: dimostrare di aver consegnato valore, non soltanto codice. Con la minore complessità necessaria e la disponibilità a cambiare direzione quando le evidenze contraddicono l’idea iniziale.
Per approfondire il ruolo di chi guida, leggi Il debito manageriale. Per continuare il confronto su engineering, organizzazione e AI, puoi iscriverti a CTO Mastermind Briefing, la newsletter in cui trovi i miei articoli in formato briefing su leadership, software engineering e AI.
