Armadilhas comuns a serem evitadas

O roteiro que discutimos para ajudá-lo a começar com o processo de revisão pós-incidente é útil, mas também pode ser útil saber sobre alguns dos obstáculos que você pode encontrar nesta jornada.

Nesta unidade, você descobrirá sobre algumas armadilhas comuns em que outras pessoas caíram durante o processo de revisão pós-incidente e como evitá-las.

Trap 1: Atribuição a "erro humano"

Você pode se lembrar de que "erro do piloto", uma forma específica do rótulo mais geral de "erro humano", foi a conclusão à qual os investigadores iniciais chegaram na história do B-17 que começamos na introdução do módulo. Vamos voltar para essa história.

Nessa introdução, sugerimos que as conclusões alcançadas poderiam ser insatisfatórias para você. Eles estavam definitivamente insatisfeitos com Alphonse Chapanis, um psicólogo militar que foi solicitado pelas Forças Aéreas do Exército dos EUA (USAAF) a investigar esses incidentes. Ele notou, entre outras coisas, que esses acidentes eram exclusivos do B-17 e um pequeno número de outras aeronaves. Havia milhares de aeronaves de transporte C-47 em uso na Europa Ocidental ao mesmo tempo, mas nenhum C-47 jamais havia experimentado um incidente semelhante.

Então ele entrevistou pilotos, e com base no que ouviu deles, ele foi e olhou para os cockpits B-17. O que ele viu foram dois interruptores: o interruptor de engrenagens e o interruptor de flaps. Os interruptores estavam a cerca de 3 polegadas de distância um do outro na cabine. O modo de operação deles era idêntico. Eles eram muito fáceis de confundir uns com os outros, e foi isso que aconteceu nesses incidentes. Se você acabou de pousar um avião, os seus flaps serão estendidos e, antes de estacionar, você vai retraí-los. E então Chapanis tentou algo diferente.

Ele colou uma pequena roda de borracha no comutador do trem de pouso e um "flap" fixo angular no comutador dos flaps e os acidentes pararam de acontecer.

Ele agora é conhecido como um dos fundadores do campo da ergonomia (o estudo de fatores de design no desempenho humano), e ele teve uma observação simples: o design do cockpit poderia afetar a probabilidade de erro humano. Essa abordagem passou a influenciar o design de aeronaves modernas. Por exemplo, nos Estados Unidos, os regulamentos para aeronaves da categoria de transporte exigem que o controle do trem de pouso tenha formato de roda e seja distinto do controle dos flaps.

Então, por que contamos essa história?

Humanos cometem erros. No entanto, o erro humano não é uma causa; É um sintoma. Quando o erro humano é considerado o motivo de uma falha, as pessoas param por aí em vez de analisar o incidente.

O design do sistema, o contexto organizacional e o contexto pessoal influenciam quando, como e com o impacto que as pessoas cometem erros. "Erro humano" é um rótulo que faz com que você pare de investigar exatamente no momento em que está prestes a descobrir algo interessante sobre seu sistema.

O problema com a conclusão do "erro humano" nas investigações é que faz você ignorar o fato de que o que os humanos fizeram parecia fazer sentido para eles na época. Erros, por definição, não são deliberados, então eles não pretendiam cometer um erro.

Quando vemos ou ouvimos "erro humano", é um sinal de que precisamos olhar mais fundo. Se quisermos aprender, não devemos parar de investigar quando encontramos um erro humano, como muitas vezes fazemos. Como a história dos B-17 demonstra, logo após o erro humano é onde aprendemos coisas interessantes sobre nosso sistema.

Armadilha 2: Raciocínio contrafatual

Contrafactual significa "contrário aos fatos", e o raciocínio contrafactual refere-se a contar uma história sobre eventos que não aconteceram para explicar os eventos que aconteceram. Isso não faz muito sentido, mesmo que as pessoas tenham uma tendência a fazê-lo o tempo todo.

Você pode identificar afirmações contrafactuais por frases-chave.

• Poderia ter
• Deveria ter
• Teria
• Falha ao
• Não
• Se apenas

Alguns exemplos de afirmações contrafactuais relacionadas a revisões pós-incidente:

"O sistema de monitoramento falhou ao detectar o problema."

"O engenheiro não verificou a validade da configuração antes de promulgá-la."

“Isso poderia ter sido detectado no ambiente de canário.”

O problema com esse tipo de raciocínio em uma revisão pós-incidente é que você está falando sobre coisas que não aconteceram em vez de ter tempo para entender como o que aconteceu, aconteceu. Você não aprende nada com essa especulação.

Trap 3: Linguagem normativa

A linguagem normativa geralmente implica que havia um curso de ação "obviamente correto" que os operadores deveriam ter tomado, e julga as ações desses operadores com o benefício da retrospectiva.

A linguagem normativa geralmente pode ser identificada por adverbs como "inadequadamente", "descuidadamente", "às pressas" e assim por diante.

O pensamento normativo leva você a julgar decisões com base em seus resultados. Essa forma de falar não é lógica, porque o resultado é a única informação que não estava disponível para aqueles que tomaram as decisões e julgamentos.

A linguagem normativa também pode ser usada no sentido oposto. As pessoas podem elogiar os operadores por terem agido "adequadamente", por exemplo. Mas, novamente, muitas vezes esse julgamento é feito com o benefício da informação que as pessoas em questão não tinham.

O problema com a linguagem normativa é semelhante ao problema do raciocínio contrafactual: se fizermos julgamentos após o fato de usar informações que não estavam disponíveis para os humanos envolvidos durante o incidente, negligenciamos entender como as ações dos operadores faziam sentido para eles na época.

Trap 4: Raciocínio mecanicista

O raciocínio mecanicista refere-se ao conceito de que um resultado específico pode ser inferido da intervenção. Às vezes é chamada de síndrome das crianças intrometidas (cunhada por Jessica DeVita) com base na premissa de que "Nosso sistema teria funcionado bem... se não tivesse sido para essas crianças intrometidas.

Quando você usa o raciocínio mecanicista em sua revisão pós-incidente, você constrói suas conclusões sobre a falácia de que os sistemas com os quais você trabalha e dentro estão basicamente funcionando corretamente, e se apenas essas "crianças intrometidas" não tivessem feito o que fizeram, a falha não teria ocorrido.

No entanto, não é assim que os sistemas funcionam.

Para ilustrar esse ponto, imagine o seguinte cenário: você trabalha em um serviço de produção. Agora você é informado de que você não tem permissão para tocar ou fazer nada com esse serviço. Tudo fora de sua equipe continua como antes: os clientes continuam a usar o serviço, as dependências externas continuam a mudar, a Internet funciona normalmente.

Mas você não pode fazer nenhuma alteração no código ou configuração. Sem implantações, sem operações de plano de controle, nada.

Você acha que seu serviço ainda estaria em execução conforme o esperado após um dia? Depois de uma semana? Depois de um mês? Depois de um ano? Por quanto tempo você poderia esperar realisticamente que seu serviço continuasse em execução sem intervenção humana? Na maioria dos casos, não seria.

Este exercício de pensamento nos leva a uma conclusão importante:

A capacidade adaptável humana é necessária para manter nossos sistemas funcionando.

A única razão pela qual seus sistemas permanecem funcionando em primeiro lugar é por causa das ações dos humanos no loop de controle. É apenas através da ação humana e da capacidade de se adaptar às circunstâncias em mudança que o sistema continua a funcionar.

Portanto, é errado concluir que o sistema estava "basicamente funcionando... se não tivesse sido para essas crianças intrometidas. Na verdade, a confiabilidade do seu serviço não é independente dos humanos que trabalham nele. Em vez disso, é um resultado direto do trabalho que os humanos fazem nele todos os dias.

O problema com o raciocínio mecanicista é que ele leva você a um caminho onde você acredita que encontrar o humano defeituoso é equivalente a encontrar o problema. No entanto, esse mesmo humano defeituoso vem improvisando e se adaptando para manter o sistema funcionando por semanas e meses. Talvez essa função seja importante o suficiente para refletir em sua revisão pós-incidente.

Agora que você sabe algumas coisas a evitar durante uma revisão pós-incidente, podemos passar para a próxima unidade, onde exploraremos algumas das práticas úteis para essas revisões.