Els KPI d'enginyeria que importen de veritat
Una vegada vaig ser en una reunió de consell on un VP of Engineering va ensenyar un dashboard amb dotze mètriques. Línies de codi per desenvolupador. PRs per sprint. Story points completats. Tot en verd. El consell va assentir.
Dos mesos més tard, el producte encara no podia donar d'alta un client sense un pedaç manual, els desplegaments es trencaven una setmana sí i una no, i dos enginyers sènior ja feien entrevistes fora.
El dashboard mesurava activitat. Ningú no mesurava si l'organització d'enginyeria estava sana, era productiva o millorava. Aquesta és la trampa: els equips trien les mètriques fàcils de recollir, no les que els diuen alguna cosa útil.
Les mètriques que de debò et diuen alguna cosa
Mètriques DORA: la teva línia de base de lliurament
Ja he escrit a fons sobre les mètriques DORA, així que no repetiré tot l'argument aquí. Però les quatre mètriques DORA — Freqüència de Desplegament, Lead Time per a Canvis, Mean Time to Restore i Change Failure Rate — són el més semblant que tenim a una mesura validada científicament del rendiment en el lliurament de programari.
Continuen sent els fonaments. Si encara no en fas el seguiment, comença per aquí abans d'afegir res més. Et diuen si el teu equip pot publicar de manera fiable i recuperar-se de pressa, que és la base de tota la resta.
Cycle time: de la idea a producció
El cycle time va més enllà del lead time de DORA. Mesura el recorregut sencer des de «hem decidit construir això» fins a «és a producció i els usuaris ho toquen». Hi entren les decisions de producte, els traspassos de disseny, els aclariments d'especificació — tots els colls d'ampolla que no són codi i que els equips d'enginyeria hereten.
Quan el cycle time és alt però el lead time de DORA és baix, el problema no és l'execució d'enginyeria. És tot el que hi ha abans: especificacions poc clares, aprovacions lentes, colls d'ampolla de disseny o massa coses obertes alhora. El cycle time revela la fricció de l'organització, no només la del pipeline.
Per seguir-lo, registra el moment en què un tiquet passa de «llest per desenvolupar» a «desplegat». La majoria d'eines de gestió de projectes ho poden treure amb una configuració mínima.
Incidents amb impacte en el client
No tots els incidents són iguals. Una tasca en segon pla que falla i es reintenta amb èxit no és el mateix que el checkout caigut durant 40 minuts un divendres a la tarda. El que importa és la freqüència i la gravetat dels incidents que els usuaris noten de debò.
Segueix dues coses:
- Freqüència d'incidents — quants incidents amb impacte en el client hi ha cada mes?
- Distribució de la gravetat — són SEV-1 (crítics per al negoci) o SEV-3 (degradació menor)?
Un equip amb dos SEV-3 al mes està en una posició radicalment diferent que un amb dos SEV-1 al mes, encara que el recompte sigui idèntic. Agregar sense tenir en compte la gravetat no vol dir res.
La tendència importa més que el número absolut. Els incidents baixen amb el temps? La gravetat es desplaça cap avall? Això et diu si les inversions en fiabilitat estan donant fruit.
Temps fins al primer valor de les noves incorporacions
Aquesta està infravalorada i gairebé ningú no la segueix: quant triga un enginyer nou a posar a producció alguna cosa amb substància?
No «quant triga a fusionar la correcció d'un typo». Quant triga a lliurar una peça de feina de veritat: una funcionalitat, la correcció d'un bug amb impacte de negoci, una millora d'infraestructura significativa.
Si als enginyers nous els calen sis setmanes per publicar la primera contribució real, tens un problema d'onboarding, un problema de complexitat del codi, o totes dues coses. Els millors equips que he vist aconsegueixen que les noves incorporacions publiquin la primera setmana. No perquè escatimin qualitat, sinó perquè han invertit en documentació, en experiència de desenvolupament i en responsabilitats clares.
Aquesta mètrica també et diu alguna cosa de la qualitat de la contractació. Si un enginyer triga tres mesos a ser productiu sigui quina sigui la seva seniority, el problema segurament és el teu entorn, no la persona.
Satisfacció i compromís de l'equip d'enginyeria
Ja ho sé: sona a mètrica tova. Però la retenció d'enginyers és una de les partides més cares que no estàs seguint, i quan algú presenta la dimissió, el mal ja està fet. Per experiència, substituir un enginyer sènior et costa sis mesos de sou i dotze mesos de context.
Fes una enquesta de clima cada trimestre. Cinc o set preguntes: creus en el que estem construint? Tens les eines per fer la teva millor feina? Tens la sensació que estàs creixent? Recomanaries aquest equip a un amic? Segueix les tendències. Una tendència a la baixa durant dos trimestres fa saltar totes les alarmes.
Les mètriques perilloses
Algunes mètriques no és que no ajudin: fan mal activament als equips quan la direcció s'hi fixa.
Línies de codi. Un desenvolupador que esborra 500 línies de codi mort i simplifica un mòdul ha fet una feina més valuosa que un altre que n'ha escrit 500 de noves per resoldre un problema que es podia haver evitat. Mesurar línies de codi incentiva el bloat.
Recompte de commits. Fàcil de manipular, trivial d'inflar, i no et diu res de la qualitat ni de l'impacte de la feina. Un desenvolupador que treballa en un problema arquitectònic dur pot fer tres commits en una setmana. Un que produeix boilerplate en pot fer trenta. Els tres commits probablement valen més.
Mètriques d'output individual. Classificar desenvolupadors per nombre de PRs o de tiquets tancats crea una competició que destrueix la col·laboració. Les millors cultures són d'equip. El rànquing individual empeny la gent cap al comportament d'heroi i l'allunya de les revisions de codi, del mentoratge i d'ajudar els companys a desencallar-se.
Hores registrades. Mesuren presència, no productivitat. Els enginyers sènior sovint fan la feina de més impacte amb menys hores. Si mesures hores, estàs gestionant una cadena de muntatge.
Com presentar mètriques a la direcció sense que acabin manipulades
El consell vol saber tres coses: l'equip és efectiu? Està millorant? On són els riscos?
Aquesta és l'estructura que faig servir:
Rendiment de lliurament — mètriques DORA, amb tendència trimestral. Mostra cap on va la corba, no només el número. «Aquest trimestre la freqüència de desplegament ha passat de setmanal a diària, i la taxa de fallades en canvis ha baixat del 22% a l'11%.» Això és una història que el consell pot seguir.
Qualitat i fiabilitat — incidents amb impacte en el client, amb tendència mensual i desglossament per gravetat. Si els incidents pugen, explica per què (una àrea de funcionalitat nova, reptes d'escala) i què hi estàs fent.
Salut de l'equip — temps fins al primer valor de les incorporacions recents, més la tendència del compromís. Són indicadors avançats. Un equip sa, amb un bon onboarding i un compromís alt, lliurarà. Un equip cremat amb un onboarding trencat és un risc, encara que l'output actual sembli bo.
Una cosa amb què cal anar amb compte: presenta mètriques d'equip, mai mètriques individuals. Tan bon punt un conseller vegi una llista de desenvolupadors ordenats per rendiment, et demanarà que gestionis a partir d'aquesta llista. I llavors la mètrica es converteix en l'objectiu, l'objectiu es manipula i has perdut el senyal del tot.
Limita el dashboard a cinc o sis mètriques. Si et calen dotze mètriques per explicar com va l'enginyeria, és que no entens com va l'enginyeria.
La mètrica que hi ha darrere la mètrica
Tota mètrica és un proxy. Les mètriques DORA són un proxy de la capacitat de lliurament. El recompte d'incidents, un proxy de la fiabilitat. Les puntuacions de compromís, un proxy del risc de rotació. Cap no captura la imatge completa per si sola.
L'habilitat real del lideratge d'enginyeria és saber de quins proxies fiar-se, quan cal investigar més a fons i quan un número et diu el que vols sentir en lloc del que passa de debò.
A Conectia, quan integrem enginyers sènior en un equip, sovint es converteixen en el catalitzador d'una millor manera de mesurar — no perquè instal·lin dashboards, sinó perquè porten l'hàbit de preguntar «com sabem que això funciona?». Han vist prou equips per saber quins senyals importen i quins són soroll. Aquesta mentalitat no te la dona cap mètrica.
Vols enginyers que aportin el criteri de saber què mesurar i què ignorar? Parla amb un CTO.
