Topologies d'Equip a la Pràctica: Triar l'Estructura d'Equip Adequada
El llibre "Team Topologies" (2019) de Skelton i Pais va donar al lideratge d'enginyeria un vocabulari compartit per a l'estructura dels equips. Però he vist organitzacions llegir el llibre, canviar el nom de tots els seus equips per adaptar-se als quatre tipus, i no canviar res sobre com flueix realment el treball. Altres creen equips de plataforma abans de tenir res que plataformejar.
Aquí s'explica com aplicar-ho realment a la pràctica, inclòs quan reestructurar i quan deixar les coses com estan.
Els Quatre Tipus d'Equip: Un Repàs Ràpid
Si has llegit el llibre, salta a la secció següent. Si no, aquí hi ha el model central.
Els equips alineats amb el flux són les unitats principals de lliurament de valor. Tenen en propietat un flux de treball — un producte, un conjunt de funcionalitats, un domini de negoci. Interfuncionals i capaços de lliurar d'extrem a extrem. La majoria dels teus enginyers haurien d'estar aquí.
Els equips habilitadors ajuden a altres equips a adoptar noves tecnologies o capacitats. No construeixen coses per a altres equips — ajuden a altres equips a construir coses ells mateixos. Temporals per disseny.
Els equips de plataforma proporcionen serveis interns que els equips alineats amb el flux consumeixen com a autoservei. CI/CD, desplegament, infraestructura compartida. Si els equips necessiten obrir un tiquet i esperar, has construït un coll d'ampolla, no una plataforma.
Els equips de subsistema complex tenen en propietat components que requereixen coneixement especialitzat profund — models d'ML, pipelines de dades en temps real, motors financers complexos. Es creen quan la càrrega cognitiva és massa alta perquè un equip alineat amb el flux la carregui.
Quan Crear Cada Tipus d'Equip
L'error més comú és crear els quatre tipus alhora perquè el llibre descriu quatre tipus. A la pràctica, els introdueixes a mesura que sorgeix la necessitat.
Alineat amb el Flux: Comença Aquí, Sempre
Totes les organitzacions d'enginyeria comencen amb equips alineats amb el flux, ja sigui que ho anomenen així o no. Si tens un equip construint un producte, és un equip alineat amb el flux.
A mesura que creixes, la pregunta és: com et divideixes? La resposta hauria de seguir els límits del teu domini, no les teves capes tècniques. Divideix per viatge de l'usuari, domini de negoci o àrea de producte — no per frontend/backend/infraestructura.
Quan crear un nou equip alineat amb el flux: Quan la càrrega cognitiva en un equip existent és massa alta — tenen massa dominis en propietat, el canvi de context és constant i l'equip està ocupat tot el temps però lliurant lentament.
Plataforma: No Fins que Tinguis Demanda Real
Aquí és on veig més errors. La conversa va: "Hauríem de tenir un equip de plataforma." "Què construirien?" "Ja saps... la plataforma."
Un equip de plataforma té sentit quan:
- Múltiples equips alineats amb el flux estan construint la mateixa cosa de manera independent. Tres equips tots construint el seu propi pipeline de desplegament o configuració de registre senyala que una capacitat de plataforma compartida estalviaria temps.
- Els equips alineats amb el flux gasten temps significatiu en treball no diferenciat. Si els equips de producte gasten el 30% del seu temps en manteniment d'infraestructura o CI/CD, un equip de plataforma pot absorbir aquesta càrrega.
- El model d'autoservei és viable. Si la "plataforma" requereix treball personalitzat per a cada consumidor, tens una cua de serveis compartits, no una plataforma.
No creïs un equip de plataforma quan: Tens menys de 4-5 equips alineats amb el flux, o quan la "plataforma" és realment les necessitats d'infraestructura d'un equip disfressades d'iniciativa compartida. Comença amb documentació i biblioteques compartides. Si la demanda d'una plataforma real creix, ho sabràs.
Habilitador: El Tipus Més Infrautilitzat
La majoria de les organitzacions no tenen equips habilitadors, i haurien de tenir-ne. L'equip habilitador és la resposta a una pregunta que escolto constantment: "Com fem que tots els nostres equips adoptin X?"
X podria ser:
- Observabilitat (registres, mètriques, traces)
- Un nou marc de proves
- Bones pràctiques de seguretat
- Una migració d'una base de dades a una altra
- Estàndards de disseny d'API
Sense un equip habilitador, l'adopció o bé s'imposa de dalt a baix (creant ressentiment) o bé no succeeix del tot. Un equip habilitador treballa juntament amb els equips alineats amb el flux com a entrenadors — programació en parella, organitzant tallers, construint eines que fan l'adopció més fàcil.
Principi clau: Els equips habilitadors haurien de tenir un límit de temps. Existeixen per transferir una capacitat, no per tenir-la en propietat de manera permanent. Si el teu porta 18 mesos "ajudant els equips a adoptar l'observabilitat", alguna cosa va malament.
Subsistema Complex: El Tipus Més Rar
Necessites un equip de subsistema complex quan el coneixement especialitzat requerit per a un component és tan profund que integrar-lo en un equip alineat amb el flux sobrecarregaria la càrrega cognitiva d'aquell equip.
Exemples:
- Un motor de recomanació en temps real que requereix experiència en ML
- Un mòdul de processament de pagaments amb requisits regulatoris complexos
- Un pipeline de transcodificació de vídeo que requereix coneixements profunds d'enginyeria de mitjans
- Un compilador o runtime de llenguatge
La prova és senzilla: Podria un enginyer generalista fort en un equip alineat amb el flux mantenir aquest component? Si la resposta és sí, no necessites un equip dedicat. Si la resposta és "només si dedica el 80% del seu temps a això", aquest és el teu senyal.
La majoria de startups i organitzacions d'enginyeria de mida mitjana tenen zero o un equip de subsistema complex. Si en tens més de dos, qüestiona si estàs sobre-especialitzant.
Els Tres Modes d'Interacció
Els modes d'interacció són la part de Team Topologies que la gent salta, i no ho hauria de fer. Com interaccionen els equips importa tant com estan estructurats.
Mode de col·laboració. Dos equips treballen junts estretament durant un període definit. Alta amplada de banda, alt cost. Usa'l per al descobriment i el treball en fase inicial, no com a estat permanent. Si dos equips col·laboren permanentment, haurien de fusionar-se.
Mode X-com-a-servei. Un equip proporciona una capacitat a través d'una interfície ben definida. El mode principal entre els equips de plataforma i els equips alineats amb el flux. Només funciona si és genuïnament en autoservei.
Mode de facilitació. Un equip ajuda un altre a aprendre o adoptar una capacitat. Com interaccionen els equips habilitadors amb els equips alineats amb el flux. L'objectiu és l'autosuficiència.
Quan Reestructurar (i Quan No)
Les reorganitzacions són cares. Cada reorganització interromp les relacions i costa setmanes de productivitat.
Reestructura quan: Els equips no poden lliurar d'extrem a extrem sense bloquejar-se en els altres. L'abast d'un equip és tan gran que estan permanentment canviant de context. Dos equips estan en mode de col·laboració permanent (fus-los). Tens demanda clara de plataforma però cap equip de plataforma.
No reestructuris quan: Simplement vols "provar Team Topologies". El problema és la gent, no l'estructura. L'equip funciona bé però no encaixa en la taxonomia. Has reorganitzat fa menys de 6 mesos.
Errors Comuns
Crear un equip de plataforma massa aviat. Construint eines que ningú utilitza mentre els equips alineats amb el flux resolen les seves pròpies necessitats.
No tenir equips habilitadors. Totes les iniciatives d'adopció es converteixen en un mandat de dalt a baix o en un esforç de base que s'esgota.
Etiquetar equips sense canviar com treballen. Canviar el nom de "Equip de Backend" a "Equip de Plataforma" no el converteix en un.
Ignorar la càrrega cognitiva. Tot el marc es construeix sobre ella. Si no estàs avaluant si els equips estan sobrecarregats, t'estàs perdent la qüestió.
A Conectia, quan integrem enginyers sèniors de LATAM en organitzacions d'enginyeria en creixement, prestem molta atenció a l'estructura de l'equip. L'enginyer adequat en l'equip equivocat lliura menys valor que un bon enginyer en un equip ben estructurat. Els nostres enginyers tenen experiència en configuracions distribuïdes i multiequip i entenen com funcionen les dinàmiques dels equips alineats amb el flux, de plataforma i habilitadors a la pràctica — no només en teoria.
Estructurant els teus equips d'enginyeria per al creixement? Parla amb un CTO — col·loquem enginyers sèniors que entenen les dinàmiques d'equip i s'integren nítidament en l'estructura del teu squad des de la primera setmana.
