El Diagrama C4 le da a QA, Dev y PO el mismo mapa
Una de las fricciones más silenciosas que vi en equipos de software no es técnica — es de vocabulario. QA, Dev y PO usan la misma palabra, "arquitectura", para describir tres cosas distintas. El PO piensa en features y flujos de usuario. El dev piensa en clases y módulos. QA piensa en superficies de prueba y puntos de falla. Nadie está mintiendo, pero tampoco están hablando de lo mismo.
El Diagrama C4 resuelve eso con una idea simple: en vez de un solo diagrama que intenta contener todo, da cuatro niveles de zoom, cada uno útil para una conversación distinta.
- Contexto: el sistema completo visto desde afuera, con quién interactúa. Es el nivel que un PO entiende sin esfuerzo.
- Contenedores: las piezas grandes — la app web, la base de datos, el servicio externo. Acá empieza a aparecer vocabulario técnico, pero todavía en un nivel que QA puede leer para pensar en qué falla si un contenedor se cae.
- Componentes: adentro de un contenedor, cómo se organiza internamente. Este nivel ya es mayormente terreno de dev.
- Código: clases, funciones, el detalle de implementación. El nivel que casi nadie fuera de dev necesita, y está bien que así sea.
Lo que cambia con esto no es que QA aprenda a programar ni que el PO aprenda UML. Es que cuando alguien dice "el problema está en la arquitectura", ahora hay una forma de preguntar "¿en qué nivel?" y que la respuesta señale un diagrama concreto, no una idea distinta en la cabeza de cada uno.
Nota
El valor del C4 no está en el nivel más técnico. Está en que los cuatro niveles comparten el mismo vocabulario visual — así un PO puede bajar un nivel para entender de qué habla un dev, sin necesitar el detalle completo.
Para QA en particular, esto tiene un beneficio extra: ver el sistema en el nivel de contenedores ayuda a diseñar mejor qué se prueba de punta a punta y qué se prueba de forma aislada — la misma pregunta que separa una prueba E2E cara de una prueba de integración barata.
Publiqué esta idea originalmente en LinkedIn.