Definição de pronto: o contrato secreto que ninguém escreve

80% dos contratos com squad externo quebram antes do primeiro deploy. O motivo nunca é técnico — é a definição de pronto. Veja por que a maioria dos times pula essa conversa e como estruturar a sua antes de assinar.

Por Victhor Araújo

Victhor Araújo

Toda vez que um contrato com squad externo quebra, alguém aponta para o código. "A qualidade caiu", "estão entregando bug", "não bate com o que pedimos". O código é o sintoma. A causa é quase sempre outra: o cliente e o squad estavam usando a mesma palavra — "pronto" — para descrever coisas diferentes.

A definição de pronto não está no SOW. Não está no MSA. Não está no playbook do squad. Ela vive na cabeça de cada pessoa envolvida, e cada cabeça tem uma versão.

Este artigo é para founders, CTOs e gestores que estão prestes a contratar um squad externo — ou que já contrataram e sentem que algo está sempre fora do esperado.

Squad alinhando o que conta como "pronto" no quadro branco antes do sprint começar

🤝 O contrato escrito vs. o contrato real

O contrato escrito fala sobre escopo, prazo, valor e cláusulas de rescisão. Todos lêem, todos assinam, todos arquivam. Pronto, formalidade resolvida.

O contrato real só aparece quando a primeira entrega acontece. É nesse momento que o cliente descobre que o squad considerou "pronto" o que ele esperava como "primeiro draft". E o squad descobre que o cliente esperava QA, deploy e validação no mesmo entregável.

As lacunas mais comuns:

• Pronto pelo dev: código mergeado, testes passando.
• Pronto pelo tech lead: code review, deploy em staging, smoke test.
• Pronto pelo PM: feature em produção, métrica subindo, time de suporte avisado.
• Pronto pelo cliente: usuários usando, sem reclamações, com documentação atualizada.

Cada um dos quatro estados é "pronto". Mas a distância entre o primeiro e o último é onde 80% dos contratos morrem.

💥 5 sintomas de definição de pronto mal feita

• Retrabalho recorrente em features "já entregues" — porque cada review descobre uma nova lacuna.
• Sprints que terminam com 90% de "pronto" e 10% de "quase" — o "quase" sempre vira o sprint seguinte.
• Discussões sobre escopo a cada review — sinal de que ninguém concordou sobre o nível de finalização esperado.
• Dúvidas sobre quem testa o quê — QA do squad, QA do cliente, usuário em homologação.
• Bugs que aparecem semanas depois — porque a definição parou em "passou nos testes do dev".

✅ Os 4 níveis de "pronto" que todo squad deveria ter

A solução não é uma única definição de pronto. É reconhecer que existem camadas — e contratar a camada certa.

1. Feature complete

Código mergeado na main, testes unitários passando, code review aprovado. O dev terminou o que pegou para fazer.

2. Quality complete

QA validou cenários positivos e negativos, edge cases documentados, regressão de áreas adjacentes verificada. Time de qualidade assinou embaixo.

3. Deploy complete

Feature em produção (ou em ambiente de homologação real), feature flag configurada, observabilidade ligada, plano de rollback documentado.

4. Adoption complete

Métrica de adoção batendo, documentação atualizada, time de suporte treinado, casos de uso comuns sem aumento de tickets. Aqui a feature está realmente "pronta" para o negócio.

O verdadeiro contrato é definido quando os dois lados concordam sobre a entrega

📝 Template de definição de pronto (use à vontade)

Antes da primeira sprint, sente com o squad e responda explicitamente:

• Qual é o nível mínimo de pronto que esperamos para cada entrega? (1, 2, 3 ou 4)
• Quem é responsável por levar do nível N até N+1? (dev, QA, devops, PM, cliente)
• Em quanto tempo o nível seguinte deve acontecer? (mesmo sprint, sprint seguinte, semana corrida)
• O que acontece se o nível esperado não for atingido? (re-trabalho, replanejamento, override)
• Onde isso fica escrito e acessível? (Notion, Confluence, README do projeto — não no Slack)

📢 Quer um template que a Revin usa internamente? Fale com nossos especialistas em um Diagnostic Sprint e a gente envia o nosso playbook de DoD junto.

🎯 Conclusão: definir pronto é definir o que você está comprando

A pergunta certa antes de assinar não é "quanto custa", é "o que conta como entregue?". Sem essa resposta, qualquer valor é caro. Com ela, qualquer valor pode caber.

Squads que insistem em alinhar definição de pronto antes do início parecem chatos. São os mesmos que entregam no prazo.

📢 Está prestes a contratar um squad e quer evitar essa armadilha? Conheça nosso modelo de delivery — DoD vem no kit.