Team Topologies
4 tipos de time, 3 modos de interação, carga cognitiva — e por que Conway dita o software
Conway's Law: "Sistemas refletem a estrutura de comunicação da organização." Se você quer um sistema com módulos desacoplados, precisa de times desacoplados. Mudar arquitetura sem mudar times é desperdício; mudar times conscientemente é arquitetura — chama-se inverse Conway maneuver.
Os 4 tipos fundamentais
Team Topologies (Skelton & Pais) propõe que toda equipe de software cai em uma destas 4 categorias. Misturas levam à confusão de propósito.
| Tipo | Propósito | Entrega valor a | Exemplo |
|---|---|---|---|
| Stream-aligned | Entregar valor de ponta a ponta em um fluxo de negócio | Cliente final / usuário | Time de Checkout, time de Onboarding, time de Subscriptions |
| Platform | Construir plataforma interna que reduz carga cognitiva de stream-aligned | Outros times (dev experience) | Time de IDP, time de CI/CD, time de Observability |
| Enabling | Ensinar e habilitar outros times em capability específica | Outros times (capacitação temporária) | Time de SRE evangelizando observability; time de Security ensinando OWASP |
| Complicated Subsystem | Cuidar de subsistema com complexidade técnica alta que exige especialistas | Outros times (componente reusável) | Time de ML inference engine; time de motor de pagamentos; time de codec de vídeo |
Default: stream-aligned. A maioria dos times deve ser stream-aligned. Se você está pensando "esse time é especial", reconsidere antes de criar uma exceção. Excesso de platforms / enablings / complicated subsystems vira indireção.
Stream-aligned em detalhe
O time tem tudo o que precisa para entregar valor sem depender de outros times no caminho crítico:
- Ownership do código de ponta a ponta (frontend + backend + dados + infra própria)
- Capacidade de fazer deploy independente
- Métricas próprias do produto
- Contato direto com usuários / produto
Platform team — não é "DevOps"
É um produto interno. Os clientes do platform team são os outros times de engenharia. Vale tratar com PM, roadmap, NPS interno, SLA.
Platform team deve oferecer capability self-service: stream-aligned cria seu próprio pipeline / cluster / database sem abrir ticket. Se exige humano no meio, virou bottleneck.
Como você decide quando criar um platform team?
Quando você tem 3+ stream-aligned teams resolvendo o mesmo problema técnico (cada um seu próprio Kubernetes, seu próprio CI/CD, seu próprio observability stack). A duplicação custa mais que o investimento em um platform team. Antes desse ponto, é YAGNI — você está montando estrutura cara para um problema que ainda não tem.