Els KPIs d'Enginyeria que Realment Importen
Una vegada vaig assistir a una reunió de junta directiva on un VP of Engineering va mostrar un dashboard amb dotze mètriques. Línies de codi per desenvolupador. Nombre de PRs per sprint. Story points completats. Tot estava en verd. La junta va assentir.
Dos mesos després, el producte encara no podia incorporar un client sense una solució manual, els desplegaments fallaven cada dues setmanes i dos enginyers sènior havien començat a fer entrevistes en altres llocs.
El dashboard mesurava activitat. Ningú mesurava si l'organització d'enginyeria era saludable, productiva o millorava. Aquesta és la trampa — els equips trien mètriques fàcils de recollir en lloc de mètriques que els diguin alguna cosa útil.
Les Mètriques que Realment et Diuen Alguna Cosa
Mètriques DORA: La Teva Línia Base de Lliurament
He escrit sobre les mètriques DORA en profunditat anteriorment, així que no repetiré l'argumentari complet 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 proper que tenim a una mesura científicament validada del rendiment en el lliurament de programari.
Continuen sent el fonament. Si no les estàs fent seguiment, comença per aquí abans d'afegir res més. Et diuen si el teu equip pot lliurar de forma fiable i recuperar-se ràpidament, que és la línia base per a tot el que ve després.
Cycle Time: de la Idea a Producció
El cycle time va més enllà del lead time de DORA. Mesura el recorregut complet des de "hem decidit construir això" fins a "està en producció i els usuaris l'estan fent servir". Això captura les decisions de producte, els traspàs de disseny, l'aclariment d'especificacions — tots els colls d'ampolla que no són codi que els equips d'enginyeria hereten.
Quan el cycle time és alt però el lead time de DORA és baix, el problema no és en l'execució d'enginyeria. És en tot el que ve abans: especificacions poc clares, aprovacions lentes, colls d'ampolla en disseny, o massa coses en progrés alhora. El cycle time revela el fregament organitzatiu, no sols el fregament del pipeline.
Mesura'l amb marques de temps de quan un tiquet passa de "llest per al desenvolupament" a "desplegat". La majoria d'eines de gestió de projectes pot mostrar això amb una configuració mínima.
Incidents amb Impacte en Clients
No tots els incidents són iguals. Un treball en segon pla que falla però torna a intentar-ho 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 gravetat dels incidents que els usuaris realment senten.
Mesura dues coses:
- Freqüència d'incidents — quants incidents amb impacte en clients per mes?
- Distribució de gravetat — són SEV-1 (crítics per al negoci) o SEV-3 (degradació menor)?
Un equip que té dos SEV-3 per mes està en una posició fonamentalment diferent d'un equip que té dos SEV-1 per mes, tot i que el recompte sigui idèntic. Agregar sense gravetat no té sentit.
La tendència importa més que el nombre absolut. Els incidents estan disminuint amb el temps? La gravetat s'està reduint? Això et diu si les teves inversions en fiabilitat estan funcionant.
Temps-fins-al-Primer-Valor per a Noves Incorporacions
Aquesta està subestimada i quasi ningú la mesura: quant temps triga un nou enginyer a lliurar alguna cosa significativa a producció?
No "quant temps fins que fusionen una correcció de typo". Quant temps fins que lliuren un treball real — una funcionalitat, un bug fix amb impacte en el negoci, una millora d'infraestructura significativa.
Si als nous enginyers els cal sis setmanes per lliurar la seva primera contribució real, tens un problema d'onboarding, un problema de complexitat de la base de codi, o tots dos. Els equips d'élite aconsegueixen que les noves incorporacions lliurin en la primera setmana. No perquè tallin dreceres, sinó perquè han invertit en documentació, experiència del desenvolupador i propietat clara.
Aquesta mètrica també et diu alguna cosa sobre la qualitat de les contractacions. Si un enginyer tarda tres mesos a ser productiu independentment de la seniority, el problema és probablement el teu entorn, no la persona.
Satisfacció i Compromís d'Enginyeria
Ho sé — sembla tou. Però la retenció d'enginyeria és una de les línies de cost més cares que no mesures, i quan algú presenta la seva dimissió, el dany ja és fet. Substituir un enginyer sènior costa sis mesos de salari i dotze mesos de context.
Fes una enquesta de pols trimestral. De cinc a set preguntes: Creus en el que estem construint? Tens les eines per fer el teu millor treball? Tens la sensació de créixer? Recomanaries aquest equip a un amic? Mesura les tendències. Una tendència a la baixa durant dos trimestres és una alarma d'incendi.
Les Mètriques Perilloses
Algunes mètriques no sols són inútils — danyem activament els equips quan el lideratge els presta atenció.
Línies de codi. Un desenvolupador que elimina 500 línies de codi mort i simplifica un mòdul ha fet un treball més valuós que un que va escriure 500 línies de codi nou per resoldre un problema que s'hauria pogut evitar. Mesurar línies de codi incentiva el bloat.
Recompte de commits. Fàcil de manipular, trivialment inflat, i no et diu res sobre la qualitat o l'impacte del treball. Un desenvolupador treballant en un problema arquitectònic difícil podria tenir tres commits en una setmana. Un desenvolupador produint boilerplate podria tenir-ne trenta. Els tres commits probablement valen més.
Mètriques de rendiment individual. Classificar els desenvolupadors per recompte de PRs o tiquets tancats crea competència que destrueix la col·laboració. Les millors cultures estan orientades a l'equip. La classificació individual empeny les persones cap al comportament d'heroi i lluny de les revisions de codi, la mentoria i ajudar els companys d'equip a desbloquejar-se.
Hores registrades. Mesura presència, no productivitat. Els enginyers sènior sovint fan el seu treball més impactant en les menys hores. Si estàs mesurant hores, estàs gestionant una línia de muntatge.
Presentar Mètriques al Lideratge Sense Que Siguin Manipulades
La junta vol saber tres coses: És efectiu l'equip? Està millorant? On estan els riscos?
Aquí està l'estructura que faig servir:
Rendiment de lliurament — mètriques DORA, amb tendència trimestral. Mostra la direcció, no sols el número. "La nostra freqüència de desplegament va augmentar de setmanal a diària aquest trimestre, i la taxa de fallades en canvis va baixar del 22% a l'11%." Això és una història que la junta pot seguir.
Qualitat i fiabilitat — incidents amb impacte en clients amb tendència mensual, amb desglossat per gravetat. Si els incidents augmenten, explica per què (nova àrea de funcionalitats, reptes d'escalat) i el que estàs fent al respecte.
Salut de l'equip — temps-fins-al-primer-valor per a les incorporacions recents, més tendències de compromís. Aquests són indicadors avançats. Un equip saludable amb un onboarding sòlid i alt compromís lliurarà. Un equip esgotat amb un pipeline d'onboarding trencat és un risc, fins i tot si l'output actual sembla bé.
Una cosa de la qual cal tenir cura: presenta mètriques a nivell d'equip, mai mètriques individuals. En el moment que un membre de la junta vegi una llista classificada del rendiment dels desenvolupadors, et demanarà que gestionis per aquesta llista. I llavors la mètrica es converteix en l'objectiu, l'objectiu es manipula, i has perdut el senyal.
Mantén el dashboard en cinc o sis mètriques. Si necessites dotze mètriques per explicar com va l'enginyeria, no entens com va l'enginyeria.
La Mètrica Darrera de la Mètrica
Cada mètrica és un proxy. Les mètriques DORA són un proxy per a la capacitat de lliurament. Els recomptes d'incidents són un proxy per a la fiabilitat. Les puntuacions de compromís són un proxy per al risc de retenció. Cap captura el panorama complet per si sola.
L'habilitat real en el lideratge d'enginyeria és saber en quins proxies confiar, quan investigar més i quan un número t'està dient el que vols sentir en lloc del que realment passa.
A Conectia, quan integrem enginyers sènior en un equip, sovint es converteixen en el catalitzador per a una millor mesura — no perquè instal·lin dashboards, sinó perquè aporten 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 és una mentalitat que no pots obtenir d'una mètrica.
Vols enginyers que aportin el criteri per saber què mesurar i què ignorar? Parla amb un CTO — els nostres enginyers sènior de LATAM han treballat en prou equips per saber quins KPIs realment mouen l'agulla.
