Quando “está feito” ainda não "está pronto"
Times não quebram por falta de código. Quebram por falta de acordos claros. Se "pronto" não significa o mesmo para todos, não é entrega, é só o problema passando de mão.
Já perdi a conta de quantas vezes disse "agora vai" antes de tudo desmoronar. Uma apresentação "pronta", um sistema "finalizado", uma decisão "madura".
Lembro de uma vez em que fechei o notebook com aquela sensação boa de dever cumprido. No dia seguinte, duas perguntas simples foram suficientes para desmanchar tudo. Não faltava esforço nem intenção, faltava definição. Eu achava que estava tudo pronto, mas descobri que não estava.
Essa confusão é mais comum do que parece. No mundo de software, ela é quase um esporte olímpico.
Feito vs. Pronto
Em projetos de TI, "feito" costuma significar: o código existe, compila, passa nos testes (os que lembramos de escrever) e atende ao requisito descrito. É um estado técnico objetivo, binário. Ou funciona, ou não funciona.
Pronto é outra conversa.
Pronto envolve contexto. É quando o software não só funciona, mas pode ser usado sem sustos. Quando está documentado o suficiente para alguém além do autor entender. Quando passou por revisão, foi testado em cenários reais, está monitorável, implantável e, detalhe importante, alinhado com o que o negócio realmente precisa agora, não com o que parecia boa ideia três sprints atrás.
É aqui que entra um conceito frequentemente subestimado: critério de aceite.
A ponte entre expectativa e realidade
Os critérios de aceite traduzem, de forma clara e verificável, o que precisa ser verdade para que algo seja considerado aceitável. Não são lista de desejos, nem contrato jurídico. São acordos explícitos que tiram o "eu achei que..." da conversa e colocam o "estava combinado que...".
Sem critérios de aceite, o time corre. Com critérios de aceite, o time corre na direção certa.
Mas tem um ponto que as metodologias ágeis trazem, mas muita gente ignora: Definition of Done - DoD e Definition of Ready - DoR não são apenas acordos internos de um time. Eles também existem, e são críticos, entre equipes.
Um exemplo real
Em um projeto de dados que trabalhei, o time de engenharia entregou uma nova pipeline para o time de analytics. Tecnicamente, estava tudo "feito": dados chegando, jobs rodando, logs limpos. Para a squad de engenharia, o trabalho estava encerrado.
Para o time de analytics, o caos estava começando.
Os dados não tinham dicionário. Os campos não estavam padronizados. Não havia histórico suficiente para análises comparativas. O SLA de atualização não estava claro.
A pergunta inevitável surgiu: isso está pronto para uso? A resposta honesta era: depende para quem você pergunta.
O que faltava ali não era competência técnica, era um DoD compartilhado entre equipes. Para a engenharia, "pronto" significava pipeline estável. Para o analytics, "pronto" significava confiável, compreensível e analisável. Dois conceitos legítimos, mas desalinhados.
A solução não foi escrever mais código. Foi sentar as equipes e definir critérios de aceite explícitos entre elas:
— Quais campos são obrigatórios?
— Qual nível de qualidade de dados é aceitável?
— Qual latência máxima é tolerável?
— O que precisa estar documentado antes da entrega?
A partir daí, o "pronto" do time de engenharia passou a ser também o "feito" do time de analytics. Só se entrega o que o outro time consegue, de fato, consumir. O resultado? Menos atrito, menos retrabalho, mais confiança entre as áreas.
Responsabilidade compartilhada
Times maduros entendem isso. Criam definitions não para se proteger, mas para colaborar melhor. Porque, em ambientes complexos, ninguém trabalha sozinho. Sempre existe alguém depois de você na cadeia de valor.
Afinal, falar de "pronto" é falar de responsabilidade compartilhada, com o usuário final, com o próximo time, com o futuro. É aceitar que terminar sua parte não significa que o trabalho acabou.
Da próxima vez que você disser “está pronto”, faça uma pausa e pergunte:
pronto para quem vem depois de mim?
Se a resposta não for clara, talvez você não esteja entregando valor, só transferindo o problema para o próximo sprint, ou para o próximo time.
Porque times não quebram por falta de código.
Quebram por falta de acordos claros.
E quando “pronto” não significa o mesmo para todos os envolvidos, o retrabalho já está contratado. Só ainda não foi entregue.
Você já viveu isso? O que mudou quando os critérios ficaram explícitos?
