El equipo de dos pizzas necesita una wiki

El modelo de equipos de dos pizzas de Amazon es una de las ideas más influyentes en el diseño organizacional moderno. Mantener los equipos lo suficientemente pequeños como para que dos pizzas puedan alimentarlos (aproximadamente entre 5 y 8 personas). Dar a cada equipo la propiedad clara de un dominio definido. Permitirles operar de forma autónoma, tomando decisiones sin esperar la aprobación de una autoridad central.

El modelo funciona. Las investigaciones muestran de manera constante que los equipos pequeños y autónomos con límites de propiedad claros mantienen una productividad por persona más alta que los equipos grandes. Se comunican de manera más eficiente, toman decisiones más rápido y realizan entregas con más frecuencia. La explosión de rutas de comunicación que ralentiza a los equipos grandes se contiene dentro del número manejable de rutas de cada equipo pequeño.

Pero el modelo tiene una dependencia de la que rara vez se habla en la literatura sobre diseño organizacional: solo funciona si la capa de conocimiento entre los equipos es lo suficientemente sólida como para manejar la coordinación intergrupal que genera la estructura de equipos pequeños.

El problema entre equipos

Cuando se divide un equipo de 30 personas en cinco equipos de 6 personas, se reduce drásticamente el coste de coordinación interna del equipo (de 435 rutas a cinco conjuntos de 15 rutas). Pero se crea una nueva superficie de coordinación: los límites entre los equipos.

El Equipo A es propietario del servicio de pagos. El Equipo B es propietario del servicio de usuarios. El Equipo C es propietario de la pasarela API. Cada equipo es autónomo dentro de su dominio. Pero los dominios interactúan: la pasarela API dirige las solicitudes tanto al servicio de usuarios como al servicio de pagos, y el servicio de pagos necesita datos de usuario del servicio de usuarios. Estas interacciones requieren coordinación entre equipos, y la calidad de esa coordinación depende de lo accesible que sea el conocimiento de cada equipo para los demás.

Si el conocimiento del Equipo A sobre el servicio de pagos vive en las cabezas de los miembros del Equipo A, el Equipo B tiene que interrumpir al Equipo A cada vez que necesite entender cómo funcionan los pagos. El coste de coordinación no se ha eliminado con la estructura de equipos pequeños. Se ha trasladado de dentro del equipo a entre equipos, y la coordinación entre equipos suele ser más costosa porque las personas implicadas no comparten el contexto diario.

La dependencia de la documentación

Los equipos pequeños funcionan cuando el conocimiento del dominio de cada equipo está lo suficientemente documentado como para que otros equipos puedan acceder a él sin necesidad de una reunión o un hilo de Slack.

Esto significa que cada equipo necesita:

Documentación del sistema que describa qué hace su servicio, cómo funciona y cómo interactuar con él. No solo documentos de API, sino contexto de arquitectura: por qué está construido de la forma en que lo está, bajo qué limitaciones opera y qué se romperá si se asumen ciertas hipótesis sobre su comportamiento.

Registros de decisiones que expliquen el razonamiento detrás de las principales decisiones técnicas. Cuando el Equipo B encuentra algo inesperado en el servicio del Equipo A, debería poder entender por qué funciona así leyendo el registro de decisiones en lugar de programar una reunión con el Equipo A.

Documentación de cambios que registre qué ha cambiado y por qué. Cuando el Equipo A modifica su servicio de manera que afecte al Equipo B, el cambio y sus implicaciones deberían ser visibles en la documentación en lugar de comunicarse a través de un mensaje de Slack que el Equipo B podría pasar por alto.

Conocimiento indexable que sea accesible a través de los límites del equipo. El Equipo B debería poder buscar en la documentación del Equipo A tan fácilmente como en la suya propia, y la búsqueda debería funcionar por significado para que no necesiten conocer las convenciones de nomenclatura del Equipo A para encontrar lo que necesitan.

La autoescritura como elemento facilitador

La razón por la que la mayoría de las implementaciones de equipos pequeños invierten poco en documentación intergrupal es que la carga de la documentación recae sobre los propios equipos individuales, que ya están ocupados con su propio trabajo. Pedirle a un equipo de seis personas que mantenga una documentación exhaustiva para beneficio de otros equipos, además de entregar sus propias funciones, es pedir que la documentación se despriorice perpetuamente.

La documentación que se autoescribe cambia esta ecuación. La documentación de cada equipo se genera a partir de su actividad existente: PRs, conversaciones de Slack, reuniones. La documentación se mantiene al día porque se deriva del propio trabajo en lugar de mantenerse como una tarea separada. Otros equipos pueden buscar en ella porque forma parte de una capa de conocimiento unificada que abarca a toda la organización.

El modelo de equipo de dos pizzas es una estrategia organizacional. La documentación que se autoescribe es la infraestructura de conocimiento que hace que funcione. Sin ella, los equipos pequeños son solo silos más pequeños, y el coste de coordinación se traslada en lugar de reducirse.

Preguntas frecuentes

¿Qué pasa con las API de equipo y los contratos? La documentación de las API y los contratos de servicio son esenciales pero insuficientes. Describen la interfaz pero no el razonamiento. Un equipo que sabe qué hace la API de otro equipo pero no por qué funciona de esa manera tomará decisiones de integración basadas en un entendimiento incompleto. Los registros de decisiones y la documentación arquitectónica llenan este vacío.

¿Cómo gestionamos las dependencias entre equipos? Documente las dependencias de forma explícita en una capa compartida. Cuando el Equipo A sabe que el Equipo B depende de un comportamiento específico de su servicio, esa dependencia debería ser visible en la documentación para que los cambios que la afecten se marquen antes de ser entregados.

¿Se aplica esto a equipos que no son de ingeniería? La misma dinámica se aplica a cualquier organización que utilice equipos pequeños y autónomos. Grupos de marketing, equipos de ventas, equipos de producto: todos necesitan una capa de conocimiento compartida para coordinarse a través de los límites del equipo sin necesidad de reuniones constantes.

Lecturas relacionadas: El problema de la escala del conocimiento, La ley de Brooks sigue teniendo razón, Cómo escalar un equipo de ingeniería. Páginas relacionadas: Documentos que se autoescriben, Una sola búsqueda, Para equipos de ingeniería.