Organograma de engenharia: como ligar as equipes aos sistemas que elas possuem

A maioria dos organogramas responde a uma única pergunta: quem se reporta a quem. Engenheiros raramente precisam dessa resposta. Durante um incidente, precisam saber qual equipe é dona do serviço que está falhando e quem está de plantão. Em uma revisão de design, precisam saber quais equipes uma mudança afeta e como essas equipes trabalham juntas. Um diagrama de nomes e cargos não responde a nenhuma dessas perguntas.

Este artigo monta um organograma de engenharia que responde. Ele mantém as linhas de reporte para o lado das pessoas e acrescenta o que a engenharia precisa: tipo de equipe, sistemas próprios, horário de plantão e a forma como as equipes interagem. Ele usa o vocabulário do Team Topologies para as equipes e termina com o que rotular e como manter o diagrama atualizado.

O que um organograma de engenharia deve mostrar

A partir de algumas equipes, deixe os engenheiros individuais fora do diagrama e mostre um cartão por líder de equipe. Um diagrama com sessenta nomes é uma lista telefônica; um com oito equipes é um mapa. Ligue cada equipe à sua própria lista de membros se alguém precisar dos nomes.

As linhas de reporte não contam a história toda

O artigo de Mel Conway "How Do Committees Invent?" foi publicado na Datamation em abril de 1968. Na sua própria página sobre a lei, ele resume a tese assim: uma organização que projeta um sistema produz um projeto cuja estrutura copia a estrutura de comunicação da organização. Mais tarde, Fred Brooks a chamou de lei de Conway, e o nome pegou.

Repare na palavra comunicação. Um organograma mostra linhas de reporte, e elas são só uma parte de como as pessoas se comunicam. Duas equipes sob diretores diferentes que conversam todos os dias moldam o sistema mais do que a linha entre seus gerentes. Por isso o diagrama deste artigo registra como as equipes trabalham juntas, e não só a quem elas se reportam.

A lei também funciona como ferramenta de design. Se dois serviços devem continuar independentes, não os entregue a equipes que precisam coordenar cada mudança. O artigo de Conway acrescenta um corolário: o primeiro design raramente é o melhor, então a organização precisa ser flexível o bastante para mudar junto com ele.

Tipos de equipe e modos de interação

O Team Topologies, de Matthew Skelton e Manuel Pais, dá às equipes um vocabulário pequeno e compartilhado: quatro tipos de equipe e três formas de interação.

Os três modos de interação:

• Colaboração. Duas equipes trabalham juntas de perto por um período definido para descobrir algo novo, como uma API ou uma prática. É caro, então defina uma data de término.
• X como serviço (X-as-a-Service). Uma equipe oferece algo e a outra consome com pouca interação, como um pipeline de deploy.
• Facilitação. Uma equipe ajuda e orienta outra, por exemplo enquanto ela adota uma nova abordagem de testes.

Um alerta do próprio site do Team Topologies: ele diz que a abordagem não é um método para projetar um novo organograma. Ela descreve como o trabalho flui entre as equipes. Use o vocabulário como rótulos no seu diagrama, não como motivo para redesenhar todas as linhas de reporte.

Mantenha a responsabilidade em um só lugar

Responsabilidade escrita apenas em um diagrama fica desatualizada. Mantenha a fonte da verdade onde os engenheiros já olham e deixe o diagrama refleti-la no nível das equipes.

Em um catálogo de serviços como o Backstage, todo componente precisa indicar um dono: no formato de descritores do catálogo, spec.owner é um campo obrigatório, e o dono é uma única entidade, geralmente uma equipe. Em um repositório, um arquivo CODEOWNERS associa caminhos às pessoas ou equipes responsáveis, e o GitHub solicita automaticamente a revisão dos donos do código quando um pull request que não é rascunho altera o código deles.

Se o diagrama e o catálogo discordarem, o catálogo geralmente está certo, e o diagrama está devendo uma revisão.

O exemplo: engenharia em uma loja online

O departamento de engenharia de uma loja online tem um VP e dois diretores. Product Engineering comanda três equipes: Checkout e Search, ambas alinhadas ao fluxo, e Payments, uma equipe de subsistema complicado que é dona do processamento de pagamentos e da pontuação de fraude. Platform Engineering comanda a equipe Platform, dona do CI/CD, dos clusters Kubernetes e da stack de observabilidade, e uma equipe Developer Experience cuja vaga de líder ainda está aberta.

Duas interações estão ativas neste trimestre. Payments e Checkout colaboram no 3-D Secure até o fim do segundo trimestre. Developer Experience facilita a migração do Checkout para testes de contrato.

Como ler:

• De cima para baixo, as linhas de reporte. O VP, dois diretores e cinco líderes de equipe. As linhas mostram quem se reporta a quem, nada mais.
• Cor do cartão, tipo de equipe. Âmbar para as alinhadas ao fluxo, rosa para o subsistema complicado, azul para a plataforma e violeta para a capacitadora. Gerentes acima do nível de equipe ficam em cinza.
• Sob cada equipe, a visão de engenharia. Os serviços que a equipe possui, o horário de plantão e a interação atual com outras equipes.
• O cartão tracejado é uma vaga em aberto. Developer Experience ainda não tem líder, e o diagrama diz isso em vez de esconder a lacuna.

O que rotular

• Nomes de equipes como as pessoas os falam. Se o canal de incidentes diz "Checkout", o diagrama diz Checkout.
• Sistemas próprios, com os nomes usados no catálogo, nos painéis e nos alertas.
• Horário de plantão e para onde escalar.
• Modo de interação e uma data de término para cada colaboração.
• Relações de linha pontilhada, como uma engenheira de segurança que se reporta à equipe de segurança, mas trabalha com Payments todos os dias.
• Local ou fuso horário quando as equipes se espalham por vários.
• A data da última revisão, no próprio diagrama.

Erros comuns

• Pessoas sem equipe. Uma árvore de nomes não diz a ninguém aonde ir quando algo quebra.
• Sistemas sem dono. Se um serviço não aparece sob nenhuma equipe, essa é a descoberta. Atribua um dono antes que o próximo incidente faça isso.
• Responsabilidade compartilhada. Dois donos costumam significar nenhum. O Backstage pede um único dono por um motivo.
• Colaboração sem fim. A colaboração é pensada para um período definido. Uma que nunca termina costuma indicar que a fronteira entre as duas equipes está no lugar errado.
• Equipes sobrecarregadas. Uma equipe dona de uma dúzia de serviços e de duas escalas de plantão será lenta em todos eles. O Team Topologies trata a carga cognitiva de uma equipe como um limite a considerar no design, e o diagrama torna essa carga visível.
• Um diagrama que ninguém atualiza. Atualize-o a cada reorganização e a cada novo serviço, e revise-o periodicamente.

O organograma mostra quem é dono do quê; ele não mostra como os sistemas se encaixam. Para isso, desenhe um diagrama do modelo C4 ou um diagrama de arquitetura de microsserviços e mantenha ambos atualizados como descrito em diagramas de arquitetura que não ficam desatualizados.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama, ou comece pelo modelo de organograma.
2. Do pack Organograma, adicione um cartão Funcionário para o VP e preencha nome, cargo, departamento e local.
3. Adicione pessoas pelas alças de mais: embaixo para um subordinado, ao lado para um par, em cima para um gestor. O diagrama se organiza sozinho de cima para baixo.
4. Adicione um cartão Vaga em aberto para cada função que você está contratando.
5. Defina a cor do cartão de cada líder de equipe pelo tipo de equipe e deixe em cinza os gerentes acima do nível de equipe.
6. Sob cada líder de equipe, adicione um Texto do pack Básico com o tipo de equipe, os sistemas que ela possui, o horário de plantão e o modo de interação atual.

O exemplo usa 8 nós de diagrama e fica dentro do plano Free. Texto não conta para o limite. A página do criador de organogramas explica como compartilhar e exportar.

Perguntas frequentes

Um organograma de engenharia deve mostrar todos os engenheiros? Para poucas equipes, sim. Além disso, mostre as equipes e seus líderes e ligue cada equipe à sua própria lista de membros. O diagrama continua legível e muda com menos frequência.

Como mostrar um gestor de linha pontilhada? Desenhe uma linha tracejada a partir do segundo gestor e mantenha a linha contínua para quem conduz as avaliações de desempenho. No Archboard, uma conexão vinda de um segundo gestor vira uma linha pontilhada, e o layout continua baseado no primeiro.

Qual a diferença entre um organograma e uma topologia de equipes? Um organograma mostra linhas de reporte. Uma topologia de equipes mostra tipos de equipe e como elas interagem. Desenhe os dois ou anote as interações no organograma, como no exemplo.

Onde a responsabilidade pelos serviços deve ficar registrada? Em um catálogo de serviços ou em arquivos CODEOWNERS, onde ferramentas e pessoas conseguem encontrá-la. O organograma a reflete no nível das equipes.

Com que frequência um organograma de engenharia deve ser atualizado? A cada reorganização, nova equipe ou novo serviço, além de uma revisão regular, por exemplo mensal. Coloque no diagrama a data da última revisão.

Comece grátis — um assento, sem cartão de crédito.