Team Topologies: como organizar o time que opera IA

A maioria das iniciativas de IA que travam não trava por causa do modelo. Trava por causa do organograma. Uma equipe pequena vira o gargalo de tudo que é IA na empresa, um time de produto tenta virar especialista em prompt e avaliação do dia para a noite, e ninguém sabe direito quem é dono do custo de token. O Team Topologies, modelo criado por Matthew Skelton e Manuel Pais no livro de 2019, resolve exatamente esse problema: ele desenha como os times se organizam e conversam para entregar rápido, e se aplica quase que sob medida a quem está colocando IA em produção. Não é sobre caixinhas de RH. É sobre fluxo de entrega.

A ideia que sustenta tudo: carga cognitiva

Antes dos tipos de time, vem o conceito que dá sentido a eles: carga cognitiva. Um time só entrega bem enquanto o volume de coisas que precisa entender e manter na cabeça cabe na cabeça dele. Quando você pede que o mesmo time domine o domínio de negócio, a infraestrutura, o pipeline de dados, a escolha de modelo, a engenharia de prompt e a conta de custo, ele não fica mais produtivo. Ele fica sobrecarregado e lento, e a qualidade cai. A tese do Team Topologies é que a estrutura de times existe para proteger a carga cognitiva, dividindo o problema de um jeito que cada time consiga carregar o seu pedaço.

Isso importa em dobro na IA, porque IA adiciona uma camada inteira de coisas novas para entender: como o modelo se comporta, como avaliar se a saída está boa, como controlar alucinação, como medir e conter o custo. Jogar tudo isso em cima de um time de produto que já tinha carga cheia é receita de projeto que atola. O modelo dá a linguagem para dividir essa carga sem criar silo.

Os quatro tipos de time

O Team Topologies reduz a zoologia de times a quatro tipos, e só quatro. O primeiro, e o mais importante, é o time alinhado a fluxo. É o time dono de uma fatia de valor entregue ao usuário, de ponta a ponta. É ele que deveria estar entregando a maior parte do software. Todos os outros três existem para reduzir a carga dele.

O segundo é o time de plataforma. Ele cuida de um conjunto de serviços internos que os times de fluxo consomem para andar mais rápido, sem precisar entender o que está por baixo. O terceiro é o time habilitador, um grupo de especialistas que ajuda os times de fluxo a adquirir uma capacidade que ainda não têm, por tempo limitado. O quarto é o time de subsistema complicado, reservado para uma parte tão densa e especializada que precisa de gente dedicada, como um motor de otimização pesado ou um componente de baixa latência.

A regra de ouro é que o time de fluxo é a estrela, e os outros são serviço. Se a sua plataforma existe para dar trabalho ao time de produto em vez de tirar, ela está invertida.

Como isso vira o desenho da sua operação de IA

Aqui o modelo encaixa com precisão. Monte um time de plataforma de IA. Ele é dono do que é comum a todo mundo: o acesso aos modelos, a camada de avaliação, os guardrails de segurança, o monitoramento de custo por token, os padrões de prompt reutilizáveis. Ele empacota tudo isso como um serviço fácil de consumir, com boa documentação, para que qualquer time de produto ligue IA na sua feature sem virar especialista em plumbing. É a plataforma que absorve a carga cognitiva da IA em nome dos outros.

Os times de fluxo, alinhados a produto, seguem donos das suas features. A diferença é que agora eles consomem IA como consomem banco de dados: um serviço confiável, não um projeto de pesquisa. Eles decidem onde a IA resolve o problema do usuário e medem o resultado, sem precisar afundar na engenharia de inferência. Essa divisão é o que impede o cenário comum em que cada squad reinventa a própria avaliação e a própria conta de custo, do zero, mal.

O time habilitador é a peça que mais gente esquece, e a que mais evita a armadilha do grupo herói. Em vez de a equipe de IA fazer tudo no lugar dos outros, e virar gargalo eterno, ela entra por tempo limitado em um time de produto, ensina a prática, sobe o nível daquele time e sai. O sucesso do habilitador é medido por autonomia deixada para trás, não por dependência criada. Isso ataca de frente o gargalo que a Teoria das Restrições nos ensina a procurar: se todo pedido de IA passa por uma equipe só, essa equipe é a restrição, e a resposta não é ela trabalhar mais, é ela transferir capacidade.

Os três modos de interação

O modelo também nomeia as três formas de dois times interagirem, e escolher a certa evita atrito. Colaboração é quando dois times trabalham juntos, de perto, para descobrir algo novo. É intensa e cara em carga cognitiva, então deve ser temporária, útil no começo de uma capacidade de IA que ninguém domina ainda. Serviço, ou "X como serviço", é quando um time consome o que o outro oferece com o mínimo de conversa, o modo ideal entre produto e plataforma no regime estável. E facilitação é quando um time ajuda o outro a remover um obstáculo, o modo típico do habilitador.

O erro comum é congelar no modo colaboração. No início, faz sentido produto e plataforma de IA colaborarem de perto para descobrir o que funciona. Mas se seis meses depois eles ainda precisam de reunião diária para cada feature, a plataforma falhou em virar serviço. A evolução saudável é migrar de colaboração para serviço à medida que a prática amadurece, liberando a carga cognitiva dos dois lados.

Por onde começar

Não reorganize a empresa inteira numa tacada. Comece nomeando o que já existe. Olhe quem hoje carrega a IA na sua operação e pergunte: esse grupo está agindo como plataforma, tirando carga dos times de produto, ou como gargalo, concentrando todo trabalho? Os times de produto conseguem usar IA sozinhos, ou dependem de pedir favor? Existe alguém transferindo a prática, ou o conhecimento está preso em duas ou três cabeças?

As respostas quase sempre apontam o mesmo desenho: falta uma plataforma de IA de verdade, tratada como serviço, e falta um esforço deliberado de habilitação com prazo para acabar. Montar essas duas coisas, e proteger a carga cognitiva dos times de fluxo, costuma destravar mais entrega de IA do que trocar de modelo. A tecnologia raramente é o gargalo. O jeito como os times estão arranjados em volta dela quase sempre é.

Se você quer desenhar a topologia dos seus times para colocar IA em produção sem criar um gargalo humano, chame a gente no WhatsApp que a gente ajuda a montar o arranjo.