Un equip tècnic asíncron no és un grup de persones que “s’apanyen per Slack”. És un equip que decideix quines coses s’han d’escriure, quines coses mereixen reunió i com es conserva el context perquè la feina avanci encara que no tothom coincideixi en horari.
La coordinació asíncrona falla quan es converteix en silenci. Funciona quan hi ha artefactes clars: issues amb context, pull requests revisables, decisions registrades, ownership explícit i acords de resposta.
Punts clau
- Asíncron no vol dir sense reunions; vol dir reunions més ben reservades.
- La documentació útil no és llarga: explica context, decisió, criteri i pròxim pas.
- Les revisions necessiten temps, owners i definició de què és bloquejant.
- Les decisions tècniques han de tenir una ruta d’escalat quan hi ha desacord.
- L’objectiu no és escriure més, sinó reduir dependència de memòria oral.
Què compta com a documentació a la pràctica
Documentar no hauria de sentir-se com “fer un informe”. En equips tècnics, la documentació més valuosa sol estar a prop de la feina:
| Artefacte | Què ha de deixar clar |
|---|---|
| Issue | Problema, context, criteri d’acceptació i owner |
| Pull request | Què canvia, per què, com provar-ho i riscos |
| ADR lleuger | Decisió, alternatives descartades i conseqüències |
| Runbook | Què fer quan alguna cosa falla |
| Comentari de revisió | Què bloqueja, què és suggeriment i què és pregunta |
Una regla útil: si una persona nova no pot entendre per què es va prendre una decisió llegint l’issue o el PR, l’equip encara depèn massa de memòria oral.
Revisions asíncrones sense paràlisi
La revisió asíncrona es trenca per dos extrems. En un, ningú revisa i la feina s’acumula. En l’altre, tothom opina de tot i cada canvi petit es converteix en debat etern.
Per evitar-ho, convé separar tipus de feedback:
- Bloquejant: seguretat, dades, bug, contracte trencat, criteri d’acceptació incomplert.
- Important però no bloquejant: naming confús, estructura millorable, test addicional recomanable.
- Preferència: estil personal, alternativa equivalent, gust d’implementació.
Un comentari sa diu quin tipus de feedback és. Per exemple: “Bloquejant: aquest endpoint pot duplicar oportunitats si el webhook es reintenta” és molt diferent de “Preferència: mouria aquesta funció a lib/formatters”.
Acords mínims d’equip
Un equip tècnic asíncron necessita pocs acords, però han de ser explícits.
| Acord | Exemple operatiu |
|---|---|
| Temps de primera resposta | PR crític: 4 hores laborals; PR normal: 24 hores |
| Owner de decisió | Si hi ha desacord tècnic, decideix qui manté el mòdul |
| Mida de PR | Canvis grans es divideixen o s’acompanyen de pla de revisió |
| Tancament de discussió | L’owner resumeix decisió i pròxim pas |
| Incidents | Tota decisió presa en urgència es documenta després |
Captura visual abans que novel·la textual
En producte digital, una captura o vídeo curt pot estalviar deu missatges. Per a bugs visuals, fluxos d’onboarding, errors d’interacció o problemes de performance, l’evidència visual sol ser més útil que una explicació llarga.
Un bon informe asíncron inclou:
- què esperava la persona;
- què va passar;
- passos per reproduir;
- entorn: navegador, dispositiu, usuari, feature flag;
- captura o vídeo;
- severitat i workaround si existeix.
Això redueix reunions perquè converteix la conversa en diagnòstic, no en reconstrucció del problema.
Quan dues opinions professionals xoquen
El desacord tècnic no és un problema. El problema és no tenir mecanisme de decisió. Per evitar debats circulars, uso tres preguntes:
- Quina opció redueix més risc ara?
- Quina opció deixa millor camí de canvi després?
- Qui haurà de mantenir això durant els pròxims mesos?
Si la decisió és reversible, decideix l’owner i avança. Si és difícil de revertir, documenta alternatives i busca revisió d’una persona amb context transversal.
Rituals mínims que sí mantindria
Mantindria pocs rituals, però molt clars: una planificació breu amb objectius de la setmana, una revisió tècnica on es resolen bloquejos reals i una retrospectiva lleugera quan es repeteix el mateix tipus de fricció. La resta hauria de viure en issues, PRs i documents curts.
També definiria un canal per a urgències reals. Si tot és urgent, res ho és; però si una caiguda de producció competeix amb un comentari de naming al mateix canal, l’equip aprèn a ignorar senyals importants.
Senyals que l’asíncron està fallant
- Els PRs esperen dies sense responsable.
- Les decisions importants es prenen per missatges solts.
- Es repeteixen discussions ja tancades.
- Les reunions s’usen per “posar al dia” en lloc de decidir.
- Les persones noves ho han de preguntar tot.
- Ningú sap què està bloquejat i què només està pendent.
Quan apareixen aquests senyals, no cal afegir més reunions per defecte. Primer cal arreglar artefactes i ownership.
Lectures relacionades
- Refactorització web urgent: senyals, riscos i pla d’acció
- Arquitectura de components en vanilla JS
- Performance i conversió: com llegir Core Web Vitals
Conclusió
Un equip asíncron de qualitat no depèn d’heroisme individual. Depèn de context ben escrit, decisions visibles i responsabilitat clara. Quan això existeix, l’asincronia no frena: redueix interrupcions i millora la qualitat de les decisions.
Preguntes freqüents
- Treballar asíncron vol dir eliminar reunions?
- No. Vol dir reservar reunions per a decisions difícils i usar documentació, issues, PRs i decisions escrites per a tot el que es pot revisar sense coincidir en horari.
- Quina documentació necessita un equip tècnic asíncron?
- Necessita context de decisió, criteris d'acceptació, owner, estat, riscos i pròxims passos. No cal escriure novel·les, però sí deixar traçabilitat suficient.
- Com evitar que les revisions asíncrones bloquegin l'avenç?
- Definint temps de resposta, reviewers responsables, criteris d'aprovació, canvis bloquejants i decisions delegades en un owner tècnic.