A caccia di fantasmi: come vedere il contributo reale degli sviluppatori

I «ghost engineer», o sviluppatori fantasma: uno sviluppatore su dieci non svolge quasi nessun lavoro utile e si limita a recitare in modo convincente la parte di chi è sempre impegnato. Le vere ragioni di questa inattività — secondi lavori, burnout o semplice pigrizia — possono restare nascoste alla direzione per moltissimo tempo. (Studio di Stanford del 2024: thread originale)

Agli sviluppatori non piace quando si parla delle loro prestazioni. Dopo una lunga «età dell’oro» per la professione, nel settore è nato un tabù intorno a una domanda semplice: il risultato dell’ingegneria giustifica il tempo e il denaro investiti? Ma gli sviluppatori fantasma irritano anche i loro colleghi — e di solito è il team, non la direzione, ad accorgersi per primo del problema.

Qui in Russia, «fare la spia» è da sempre visto molto male. Così, molte persone possono sapere che c’è un problema, ma nessuno vuole parlarne. Perché infilarsi nei guai degli altri? Tutto viene fuori soltanto quando la pazienza è ormai finita.

Ma forse dovremmo lasciarli stare, questi fantasmi. Dopotutto, non è che all’azienda mancheranno quei soldi.

E invece c’è un problema…

Quando parlo di scarse prestazioni, non intendo dire che Marco si impegna, suda sulla tastiera e alla fine produce il 10% in meno di Luca. Intendo altro: a ogni stand-up, tutto il team deve sorbirsi l’ennesima storia strappalacrime — l’altro team non ha collaborato, il ticket era poco chiaro, le stelle non si sono allineate. Ma domani il lavoro sarà sicuramente finito. Parola di scout.

Peccato che quel «domani» fosse già ieri, e l’altro ieri — e ormai sia diventato una tradizione.

I team notano in fretta queste cose. Chi porta davvero il peso del lavoro comincia naturalmente a chiedersi: perché ammazzarsi di fatica se si possono raccontare frottole senza subire alcuna conseguenza?

Ma accorgersi del problema non basta. Senza numeri e fatti alla mano, la conversazione degenera presto in una disputa: il team dice «rende poco», lo sviluppatore risponde «non mi lasciano lavorare». Di solito nessuno comincia a indagare finché la pazienza non è esaurita e il team chiede al responsabile di sostituire lo sviluppatore.

È allora che inizia la lunga trafila: raccogliere i fatti, ascoltare entrambe le parti, dare un feedback e lasciare alla persona il tempo di migliorare la situazione. Nella mia esperienza, quasi sempre finisce con il fantasma che passa a un nuovo — e davvero fortunato — datore di lavoro.

Il problema non è soltanto che una persona fa meno. L’azienda paga due volte: prima per il lavoro che non viene mai svolto, poi per il tempo che colleghi e responsabili spendono a ricontrollare, coprire i vuoti e cercare di capirne il motivo. Alla fine non è più un singolo sviluppatore a rendere poco. È tutto il team.

Può un responsabile individuare prima il problema — notare l’anomalia, chiedere il contesto e indagare prima che il team perda la pazienza e l’azienda perda tempo e denaro?

Con sufficiente esperienza, spesso è possibile riconoscere in anticipo queste situazioni attraverso alcuni comportamenti caratteristici:

• Ogni successo è merito mio; ogni fallimento è colpa tua.
• Scuse per il fallimento di un’attività prima ancora che il lavoro sia iniziato.
• La mancanza di competenza viene compensata parlando troppo.
• Con il tempo, il responsabile in particolare viene dipinto come il «colpevole».
• A differenza di chi è davvero in difficoltà, questo comportamento non migliora neppure dopo un feedback diretto.

Ma per verificare i sospetti servono tracce digitali.

Vediamo gli strumenti più comuni per misurare le prestazioni nell’ingegneria e se possono aiutarci a scovare i fantasmi.

Prima di confrontarli, devo dichiarare l’ovvio conflitto di interessi: state leggendo il blog ufficiale di DevGhost e io sono il fondatore del prodotto. Questo è il punto di vista di un autore, non uno studio indipendente.

Per valutare l’ingegneria del software in sé — non l’azienda o il prodotto nel suo complesso — uso una semplice triade: velocità, qualità e volume. Le metriche DORA ci parlano della velocità; test e difetti della qualità. Il volume è più difficile. È il terreno meno battuto — ed è qui che tendono a nascondersi i fantasmi che stiamo cercando.

DORA: velocità e affidabilità dei rilasci

DORA mostra con quale velocità e affidabilità un team porta le modifiche in produzione. Il modello usa cinque metriche: il tempo dal commit alla produzione, la frequenza dei deployment, la percentuale di deployment che causano malfunzionamenti, il tempo di ripristino e la quota di rilavorazioni non pianificate.

È una buona misura del processo di delivery, ma non del contributo individuale. Se una persona fa il lavoro di tre mentre un’altra si nasconde dietro il risultato complessivo del team, DORA non lo rivela.

Queste metriche sono anche KPI meravigliosamente comodi. In un’azienda per cui ho lavorato, le spremavamo dal 2018 — riuscendo a far diventare verde ogni dashboard e a rendere tutti felici. Il modello DORA attuale.

Test e difetti: quanto è stato fatto bene il lavoro

I metodi sono consolidati e funzionano nella pratica. La qualità si controlla con code review, test e analisi statica; le conseguenze si monitorano attraverso difetti e incidenti.

Ma questi segnali non dicono nulla sul volume. Una modifica minuscola e impeccabile farà diventare verde ogni indicatore — e il fantasma resterà invisibile.

Jira e story point: quanti ticket sono stati chiusi

Jira mostra ticket chiusi e story point, ma le stime provengono dal team stesso. Lo stesso lavoro può essere valutato tre punti o tredici, suddiviso in cinque ticket o accorpato in uno solo.

Gli story point sono utili per pianificare, ma inaffidabili come misura del contributo individuale. Appena i punti diventano l’obiettivo, le persone cominciano a ottimizzare i punti.

Anche questi sono KPI molto comodi. Si inseriscono dati e si spostano ticket soltanto per superare i quality gate. Una gran quantità di lavoro manuale inutile.

Commit e righe di codice: fatti senza contesto

Git non dipende dalle stime del team, quindi contare commit e righe è allettante. Ma cinque commit possono rappresentare una minuscola correzione, mentre un solo squash commit può rappresentare una settimana di lavoro.

Formattazione, codice generato, copie e spostamenti gonfiano il conteggio delle righe, mentre una correzione difficile può essere lunga appena dieci righe.

Swarmia, LinearB e Waydev: l’intero sistema di ingegneria in un solo posto

Swarmia, LinearB e Waydev riuniscono Git, strumenti di gestione delle attività e CI/CD. I responsabili possono vedere metriche DORA, code delle review, tempi di consegna delle modifiche e risultati dei sondaggi.

Offrono una visione utile del sistema di ingegneria — e spesso rivelano che il problema si trova nel processo, non in una persona. Ma misurare il volume di lavoro di un singolo sviluppatore su una scala comparabile non è la domanda centrale a cui queste piattaforme cercano di rispondere. Swarmia, LinearB, Waydev.

GitClear: ciò che rimane dopo il rumore del codice

GitClear distingue tra codice aggiunto, spostato e copiato, esclude i file generati e considera se il nuovo codice è stato poi riscritto o eliminato.

Da qui nasce Diff Delta, l’unità proprietaria di GitClear per le modifiche significative che restano nella base di codice. Il codice copiato o scartato rapidamente pesa meno di una modifica compatta che continua a funzionare in produzione. Come funziona Diff Delta.

Diff Delta non risponde alla domanda su quanto lavoro sia stato necessario. Dice quante modifiche significative sono rimaste dopo il rumore e le rilavorazioni. Il punto di forza di GitClear è misurare la durata e la qualità del codice e analizzare l’impatto dell’IA.

Ora ci stiamo avvicinando. Il servizio pubblica benchmark, ma Diff Delta resta una sua unità: un numero come 10.000 dice poco senza il confronto giusto e senza conoscere la metodologia. Non c’è un riferimento chiaro come «100% è la norma». Benchmark di Diff Delta.

BlueOptima: la stessa domanda su scala aziendale

Conosco BlueOptima in prima persona. Ho iniziato a lavorare con la piattaforma nel 2019. È stata questa esperienza a ispirarmi nella creazione del mio prodotto.

L’algoritmo Coding Effort analizza ogni modifica al codice sorgente attraverso un insieme di metriche statiche, tenendo conto di dimensioni, complessità e relazione con il resto del codice. Poi esprime il risultato in ore.

Questo permette di confrontare sviluppatori di team e stack tecnologici diversi, anche rispetto a un benchmark globale. Per me è stato il primo tentativo convincente di rispondere non alla domanda «Quante righe ha scritto questo sviluppatore?», ma a «Quanto lavoro sostanziale rappresentano queste modifiche?» Metodologia di BlueOptima, benchmark globale.

Nel mio caso, accedere a quelle funzionalità enterprise ha richiesto un’implementazione piuttosto impegnativa: bisognava installare un agente all’interno di un ambiente di rete chiuso, il prezzo era elevato e i risultati richiedevano l’interpretazione di un esperto.

Per un’azienda con migliaia di sviluppatori, può essere giustificato. Per una startup o un piccolo team, probabilmente no. Quel divario è poi diventato uno dei motivi per cui esiste DevGhost.

Lo stesso metro, senza gara d’appalto

Quando ho creato DevGhost, non volevo costruire l’ennesima piattaforma tuttofare piena di ogni metrica di ingegneria immaginabile.

Volevo la stessa risposta fornita da BlueOptima — quanto lavoro sostanziale si nasconde dietro le modifiche —, ma in una forma che il fondatore di una startup o un piccolo team potesse usare senza una gara d’appalto, una lunga implementazione o una squadra di consulenti.

La logica è semplice: DevGhost analizza le modifiche stesse — ciò che è stato aggiunto, eliminato e ristrutturato e quanto è stato difficile creare e verificare il risultato. Formattazione, spostamenti di codice, sostituzioni automatiche in massa e codice generato vengono separati dal lavoro sostanziale.

Il risultato è una stima dell’impegno espressa in ore equivalenti: il tempo che impiegherebbe uno sviluppatore di livello intermedio, che conosce la base di codice e lavora senza IA, per scrivere lo stesso codice. Non è il tempo realmente trascorso alla tastiera, né una valutazione della qualità o del valore commerciale del codice. È un metro comune per confrontare le modifiche. Scopri di più sulla metodologia di DevGhost.

Ghost% confronta questa stima con il risultato atteso da uno sviluppatore di livello intermedio, tenendo conto della quota di tempo che la persona dedica realmente allo sviluppo. Un risultato del 100% significa che è in linea con la norma. Un risultato inferiore è un motivo per indagare; uno superiore merita di essere studiato e magari trasformato in una best practice.

Il benchmark presuppone intenzionalmente un lavoro senza IA. DevGhost non cerca di stabilire chi abbia scritto uno specifico pezzo di codice — una persona, Copilot o un agente autonomo. Valuta le modifiche finali: quanto impegno sarebbe servito a uno sviluppatore di livello intermedio per crearle e verificarle senza IA?

Questo significa che l’effetto dell’IA non scompare dentro la metrica. Diventa visibile. Se, in un certo periodo, uno sviluppatore crea e verifica un lavoro che prima avrebbe richiesto due o tre volte più impegno, Ghost% lo riflette. Formattazione, generazione in massa e altre forme di rumore nel codice non dovrebbero produrre lo stesso effetto.

E chi giudica il giudice?

La domanda più ovvia è: perché qualcuno dovrebbe fidarsi di una stima generata da una macchina? La risposta breve è che nessuno dovrebbe fidarsene ciecamente.

Valutare la difficoltà di un lavoro è soggettivo per definizione. Lo abbiamo verificato chiedendo a diversi sviluppatori esperti di stimare le stesse modifiche — e abbiamo ricevuto numeri sensibilmente diversi. Ognuno ha un ritmo diverso, esperienze diverse e una propria idea di ciò che è difficile.

Anche DevGhost può sbagliare. Il suo vantaggio non sta nell’accesso a una qualche verità assoluta. Sta nel fatto che ogni modifica viene valutata con lo stesso metro — senza favoritismi, stanchezza o un’opinione preconcetta sul suo autore.

Per questo Ghost% è un segnale, non un verdetto. Un risultato basso può indicare un contributo debole, ma può anche essere spiegato dalle responsabilità di un team lead, dal lavoro di architettura, dal mentoring, dagli incidenti o dai blocchi.

Il numero indica dove fare una domanda. Il responsabile deve comunque trovare la risposta — ma ora dispone di un secondo parere indipendente, invece della sola intuizione.

«So già come lavora ogni persona del mio team»

Uno dei clienti di DevGhost guida l’ingegneria di un’azienda di IA in rapida crescita. All’inizio era scettico sull’idea stessa di misurare le prestazioni nell’ingegneria. La sua posizione era semplice: un buon responsabile tecnico sa già come lavora ogni persona, senza bisogno di una dashboard.

Abbiamo analizzato la cronologia di un repository che conosceva bene. C’erano già dubbi su tre sviluppatori: i loro ticket avanzavano lentamente, ma lavoravano su un servizio separato, il che rendeva difficile confrontarli con il resto del team. DevGhost ha mostrato risultati costantemente bassi per tutti e tre per circa sei mesi.

In seguito, quando gli sviluppatori hanno iniziato ad andarsene, è emerso che per tutto quel periodo stavano anche costruendo prodotti propri. DevGhost non poteva conoscerne il motivo. Ha semplicemente portato alla luce qualcosa che il conteggio dei commit, le pull request e le conversazioni quotidiane su Slack non avevano mostrato: il loro volume di lavoro era notevolmente inferiore alle attese.

Ma l’analisi non si è trasformata in una lista di licenziamenti. Per altri due sviluppatori, un risultato basso ha permesso di dare un feedback specifico, indagare le cause e migliorare le prestazioni. Entrambi sono rimasti nel team.

Anche gli sviluppatori che considerava forti sono comparsi esattamente dove se li aspettava. E ora poteva vedere non solo chi superava le aspettative, ma con quale costanza.

Un singolo caso, naturalmente, non dimostra che il metodo sia accurato. Ciò che ha sorpreso il cliente è stata la forte corrispondenza tra il quadro generale e quanto prima era noto soltanto a livello intuitivo — e che, in alcuni casi, è diventato evidente solo con il senno di poi.

E se uno sviluppatore ottenesse i risultati di tre persone?

La caccia ai fantasmi è la parte di questa storia che attira di più l’attenzione. Ma la parte alta del grafico potrebbe essere ancora più utile.

Se uno sviluppatore produce con costanza risultati molte volte superiori alla media, vale la pena capire esattamente come ci riesce.

Oggi la domanda non è più se uno sviluppatore usi l’IA — per molti è diventata una normale parte del lavoro. La domanda è con quanta efficacia trasformi gli agenti in capacità aggiuntiva di delivery.

Una persona si ferma al completamento automatico. Un’altra sa fornire agli agenti il contesto giusto, definire regole chiare, gestire più attività in parallelo e controllare con cura il risultato. Lo stesso accesso all’IA può quindi produrre incrementi di produttività radicalmente diversi.

Un Ghost% elevato aiuta a individuare gli sviluppatori che stanno già ottenendo ottimi risultati da questa collaborazione tra persona e agente — e a capire quali pratiche potrebbe adottare il resto del team.

Se il risultato elevato è confermato dalla qualità del lavoro e dalla valutazione del responsabile, quello sviluppatore va valorizzato, trattenuto e preso in considerazione per una promozione. Le sue pratiche vanno studiate e diffuse nel team.

Non trasformate il metro in un’arma

Ogni metrica incontra lo stesso destino: prima o poi, qualcuno cerca di trasformarla in un KPI. Ghost% non è adatto a questo scopo.

Fate di Ghost% un KPI di team e le persone inizieranno a ottimizzare il lavoro in funzione della metrica. Pubblicate una classifica e la fiducia sparirà. Trasformate il punteggio in un pulsante per licenziare e gli errori diventeranno inevitabili.

Stabilirei quattro regole:

• Non traete conclusioni da una singola misurazione o da un periodo breve.
• Considerate il ruolo della persona, la quota di tempo dedicata allo sviluppo e il lavoro che avviene fuori dal codice.
• Mostrate il risultato allo sviluppatore e dategli la possibilità di spiegare il contesto.
• Non usate Ghost% come unico fondamento per una decisione sul rapporto di lavoro.

Se un risultato basso persiste, il responsabile deve prima indagarne le ragioni. Forse la persona è davvero in difficoltà. Oppure sta lavorando all’architettura, gestisce gli incidenti altrui o è bloccata dai processi del team.

Se il problema viene confermato, serve un piano di miglioramento specifico e una nuova valutazione dopo un periodo concordato.

Rifiutare le metriche non elimina la valutazione delle persone. Lascia soltanto sensazioni, storie raccontate negli stand-up e preferenze personali del responsabile.

Velocità, qualità e volume richiedono strumenti diversi. DORA mostra come le modifiche arrivano in produzione. Test e difetti mostrano la qualità. DevGhost aggiunge una stima del lavoro che sta dietro alle modifiche del codice.

Nessuna di queste metriche dovrebbe prendere decisioni al posto del responsabile.

Il valore di un numero non sta nel pronunciare un verdetto. Sta nel far cominciare prima una conversazione difficile — e nel basarla sui fatti.

Come valutate il volume di lavoro degli sviluppatori e dove tracciate il confine tra trasparenza utile e sorveglianza?