O que é "done" de verdade e por que a definição importa

O problema

Muita entrega parece pronta antes de estar pronta.

O time diz:

• “já terminei”
• “essa task está done”
• “agora só falta detalhe”

E os detalhes são exatamente o que derruba produção, QA ou rollout:

• teste faltando
• regra mal validada
• observabilidade inexistente
• documentação mínima não feita
• critério de aceite ainda aberto

Modelo mental

Pensa assim:

definição de done existe para impedir que “acabou” signifique coisas diferentes para pessoas diferentes.

Ela não serve para inflar processo.

Serve para alinhar o que precisa estar verdadeiro antes de chamar a entrega de concluída.

Quebrando o problema

”Código escrito” não é done

Esse é o primeiro corte importante.

Dependendo do contexto, entre “escrevi o código” e “está done” ainda podem existir:

• revisão
• testes
• validação funcional
• deploy
• monitoramento mínimo
• confirmação de que o fluxo crítico continua íntegro

O nível de done depende do risco

Nem toda task precisa do mesmo peso.

Uma alteração visual pequena pode pedir um done menor do que uma mudança em:

• faturamento
• autenticação
• checkout
• pipeline crítico

O erro não é ter gradação.

O erro é não explicitar qual é a barra de qualidade e operação em cada caso.

Done bom evita progresso falso

Sem definição clara, o board anda e a realidade não.

O time acha que queimou trabalho.

Mas na prática só empurrou incerteza para frente.

Isso destrói estimativa, status update e confiança.

Exemplo simples

Imagine um ticket de mudança em autenticação.

Versão fraca de done:

• código subiu
• PR aprovado

Versão melhor:

• código revisado
• fluxo feliz e erro principal validados
• deploy feito
• logs e alerta mínimo checados
• rollback conhecido

A segunda versão parece mais exigente.

Na prática, ela só é mais honesta sobre o que faltava.

Erros comuns

• Tratar “mergeado” como sinônimo de entregue.
• Fazer definição de done tão vaga que não decide nada.
• Fazer definição de done tão grande que ninguém leva a sério.
• Esconder qualidade e operação em “ajuste posterior”.
• Aplicar a mesma barra para todo tipo de trabalho sem contexto.

Como um senior pensa

Quem está mais maduro costuma usar definição de done como mecanismo de clareza, não como burocracia.

A lógica é:

• o que precisa estar verdadeiro para eu realmente confiar nessa entrega?
• o que é essencial neste tipo de fluxo?
• o que pode variar sem virar risco escondido?

Isso melhora muito a conversa entre engenharia, produto e QA.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador costuma procurar:

• noção de qualidade além do código
• clareza operacional
• entendimento de risco e contexto
• capacidade de alinhar o time sem ritual vazio

Uma resposta forte costuma soar assim:

Eu gosto de deixar claro que “done” não é só código escrito. Dependendo do fluxo, pode incluir revisão, teste, validação funcional e preparação mínima para operar a mudança. O objetivo não é burocratizar. É evitar chamar de pronto algo que ainda empurra risco para frente.

Quando o time não define done direito, o board fica otimista e a realidade continua devendo.