Trampas comunes para evitar

La hoja de ruta que hemos analizado para ayudarle a empezar a trabajar con el proceso de revisión posterior al incidente es útil, pero también puede ser útil conocer algunos de los obstáculos que podría encontrar en este recorrido.

En esta unidad, obtendrá información sobre algunas trampas comunes en las que otros han caído durante el proceso de revisión posterior al incidente y cómo evitarlas.

Trampa 1: Atribución a "error humano"

Es posible que recuerde que "error del piloto", una forma específica de la etiqueta "error humano" más general, fue la conclusión a la que llegaron los investigadores iniciales en la historia del B-17 que empezamos en la introducción del módulo. Volvamos a esa historia.

En esa introducción, se sugirió que las conclusiones alcanzadas pudieran resultarle insatisfactorias. Definitivamente no estaban satisfechos con Alphonse Chapanis, un psicólogo militar que fue solicitado por las Fuerzas Aéreas del Ejército de LOS EE.UU. (USAAF) para investigar estos incidentes. Él notó, entre otras cosas, que estos accidentes eran únicos para el B-17 y un pequeño número de otros aviones. Había miles de aviones de transporte C-47 en uso en Europa Occidental al mismo tiempo, pero no había experimentado nunca un incidente similar.

Así que entrevistó pilotos, y basado en lo que oyó de ellos, fue y miró a las cabinas B-17. Lo que vio allí eran dos interruptores: el de engranajes y el de aletas. Los interruptores estaban a unos 3 pulgadas separados entre sí en la cabina. Su modo de funcionamiento era idéntico. Eran demasiado fáciles de confundir entre sí, y eso es lo que había ocurrido en estos incidentes. Cuando un avión acaba de aterrizar, los alerones van a estar desplegados y, antes de aparcar, se repliegan. Y así, Chapanis intentó algo diferente.

Pegó una pequeña rueda de goma en el interruptor del tren de aterrizaje y un "alerón" de pico pronunciado en el interruptor de los alerones, bastante convencido de que los accidentes dejarían de suceder.

Ahora se conoce como uno de los fundadores del campo de la ergonómica (el estudio de factores de diseño en el rendimiento humano) y tuvo una observación sencilla: el diseño de la cabina podría afectar a la probabilidad de error humano. Este enfoque pasó a influir en el diseño de aviones modernos. Por ejemplo, en los Estados Unidos, las normativas para aviones de categoría de transporte requieren que el control del tren de aterrizaje tenga forma de rueda y sea distinto del control de aleta.

¿Por qué te dijimos esta historia?

Los humanos cometen errores. Sin embargo, el error humano no es una causa; es un síntoma. Cuando se considera que el error humano es el motivo de un error, las personas se detienen allí en lugar de analizar aún más el incidente.

El diseño del sistema, el contexto organizativo y el contexto personal influyen en cuándo, cómo y con qué impacto las personas cometen errores. "Error humano" es una etiqueta que hace que dejes de investigar en el momento en que estás a punto de descubrir algo interesante sobre tu sistema.

El problema con la conclusión del "error humano" en las investigaciones es que hace que pierdas de vista el hecho de que lo que los humanos hicieron tuviera sentido para ellos en ese momento. Los errores, por definición, no son deliberados, por lo que no tenían intención de cometer un error.

Cuando vemos o escuchamos "error humano", es una señal que necesitamos examinar más profundamente. Si queremos aprender, no debemos dejar de investigar cuando encontramos un error humano, como lo hacemos con tanta frecuencia. Como la historia de los B-17 muestra, justo más allá del error humano es donde aprendemos cosas interesantes sobre nuestro sistema.

Trampa 2: razonamiento contrafactual

Contrafactual significa "contrario a los hechos" y el razonamiento contrafactual hace referencia a contar una historia sobre eventos que no se produjeron para explicar los eventos que hicieron. Esto no tiene mucho sentido, aunque la gente tiene una tendencia a hacerlo todo el tiempo.

Puede identificar enunciados contrafácticos mediante frases clave.

• ... podría haberse...
• ... debería haberse...
• ... se hubiera...
• ... no pudo...
• No lo hizo
• ... si se hubiese...

Algunos ejemplos de declaraciones contrafactuales relacionadas con las revisiones posteriores al incidente:

"El sistema de supervisión no pudo detectar el problema".

"El ingeniero no ha comprobado la validez de la configuración antes de aplicarla".

"Esto podría haberse detectado en el entorno de valores controlados".

El problema con este tipo de razonamiento en una revisión posterior al incidente es que se habla de cosas que no sucedieron en lugar de tomarse el tiempo para comprender cómo ocurrieron los hechos. No aprendes nada de esta especulación.

Trampa 3: Lenguaje normativo

El lenguaje normativo a menudo implica que había un curso de acción "obviamente correcto" que los operadores deberían haber tomado, y juzga las acciones de esos operadores con el beneficio de la retrospectiva.

Normalmente, el lenguaje normativo se puede identificar mediante adverbios como "incorrectamente", "descuidadamente", "apresuradamente" y así sucesivamente.

El pensamiento normativo le lleva a juzgar las decisiones en función de sus resultados. Esta forma de hablar no es lógica, porque el resultado es el único fragmento de información que no estaba disponible para aquellos que tomaron las decisiones y los juicios.

El lenguaje normativo también se puede usar en el sentido opuesto. Las personas pueden elogiar a los operadores por haber actuado "adecuadamente", por ejemplo. Pero de nuevo, a menudo esta sentencia se hace con el beneficio de la información que las personas en cuestión no tenían.

El problema con el lenguaje normativo es similar al problema con el razonamiento contrafactual: si hacemos juicios después del hecho de usar información que no estaba disponible para los seres humanos implicados durante el incidente, nos olvidamos de comprender cómo las acciones de los operadores tenían sentido para ellos en el momento.

Trampa 4: razonamiento mecanístico

El razonamiento mecanístico hace referencia al concepto de que un resultado determinado se puede deducir de la intervención. A veces se denomina síndrome de los niños entrometidos (acudida por Jessica DeVita) en función de la premisa de que "Nuestro sistema habría funcionado bien... si no hubiera sido por esos chicos entrometidos".

Cuando usas el razonamiento mecanístico en tu revisión posterior al incidente, basas tus conclusiones en la falacia de que los sistemas con los que trabajas están funcionando correctamente, y si solo esos "chicos entrometidos" no hubieran hecho lo que hicieron, la falla no habría ocurrido.

Sin embargo, eso no es cómo funcionan los sistemas.

Para ilustrar este punto, imagine el siguiente escenario: Trabaja en un servicio de producción. Se nos indica en un momento dado que no podemos tocar ni hacer nada en ese servicio. Todo lo que está fuera de su equipo continúa como antes: los clientes siguen usando el servicio, las dependencias externas siguen cambiando, y el Internet funciona normalmente.

Pero no puede realizar ningún cambio en el código o la configuración. Sin implementaciones, sin operaciones de plano de control, nada.

¿Cree que el servicio seguirá ejecutándose como se esperaba después de un día? ¿Después de una semana? ¿Después de un mes? ¿Después de un año? ¿Cuánto tiempo podría esperar realista que su servicio siga funcionando sin intervención humana? En la mayoría de los casos, no lo haría.

Este ejercicio de pensamiento nos lleva a una conclusión importante:

La capacidad adaptable humana es necesaria para mantener nuestros sistemas en funcionamiento.

La única razón por la que sus sistemas permanecen en funcionamiento en primer lugar es debido a las acciones de los seres humanos en el bucle de control. Solo es a través de la acción humana y la capacidad de adaptarse a las circunstancias cambiantes que el sistema sigue funcionando.

Por lo tanto, es erróneo concluir que el sistema estaba "básicamente funcionando... de no haber sido por esos niños entrometidos". De hecho, la confiabilidad del servicio no es independiente de los usuarios que trabajan en él. En su lugar, es un resultado directo del trabajo que hacen los humanos todos los días.

El problema con el razonamiento mecanístico es que te lleva por un camino donde uno cree que encontrar a la persona defectuosa es equivalente a encontrar el problema. Sin embargo, ese mismo humano defectuoso ha estado improvisando y adaptando para mantener el sistema funcionando durante semanas y meses. Quizás este rol sea lo suficientemente importante como para reflexionar en la revisión posterior al incidente.

Ahora que sabe algunas cosas que evitar durante una revisión posterior al incidente, podemos pasar a la siguiente unidad donde exploramos algunas de las prácticas útiles para esas revisiones.