Prima o poi, ogni manager ha la brillante idea di misurare la produttività dei suoi sviluppatori. Ma contare le righe di codice può portare fuori strada. Ecco come metriche intelligenti e una governance chiara aiutano i team a consegnare valore reale, rapidamente e senza sprechi
Non molto tempo fa, mi godevo una piacevole conversazione al sole di inizio primavera con il COO di uno dei miei clienti. Il tema era ancora una volta quello della misurazione della produttività: un argomento che ho affrontato innumerevoli volte con diversi manager negli ultimi trent’anni. «Dovremmo essere in grado di capire chi è bravo e chi non lo è» – rifletteva il COO. «E se contassimo il numero di righe di codice che scrivono»? Vedendo la mia espressione perplessa, aggiunse: «O forse, meglio, quante volte committano? Questo dovrebbe darci un’indicazione chiara della loro produttività, giusto»?
Risposi: «Ci sono alcune cose che dovresti considerare. Prima di tutto, il codice scritto copre solo una piccola parte del tempo effettivamente speso dagli sviluppatori. La maggior parte del tempo viene impiegata per confrontarsi con il business, riflettere e progettare soluzioni. E non dimentichiamoci delle riunioni». Poi aggiunsi: «Sviluppare software non è come giocare a tennis o a scacchi: è uno sport di squadra, come la pallavolo o l’hockey. Come puoi misurare la produttività individuale, se più persone collaborano alla stessa soluzione»?
Scaricare kerosene
Dimenticai, però, di aggiungere che esiste la Legge di Goodhart, che può essere riassunta così: quando una misura diventa un obiettivo, smette di essere una buona misura. Un esempio perfetto per spiegare meglio il concetto, mi è stato raccontato da un amico: qualche anno fa, la Royal Dutch Air Force decise di garantire un numero sufficiente di movimenti di volo nelle proprie basi di addestramento, misurandoli in base alla quantità di kerosene consumato. Più kerosene significava più voli, dunque una base aerea più attiva. Semplice, no? In pratica, però, la metrica portò alcuni reparti a scaricare kerosene invece di volare di più, causando un grave inquinamento del suolo. Nel caso degli sviluppatori, se un’organizzazione misurasse la produttività semplicemente contando i commit e ritenesse più produttivo chi ne fa di più, il risultato sarebbe simile: gli sviluppatori potrebbero frammentare il codice in parti più piccole e inviarle più spesso, solo per far salire il numero. Anche se i commit più frequenti sono in sé un buon segnale, il conteggio in sé non è una buona misura. In breve, gli sviluppatori finirebbero anche loro per “scaricare kerosene”. La vera domanda, quindi, è: si può – e si deve – misurare la produttività nello sviluppo software? E soprattutto: i team possono migliorare grazie alle misurazioni, invece di cadere nella trappola della Legge di Goodhart?
Le metriche DORA
Qui entra in gioco DORA, un insieme di metriche ormai riconosciuto come standard di riferimento nel settore. Sviluppato dal team DevOps Research and Assessment (da cui l’acronimo), DORA si basa su anni di indagini e studi su migliaia di team in tutto il mondo. Le ricerche hanno dimostrato una chiara correlazione tra alte prestazioni nello sviluppo software e migliori risultati di business – tra cui crescita dei ricavi, aumento della quota di mercato e maggiore soddisfazione dei clienti. In altre parole, più un’organizzazione riesce a sviluppare software bilanciando velocità, qualità e stabilità, maggiori saranno i benefici complessivi. Nel mio ruolo attuale di CTO in iBOOD, questo effetto è evidente: quanto più rapidamente e con maggiore efficacia i nostri team sviluppano, tanto più crescono i ricavi, la fidelizzazione dei clienti e la qualità dei processi di business. DORA definisce quattro metriche chiave che distinguono i team ad alte prestazioni dagli altri: 1) la frequenza di deployment, quanto spesso un team rilascia codice in produzione; 2) lead time per le modifiche, in pratica il tempo che intercorre tra un commit e la messa in produzione; 3) il tasso di fallimento dei cambiamenti che indica la percentuale di rilasci che falliscono; e infine il tempo medio di recupero, che descrive la rapidità con cui un team riesce a riprendersi da un problema. Prese insieme, queste metriche mostrano con quanta rapidità, sicurezza e affidabilità i team riescono a consegnare valore agli utenti.
Un caso concreto
Qualche mese fa, il nostro tech board, il gruppo di stakeholder che definisce le priorità per i team tecnologici, decise di testare una nuova funzione di ricerca intelligente per il sito e per l’app. Abbiamo dedicato una settimana e mezza alla sperimentazione e sviluppo, seguiti da alcuni giorni di test con un gruppo ristretto di utenti. La nuova ricerca ha funzionato, e abbiamo scelto di rilasciarla a tutti i clienti. L’impatto sui ricavi è stato immediato, anche se difficile da quantificare con precisione, dato il flusso continuo di nuovi ordini. Le metriche DORA si sono rivelate un’ottima guida. Tuttavia, è importante ricordare che DORA rappresenta solo un punto di partenza – eccellente, ma non è definitivo.
Oltre le metriche
In iBOOD stiamo lavorando a una nuova piattaforma e-commerce su un’architettura micro-everything: l’intero ecosistema, compreso il software rivolto ai clienti, è composto da circa 180 micro-repository, ognuno con la propria pipeline di deployment. Ogni commit viene distribuito automaticamente in produzione se tutti i test automatizzati vengono superati. Attualmente effettuiamo 40–50 commit al giorno, e le nostre pipeline impiegano 10–15 minuti per completare un rilascio.Non tutti i commit sono perfetti: circa il 20-25% contiene piccole imperfezioni. I colleghi le segnalano sul canale Slack #ask-tech, e di solito le correggiamo subito, generando una nuova versione. Abbiamo team altamente performanti: ne sono convinto. Tuttavia, nella nostra fase attuale, DORA non è più la nostra stella polare. Possiamo ancora ottimizzare le pipeline – e lo stiamo facendo – ma ridurre il tempo da 10 a 8 minuti non cambierà in modo significativo la performance complessiva. La domanda diventa quindi: qual è il prossimo passo?
Costruire le cose giuste
Sono convinto che, per team ad alte prestazioni che già sanno costruire le cose nel modo giusto, la vera sfida è imparare a costruire le cose giuste. I nostri team ricevono più richieste di quante possano gestire. La domanda che dobbiamo farci è: il tempo che investiamo genera davvero il massimo valore per l’azienda? Per valutarlo, abbiamo creato un comitato – il tech board – in cui sono rappresentati tutti i principali dipartimenti. Ci riuniamo ogni due settimane. Ogni nuova proposta viene presentata con una breve analisi del suo valore per il business: maggiori ricavi, migliore fidelizzazione, aumento del valore medio dell’ordine, oppure efficienza nei processi.
Per ogni iniziativa ci poniamo quattro domande fondamentali: Ci aiuta ad avvicinarci ai nostri obiettivi strategici? Se la risposta è negativa, non la sviluppiamo. Possiamo davvero realizzarla? Abbiamo competenze, piattaforma e tecnologia adeguate? È abbastanza piccola da essere completata rapidamente? In caso contrario, rischierebbe di bloccare risorse utili altrove. Ci serve davvero adesso? Se no, la etichettiamo come “un giorno, forse”. Questo approccio stimola il confronto e consente di validare il valore di ogni iniziativa rispetto alle altre. In questo modo, i team non solo lavorano bene, ma costruiscono le cose giuste. Oltre al continuo miglioramento delle metriche DORA, questo meccanismo decisionale condiviso ci permette di estrarre il massimo valore possibile dalla nostra tecnologia. Ma è anche ciò che ci consente di gestire una piattaforma e-commerce completa e performante con meno di quindici sviluppatori, senza burocrazia, senza ruoli aggiuntivi, con un’architettura solida e pipeline di deployment completamente automatizzate. Niente Scrum, niente sprint, nessuna misurazione di righe di codice. Solo collaborazione, fiducia e responsabilità condivisa. Perché, dopotutto, sviluppare software è, e sarà sempre, uno sport di squadra.
Sander Hoogendoorn
Consulente indipendente, artigiano del software, architetto, programmatore, coach, speaker, formatore e scrittore. La sua carriera è un percorso ricco di esperienze che lo hanno visto confrontarsi con le pratiche più avanzate dell’ingegneria del software. Ha una profonda conoscenza di Agile, Scrum, Kanban, Continuous Delivery, Agile Requirements, Design Patterns, Domain Driven Design, UML, Software Architecture e Microservices, e una vera passione per la scrittura di codice che rispecchia i più alti standard di qualità e design. Autore di bestseller come “This is Agile” e “Pragmatic Modeling with UML”, ha pubblicato più di 250 articoli tecnici su importanti riviste del settore.
Sander Hoogendoorn presenterà per Technology Transfer il seminario “Progettare, sviluppare e implementare una Microservices Architecture” che si terrà online live streaming il 12 dicembre 2025.
