Metriche di Engineering Senza Jira
Non hai bisogno di Jira per misurare ciò che conta. Come monitorare la salute del team engineering da Git, CI e gli strumenti già in uso.
By Ellis Keane · 2026-03-23
I team piccoli che ottengono la migliore visibilità di engineering tendono ad essere quelli che hanno smesso di inseguire le metriche che Jira vuole che traccino.
Mi rendo conto che sembra che stia solo facendo il contrario per il gusto di farlo – e onestamente, forse un po' lo è. Ma ho trascorso quasi tre anni a mantenere fedelmente sprint board, a rifinire backlog e ad aggiornare stime su ticket che erano già a metà lavoro prima che qualcuno aprisse Jira quella mattina. Ogni due settimane ci sedevamo in una stanza (beh, su Zoom – era il 2023) e fissavamo un grafico di velocity che non ci diceva assolutamente nulla che non sapessimo già parlandoci tra di noi. Le metriche di engineering senza Jira non è qualcosa che stavo cercando. È quello che è successo quando ho smesso di fingere che i grafici di velocity mi stessero dicendo qualcosa di utile.
Se il tuo team è abbastanza piccolo da stare attorno a un tavolo, probabilmente non hai bisogno di Jira per sapere come stai andando. Hai bisogno di segnali migliori dagli strumenti che già stai usando.
Questo non è un articolo "Jira fa schifo". Jira è un buon strumento per le organizzazioni che hanno bisogno di un tracciamento di tipo Jira (e a una certa scala, ne hanno genuinamente bisogno). Ma se sei un engineering manager in una startup da 10 a 40 persone e stai pagando Jira esclusivamente per produrre grafici di velocity, è un po' come comprare un forno industriale per riscaldare il pranzo.
"Pagare per Jira esclusivamente per produrre grafici di velocity è un po' come comprare un forno industriale per riscaldare il pranzo." attribution: Chris Calo
Cosa Misurano Davvero le Metriche di Jira
Diciamolo chiaramente: la maggior parte delle metriche Jira misura l'utilizzo di Jira, non l'output di engineering. Gli story point misurano la capacità del team di stimare gli story point. La velocity misura la regolarità con cui il team riempie gli sprint alla stessa capacità circa. I burndown chart misurano se qualcuno si è ricordato di spostare i ticket sulla board il giovedì pomeriggio.
Nessuna di queste è totalmente inutile. Ma sono metriche di processo travestite da metriche di produttività degli sviluppatori, e il divario tra le due è dove gli engineering manager perdono il filo.
Sono stato quell'EM che trascorre quasi un'ora prima di una riunione con gli stakeholder a manipolare dati Jira per una presentazione che mostra "siamo in carreggiata". Lo stakeholder annuisce, fa una domanda sul bug di login di martedì scorso, e la riunione finisce. L'ora era per la presentazione. La vera risposta era "chiedi all'engineer".
Se le tue metriche richiedono più manutenzione del lavoro che misurano, le metriche sono il problema.
Tempo di Ciclo da Git, Non dai Ticket Board
Per i piccoli team di prodotto, il tempo di ciclo è di solito la metrica con il segnale più alto che puoi monitorare. Misura la durata dal primo commit al deploy in produzione, e puoi ricavarlo interamente dalla tua cronologia Git e dalla pipeline CI – nessun ticket board necessario.
I componenti:
- Timestamp del primo commit su un branch o PR
- Timestamp del merge della PR
- Timestamp del deploy (dal tuo CI/CD – GitHub Actions, CircleCI, o qualsiasi altra cosa tu stia usando)
Il delta tra 1 e 3 è il tuo tempo di ciclo. Dividilo in segmenti – tempo di codifica (dall'1 all'apertura della PR), tempo di revisione (dall'apertura della PR al merge) e coda di deploy (dal merge alla produzione) – e hai una diagnosi che ti dice dove il lavoro si inceppa davvero.
Quando l'ho fatto per la prima volta per il nostro team, i numeri erano genuinamente sorprendenti. Avevo assunto che il tempo di revisione fosse il nostro collo di bottiglia (tutti lo assumono sempre, vero?). Si è scoperto che la nostra fase di codifica fino alla PR era a posto, le revisioni erano a posto, e stavamo perdendo in media circa due giorni tra il merge e il deploy perché il nostro ambiente di staging era instabile e nessuno aveva prioritizzato la correzione. Un grafico di velocity non avrebbe mai rivelato questo.
Come Misurarlo
Se usi GitHub, puoi estrarlo con la CLI:
```bash
Ottieni le PR unite negli ultimi 30 giorni
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Per i timestamp di deploy, la maggior parte dei sistemi CI li espone tramite API o webhook. Mappa i SHA di merge delle PR agli eventi di deploy, e hai il tempo di ciclo segmentato per fase.
Suggerimento: Se il tuo CI non espone i timestamp di deploy in modo pulito, un approccio semplicissimo è un bot Slack che pubblica nel canale #deploys con il SHA del commit. Ottieni timestamp, un log leggibile da un umano e – come effetto collaterale – un canale che ti dice quanto spesso stai rilasciando.
Throughput delle Revisioni del Codice
Il throughput delle revisioni – il numero di PR revisionate per engineer a settimana, e il tempo mediano dall'apertura della PR alla prima revisione – dice di più sulla salute del team di qualsiasi metrica di sprint. È sottovalutato.
Perché? Perché il comportamento nelle revisioni è un indicatore anticipatore. Quando i tempi di revisione aumentano, di solito significa che gli engineer sono sovraccarichi, stanno facendo troppi cambi di contesto, o – e questo è quello scomodo – stanno evitando il codice degli altri. Qualsiasi di questi vale la pena sapere prima che si manifesti come una scadenza mancata due settimane dopo.
GitHub ti fornisce questi dati tramite la sua API. I campi chiave sono createdAt sulla PR e submittedAt sul primo evento di revisione.
Il numero che tengo d'occhio è le ore mediane alla prima revisione. Dalla nostra esperienza in diversi team piccoli, una cadenza di revisione sana tende a stare sotto circa 8 ore. Quando supera costantemente un giorno, qualcosa di strutturale è cambiato – e qualunque cosa sia, è invisibile su Jira.
Il Rapporto Riunioni-su-Decisioni
Questa non è una metrica di engineering tradizionale, e devo essere diretto: è un'euristica approssimativa, non un KPI. Ma per i team piccoli, la trovo sorprendentemente rivelatrice.
Conta le riunioni che il tuo team ha avuto questa settimana. Conta le decisioni concrete che ne sono uscite (non "dovremmo esaminare X" – decisioni vere con responsabili e passi successivi). Dividi il secondo per il primo.
Se meno della metà delle tue riunioni ha prodotto una decisione, vale la pena chiedersi se quelle riunioni stanno guadagnando il loro tempo. Alcune riunioni esistono per ridurre il rischio o condividere il contesto, ed è legittimo – non tutto deve terminare con una risoluzione. Ma quando inizi a monitorare questo anche informalmente (tenevo letteralmente un conteggio nel mio taccuino), sviluppi un senso per quali riunioni sono generative e quali sono solo rituali che nessuno ha mai messo in discussione.
Ho monitorato questo per circa un mese, e ha cambiato il modo in cui programmavo le riunioni più di qualsiasi articolo sulla produttività. Quando riesci a vedere che il tuo standup del lunedì ha prodotto esattamente zero decisioni per tre settimane di fila, cancellarlo smette di sembrare radicale.
Costruire Metriche di Engineering Senza Jira: una Dashboard Leggera
Non hai bisogno di uno strumento BI per questo. Una pagina Notion, un foglio Google o un post settimanale su Slack con quattro numeri è sufficiente:
- Tempo di ciclo mediano (da Git/CI) – stiamo rilasciando più velocemente o più lentamente?
- Tempo mediano alla prima revisione (da GitHub) – il team revisiona tempestivamente?
- Frequenza di deploy (da CI o canale #deploys) – quanto spesso stiamo rilasciando?
- Rapporto riunioni-su-decisioni (conteggio manuale) – le nostre riunioni si guadagnano il loro posto?
Quattro numeri, tutti ricavabili dagli strumenti che già possiedi, nessuno dei quali richiede di mantenere una board Jira. Aggiornali settimanalmente. Se un numero va nella direzione sbagliata per due settimane consecutive, indaga. Se rimane stabile, lascialo stare.
L'obiettivo non è costruire un sistema di sorveglianza (per favore non farlo – i tuoi engineer ti odieranno, e avranno ragione). La visibilità del team di engineering dovrebbe provenire dal lavoro stesso, non dal chiedere alle persone di riferire sul lavoro.
Le migliori metriche di engineering sono poco costose da raccogliere, difficili da manipolare e ti dicono qualcosa su cui puoi agire. Gli story point falliscono su tutti e tre i fronti.
Quando Hai Davvero Bisogno di un Ticket Board
Ho detto che questo non è un articolo "Jira fa schifo", e lo intendevo. Ci sono situazioni legittime in cui monitorare le metriche senza uno strumento di gestione dei progetti diventa genuinamente irresponsabile:
- Settori con forti requisiti di conformità dove le tracce di audit sullo stato dei task sono legalmente obbligatorie
- Organizzazioni di engineering più grandi dove le dipendenze tra team rendono il coordinamento informale insostenibile
- Organizzazioni con funzioni di gestione dei progetti dedicate che hanno bisogno di una fonte canonica di verità tra i team
Se questa è la tua situazione, Jira (o Linear, o Shortcut) è la scelta giusta. Quello che sostengo è che per i team piccoli, mantenere uno strumento pesante esclusivamente per le metriche è un cattivo compromesso. Finisci per ottimizzare per il modello di lavoro dello strumento piuttosto che per il lavoro reale del tuo team.
E onestamente? Anche i team che usano Jira trarrebbero beneficio dall'integrare i dati del loro board con le metriche derivate da Git di cui sopra. Jira ti dice quello che le persone dicono di star facendo. Git ti dice quello che stanno facendo davvero. Entrambi sono utili, ma solo uno è immune al teatro degli aggiornamenti di stato.
Se la questione delle metriche continua a emergere nella tua startup, prova la dashboard a quattro numeri per un mese. Le metriche di engineering senza Jira possono sembrare lavorare senza rete di sicurezza – ma una volta che vedi quanto segnale vive nella tua cronologia Git e pipeline CI, ti chiederai cosa stesse aggiungendo il ticket board.
Individua automaticamente il tempo di ciclo, le PR bloccate e i colli di bottiglia nelle revisioni – senza script personalizzati né un Jira board.
Q: Si possono ottenere metriche di engineering significative senza uno strumento di gestione dei progetti? A: Sì. Il tempo di ciclo (primo commit fino al deploy), il throughput delle revisioni e la frequenza di deploy si trovano tutti nella tua cronologia Git e nella pipeline CI. Per team con meno di circa 40 engineer, tendono ad essere più precisi e più difficili da manipolare di qualsiasi cosa produca un ticket board – e non richiedono che qualcuno sposti le carte su una board per rimanere accurati.
Q: Sugarbug mostra le metriche di engineering automaticamente? A: Sugarbug si connette a GitHub, Linear, Slack e ai calendari per costruire un grafo della conoscenza dell'attività del tuo team. Segnala pattern come PR bloccate, colli di bottiglia nelle revisioni e decisioni non risolte – il che copre molti dei segnali descritti qui senza richiedere che tu scriva e mantenga script personalizzati contro l'API di GitHub.
Q: Come ottengo il consenso per smettere di usare Jira per le metriche? A: Inquadralo come un esperimento, non una rivolta. Esegui metriche derivate da Git accanto ai tuoi dashboard Jira esistenti per quattro settimane, poi confronta quali numeri hanno generato cambiamenti reali. Se le metriche Git si rivelano più azionabili (e dalla nostra esperienza, tendono ad esserlo), l'argomentazione si costruisce da sola.
Q: Qual è la differenza tra metriche di processo e metriche di performance? A: Le metriche di processo (story point, velocity, burndown) misurano la regolarità con cui un team segue un flusso di lavoro. Le metriche di performance (tempo di ciclo, frequenza di deploy, throughput delle revisioni) misurano ciò che il team consegna effettivamente e quanto velocemente. I team piccoli ottengono quasi sempre più segnale dalle seconde, perché le metriche di performance sono derivate dal lavoro stesso piuttosto che da aggiornamenti di stato manuali.