Uma pergunta que Murilo Moura Alencar, board member e Tech, People & Game Strategist, considera das menos úteis costuma abrir reuniões depois de uma falha grave: quem errou? O sistema de pagamentos ficou fora do ar por três horas no sábado; um desenvolvedor aplicou a atualização que desencadeou o problema, e a conversa termina com uma advertência e a sensação de assunto resolvido.
Não está. A causa real quase sempre envolve um processo que permitiu que o erro chegasse até ali. É isso que a análise de incidentes sem culpados, prática difundida em equipes de engenharia de software, procura descobrir. A seguir, os passos para aplicá-la.
Separe a pessoa do evento
O ponto de partida é assumir que todos agiram com boa intenção e com as informações que tinham naquele momento. Murilo Moura Alencar comenta que isso até pode parecer ingenuidade, mas, na realidade, é pragmatismo.
Quando um erro resulta em punição, a equipe aprende uma lição diferente da esperada: esconder problemas. O desenvolvedor que admitiu a falha e foi advertido dificilmente será o primeiro a levantar a mão na próxima vez, e os colegas também não. A empresa passa a descobrir os erros mais tarde, quando já custam mais caro. Tirar a culpa da mesa não significa tirar a responsabilidade. Significa deslocá-la da pessoa para o sistema que todos compartilham.
Reconstrua a linha do tempo
Com o clima certo, o próximo passo é montar a sequência dos fatos: quando o problema começou, quando foi percebido, quem foi acionado e que decisões foram tomadas em cada momento.
O detalhe mais importante é registrar o que cada pessoa sabia na hora, e não o que se sabe agora. Depois que o desfecho é conhecido, qualquer decisão parece obviamente errada, um efeito que a psicologia chama de viés retrospectivo. Murilo Alencar lembra que, sem esse cuidado, a linha do tempo vira um julgamento disfarçado, e a equipe volta a se proteger em vez de contribuir.
Pergunte como, não quem
Em vez de perguntar quem aplicou a atualização, a análise pergunta como uma mudança sem teste suficiente conseguiu chegar ao ambiente de produção. A troca de pronome muda a conversa inteira.
Surgem então fatores que ninguém via: a etapa de revisão era opcional em horários de pouco movimento, o alerta que deveria ter disparado estava desligado, e a documentação para desfazer a mudança não existia. Raramente há uma causa única. Incidentes graves costumam nascer da combinação de várias fragilidades pequenas, cada uma inofensiva quando isolada. Corrigir apenas o comportamento de uma pessoa deixaria todas as outras fragilidades intactas, à espera do próximo incidente.
Transforme conclusões em ações
Uma análise que termina em boas intenções não muda nada. Cada fragilidade encontrada precisa virar uma ação concreta, com responsável e prazo: tornar a revisão obrigatória, reativar o alerta, escrever o roteiro para reverter atualizações. Ações vagas, como ter mais atenção, não contam, porque não alteram nada no processo.
Também vale compartilhar o documento final com outras equipes. Um incidente analisado com cuidado ensina a empresa inteira, e não apenas quem estava de plantão naquele sábado. Acompanhar a conclusão das ações nas semanas seguintes fecha o ciclo e mostra que o processo é levado a sério.
Segurança para errar é segurança para aprender
A aviação percebeu cedo que pilotos só relatam quase acidentes quando não temem punição, e esses relatos se tornaram uma das principais fontes de melhoria da segurança de voo. Equipes de tecnologia seguem a mesma lógica. Onde o erro pode ser contado, ele pode ser corrigido, e a cultura que permite falar da falha sem medo é a mesma que ajuda a prevenir a seguinte.
Para Murilo Moura Alencar, a forma como uma empresa reage à primeira grande falha diz mais sobre sua cultura do que qualquer declaração de valores, porque é nesse momento que a equipe descobre se pode ou não confiar na liderança.
