Por que o mesmo defeito volta?

Durante a “T01.02 — Qualidade Além dos Testes”, do QA Transform, surgiu uma situação familiar para muitas organizações: um problema conhecido reaparece em produção quando a operação está sob pressão. O serviço precisa voltar, o cliente espera e a equipe faz uma correção urgente. Para ganhar tempo, algumas etapas são puladas. A mudança pode não ser registrada corretamente ou ser aplicada em uma branch, mas não nas demais versões mantidas.

O sistema volta a funcionar. Dias ou semanas depois, o mesmo defeito retorna.

A urgência explica o atalho, mas não elimina sua consequência. Quando uma correção não é incorporada de forma consistente ao fluxo oficial, a organização não resolveu o problema: restaurou temporariamente a operação.

Corrigir não é o mesmo que resolver

Vale separar três termos. O defeito é uma condição no software, na configuração ou no processo capaz de produzir um comportamento incorreto. A falha é sua manifestação observável. O incidente é a situação em produção que exige resposta porque afeta usuários, operação ou negócio.

Durante um incidente, a prioridade inicial costuma ser reduzir o dano. Isso pode significar reverter um deploy, desativar uma funcionalidade, corrigir uma configuração ou publicar um hotfix, a correção emergencial. Essas ações tratam o sintoma imediato e podem ser exatamente o que a situação exige.

O problema começa quando a resposta termina aí.

Resolver de forma permanente exige investigar por que o defeito surgiu, escapou, chegou à produção e reapareceu. A análise de causa raiz reúne técnicas para atravessar as camadas do sintoma e encontrar causas e fatores contribuintes que possam ser tratados. Em sistemas complexos, raramente existe uma única causa ou um único culpado.

Uma técnica conhecida é a dos “Cinco Porquês”, associada a Sakichi Toyoda e incorporada às práticas de melhoria contínua. A ideia não é repetir “por quê?” mecanicamente, mas evitar que a primeira explicação conveniente seja aceita como diagnóstico.

Se o defeito voltou, a pergunta não é apenas “qual linha de código estava errada?”. Também precisamos saber: a correção chegou a todas as branches necessárias? Qual versão foi publicada? Havia um teste que reproduzia a falha? O procedimento de emergência estava definido?

Versionamento de código é memória organizacional

O Git foi criado em 2005 para apoiar o desenvolvimento distribuído do kernel Linux, um projeto com grande volume de mudanças e trabalho paralelo. Seu valor não está em tornar o trabalho mais formal, mas em permitir que alterações sejam registradas, comparadas, revisadas e integradas sem depender da memória de uma pessoa.

Um commit registra um ponto do código-fonte. Uma branch representa uma linha paralela de desenvolvimento. Uma release é uma versão preparada para uso. Deploy é a ação de colocá-la em um ambiente.

Esses termos não são sinônimos. Voltar para um commit anterior não restaura automaticamente a produção; normalmente é necessário publicar uma release conhecida e segura. Da mesma forma, corrigir uma branch não atualiza todas as outras. A equipe precisa definir como a mudança será incorporada às linhas mantidas, validada e implantada.

Por isso, o risco não está apenas em uma correção “ficar na máquina do desenvolvedor”. Ela pode estar no repositório e, ainda assim, não ter sido propagada para outra branch ou release. O código existe, mas as versões continuam divergentes e o defeito fica esperando o próximo deploy.

Da resposta urgente ao aprendizado

Uma resposta madura não ignora a urgência. Ela cria um caminho seguro para operar dentro dela.

Durante o incidente, a equipe restaura o serviço pelo meio de menor risco e registra o que foi alterado. Depois, reconcilia a correção com a fonte oficial do código, verifica as versões afetadas, adiciona evidências de teste e confirma o deploy. Por fim, analisa o ocorrido sem caça aos culpados, documentando impacto, causas e ações preventivas com responsáveis e prazos.

Análises estruturadas depois de incidentes relevantes, as Post-mortems, existem para transformar falhas em aprendizado compartilhado. Sem acompanhamento das ações, porém, o documento vira apenas um relato bem escrito do próximo problema recorrente.

As métricas ajudam a transformar percepções em sinais comparáveis: mostram se os incidentes estão se repetindo, se a recuperação está mais rápida e se as mudanças adotadas realmente melhoraram o processo. As métricas DORA, originadas de pesquisas sobre o desempenho da entrega de software, observam como velocidade e estabilidade se relacionam. Nesse contexto, o MTTR, Mean Time to Recover ou tempo médio de restauração, mede quanto tempo a equipe leva para restaurar o serviço após uma falha. Já o Change Failure Rate indica a proporção de deploys que causam incidentes ou exigem rollback e correções emergenciais. Esses números não revelam sozinhos a causa do problema, mas orientam a investigação e permitem acompanhar se as ações reduziram sua recorrência.

O custo invisível da reincidência

Considere um cenário ilustrativo: um incidente mobiliza duas pessoas de desenvolvimento, uma de operações, uma de QA, uma de produto e uma de suporte por duas horas. São 12 horas de trabalho desviadas, antes de contabilizar atendimento ao cliente, perda de transações, atraso de entregas ou desgaste reputacional.

Se isso acontece uma vez por mês, são 144 horas por ano consumidas pelo mesmo padrão. A empresa paga pela interrupção das prioridades, pela investigação repetida, pela comunicação de crise e pela incerteza criada para clientes e liderança.

Em um e-commerce, o defeito pode reaparecer no checkout durante uma campanha. Em uma fintech, na conciliação de pagamentos. Em uma plataforma SaaS, nas permissões de determinados clientes. O setor muda; o padrão permanece: uma solução parcial oferece alívio, mas não reduz o risco do sistema.

Qualidade também aparece depois do incidente

Qualidade além dos testes significa entender que a recorrência não pertence a uma única área. Desenvolvimento contribui com integração e testes. QA amplia cenários de risco e produz evidências. Operações fortalece observabilidade, rollback e resposta. Produto e negócio priorizam a correção estrutural. Suporte torna visível o impacto sobre clientes. Liderança protege tempo para aprendizado e evita transformar esforço emergencial em processo permanente.

Responsabilidade compartilhada não elimina especialidades. Ela impede que a organização espere que uma única função compense falhas de versionamento, decisão, comunicação e operação.

Quando um defeito volta, ele revela a qualidade real do produto e a capacidade da organização de alcançar resultados com previsibilidade. Restaurar o serviço foi necessário. Aprender, equalizar as versões e impedir a repetição é o que transforma resposta em maturidade.

A pergunta final não é apenas “quanto tempo levamos para corrigir?”. É: depois da correção, o sistema e a organização ficaram menos propensos a repetir o mesmo incidente?

E se a resposta é não, o problema não desapareceu. Ele só está esperando o próximo deploy em produção.

---

Mas antes de encerrar completamente essa história, resta outra pergunta incômoda: e se o próximo deploy for amanhã?

Agir rápido não precisa significar abandonar o controle. Times maduros preparam caminhos para entregar, interromper, reverter e restaurar mudanças sem depender de memória ou sorte.

No próximo post, vamos olhar para duas medidas citadas que ajudam a separar velocidade sustentável de improviso: Lead Time e tempo de recuperação. Afinal, ser rápido pode demonstrar maturidade, ou apenas cortar caminho até o próximo problema.