Organigrama de ingeniería: cómo relacionar los equipos con los sistemas que poseen

La mayoría de los organigramas responden a una sola pregunta: quién reporta a quién. Los ingenieros rara vez necesitan esa respuesta. Durante un incidente necesitan saber qué equipo es dueño del servicio que falla y quién está de guardia. En una revisión de diseño necesitan saber a qué equipos afecta un cambio y cómo trabajan juntos esos equipos. Un diagrama de nombres y cargos no responde a ninguna de estas preguntas.

Este artículo construye un organigrama de ingeniería que sí lo hace. Mantiene las líneas de reporte para la parte de personas y añade lo que necesita ingeniería: tipo de equipo, sistemas propios, horario de guardia y forma de interactuar entre equipos. Usa el vocabulario de Team Topologies para los equipos y termina con qué etiquetar y cómo mantener el diagrama al día.

Qué debe mostrar un organigrama de ingeniería

A partir de unos pocos equipos, deja a los ingenieros individuales fuera del diagrama y muestra una tarjeta por cada líder de equipo. Un diagrama con sesenta nombres es una guía telefónica; uno con ocho equipos es un mapa. Enlaza cada equipo con su propia lista de miembros si alguien necesita los nombres.

Las líneas de reporte no lo cuentan todo

El artículo de Mel Conway "How Do Committees Invent?" se publicó en Datamation en abril de 1968. En su propia página sobre la ley, resume así su tesis: una organización que diseña un sistema produce un diseño cuya estructura copia la estructura de comunicación de la organización. Más tarde, Fred Brooks la llamó ley de Conway, y el nombre se quedó.

Fíjate en la palabra comunicación. Un organigrama muestra líneas de reporte, y estas son solo una parte de cómo se comunica la gente. Dos equipos bajo directores distintos que hablan todos los días dan forma al sistema más que la línea entre sus managers. Por eso el diagrama de este artículo anota cómo trabajan juntos los equipos, no solo a quién reportan.

La ley también sirve como herramienta de diseño. Si dos servicios deben seguir siendo independientes, no se los asignes a equipos que tengan que coordinar cada cambio. El artículo de Conway añade un corolario: el primer diseño rara vez es el mejor, así que la organización necesita ser lo bastante flexible para cambiar con él.

Tipos de equipo y modos de interacción

Team Topologies, de Matthew Skelton y Manuel Pais, da a los equipos un vocabulario breve y compartido: cuatro tipos de equipo y tres formas de interactuar.

Los tres modos de interacción:

• Colaboración. Dos equipos trabajan estrechamente durante un periodo definido para descubrir algo nuevo, como una API o una práctica. Es costoso, así que ponle una fecha de fin.
• X como servicio (X-as-a-Service). Un equipo ofrece algo y el otro lo consume con poca interacción, como un pipeline de despliegue.
• Facilitación. Un equipo ayuda y orienta a otro, por ejemplo mientras adopta un nuevo enfoque de pruebas.

Una advertencia de la propia web de Team Topologies: dice que el enfoque no es un método para diseñar un nuevo organigrama. Describe cómo fluye el trabajo entre equipos. Usa su vocabulario como etiquetas en tu diagrama, no como excusa para redibujar todas las líneas de reporte.

Mantén la propiedad en un solo lugar

La propiedad escrita solo en un diagrama se queda desactualizada. Mantén la fuente de verdad donde los ingenieros ya miran y deja que el diagrama la refleje a nivel de equipo.

En un catálogo de servicios como Backstage, cada componente debe indicar un propietario: en el formato de descriptores del catálogo, spec.owner es un campo obligatorio, y el propietario es una sola entidad, normalmente un equipo. En un repositorio, un archivo CODEOWNERS asigna rutas a las personas o equipos responsables, y GitHub solicita automáticamente la revisión de los propietarios del código cuando una pull request que no es borrador modifica su código.

Si el diagrama y el catálogo no coinciden, normalmente el catálogo tiene razón y al diagrama le toca una revisión.

El ejemplo: ingeniería en una tienda online

El departamento de ingeniería de una tienda online tiene un VP y dos directores. Product Engineering dirige tres equipos: Checkout y Search, ambos alineados al flujo, y Payments, un equipo de subsistema complicado que es dueño del procesamiento de pagos y de la puntuación de fraude. Platform Engineering dirige el equipo Platform, dueño del CI/CD, los clústeres de Kubernetes y el stack de observabilidad, y un equipo Developer Experience cuyo puesto de líder sigue vacante.

Este trimestre hay dos interacciones activas. Payments y Checkout colaboran en 3-D Secure hasta el final del segundo trimestre. Developer Experience facilita la migración de Checkout a pruebas de contrato.

Cómo leerlo:

• De arriba abajo, las líneas de reporte. El VP, dos directores y cinco líderes de equipo. Las líneas muestran quién reporta a quién, nada más.
• Color de la tarjeta, tipo de equipo. Ámbar para los equipos alineados al flujo, rosa para el subsistema complicado, azul para la plataforma y violeta para el habilitador. Los managers por encima del nivel de equipo se quedan en gris.
• Bajo cada equipo, la vista de ingeniería. Los servicios que posee el equipo, su horario de guardia y su interacción actual con otros equipos.
• La tarjeta discontinua es una vacante. Developer Experience aún no tiene líder, y el diagrama lo dice en lugar de ocultar el hueco.

Qué etiquetar

• Los nombres de los equipos tal como los dice la gente. Si el canal de incidentes dice "Checkout", el diagrama dice Checkout.
• Los sistemas propios, con los nombres que se usan en el catálogo, los paneles y las alertas.
• El horario de guardia y a quién escalar.
• El modo de interacción y una fecha de fin para cada colaboración.
• Las relaciones de línea punteada, como una ingeniera de seguridad que reporta al equipo de seguridad pero trabaja con Payments todos los días.
• La ubicación o la zona horaria cuando los equipos abarcan varias.
• La fecha de la última revisión, en el propio diagrama.

Errores comunes

• Personas sin equipo. Un árbol de nombres no le dice a nadie adónde ir cuando algo se rompe.
• Sistemas sin dueño. Si un servicio no aparece bajo ningún equipo, ese es el hallazgo. Asígnalo antes de que lo haga el próximo incidente.
• Propiedad compartida. Dos dueños suelen significar ninguno. Backstage pide un único propietario por algo.
• Colaboración sin fin. La colaboración está pensada para un periodo definido. Una que nunca termina suele indicar que la frontera entre los dos equipos está en el lugar equivocado.
• Equipos sobrecargados. Un equipo dueño de una docena de servicios y de dos rotaciones de guardia será lento en todo. Team Topologies trata la carga cognitiva de un equipo como un límite que hay que tener en cuenta al diseñar, y el diagrama hace visible esa carga.
• Un diagrama que nadie actualiza. Actualízalo con cada reorganización y cada servicio nuevo, y revísalo periódicamente.

El organigrama muestra quién es dueño de qué; no muestra cómo encajan los sistemas. Para eso, dibuja un diagrama del modelo C4 o un diagrama de arquitectura de microservicios, y mantén ambos al día como se explica en diagramas de arquitectura que no se quedan obsoletos.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama, o parte de la plantilla de organigrama.
2. Del pack Organigrama, añade una tarjeta Empleado para el VP y completa nombre, cargo, departamento y ubicación.
3. Añade personas con los controles de suma: abajo para un subordinado, al lado para un par y arriba para un responsable. El diagrama se organiza solo de arriba abajo.
4. Añade una tarjeta Vacante por cada puesto que estés cubriendo.
5. Pon el color de la tarjeta de cada líder de equipo según su tipo de equipo, y deja en gris a los managers por encima del nivel de equipo.
6. Bajo cada líder de equipo, añade un Texto del pack Básico con el tipo de equipo, los sistemas que posee, su horario de guardia y su modo de interacción actual.

El ejemplo usa 8 nodos de diagrama, dentro del plan Free. El texto no cuenta para el límite. La página del creador de organigramas explica cómo compartir y exportar.

Preguntas frecuentes

¿Un organigrama de ingeniería debe mostrar a cada ingeniero? Para unos pocos equipos, sí. A partir de ahí, muestra los equipos y sus líderes, y enlaza cada equipo con su propia lista de miembros. El diagrama sigue siendo legible y cambia con menos frecuencia.

¿Cómo muestro a un responsable de línea punteada? Dibuja una línea discontinua desde el segundo responsable y reserva la línea continua para quien hace las evaluaciones de desempeño. En Archboard, una conexión desde un segundo responsable se convierte en una línea punteada, y el diseño sigue basándose en el primero.

¿Qué diferencia hay entre un organigrama y una topología de equipos? Un organigrama muestra líneas de reporte. Una topología de equipos muestra tipos de equipo y cómo interactúan. Dibuja ambos, o anota las interacciones en el organigrama, como en el ejemplo.

¿Dónde debe registrarse la propiedad de los servicios? En un catálogo de servicios o en archivos CODEOWNERS, donde las herramientas y las personas puedan encontrarla. El organigrama la refleja a nivel de equipo.

¿Con qué frecuencia debe actualizarse un organigrama de ingeniería? Con cada reorganización, equipo nuevo o servicio nuevo, además de una revisión periódica, por ejemplo mensual. Pon en el diagrama la fecha de la última revisión.

Empieza gratis — un puesto, sin tarjeta de crédito.