Armadilhas comuns a serem evitadas
O roteiro que discutimos para ajudar você a começar 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 nesse percurso.
Nesta unidade, você descobrirá algumas armadilhas comuns em que outras pessoas caíram durante o processo de revisão pós-incidente e como evitá-las.
Armadilha 1: Atribuição a “erro humano”
Você pode se lembrar de que "erro do piloto" (também conhecido como "erro humano") foi a conclusão a que os investigadores iniciais chegaram na história sobre a B-17 que começamos na introdução do módulo. Vamos retornar para essa história.
Naquela introdução, sugerimos que as conclusões obtidas poderiam não ser satisfatórias para você. E elas com certeza não foram satisfatórias para Alphonse Chapanis, um psicólogo militar que a Força Aérea dos EUA solicitou para investigar esses incidentes. Ele observou, entre outras coisas, que esses acidentes eram exclusivos à B-17 e a uma pequena quantidade de outras aeronaves. Havia milhares de aeronaves de transporte C-47 em uso na Europa Ocidental ao mesmo tempo, mas nenhuma C-47 tinha tido um incidente semelhante antes.
Então ele entrevistou pilotos, e com base no que ouviu deles, ele examinou as cabines de pilotagem da B-17. O que ele viu foi que havia dois comutadores: o comutador do trem de pouso e o comutador dos flaps. Os comutadores tinham cerca de 3 polegadas (cerca de 7,5 centímetros) de distância uns dos outros na cabine de pilotagem. O modo de operação deles era idêntico. Eles eram simplesmente muito fáceis de confundir e isso é o 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. Assim, 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 da área de ergonomia (o estudo de fatores de design no desempenho humano) e fez uma simples observação: que o design da cabine de pilotagem pode afetar a probabilidade de erro humano. Essa abordagem passou a fazer parte do design de todas as aeronaves modernas. Os dois comutadores em aviões atuais agora são muito distintos, conforme exigido pela lei federal nos EUA.
Então, por que contamos essa história?
As pessoas cometem erros. No entanto, erro humano não é uma causa, é um sintoma. Quando o erro humano é considerado o motivo de uma falha, as pessoas param aí em vez de analisar ainda mais o incidente.
O design do sistema, o contexto organizacional e o contexto pessoal afetam quando as pessoas erram, como erram e o que as faz errar. “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 o seu sistema.
O problema com a conclusão de “erro humano” nas investigações é que ela faz com que você perca a percepção de que o que as pessoas fizeram fazia sentido para elas naquele momento. Os erros, por definição, não são deliberados, portanto, elas não pretendiam cometer um erro.
Quando vemos ou ouvimos “erro humano”, é um sinal que precisamos analisar mais profundamente. Se quisermos aprender, não poderemos parar a investigação quando localizarmos um erro humano, como fazemos com tanta frequência. Como a história da B-17s demonstra, um pouco além do erro humano é onde aprendemos coisas interessantes sobre nosso sistema.
Armadilha 2: Raciocínio contrafatual
Contrafatual significa “contrário aos fatos” e o raciocínio contrafatual refere-se a contar uma história sobre eventos que não aconteceram, a fim de explicar os eventos que aconteceram. Isso não faz muito sentido, embora as pessoas tenham a tendência de fazê-lo frequentemente.
Você pode identificar declarações contrafatuais por frases-chave:
- Poderia ter
- Deveria ter
- Teria
- Falha ao
- Não
- Se apenas
Alguns exemplos de declarações contrafatuais relacionadas a revisões pós-incidente:
“Falha ao detectar o problema do sistema de monitoramento.”
“O engenheiro não verificou a validade da configuração antes de aprová-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 algo que não aconteceu, em vez de dedicar um tempo para entender como o que aconteceu, aconteceu. Você não aprende nada com essa especulação.
Armadilha 3: Linguagem normativa
A linguagem normativa geralmente implica que havia um plano de ação "obviamente correto" que os operadores deveriam ter tomado e julga as ações desses operadores com o benefício de uma visão retrospectiva.
A linguagem normativa geralmente pode ser identificada por advérbios, como “inadequadamente”, “descuidadamente”, “apressadamente” e assim por diante.
O pensamento normativo leva você a avaliar decisões com base nos seus resultados. Essa maneira de falar não é lógica porque o resultado é a única informação que não estava disponível àqueles que tomaram 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 das informações que as pessoas em questão não tinham.
O problema com a linguagem normativa é semelhante ao problema com o raciocínio contrafatual: se fizermos julgamentos após o fato usando informações que não estavam disponíveis para as pessoas envolvidas durante o incidente, não entenderemos como as ações dos operadores faziam sentido para eles naquele momento.
Armadilha 4: Raciocínio mecanicista
O raciocínio mecanicista refere-se ao conceito de que um determinado resultado pode ser inferido pela intervenção. Às vezes, ele é chamado de síndrome da criança enxerida (cunhado por Jessica DeVita) com base na premissa de que “Nosso sistema teria funcionado… se não fossem essas crianças enxeridas”.
Ao usar o raciocínio mecanicista na sua revisão pós-incidente, você cria as suas conclusões com base na falácia de que os sistemas com os quais você trabalha e dos quais você faz parte estão basicamente trabalhando corretamente e, se não fossem as “crianças enxeridas” terem feito o que quer que elas tenham feito, 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 não tem permissão para tocar ou fazer nada nesse serviço. Tudo exceto a sua equipe continua como antes: os clientes continuam a usar o serviço, as dependências externas continuam a mudar e a Internet funciona normalmente.
Mas você não pode fazer nenhuma alteração no código ou na configuração. Nenhuma implantação, nenhuma operação do painel de controle, nada.
Você acha que o seu serviço ainda estaria sendo executado conforme o esperado após um dia? Após uma semana? Após um mês? Após um ano? Por quanto tempo realisticamente você espera que o seu serviço continue em funcionamento sem a intervenção humana? Na grande maioria dos casos, ele não continuaria.
Esse exercício de reflexão nos leva a uma conclusão importante:
A capacidade adaptável humana é necessária para manter os nossos sistemas em funcionamento.
O único motivo pelo qual os sistemas permanecem em funcionamento em primeiro lugar é devido às ações de seres humanos no loop de controle. É apenas por meio de ação humana e da capacidade de adaptar-se às circunstâncias em constante mudança que o sistema continua a funcionar.
Portanto, é errado concluir que o sistema estava “basicamente funcionando… se não fossem essas crianças enxeridas”. Na verdade, a confiabilidade do seu serviço não é independente dos seres humanos que trabalham nele. Em vez disso, é um resultado direto do trabalho que os seres humanos realizam nele todos os dias.
O problema com o raciocínio mecanicista é que ele leva a um caminho no qual você acredita que localizar o humano com falha é equivalente a localizar o problema. No entanto, esse mesmo humano com falha esteve improvisando e adaptando para manter o sistema em execução por semanas e meses. Talvez essa função seja importante o suficiente para refletir na sua revisão pós-incidente.
Agora que você sabe algumas coisas que devem ser evitadas durante uma revisão pós-incidente, podemos passar para a próxima unidade, na qual exploramos algumas das práticas úteis nessas revisões.