A Decisão Não Parava de Mudar Enquanto Construíamos

Sobre a Estrutura da Entrega — Uma Coluna de Maycon Santos

Uma feature pode chegar no prazo e ainda assim não ser o que vocês combinaram construir. Governança e execução são dois sistemas separados — e a maioria dos times opera os dois como se fossem um.

“Uma feature subiu no dia que prometemos. Na review, dois de nós percebemos que tínhamos construído coisas ligeiramente diferentes, e nenhuma era exatamente o que o ticket descrevia.”

Ninguém tinha perdido prazo. Nós tínhamos passado a sprint inteira executando contra uma decisão que ficou mudando enquanto trabalhávamos.

Não É um Problema de Comunicação, São Dois Sistemas Operados como Um

É tentador chamar isso de problema de comunicação, ou de problema de disciplina, e resolver com mais standups e uma definition of ready mais rigorosa. Esse é o diagnóstico errado. O que de fato aconteceu é que dois sistemas diferentes foram colapsados num só. Existe a decisão sobre o que estamos construindo, e existe o trabalho que transforma essa decisão em software. Não são a mesma atividade, e não deveriam se mover na mesma velocidade. A decisão é governança. O trabalho é execução. Quando os dois vivem no mesmo lugar — a mesma thread do Slack, o mesmo ticket, a mesma conversa de corredor — a decisão fica editável exatamente no momento em que ela mais precisa ficar parada.

O gap é o espaço entre o que foi combinado e o que foi executado, e a maioria dos times não consegue ver isso porque nada no ferramental deles marca onde o acordo termina e a construção começa. O ticket diz uma coisa. A thread embaixo dele refina essa coisa três vezes em dois dias. O pull request implementa uma quarta versão que vive só na cabeça de um engenheiro. Cada passo pareceu razoável. Ninguém decidiu derivar. Mas quando o trabalho chega na review, você não está verificando se a execução bateu com a decisão. Você está reconciliando várias decisões que nunca foram registradas como decisões.

A Decisão Vira Sugestão na Thread em Que Ela Vive

Já vi isso acontecer em times que, por todo critério visível, estavam fazendo as coisas certas. Os requisitos estavam escritos. Os tickets estavam groomados. As pessoas conversavam o tempo todo. A conversa era o problema. Na maioria das organizações de engenharia, o lugar onde as decisões são de fato tomadas é indistinguível do lugar onde o trabalho é discutido. Uma decisão de governança — aquele tipo que deveria ficar fixa pela duração da sprint — é tomada numa thread, e aí a mesma thread continua, e a decisão silenciosamente vira sugestão. Ninguém reabriu de propósito. Ela simplesmente nunca foi fechada, porque o canal em que ela vive não tem como fechar nada.

Veja como isso se desenrola ao longo de uma sprint. Na segunda o time concorda no formato de uma feature. Na terça alguém levanta um edge case razoável na thread, e o formato muda um pouquinho pra acomodar. Na quarta um segundo engenheiro, fundo no código, toma uma decisão por conta própria que a thread nunca cobriu, porque a thread tinha ficado em silêncio e o trabalho não podia esperar. Na quinta o design está, na prática, três revisões à frente do que foi acordado, e nenhuma dessas revisões existe em algum lugar pra onde você possa apontar. Na sexta sobe, no prazo, e é genuinamente incerto se está correto, porque não existe mais uma definição estável de correto pra checar.

Quando chega na review, a própria review silenciosamente trocou de função. Ela deveria checar o trabalho contra a decisão. Em vez disso vira uma sessão de arqueologia: pessoas reconstruindo, a partir do diff e da própria memória, qual deve ter sido a decisão, e negociando uma nova ali na hora pra tornar o trabalho aceitável. O time é bom nisso, e essa é a armadilha. Um time hábil em reconciliar drift consegue absorver uma quantidade enorme dele antes que alguém nomeie isso como problema, o que significa que o gap pode ficar aberto por muito tempo enquanto cada standup ainda reporta verde.

E aí o custo chega tarde, e chega como retrabalho. A feature que subiu no prazo é meio-reconstruída na semana seguinte, porque a versão que chegou em produção era a quarta revisão informal e o stakeholder queria a segunda. O estimate nunca esteve errado. A coisa sendo estimada mudou depois que o estimate foi dado. E essa é a parte que se compõe: não acontece uma vez. Acontece um pouquinho toda sprint, em cada peça de trabalho onde decidir e construir dividem o mesmo cômodo, até que uma parcela real da capacidade do time esteja indo pra reconciliar o que foi combinado com o que foi feito, todo ciclo, como um imposto permanente.

“A decisão é governança.

O trabalho é execução.”

IA Tornou a Execução Gratuita, e Execução Gratuita Corre Mais Rápido Que Governança Informal

Eis o que a maior parte da conversa atual sobre isso perde, porque está ocupada falando de IA escrevendo código bugado ou de prompts melhores. A mudança real é que a IA tornou a execução quase gratuita, e uma camada de execução gratuita se move mais rápido do que governança informal consegue acompanhar. Quando um engenheiro trabalhando com IA produz numa tarde o que costumava levar três dias, o trabalho corre na frente da decisão em vez de esperar por ela. Mais coisa é construída contra acordos que nunca foram fixados. O gap não fecha. Ele se abre, sprint após sprint, mais rápido do que qualquer thread consegue acompanhar.

Isso é um diagnóstico de estrutura ausente, não de IA, e essa distinção é o ponto inteiro. Quando a decisão está fixada antes do trabalho começar, execução barata vira a melhor coisa que pode acontecer com você. Cada unidade de construção quase gratuita aterriza numa decisão que segura, e a alavancagem se compõe em vez de se espalhar em quatro revisões. IA estruturada não é a opção lenta. É IA mirada num alvo que não está se movendo enquanto você atira nele.

Pare de Perguntar Se o Time É Rápido, Pergunte Onde Vivem as Decisões Fixas

Então se você lidera entrega, a pergunta para parar de fazer é se o time está executando rápido o suficiente. Velocidade raramente foi a restrição real, e a IA fez ela ser menos ainda. A pergunta para começar a fazer é se você consegue dizer, em qualquer momento, quais decisões podem se mover e quais não, e onde as que não podem de fato vivem. Se a resposta honesta é que elas vivem nas mesmas threads onde o trabalho é discutido, então você não tem uma camada de governança. Você tem uma conversa que ocasionalmente produz decisões e depois fica editando elas. A solução não é mais processo empilhado em cima do trabalho. É dar às decisões um lugar pra onde ir e parar de se mover, separado do lugar onde a construção acontece.

No prazo nunca foi a parte difícil. A parte difícil é saber se o que subiu ainda é o que vocês combinaram construir.