Perché non misuriamo la produttività degli sviluppatori (e cosa misuriamo invece)

La ribellione è qui

Nel gennaio 2024, l'autorità francese per la protezione dei dati ha multato Amazon per 32 milioni di euro per sorveglianza dei dipendenti "eccessivamente invasiva"¹. L'azienda aveva tracciato le battute sulla tastiera, l'attività degli scanner e ogni momento di "inattività" nei suoi magazzini.

Amazon non è sola. Uno studio recente ha rilevato che il 50% dei lavoratori sottoposti a monitoraggio preferirebbe dimettersi piuttosto che sopportare una sorveglianza costante². Nel frattempo, i "mouse jiggler"—dispositivi che simulano attività per ingannare i software di monitoraggio—sono ora bestseller su Amazon. L'ironia si scrive da sola.

Questo non sta accadendo solo nei magazzini. Sta accadendo nell'ingegneria.

Un ecosistema crescente di strumenti per la "produttività degli sviluppatori" promette di aiutare i leader dell'ingegneria a capire cosa stanno facendo i loro team. Tracciano righe di codice, commit al giorno, ore alla tastiera e, sempre più spesso—con l'AI—persino il contenuto di ciò che gli sviluppatori scrivono.

Ecco la verità scomoda: questi strumenti sono sorveglianza mascherata da gestione. E stanno peggiorando i team di ingegneria, non migliorandoli.

Il problema: perché le metriche di produttività sono tossiche

Esaminiamo cosa misurano effettivamente questi strumenti:

Righe di codice

Come dice il proverbio, misurare la produttività della programmazione in base alle righe di codice è come misurare il progresso degli aerei in base al peso. Bill Gates avrebbe detto senza mezzi termini: "Misurare il progresso della programmazione in base alle righe di codice è come misurare il progresso della costruzione di aerei in base al peso."

Una discussione su Stack Overflow l'ha catturato perfettamente: "Misurare l'output degli sviluppatori in base alle righe di codice è come misurare l'efficacia di una centrale elettrica in base ai rifiuti che produce."

Più righe spesso significa codice peggiore. Un refactoring che riduce 500 righe a 50 è progresso. Un'automazione che elimina un processo manuale è progresso. Un'astrazione ben progettata che previene lavoro futuro è progresso. Nessuno di questi appare positivamente nelle metriche LOC.

Commit al giorno

Banalmente facile da manipolare. Vuoi aumentare il tuo conteggio di commit? Dividi una singola modifica logica in quindici piccoli commit. Aggiungi modifiche agli spazi bianchi. Fai commit durante la pausa pranzo.

Ancora più importante, i commit misurano attività, non impatto. Uno sviluppatore che passa una settimana a progettare un'architettura che fa risparmiare al team mesi di lavoro avrà meno commit di qualcuno che rilascia freneticamente funzionalità che creano debito tecnico.

Ore lavorate

Questa è particolarmente insidiosa. La ricerca mostra costantemente che lavorare oltre le 50 ore settimanali riduce effettivamente l'output totale³. Gli sviluppatori che restano fino a tardi realizzano meno, non di più, perché l'esaurimento porta a bug, decisioni sbagliate e codice che richiede rilavorazione.

Uno studio ha rilevato che gli sviluppatori che lavorano ore eccessive producevano letteralmente lavoro negativo—creavano più problemi di quanti ne risolvessero.

Eppure le "ore online" rimangono un pilastro degli strumenti di sorveglianza.

Il problema di Goodhart

L'economista britannico Charles Goodhart ha osservato che "quando una misura diventa un obiettivo, cessa di essere una buona misura."⁴

Ogni metrica menzionata sopra è banalmente manipolabile:

• Vuoi più commit? Dividi le modifiche in frammenti.
• Vuoi più righe? Scrivi codice prolisso.
• Vuoi più ore? Tieni aperto il laptop.
• Vuoi più PR? Invia modifiche più piccole e frequenti.

Nel momento in cui inizi a misurare queste cose, non stai più misurando ciò che volevi misurare. Stai misurando quanto bene le persone manipolano le tue metriche.

Il paradosso dell'AI: perché sta peggiorando

Se pensavi che le metriche tradizionali fossero fallimentari, l'AI sta per peggiorare tutto.

L'illusione della produttività

Il rapporto DORA (DevOps Research and Assessment) del 2024—lo studio annuale più completo sulle prestazioni di consegna del software—ha rilevato qualcosa di sorprendente: i team che utilizzano assistenti di codifica AI hanno mostrato una diminuzione dell'1,5% nel throughput e una diminuzione del 7,2% nella stabilità⁵.

Aspetta, cosa?

Uno studio del 2025 di METR è andato oltre. Ha rilevato che gli sviluppatori esperti che utilizzano assistenti AI erano effettivamente più lenti del 19% su compiti del mondo reale. Ma ecco il colpo di scena: quegli stessi sviluppatori credevano di essere più veloci del 20%⁶.

L'AI crea un divario tra percezione e realtà. Gli sviluppatori si sentono più produttivi mentre in realtà realizzano meno.

Velocità individuale, rallentamento organizzativo

L'AI amplifica la produttività individuale su determinati compiti—generare boilerplate, scrivere test, spiegare codice. Ma questo aumento di velocità individuale spesso si traduce in rallentamento organizzativo.

L'analisi dei dati di ingegneria ha rilevato che i team assistiti da AI completavano il 21% in più di compiti, ma le loro revisioni del codice richiedevano il 91% in più di tempo e introducevano il 9% in più di bug⁷.

Più output + revisioni più lunghe + più bug = consegna più lenta.

Qual è la differenza tra produttività ed efficacia?

La produttività degli sviluppatori misura l'attività: commit, righe di codice, ore alla tastiera. L'efficacia degli sviluppatori misura i risultati: se il lavoro è stato consegnato, se è rimasto e se ha aiutato il team. È qui che ci discostiamo dall'approccio del capitalismo della sorveglianza alle metriche di ingegneria.

"La produttività degli sviluppatori" è un concetto fallimentare. Ma l'efficacia degli sviluppatori è misurabile—se ti concentri sui risultati, non sull'attività.

I nostri cinque principi fondamentali guidano tutto ciò che costruiamo:

1. Orientato ai risultati: Misura il valore consegnato, non l'attività
2. Neutrale rispetto all'AI: Non tracciare l'uso degli strumenti, deduci dai risultati
3. Developer-first: Profili individuali privati per impostazione predefinita
4. Coaching invece di giudizio: Tendenze e orientamento, non classifiche
5. Anti-manipolazione: Il punteggio multidimensionale resiste alla manipolazione

Cosa significa in pratica

Non misuriamo commit, righe di codice o ore lavorate. Misuriamo:

• Il lavoro è stato consegnato? (Consegna)
• È fluito in modo sostenibile? (Flusso)
• È rimasto? (Qualità)
• Ha aiutato il team? (Collaborazione)

Uno sviluppatore che ottiene risultati eccellenti con l'AI = efficace. Uno sviluppatore che ottiene risultati eccellenti senza AI = efficace. Alta attività + bassi risultati = preoccupazione, indipendentemente dagli strumenti.

Le 6 dimensioni dell'efficacia

Misuriamo l'efficacia attraverso sei dimensioni. Ogni dimensione ha più componenti che creano intenzionalmente tensione tra loro.

Ogni dimensione racconta parte della storia. La magia sta in come interagiscono.

Il Design Anti-Gaming (Il Segreto)

Ecco cosa rende questo sistema diverso: ottimizzare una singola dimensione tipicamente danneggia almeno un'altra.

Il Punto Ottimale della Dimensione Batch

Considera le dimensioni delle PR. Non premiamo "più PR" o "PR più grandi". Premiamo il dimensionamento ottimale:

• 100-400 righe: Ottimale. Punteggio di 100.
• Sotto 50 righe: Eccessivamente frammentato. Il punteggio cala.
• Oltre 800 righe: Troppo grande per una review efficace. Il punteggio cala.

Non puoi ingannare il sistema rendendo le PR più piccole O più grandi. C'è un intervallo ottimale, e le deviazioni in entrambe le direzioni ti danneggiano.

Rapporto di Correzione Bug

Allo stesso modo per la qualità, non penalizziamo solo i bug. Misuriamo il contributo netto:

• Hai corretto più bug di quanti ne hai introdotti: Punti bonus.
• Hai introdotto più bug di quanti ne hai corretti: Penalità.

Non puoi ingannare il sistema evitando il codice (nessun bug, ma anche nessuna correzione). Il sistema premia il contributo netto positivo alla qualità.

Privacy come Architettura, Non come Policy

Molti strumenti affermano di essere "orientati alla privacy" pur consentendo la sorveglianza. Aggiungono una casella di controllo nelle impostazioni. Promettono che i manager non guarderanno i dati individuali. Creano policy.

Le policy possono essere cambiate. Le impostazioni possono essere modificate. Le promesse possono essere infrante.

Il nostro approccio è diverso. La privacy è integrata nell'architettura:

1. I profili individuali sono isolati — Non esiste un endpoint per recuperare "tutti i punteggi degli sviluppatori"
2. Non esistono classifiche — Il concetto non è stato costruito
3. I manager vedono aggregati — Pattern a livello di team, non classifiche individuali
4. Gli insight di coaching hanno un ambito definito — Visibili solo allo sviluppatore (e opzionalmente, al suo manager diretto)
5. Limitazioni all'esportazione — I dati individuali possono essere esportati solo dall'individuo

Non si tratta solo di rispettare gli sviluppatori (anche se lo è). Si tratta di ottenere dati accurati. Nel momento in cui le persone sanno di essere classificate, entra in gioco la Legge di Goodhart. Nel momento in cui inizia la sorveglianza, i dati diventano inaffidabili.

La fiducia consente l'accuratezza. La sorveglianza distrugge entrambe.

La Visione: Dall'Attività ai Risultati

Il settore è a un punto di svolta.

Il vecchio approccio—metriche di sorveglianza, tracciamento delle attività, teatro della produttività—si sta sgretolando. L'AI sta accelerando il collasso. I numeri sono più grandi, ma significano meno.

Il nuovo approccio si concentra su ciò che conta:

• Da "quanto codice" → "aiuta gli utenti?"
• Dalla sorveglianza → fiducia
• Dalle metriche di vanità → impatto sul business
• Dal teatro della produttività → miglioramento reale

I team che capiranno questo avranno un vantaggio enorme. Manterranno sviluppatori migliori (che non tollereranno la sorveglianza). Prenderanno decisioni migliori (basate su dati significativi). Miglioreranno davvero (invece di ingannare le metriche).

Il Sogno del CTO

Ciò che i leader dell'ingegneria vogliono davvero:

1. Prova che l'ingegneria sta migliorando — Non solo istantanee, ma traiettorie
2. Metriche difendibili — Qualcosa che possono mostrare al consiglio che non può essere facilmente respinto
3. Nessun gaming — Metriche che resistono alla manipolazione
4. Preservazione della fiducia — Misurazione che non distrugge la cultura del team
5. Misurazione pronta per l'AI — Metriche che funzionano indipendentemente dagli strumenti che le persone usano

Le metriche di produttività tradizionali falliscono tutti e cinque i requisiti. Sono istantanee, facilmente ingannabili, distruttive della fiducia e completamente compromesse dall'AI.

Le metriche di efficacia—focalizzate sui risultati, progettate per l'anti-gaming, costruite sulla fiducia—soddisfano tutti e cinque i requisiti.

Cosa Significa Questo per il Tuo Team

Se sei un leader dell'ingegneria che sta considerando strumenti di "produttività degli sviluppatori", fai queste domande:

1. Cosa stiamo misurando esattamente? Se la risposta è attività (commit, LOC, ore), scappa.
2. Può essere ingannato? Se ottimizzare la metrica è più facile che fare un buon lavoro, la metrica è inutile.
3. Cosa succede ai dati? Se gli individui possono essere confrontati e classificati, la fiducia si eroderà.
4. Come gestisce l'AI? Se cerca di tracciare l'uso degli strumenti, è già obsoleto.
5. Aiuta gli sviluppatori a migliorare? Se è solo misurazione senza coaching, è sorveglianza con passaggi extra.

Se sei uno sviluppatore sottoposto a questi strumenti, sappi che non sei pazzo. Le metriche sono prive di significato. La sorveglianza fa male. I team migliori—quelli per cui probabilmente vorresti lavorare—stanno rifiutando questo approccio.

Unisciti alla Ribellione

Stiamo costruendo qualcosa di diverso.

Non sorveglianza. Non teatro della produttività. Non metriche di vanità che sembrano belle nelle presentazioni al consiglio ma guidano comportamenti negativi.

Stiamo costruendo la prova che il tuo team sta effettivamente migliorando.

Inizia con la misurazione di ciò che conta: risultati, non attività. Tendenze, non istantanee. Efficacia, non produttività.

Se sei stanco di metriche che misurano le cose sbagliate, sorveglianza che distrugge la fiducia e strumenti che diventano obsoleti nel momento in cui qualcuno apre un assistente AI—dovremmo parlare.

Fonti