Guies

Com mesurar la productivitat d'un equip de desenvolupament remot sense microgestió

Per Marc Molas·3 d’agost del 2024·9 min de lectura

Si mesures el teu equip de desenvolupament remot per hores connectades o per línies de codi escrites, estàs mesurant el que no toca.

Ho dic per experiència. He vist fundadors instal·lar programari de vigilància, exigir càmeres enceses vuit hores al dia i obsessionar-se amb el puntet verd de Slack. El resultat sempre és el mateix: els bons enginyers marxen, els que es queden optimitzen per semblar ocupats i el producte no avança.

Mesurar la productivitat d'un equip remot és possible. Però cal mesurar el que importa, no el que és fàcil de comptar.

El que NO hauries de mesurar

Abans de parlar del que funciona, descartem el que no:

Hores en línia: un enginyer pot estar connectat deu hores i produir menys que un altre que en treballa sis amb concentració. Les hores mesuren presència, no productivitat.
Tecles premudes o moviment del ratolí: si has arribat fins aquí, tens un problema de confiança, no de productivitat. El programari de vigilància destrueix la motivació i la retenció.
Línies de codi: un refactor que elimina 500 línies i simplifica l'arquitectura val més que afegir-ne 2.000 de mal estructurades. Mesurar línies incentiva el codi inflat.
Commits per dia: un commit atòmic i ben pensat val més que quinze «fix typo». Mesurar commits incentiva fragmentar la feina sense sentit.

Totes aquestes mètriques comparteixen un problema: són fàcils de manipular. Quan mesures el que no toca, la gent optimitza per a la mètrica, no per al resultat. És la llei de Goodhart en acció: quan una mesura es converteix en objectiu, deixa de ser una bona mesura.

El que SÍ que hauries de mesurar: mètriques DORA adaptades

Les mètriques DORA (DevOps Research and Assessment) són l'estàndard del sector per mesurar el rendiment dels equips d'enginyeria. No es van dissenyar per vigilar persones, sinó per avaluar la salut de l'equip i la seva capacitat de lliurament.

Adaptades a startups, en són quatre:

1. Freqüència de desplegament

Cada quan el teu equip desplega a producció. Com més sovint ho fa, més sa és el pipeline, menys risc té cada desplegament i més contínuament lliura l'equip, en lloc d'acumular canvis.

Si el teu equip desplega un cop al mes, cada desplegament és un esdeveniment d'alt risc. Si desplega diverses vegades al dia, cada canvi és petit, manejable i fàcil de revertir.

Referència per a startups: com a mínim, setmanal. Idealment, diverses vegades per setmana.

2. Lead time (temps de lliurament dels canvis)

Des que un desenvolupador fa commit fins que el canvi és a producció. Inclou la revisió de codi, el CI/CD, el QA i el desplegament. Com més curt, millors són les teves pràctiques d'enginyeria.

Un lead time llarg sol apuntar a colls d'ampolla: revisions de codi que triguen dies, pipelines de CI lents, processos de QA manuals o aprovacions innecessàries.

Referència per a startups: menys de 2 dies per a canvis estàndard.

3. Taxa de fallada dels canvis

Quin percentatge de desplegaments provoca incidents o obliga a fer un rollback. Com més baixa, més qualitat de codi, millor testing i revisions de codi més efectives.

Si un de cada tres desplegaments trenca alguna cosa, el teu equip desplega ràpid però sense qualitat. La velocitat sense qualitat només és velocitat a l'hora de crear problemes.

Referència per a startups: per sota del 15%.

4. Temps de recuperació

Quan alguna cosa peta a producció, quant triga el teu equip a restaurar el servei. Aquesta mètrica mesura la capacitat de reacció, no la perfecció. Les fallades arribaran. El que importa és com de ràpid et recuperes.

Referència per a startups: menys de 4 hores per als incidents crítics.

Indicadors a escala d'equip (sense vigilar ningú)

Més enllà de DORA, hi ha mètriques d'equip que et donen visibilitat sobre la salut operativa:

Cycle time de les PR: quant passa des que s'obre una pull request fins que es fa el merge. Si les PR s'acumulen sense revisió, tens un coll d'ampolla.
Tendència de la velocitat de sprint: no el número absolut (que és fàcil d'inflar), sinó la tendència. Si la velocitat cau sprint rere sprint, alguna cosa falla. Si és estable, l'equip és previsible.
Tasques bloquejades: quantes tasques estan bloquejades i durant quant de temps. Els bloqueigs prolongats indiquen dependències no resoltes o una comunicació que s'ha trencat.
Bug escape rate: quants bugs arriben a producció respecte dels que s'atrapen al testing. Si la taxa puja, la qualitat del testing està caient.

Cap d'aquestes mètriques no requereix vigilar ningú. Totes surten de les eines que ja fas servir: GitHub, Jira, Linear, el teu sistema de CI/CD.

Indicadors individuals (amb peus de plom)

Les mètriques individuals són terreny perillós. Mal emprades, creen competència tòxica i destrueixen la col·laboració. Però fetes servir amb criteri, ajuden a identificar on un enginyer necessita suport o on aporta més del que es veu a primera vista.

Qualitat de les revisions de PR: no quantes PR revisa, sinó la profunditat dels comentaris. Un enginyer que detecta problemes d'arquitectura a les revisions aporta més del que sembla.
Compartició de coneixement: quantes PR revisa d'altres equips o mòduls. Els enginyers que surten de la seva zona per ajudar els altres multipliquen la capacitat de l'equip.
Iniciativa en millores: qui proposa millores al pipeline, automatitza processos o documenta decisions tècniques sense que ningú l'hi demani.
Qualitat de la comunicació: en un equip remot, saber comunicar context de manera asíncrona és una habilitat crítica. Un enginyer que escriu descripcions de PR clares, documenta decisions i avisa dels bloqueigs de manera proactiva estalvia temps a tot l'equip.

La clau: aquestes mètriques han de servir per a converses de desenvolupament professional, no per a rànquings ni avaluacions punitives.

L'equació de la confiança

Les mètriques són una eina. Però el fonament de la productivitat en equips remots és la confiança. I la confiança es construeix amb sistemes, no amb bones intencions.

L'objecció honesta: hi haurà enginyers que abusaran d'aquesta confiança. És cert, passa. Però les mètriques d'aquí dalt destapen en un sprint o dos l'enginyer que es limita a fer el mínim, més de pressa que qualsevol eina de captures de pantalla, i sense dir a la resta de l'equip que tampoc no et refies d'ells.

Gestió basada en l'output: defineix amb claredat què s'espera de cada sprint. Avalua el que es lliura, no com ni quan s'ha fet la feina.

Standups asíncrons: en lloc d'una reunió diària de 30 minuts on mig equip no escolta, un missatge escrit amb tres punts: què vaig fer ahir, què faré avui, què em bloqueja. Cadascú l'escriu quan comença la seva jornada.

Demos setmanals: un cop per setmana, l'equip ensenya el que ha construït. Ni diapositives ni presentacions: codi funcionant. Això obliga a retre comptes sense microgestió.

Seguiment per fites: en lloc de controlar el dia a dia, defineix fites clares amb dates i fes el seguiment a escala de fita. Si l'equip compleix les fites, els detalls del dia a dia són irrellevants.

Antipatrons que destrueixen equips remots

Si fas alguna d'aquestes coses, atura't i repensa-ho:

Programari de vigilància: captures de pantalla, registre de tecles, gravació d'activitat. No hi ha manera més clara de dir «no em fio de tu». Els enginyers sènior que trobin això a la seva màquina començaran a buscar feina nova immediatament.
Càmeres enceses obligatòries: una videotrucada de 30 minuts amb càmera és raonable. Vuit hores de càmera encesa són vigilància disfressada de «cultura d'equip».
«Activity scores»: qualsevol mètrica que puntuï l'activitat d'un enginyer a partir de la seva presència en línia és inútil com a mesura de productivitat i destructiva per a la moral.
Vigilar l'estat de Slack: si el teu primer impuls quan veus algú «absent» a Slack és qüestionar-ne el compromís, el problema ets tu, no l'enginyer.

Els millors enginyers produeixen més en un entorn de confiança i autonomia que en un de control i vigilància. I això no és una opinió: és el que mostren de manera consistent les dades de la recerca de DORA i dels informes State of DevOps.

Com treballem amb equips distribuïts

A Conectia, els nostres enginyers s'integren directament als teus processos i ritmes de treball. Fan servir el teu stack, segueixen la teva metodologia de sprints, participen a les cerimònies de l'equip i responen als teus estàndards de qualitat.

No imposem processos paral·lels ni informes a part. El que sí que fem són check-ins continus de satisfacció i lliurament cada 90 dies, tant amb l'enginyer com amb el teu equip. Si alguna cosa no funciona, ho detectem aviat i ho corregim.

El resultat: tens un enginyer sènior que és part real del teu equip, amb autonomia per produir i mecanismes de feedback per garantir un lliurament consistent. Sense programari de vigilància. Sense microgestió. Amb mètriques que importen.

Vols incorporar enginyers remots que lliurin sense supervisió constant? Parla amb un CTO: integrem enginyers sènior de LATAM que treballen amb els teus processos i els teus estàndards de qualitat.