I KPI di Ingegneria che Contano Davvero
Una volta ho partecipato a una riunione del consiglio di amministrazione dove un VP of Engineering ha mostrato una dashboard con dodici metriche. Righe di codice per sviluppatore. Numero di PR per sprint. Story point completati. Tutto era verde. Il consiglio annuì.
Due mesi dopo, il prodotto non riusciva ancora ad acquisire un cliente senza un workaround manuale, i deploy si rompevano una settimana sì e una no, e due ingegneri senior avevano iniziato a fare colloqui altrove.
La dashboard misurava l'attività. Nessuno misurava se l'organizzazione di ingegneria fosse sana, produttiva o in miglioramento. Questa è la trappola: i team scelgono metriche facili da raccogliere piuttosto che metriche che dicano loro qualcosa di utile.
Le Metriche che Ti Dicono Davvero Qualcosa
Metriche DORA: La Tua Baseline di Consegna
Ho scritto in dettaglio delle metriche DORA in precedenza, quindi non ripeterò l'intero ragionamento qui. Ma le quattro metriche DORA — Frequenza di Deploy, Lead Time per i Cambiamenti, Mean Time to Restore e Change Failure Rate — sono la cosa più vicina che abbiamo a una misura scientificamente validata delle performance di consegna software.
Rimangono il fondamento. Se non le stai tracciando, inizia da lì prima di aggiungere altro. Ti dicono se il tuo team riesce a consegnare in modo affidabile e a riprendersi rapidamente, che è la baseline per tutto il resto.
Cycle Time: dall'Idea alla Produzione
Il cycle time va oltre il lead time di DORA. Misura l'intero percorso da "abbiamo deciso di costruire questo" a "è in produzione e gli utenti lo stanno usando". Questo cattura le decisioni di prodotto, i passaggi di design, i chiarimenti delle specifiche — tutti i colli di bottiglia non-codice che i team di ingegneria ereditano.
Quando il cycle time è alto ma il lead time DORA è basso, il problema non è nell'esecuzione tecnica. È in tutto ciò che viene prima: specifiche poco chiare, approvazioni lente, colli di bottiglia nel design, o troppe cose in corso contemporaneamente. Il cycle time rivela l'attrito organizzativo, non solo l'attrito della pipeline.
Traccialo marcando il tempo quando un ticket passa da "pronto per lo sviluppo" a "deployato". La maggior parte degli strumenti di project management può mostrarlo con una configurazione minima.
Incidenti con Impatto sui Clienti
Non tutti gli incidenti sono uguali. Un job in background che fallisce ma riprova con successo non è uguale a un checkout down per 40 minuti un venerdì pomeriggio. Ciò che conta è la frequenza e la gravità degli incidenti che gli utenti percepiscono realmente.
Traccia due cose:
- Frequenza degli incidenti — quanti incidenti con impatto sui clienti al mese?
- Distribuzione della gravità — sono SEV-1 (critici per il business) o SEV-3 (degrado minore)?
Un team che ha due SEV-3 al mese è in una posizione fondamentalmente diversa da un team che ha due SEV-1 al mese, anche se il conteggio è identico. Aggregare senza la gravità non ha senso.
La tendenza conta più del numero assoluto. Gli incidenti stanno diminuendo nel tempo? La gravità si sta abbassando? Questo ti dice se i tuoi investimenti in affidabilità stanno funzionando.
Tempo-fino-al-Primo-Valore per i Nuovi Assunti
Questa è sottovalutata e quasi nessuno la traccia: quanto tempo impiega un nuovo ingegnere a consegnare qualcosa di significativo in produzione?
Non "quanto tempo fino a quando fanno il merge di una correzione di typo". Quanto tempo fino a quando consegnano un lavoro reale — una funzionalità, un bug fix con impatto sul business, un miglioramento infrastrutturale significativo.
Se i nuovi ingegneri impiegano sei settimane per consegnare il loro primo contributo reale, hai un problema di onboarding, un problema di complessità della codebase, o entrambi. I team d'élite riescono a far consegnare i nuovi assunti nella prima settimana. Non perché tagliano i corner, ma perché hanno investito in documentazione, developer experience e ownership chiara.
Questa metrica ti dice anche qualcosa sulla qualità delle assunzioni. Se un ingegnere impiega tre mesi per diventare produttivo indipendentemente dalla seniority, il problema è probabilmente il tuo ambiente, non la persona.
Soddisfazione e Coinvolgimento dell'Ingegneria
Lo so — sembra soft. Ma la retention in ingegneria è una delle voci di costo più costose che non tieni traccia, e quando qualcuno si dimette, il danno è fatto. Sostituire un ingegnere senior costa sei mesi di stipendio e dodici mesi di contesto.
Fai un sondaggio pulse trimestrale. Da cinque a sette domande: Credi in quello che stiamo costruendo? Hai gli strumenti per fare il tuo lavoro migliore? Hai la sensazione di crescere? Raccomanderesti questo team a un amico? Traccia le tendenze. Una tendenza al ribasso per due trimestri è un allarme antincendio.
Le Metriche Pericolose
Alcune metriche non sono solo inutili — danneggiano attivamente i team quando il leadership le prende sul serio.
Righe di codice. Uno sviluppatore che elimina 500 righe di codice morto e semplifica un modulo ha fatto un lavoro più prezioso di uno che ha scritto 500 righe di nuovo codice per risolvere un problema che poteva essere evitato. Misurare le righe di codice incentiva il bloat.
Conteggio dei commit. Facile da manipolare, banalmente gonfiato, e non ti dice nulla sulla qualità o l'impatto del lavoro. Uno sviluppatore che lavora su un problema architetturale difficile potrebbe avere tre commit in una settimana. Uno sviluppatore che produce boilerplate potrebbe averne trenta. I tre commit valgono probabilmente di più.
Metriche di performance individuali. Classificare gli sviluppatori per numero di PR o ticket chiusi crea competizione che distrugge la collaborazione. Le migliori culture sono orientate al team. La classifica individuale spinge le persone verso il comportamento da eroe e lontano dalle code review, dal mentoring e dall'aiutare i colleghi a sbloccarsi.
Ore registrate. Misura la presenza, non la produttività. Gli ingegneri senior spesso fanno il loro lavoro più impattante nelle meno ore. Se stai misurando le ore, stai gestendo una catena di montaggio.
Presentare le Metriche al Leadership Senza Che Vengano Manipolate
Il consiglio vuole sapere tre cose: Il team è efficace? Sta migliorando? Dove sono i rischi?
Questa è la struttura che uso:
Performance di consegna — metriche DORA, con tendenza trimestrale. Mostra la direzione, non solo il numero. "La nostra frequenza di deploy è passata da settimanale a quotidiana questo trimestre, e il tasso di fallimento dei cambiamenti è sceso dal 22% all'11%." Questa è una storia che il consiglio può seguire.
Qualità e affidabilità — incidenti con impatto sui clienti con tendenza mensile, con ripartizione della gravità. Se gli incidenti aumentano, spiega perché (nuova area funzionale, sfide di scaling) e cosa stai facendo al riguardo.
Salute del team — tempo-fino-al-primo-valore per le assunzioni recenti, più le tendenze di coinvolgimento. Questi sono indicatori anticipatori. Un team sano con un onboarding solido e alto coinvolgimento consegnerà. Un team esaurito con una pipeline di onboarding rotta è un rischio, anche se l'output attuale sembra buono.
Una cosa a cui prestare attenzione: presenta metriche a livello di team, mai metriche individuali. Nel momento in cui un membro del consiglio vede una lista classificata di performance degli sviluppatori, ti chiederà di gestire in base a quella lista. E allora la metrica diventa l'obiettivo, l'obiettivo viene manipolato, e hai perso il segnale.
Mantieni la dashboard a cinque o sei metriche. Se hai bisogno di dodici metriche per spiegare come va l'ingegneria, non capisci come va l'ingegneria.
La Metrica Dietro la Metrica
Ogni metrica è un proxy. Le metriche DORA sono un proxy per la capacità di consegna. I conteggi degli incidenti sono un proxy per l'affidabilità. I punteggi di coinvolgimento sono un proxy per il rischio di retention. Nessuna cattura il quadro completo da sola.
La vera abilità nel leadership dell'ingegneria è sapere quali proxy fidarsi, quando approfondire l'indagine, e quando un numero ti sta dicendo quello che vuoi sentire piuttosto che quello che sta accadendo realmente.
In Conectia, quando integriamo ingegneri senior in un team, spesso diventano il catalizzatore per una migliore misurazione — non perché installino dashboard, ma perché portano l'abitudine di chiedersi "come facciamo a sapere che funziona?". Hanno visto abbastanza team da sapere quali segnali contano e quali sono rumore. Questa è una mentalità che non puoi ottenere da una metrica.
Vuoi ingegneri che portino il giudizio per sapere cosa misurare e cosa ignorare? Parla con un CTO — i nostri ingegneri senior LATAM hanno lavorato in abbastanza team da sapere quali KPI fanno davvero la differenza.
