Mentalidade de Registro de Erros

Do erro ao fluxo: o caminho sem culpa

Você já fez a parte mais difícil — registrar. Agora o registro precisa virar dado, não papel. Reúna a equipe e declare: "Nosso objetivo não é achar culpado, é achar o ponto de falha no fluxo."

Passo a passo concreto

1. Reconstrua a cadeia de decisão: pergunte à técnica o que ela viu, pensou e assumiu antes de administrar. Não "por que você errou", mas "o que te levou a confirmar aquele leito?".
2. Aplique os cinco porquês: por que o leito errado? Porque confirmou só o sobrenome. Por que só o sobrenome? Porque a pulseira estava virada. Por que virada? Porque o suporte estava mal posicionado. Chegou no fluxo.
3. Vire em procedimento: crie a regra de dupla checagem com nome completo + data de nascimento + leito, verbalizada em voz alta. Teste por 30 dias.
4. Registre o antes e depois: anote quantas vezes a checagem falhou no período.

Erro vira melhoria quando muda o processo, não quando muda a pessoa.

A técnica não é o problema — o fluxo que permitia confusão é. Ao atacar o fluxo, você protege a equipe e o paciente. Isso não é punição; é engenharia de segurança.

Três incidentes, um padrão escondido

"Falta de atenção" é o fim da conversa, não o começo. Você precisa de um Issue Log nos moldes da Bridgewater: todo incidente vira um registro estruturado, sem exceção.

Como classificar cada bug:

1. Categoria: comunicação de requisito, ausência de teste de integração, débito técnico, mudança de contexto.
2. Gravidade: impacto no usuário (tempo de indisponência, perda de dados, bloqueio de conversão).
3. Causa raiz com cinco porquês: por que o checkout caiu? Porque uma migração sobrescreveu config. Por que sobrescreveu? Porque o deploy rodou sem validação. Por que sem validação? Porque o pipeline não tinha teste de regressão para aquele endpoint.
4. Padrão: agrupe os três incidentes. Se todos envolvem deploy sem validação, o padrão é "pipeline fraco", não "pessoas descuidadas".

Ação que quebra o ciclo: para cada padrão identificado, escreva uma mudança de processo mensurável — por exemplo, "todo deploy que toca checkout exige smoke test automatizado, bloqueando merge se falhar".

Se o mesmo erro volta três vezes, o problema não é atenção; é ausência de barreira.

Registre, classifique, agrupe e ataque a causa sistêmica. Só então a retrospectiva deixa de ser teatro e vira engenharia.

Do "travamento invisível" ao mapa didático

Você identificou o sintoma: repetição. Agora precisa documentar onde exatamente a compreensão quebra. Sem registro, você ensina no escuro.

Método simples, aplicável já na próxima aula:

1. Crie um "caderno de travamentos" — físico ou digital, uma página por questão/tópico. Cada vez que um aluno errar, anote: qual frase do enunciado confundiu, qual alternativa foi escolhida, o que ele disse ao explicar o raciocínio.
2. Classifique o tipo de erro: vocabulário desconhecido, inferência além do texto, confusão entre ideia principal e detalhe, pressa na leitura.
3. Após cada avaliação, agrupe por padrão. Se 70% dos erros caem em "inferência", sua explicação precisa mudar: em vez de repetir o conteúdo, ensine explicitamente a estratégia de inferência com exemplos contrastados.
4. Ajuste a didática com base no dado: se o travamento é vocabular, introduza glossário antes da leitura; se é pressa, ensine sublinhado seletivo.

Repetir a mesma explicação para o mesmo erro é esperar resultado diferente com a mesma ação.

O caderno vira seu instrumento de melhoria contínua. No próximo bimestre, você não pergunta "por que erraram de novo", mas "o que mudei no ensino com base no que registrei". Isso transforma erro de aluno em dado de professor.