Mesures incidents, però ignores les mètriques que importen (i per això el teu equip no millora)

El 69% d'equips mesuren nombre d'incidents. Només el 12% fa servir mètriques custom que realment prediuen problemes. Resultat: saps quan falles, però no per què ni com evitar-ho.

La dada que t'hauria de preocupar

LeadDev acaba de publicar el seu Engineering Performance Report 2025 amb dades de 400 líders tècnics. Una pregunta destrossa l'autoengany col·lectiu de la indústria:

"Quines mètriques fa servir el teu equip per mesurar el performance dels sistemes?"

Les respostes:

• 69%: Nombre d'incidents
• 60%: Severitat dels incidents
• 51%: Compliment de SLAs
• 46%: Uptime
• 44%: Costos operacionals
• 12%: Mètriques custom

Traducció: 7 de cada 10 equips mesuren quantes vegades cau el sistema. Només 1 de cada 10 mesura el que realment prediu si caurà.

Si el teu dashboard principal és un comptador d'incidents, no estàs mesurant performance. Estàs mesurant fracassos.

Per què això és un problema (més gros del que sembla)

1. Les mètriques reactives no prevenen problemes

Mesurar incidents és com mesurar accidents de cotxe per millorar la conducció. Et diu que has xocat, no per què ni com evitar-ho.

El cicle viciós:

1. L'incident passa → el comptador puja
2. Post-mortem → "necessitem més monitoring"
3. Afegeixes més dashboards de... incidents
4. Següent incident → repetir

Resultat: Més dades del passat, zero capacitat de prevenir el futur.

2. Ignores les mètriques que sí que prediuen (i costen menys)

Segons el mateix report, només el 39% fa seguiment de l'"engineering time" (temps de l'equip en tasques).

Això és crític perquè:

• Un equip que inverteix el 60% del temps a "apagar focs" tindrà incidents
• Un equip que inverteix el 40% en deute tècnic reduirà incidents
• Però si no mesures el temps, no saps on el gastes

Exemple real (client nostre, fintech Series B):
Before: Mesuraven només incidents (5-8/mes)
After: Van afegir tracking del temps de l'equip → Van descobrir que el 70% del temps anava a "pedaços urgents" → Van reduir els pedaços al 30%, van augmentar el refactoring al 40% → Els incidents van baixar a 1-2/mes en 2 mesos.

No necessitaven més monitoring d'incidents. Necessitaven mesurar on gastaven el temps.

3. La paradoxa de l'uptime

El 46% d'equips mesuren uptime. Sona raonable, oi?

Problema: l'uptime és una mètrica de resultat, no de causa.

Escenari típic:

• El teu sistema té un 99.9% d'uptime (43 min de downtime/mes)
• Creus que vas bé
• Però aquest 99.9% amaga que:
  • El 80% de l'equip està en "mode bomber"
  • El deploy triga 6h per por de trencar
  • El deute tècnic creix sense control

Uptime alt ≠ sistema sa. Pot ser un equip exhaust sostenint un castell de cartes.

Les mètriques que SÍ que prediuen (i que ningú mesura)

Segons el LeadDev Report, aquestes són les mètriques menys seguides però més predictives:

1. Engineering time breakdown (el 39% ho mesura)

Què mesurar:

• % temps en noves features
• % temps en bugs/pedaços
• % temps en deute tècnic
• % temps a "apagar focs"

Per què importa: Si >50% del temps és reactiu (bugs + focs), el teu sistema està malalt encara que l'uptime sigui del 99.9%.

2. MTTD - Mean Time To Detect (el 23% ho mesura)

Què és: Temps entre que passa un problema i el detectes.

Per què importa: Un bug que triga 3 dies a detectar-se causa 10x més dany que un detectat en 10 minuts.

Benchmark: Good: <30 min MTTD per a issues crítics | Excellent: <5 min MTTD (monitoring proactiu + alerts)

3. Deployment frequency + lead time

Per què importa: Els equips que fan deploy 10x/dia tenen un 60% menys d'incidents que els equips que fan deploy 1x/setmana (DORA metrics).

Paradoxa: Més deploys = menys incidents (perquè els canvis petits són menys arriscats).

4. Custom metrics (només el 12% les fa servir)

Què són: Mètriques específiques del teu domini que prediuen problemes.

Exemples:

• E-commerce: "Checkout abandonment rate"
• Fintech: "Failed transaction retry rate"
• SaaS: "API error rate per client"

La mètrica invisible (que explica totes les altres): la càrrega cognitiva de l'equip

Hi ha una mètrica que gairebé ningú segueix però que explica per què les altres mètriques fallen: la càrrega cognitiva de l'equip.

Què és la càrrega cognitiva en equips de desenvolupament?

Definició: La quantitat d'informació que un developer ha de mantenir al cap per ser productiu.

Els 3 tipus de càrrega cognitiva (segons Team Topologies):

1. Càrrega intrínseca: Complexitat inherent de la tasca
2. Càrrega extrínseca: Soroll de l'entorn (eines mal configurades, deploys manuals)
3. Càrrega pertinent: Aprenentatge útil que queda

Com mesurar la càrrega cognitiva (sense enquestes complexes)

✅ Context switches per dia:

• <3 canvis/dia = càrrega manejable
• 5-7 canvis/dia = càrrega alta (productivitat -60%)
• >10 canvis/dia = equip col·lapsat

Com mesurar-ho: Track de tasques Jira/Linear per developer per dia + reunions al calendari.

✅ Time to productive (nou developer):

• <2 setmanes = arquitectura simple, bona documentació
• 4-6 setmanes = complexitat mitjana
• >8 setmanes = càrrega cognitiva brutal

✅ Tool proliferation:

• <5 eines = bé
• >10 eines = càrrega extrínseca brutal

La connexió oculta: Càrrega cognitiva → Incidents

Per què els equips amb alta càrrega cognitiva tenen més incidents:

1. Un developer exhaust comet errors: Càrrega cognitiva >80% → 3x més bugs introduïts
2. Zero temps per a la prevenció: Si el 70% del temps és firefighting, no hi ha espai mental per al refactoring
3. Pèrdua de context: Canviar de context 7x/dia → oblides edge cases, t'estalvies tests

DevEx: La mètrica que unifica totes les altres

Developer Experience (DevEx) no és "tenir un Slack bonic". És mesurar la fricció en la feina diària del developer.

Les 3 dimensions de DevEx (segons el SPACE framework):

1. Feedback loops: Quant triga un developer a validar el seu canvi?
   • Build time: <5 min = excel·lent, >15 min = fricció alta
2. Flow state: Quantes hores de feina profunda sense interrupcions?
   • <2h/dia = equip reactiu (càrrega cognitiva brutal)
   • 4-6h/dia = equip sa
3. Cognitive load: Quanta complexitat innecessària carrega el developer?

Alta càrrega cognitiva
  → Developer exhaust
    → Més bugs introduïts
      → Més incidents
        → Més firefighting
          → Menys temps per al refactoring
            → El deute tècnic creix
              → Deploy més arriscat
                → Més càrrega cognitiva
                  → [el cicle es repeteix]
          

Framework: Quines mètriques seguir (i en quin ordre)

Nivell 1: Bàsic (si no tens això, comença aquí)

• Uptime / downtime
• Nombre i severitat d'incidents
• MTTR (mean time to resolve)

Problema: Només mesures fracassos, no prevenció.

Nivell 2: Intermedi (aquí millores de veritat)

• MTTD (mean time to detect)
• Engineering time breakdown
• Deployment frequency + lead time
• Operational costs per servei

Benefici: Comences a veure patrons ABANS dels incidents.

Nivell 3: Avançat (aquí competeixes amb els top performers)

• Mètriques custom del teu domini
• Cost per feature
• % code coverage + mutation testing
• Change failure rate
• Context switches per developer (càrrega cognitiva)
• Feedback loop time (DevEx)
• Flow state hours (temps de feina profunda)

Benefici: Prediis problemes amb setmanes d'antelació i mesures la salut de l'equip, no només la del sistema.

Cas real: D'apagar focs a 0 incidents en 8 setmanes

Client: Scaleup healthtech Series B, 15 developers
Problema: 6-8 incidents/mes, equip exhaust

Fase 1: Diagnòstic (Setmana 1-2)

• Vam implementar tracking de l'engineering time
• Descobriment: 65% del temps en hotfixes i pedaços
• Root cause: No mesuraven MTTD ni deployment frequency

Fase 2: Mètriques predictives (Setmana 3-4)

• Vam afegir MTTD tracking: 4 hores de mitjana (dolent)
• Vam afegir deployment frequency: 2x/setmana (baix)
• Vam afegir custom metric: "API timeout rate per endpoint"

Fase 3: Acció (Setmana 5-8)

• Van prioritzar reduir el MTTD a <30 min (millor alerting)
• Van augmentar els deploys a 2x/dia (CI/CD refactor)
• Van monitoritzar l'API timeout → van detectar 3 endpoints problemàtics abans dels incidents

Resultats (2 mesos després):
• Incidents: 6-8/mes → 0-1/mes (-87%)
• MTTD: 4h → 15 min (-93%)
• Temps en hotfixes: 65% → 20% (-70%)
• Context switches: 8/dia → 4/dia (-50%)
• Flow state: 1.5h/dia → 5h/dia (+233%)

Inversió: 40h d'equip + €200/mes de tooling
ROI: ~120h/mes estalviades = €12k/mes

"Per fi treballem en features, no en focs"

Insight clau: Reduir els context switches va ser el canvi que va permetre tota la resta. Amb més flow state, van detectar problemes abans, van escriure millor codi, van reduir bugs.

Acció immediata: Què fer aquesta setmana

Dilluns (1h): Audita les teves mètriques actuals

Pregunta honesta: Quin % de les teves mètriques són reactives (incidents) vs predictives (MTTD, time breakdown, custom)?

Si >70% són reactives, estàs en mode bomber.

Dimarts (2h): Afegeix 1 mètrica predictiva

Tria'n una:

• Engineering time breakdown (més fàcil de començar)
• MTTD (més impacte si tens incidents freqüents)
• Deployment frequency (més impacte si els deploys són dolorosos)

Dimecres-Divendres (3h): Primera anàlisi

• Fes tracking de la mètrica durant 1 setmana
• Analitza les primeres dades
• Identifica 1 quick win

Conclusió: Deixa de comptar fracassos, comença a predir èxits

El problema de mesurar només incidents:

• Saps que has fallat
• No saps per què
• No pots evitar el pròxim

La solució:

• Mesura el temps de l'equip (per saber si estàs en mode reactiu)
• Mesura el MTTD (per detectar problemes abans que escalin)
• Mesura mètriques custom del teu domini (per predir problemes amb dies d'antelació)
• Mesura la càrrega cognitiva i el DevEx (per entendre la salut real del teu equip)

El canvi de mentalitat: De "quants incidents hem tingut?" a "quants incidents hem evitat?"