Armadilhas comuns a evitar
- 7 minutos
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 nessa jornada.
Nesta unidade, você descobrirá algumas armadilhas comuns nas quais outros caíram durante o processo de revisão pós-incidente e como evitá-las.
Armadilha 1: Atribuição a "erro humano"
Você deve se lembrar que "erro piloto" (também conhecido como "erro humano") foi a conclusão a que os investigadores iniciais chegaram na história do B-17 que começamos na introdução do módulo. Voltemos a essa história.
Nessa introdução, sugerimos que as conclusões alcançadas podem ser insatisfatórias para si. Eles foram definitivamente insatisfatórios para Alphonse Chapanis, um psicólogo militar que foi convidado pela Força Aérea dos EUA para investigar esses incidentes. Ele notou, entre outras coisas, que esses acidentes eram exclusivos do B-17 e de uma pequena quantidade de outras aeronaves. Havia milhares de aviões de transporte C-47 em uso na Europa Ocidental ao mesmo tempo, mas nenhum C-47 havia sofrido um incidente semelhante.
Então ele entrevistou pilotos e, com base no que ouviu deles, foi e olhou para os cockpits do B-17. O que ele viu foram dois interruptores: o interruptor de marchas e o interruptor de abas. Os interruptores estavam a cerca de 3 centímetros de distância um do outro no cockpit. O seu modo de funcionamento era idêntico. Eram simplesmente demasiado fáceis de confundir, e foi isso que aconteceu nestes incidentes. Se você acabou de pousar um avião, suas abas serão estendidas e, antes de estacionar, você as retrairá. E assim Chapanis tentou algo diferente.
Ele colou uma pequena roda de borracha no interruptor para a marcha, e uma "aba" angular dura no interruptor para as abas, e com certeza 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 tinha uma observação simples: o design do cockpit poderia afetar a probabilidade de erro humano. Esta abordagem passou a informar o projeto de todas as aeronaves modernas. Os dois interruptores nos aviões atuais são agora muito distintos, como manda a lei federal nos EUA.
Então, por que contamos essa história?
Os seres humanos cometem erros. No entanto, erro humano não é uma causa; é um sintoma. Quando o erro humano é considerado a razão de uma falha, as pessoas param por aí em vez de analisar melhor o incidente.
O design do sistema, o contexto organizacional e o contexto pessoal afetam quando, como e com que impacto 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 ela faz com que você perca de vista o fato de que o que os humanos fizeram fazia sentido para eles na época. Os erros, por definição, não são deliberados, por isso não pretendiam errar.
Quando vemos ou ouvimos "erro humano", é um sinal de que precisamos olhar mais fundo. Se queremos aprender, não devemos parar de investigar quando encontramos um erro humano, como tantas vezes fazemos. Como a história dos B-17 demonstra, logo além do erro humano é onde aprendemos coisas interessantes sobre nosso sistema.
Armadilha 2: Fundamentação contrafactual
contrafáctico significa "contrário aos factos", e raciocínio contrafáctico refere-se a contar uma história sobre eventos que não aconteceram para explicar os eventos que ocorreram. Isso não faz muito sentido, embora as pessoas tenham a tendência de fazê-lo o tempo todo.
Pode identificar declarações contrafactuais através de frases-chave:
- Poderia ter
- Devia ter
- Teria
- Não conseguiu
- Não
- Se ao menos
Alguns exemplos de declarações contrafactuais relacionadas com análises pós-incidente:
"O sistema de monitoramento não conseguiu detetar o problema."
"O engenheiro não verificou a validade da configuração antes de implementá-la."
"Isso poderia ter sido captado no ambiente 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 reservar um tempo para entender como o que aconteceu, aconteceu. Não se aprende nada com esta especulação.
Armadilha 3: Linguagem normativa
A linguagem normativa muitas vezes implica que houve 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 visão retrospetiva.
A linguagem normativa geralmente pode ser identificada por advérbios como "inadequadamente", "descuidadamente", "apressadamente" e assim por diante.
O pensamento normativo leva-o a julgar decisões com base nos seus resultados. Esta maneira de falar não é lógica, porque o resultado é a única peça de 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 de informações que as pessoas em questão não tinham.
O problema da linguagem normativa é semelhante ao problema do raciocínio contrafactual: se fazemos julgamentos após o fato usando informações que não estavam disponíveis para os seres humanos envolvidos durante o incidente, negligenciamos entender como as ações dos operadores faziam sentido para eles na época.
Armadilha 4: Raciocínio mecanicista
de raciocínio mecanicista refere-se ao conceito de que um determinado resultado pode ser inferido da intervenção. Às vezes é chamado de síndrome de crianças intrometidas (cunhado por Jessica DeVita) com base na premissa de que "Nosso sistema teria funcionado bem... se não fossem aquelas 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 deles 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 informam-lhe que não lhe é permitido tocar ou fazer qualquer coisa nesse serviço. Tudo fora da sua equipa 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 na configuração. Sem implantações, sem operações de avião de controle, nada.
Você acha que seu serviço ainda estaria funcionando como esperado depois de um dia? Depois de uma semana? Depois de um mês? Depois de um ano? Por quanto tempo você poderia realisticamente esperar que seu serviço continuasse funcionando sem intervenção humana? Na grande maioria dos casos, não.
Este exercício de reflexão leva-nos a uma importante conclusão:
A capacidade de adaptação humana é necessária para manter os nossos sistemas a funcionar.
A única razão pela qual seus sistemas permanecem ativos e funcionando em primeiro lugar é por causa das ações dos seres humanos no loop de controle. Só através da ação humana e da capacidade de adaptação às circunstâncias em mudança é que o sistema continua a funcionar.
Portanto, é errôneo concluir que o sistema estava "basicamente funcionando... se não fossem aquelas crianças intrometidas." 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 humanos fazem nele todos os dias.
O problema com o raciocínio mecanicista é que ele leva você por 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 esse papel 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 exploramos algumas das práticas úteis para essas avaliações.