Team Topologies na prática: como desenhamos nosso time de pagamentos

O organograma também é arquitetura

Em 1968, o programador Melvin Conway escreveu uma frase que virou lei: toda organização que projeta um sistema acaba produzindo um desenho que copia a sua própria estrutura de comunicação.

Na prática, é simples de ver. Se três times constroem um produto, ele tende a nascer com três partes. As fronteiras do software ficam onde os times conversam menos, e as partes mais confusas ficam onde ninguém sabe direito de quem é a responsabilidade.

Não é só intuição

A frase de Conway nasceu como observação, mas depois foi testada. Dois estudos me convenceram de que ela descreve algo real.

O primeiro é de pesquisadores de Harvard, Alan MacCormack, Carliss Baldwin e John Rusnak. Eles compararam pares de softwares que faziam a mesma coisa, um construído por uma organização muito integrada e outro por uma comunidade distribuída, pouco acoplada. Em todos os pares, o produto da organização pouco acoplada era bem mais modular. Eles chamaram isso de hipótese do espelhamento.

O segundo é da Microsoft Research. Nachiappan Nagappan, Brendan Murphy e Victor Basili analisaram o Windows Vista e mediram a estrutura da organização por trás de cada parte do sistema: quantas pessoas mexeram, de quantas áreas, quantas tinham saído. Essas medidas previram quais partes teriam falhas melhor do que as métricas técnicas tradicionais, como complexidade do código e cobertura de testes.

O que a pesquisa diz: A forma da organização não só influencia a arquitetura: ela chega a prever a qualidade do software melhor do que o próprio código.

Durante muito tempo tratei isso como curiosidade. Hoje trato como ferramenta. Se o desenho dos times molda o software, dá para inverter a lógica: primeiro decidir que arquitetura queremos e depois organizar os times para que ela aconteça. Essa ideia tem nome, manobra inversa de Conway, termo usado por Jonny LeRoy e Matt Simons em 2010.

O livro que organizou tudo isso para mim foi o Team Topologies, de Matthew Skelton e Manuel Pais. Acredito muito no conceito, e ele foi uma das bases da estrutura que temos hoje.

O time vem primeiro

O ponto de partida do livro é tratar o time, e não a pessoa, como a unidade de entrega. Um time estável, que trabalha junto por bastante tempo, aprende a se entender, cria confiança e fica mais rápido. Montar e desmontar grupos a cada projeto joga esse aprendizado fora.

Daí saem algumas escolhas práticas: times pequenos, de cinco a nove pessoas; times de longa duração; e o trabalho indo até o time, em vez de as pessoas correrem atrás do trabalho.

Nada disso é novo. Em 1975, Fred Brooks mostrou em The Mythical Man-Month que colocar mais gente em um projeto atrasado o atrasa ainda mais. O motivo é matemático: o número de conversas possíveis cresce muito mais rápido que o número de pessoas.

O livro também se apoia no trabalho do antropólogo Robin Dunbar sobre o tamanho dos grupos em que conseguimos manter confiança de verdade: algo perto de cinco pessoas para a confiança mais próxima e de quinze para a confiança profunda. É a mesma lógica dos "times de duas pizzas" da Amazon: se duas pizzas não alimentam o time, ele está grande demais.

Carga cognitiva: o limite que ninguém vê

O conceito que mais mudou a minha forma de pensar foi o de carga cognitiva. Um time só consegue cuidar bem de uma quantidade limitada de coisas. Quando passa desse limite, a qualidade cai, as entregas atrasam e as pessoas se desgastam.

O conceito vem da psicologia da educação. Foi proposto por John Sweller em 1988 para explicar por que alunos travam diante de certos problemas: a memória de trabalho tem limite, e o que não cabe nela não é aprendido. Skelton e Pais levaram a ideia do aluno para o time, e separam a carga em três tipos:

• Intrínseca: o esforço do próprio trabalho. Saber programar, conhecer a linguagem, entender a ferramenta.
• Estranha: o esforço que o ambiente impõe e que não gera valor. Um deploy manual cheio de passos, um ambiente difícil de montar, uma aprovação que ninguém sabe a quem pedir.
• Relevante: o esforço de entender o negócio. Em pagamentos, é saber como funciona uma liquidação ou o que o regulador exige.

O objetivo é reduzir a intrínseca com treino e boas escolhas técnicas, eliminar a estranha com automação e plataforma, e deixar espaço para a relevante, que é onde o time realmente faz diferença.

Os quatro tipos de time

Em vez de inventar um tipo de time para cada necessidade, o livro propõe só quatro. Menos tipos significa menos dúvida sobre o papel de cada um.

• Alinhado ao fluxo de valor (stream-aligned): cuida de uma fatia do negócio de ponta a ponta e entrega direto para o cliente. É o tipo principal, e a maioria dos times deveria ser assim. Os outros três existem para ajudá-lo.
• Plataforma: oferece serviços internos prontos para uso, para que os outros times não precisem resolver o mesmo problema várias vezes.
• Habilitador (enabling): especialistas que ajudam outros times a aprender algo novo, e depois saem de cena. O sucesso deles é não serem mais necessários.
• Subsistema complicado: cuida de uma parte que exige conhecimento muito específico, que não faria sentido espalhar por todos os times.

Por que o time alinhado ao fluxo é o centro de tudo? Porque é ele que encurta a distância entre uma ideia e o cliente. A melhor evidência disso está em Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim, que reúne anos de pesquisa com milhares de organizações.

O livro mede a entrega de software por quatro indicadores: frequência de deploy, tempo entre o código e a produção, tempo para se recuperar de uma falha e taxa de mudanças que dão errado. E mostra que um dos fatores que mais explicam o bom desempenho é ter arquitetura e times pouco acoplados: times que conseguem testar e publicar o próprio trabalho sem depender de coordenação com outros.

O que a pesquisa diz: Times que entregam bem não são os maiores nem os que têm mais orçamento. São os que conseguem mudar o próprio sistema sem pedir permissão a meio mundo.

As três formas de interagir

Definir os times é só metade do trabalho. A outra metade é definir como eles conversam, e o livro também é econômico aqui: são só três modos.

• Colaboração: dois times trabalham juntos por um período para descobrir algo novo. É o modo mais rico e o mais caro, porque as fronteiras ficam borradas. Deve ter prazo para acabar.
• X como serviço: um time consome o que o outro oferece, com o mínimo de conversa. Funciona quando a interface é clara e o serviço é confiável.
• Facilitação: um time ajuda o outro a aprender ou a destravar algo, sem fazer o trabalho por ele.

O que mais gosto aqui é a clareza. Quando dois times se desentendem, quase sempre é porque cada um esperava um modo diferente: um queria ser atendido como serviço e o outro achava que estavam colaborando.

Onde cortar: os planos de fratura

A pergunta difícil é onde passar a faca. O livro chama esses pontos naturais de divisão de planos de fratura e sugere alguns: o domínio de negócio, a exigência regulatória, o ritmo de mudança, o risco, a tecnologia e o tipo de usuário.

O primeiro deles vem do Domain-Driven Design, de Eric Evans: dividir o sistema em contextos delimitados, áreas do negócio com linguagem e regras próprias. Um contexto bem delimitado é um bom candidato a ser a casa de um time.

Em pagamentos, dois desses planos aparecem com muita força: a exigência regulatória e o ritmo de mudança. Foi por eles que passou a principal divisão do nosso time.

Como ficou o desenho do nosso time

Lidero um time de tecnologia em pagamentos. Antes de mostrar a estrutura, um registro importante: ela não foi desenhada por uma pessoa só. Foi construída a várias mãos, com a liderança de produto e com os líderes de tecnologia.

O meu papel foi trazer aquilo em que eu acreditava, e o Team Topologies era a principal referência. Mas a influência sempre veio depois da escuta. Quem conhece a jornada do cliente e sabe onde o negócio quer chegar é o time de produto, e um desenho de times que ignora isso organiza bem a tecnologia e mal o produto.

Sem entrar em detalhes da empresa, a estrutura tem três partes.

A linha core cuida do pagamento em si: adquirência, Pix, boleto, banking e a parte regulatória. É onde o dinheiro de fato se move e onde as regras do setor pesam mais. Um erro aqui custa caro, então esses times precisam de profundidade e de estabilidade.

A linha de cliente cuida de como o cliente chega até o pagamento: app e canais, dispositivos (as maquininhas, POS e SmartPOS) e o link de pagamento, que é o pagamento digital, não presencial. Aqui o que importa é a experiência e a velocidade para testar, aprender e ajustar.

Os times de plataforma sustentam as duas linhas: infraestrutura, DevEx (a experiência de quem desenvolve) e dados.

Lendo pelas lentes do livro:

• Os times da linha de cliente são alinhados ao fluxo de valor. Cada um tem um pedaço claro da jornada do cliente e consegue levar uma ideia até a produção.
• A linha core também é alinhada a fluxos, só que fluxos de produto de pagamento. Para a linha de cliente, ela funciona como uma plataforma: quem faz o app ou a maquininha não precisa conhecer as regras de uma liquidação para oferecer um Pix.
• Infraestrutura, DevEx e dados são plataformas no sentido clássico. DevEx tem também um pé no papel de habilitador: parte do trabalho é ensinar os times a usar bem o que existe.

Por que separar core de cliente

A separação resolve um conflito que todo time de pagamentos conhece. O núcleo pede cuidado: mudança pequena, muito teste, respeito ao regulador. A ponta do cliente pede velocidade: experimentar, medir, mudar de novo.

Quando os dois ritmos vivem no mesmo time, um atrapalha o outro. Ou a experiência fica lenta porque herda o rigor do núcleo, ou o núcleo fica frágil porque herda a pressa da ponta.

Com as duas linhas, cada time carrega só o que precisa carregar. Quem cuida do app não precisa ter na cabeça as regras de adquirência. Quem cuida do Pix não precisa acompanhar cada teste de tela. É carga cognitiva distribuída de propósito.

Como os times conversam

O desenho só funciona se a forma de interagir for tão clara quanto as caixas.

Entre a linha de cliente e a linha core, o modo que buscamos é o de serviço: contratos claros, APIs estáveis e o mínimo de reunião para fazer o básico. Se um time de cliente precisa marcar agenda com o core para cada funcionalidade, a fronteira está no lugar errado ou a interface está pobre.

Quando surge algo realmente novo, um produto ou uma exigência regulatória que muda a jornada, o modo vira colaboração: os times trabalham juntos por um tempo definido, até a interface ficar clara. Depois voltam ao modo de serviço.

E as plataformas precisam ser tratadas como produto. Os outros times são os clientes delas. A definição que o livro adota é a de Evan Bottcher: uma plataforma é uma base de APIs, ferramentas, serviços, conhecimento e suporte de autoatendimento, organizada como um produto interno atraente.

A palavra importante é "atraente". O livro defende a menor plataforma viável: o mínimo que resolve o problema dos times, bem documentado e fácil de usar. Uma plataforma que ninguém quer usar não é plataforma, é obrigação.

O que aprendi no caminho

• Não é organograma. O que importa não são as caixas, e sim quanto cada time carrega e como eles conversam. Dá para ter o desenho certo no papel e times sobrecarregados na prática.
• O desenho não é definitivo. O negócio muda, os produtos amadurecem e as fronteiras precisam acompanhar. Revisamos a estrutura com a mesma naturalidade com que se revisa uma arquitetura.
• Autonomia depende de plataforma. Pedir autonomia para um time sem dar a ele infraestrutura, ferramentas e dados prontos é só transferir peso. Por isso infraestrutura, DevEx e dados não são apoio: são o que torna a autonomia possível.
• Desenho de time se faz com produto. A fronteira entre os times é também a fronteira entre os produtos. Decidir isso só pela ótica da tecnologia é meia decisão.
• Estrutura não substitui cultura. O desenho facilita, mas quem faz funcionar são as pessoas. Senso de dono e colaboração, de que já falei em outro artigo, é o que dá vida às caixas.

Por onde começar

Para quem quer aplicar a ideia no próprio time, o caminho que eu sugiro é curto:

1. Desenhe os times como eles são hoje, não como o organograma diz. Quem depende de quem para entregar?
2. Pergunte a cada time quanto ele carrega. Sistemas, domínios, plantões, demandas de outros times. A sobrecarga costuma aparecer rápido.
3. Marque as dependências que travam. Onde um time espera o outro para terminar o próprio trabalho?
4. Escolha uma fronteira para mexer, a que mais dói, e defina o modo de interação dela.
5. Revise depois de alguns meses. Topologia é algo que evolui, não um projeto com data de entrega.

Fechamento

O Team Topologies me deu vocabulário para uma coisa que eu já sentia: a maior parte dos problemas de entrega não é técnica, é de fronteira. Times que carregam demais, que dependem demais uns dos outros ou que não sabem como devem conversar.

Desenhar a linha core, a linha de cliente e as plataformas foi a nossa forma de tratar essas fronteiras como parte da arquitetura, e só deu certo porque produto e tecnologia desenharam juntos. Não está pronto, e não é para estar. Mas hoje, quando algo trava, a primeira pergunta que faço deixou de ser "qual é o problema no código?" e passou a ser "qual é o problema no desenho?".

Fontes

• Team Topologies: Organizing Business and Technology Teams for Fast Flow, Matthew Skelton e Manuel Pais, IT Revolution Press, 2019
• Key Concepts, Team Topologies
• How Do Committees Invent?, Melvin Conway, Datamation, 1968
• Exploring the Duality Between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis, Alan MacCormack, Carliss Baldwin e John Rusnak, Research Policy, 2012
• The Influence of Organizational Structure on Software Quality: An Empirical Case Study, Nachiappan Nagappan, Brendan Murphy e Victor Basili, ICSE, 2008
• The Mythical Man-Month, Fred Brooks, Addison-Wesley, 1975
• Cognitive Load During Problem Solving: Effects on Learning, John Sweller, Cognitive Science, 1988
• Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble e Gene Kim, IT Revolution Press, 2018
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans, Addison-Wesley, 2003
• What I Talk About When I Talk About Platforms, Evan Bottcher, 2018