El 31 de mayo de 2014, en Hanscom Field, Bedford, Massachusetts, un Gulfstream G-IV inició el despegue con el seguro de controles puesto. En la cabina se advirtió el problema a 129 nudos. La presión de frenos subió diez segundos después, a 162. El avión salió de pista a 151 nudos y murieron las siete personas a bordo: los dos pilotos, la sobrecargo y cuatro pasajeros.
La NTSB publicó el informe AAR-15/03.
La cadena
La causa probable, en los términos del informe: la falla de la tripulación en realizar la verificación de controles de vuelo antes del despegue, el intento de despegar con el sistema de seguro activado, y la ejecución tardía del despegue rechazado una vez que advirtieron que los controles estaban trabados.
Tres eslabones. Ninguno de los tres es exótico, y ahí está el asunto.
El primero
No se hizo la verificación de controles.
El segundo
El avión no lo dijo con suficiente claridad. El interlock mecánico del gust lock debía limitar el movimiento de las palancas de potencia a 6 grados. Permitía entre 18 y 24 — tres a cuatro veces más. La NTSB concluyó que esa restricción no entregaba la advertencia inequívoca que exige el estándar de certificación. El sistema diseñado para hacer imposible este accidente lo hizo apenas incómodo.
El tercero
Entre la advertencia en cabina y el aumento de presión de frenos pasaron diez segundos. Sobre este punto el informe es preciso: si el despegue se hubiera rechazado dentro de los once segundos posteriores a descubrir el problema, el avión se habría detenido sobre pavimento.
Había margen. Se consumió decidiendo.
Dónde se normalizó
El dato que convierte este accidente en otra cosa no está en la cabina. Está en el registrador de acceso rápido.
Despegues registrados en los que esa tripulación realizó la verificación completa de controles.
Eso no es un olvido. Es un procedimiento que dejó de existir en algún momento y siguió existiendo únicamente en el manual. La NTSB lo llama deriva procedimental: cuando ejecutas una verificación muchas veces y nunca encuentras nada, la evidencia acumulada empieza a decirte que la verificación no sirve.
Y esa conclusión es, en sentido estricto, razonable. Funciona perfecto hasta el día que no.
Hay un hallazgo más, y es el que más pesa. Volaban casi siempre juntos y no habían volado recientemente con otros pilotos. Nadie ajeno entró a esa cabina a ver cómo trabajaban. No hubo quién se sorprendiera.
El espejo
La pregunta no es si haces el check de controles. Seguramente lo haces.
La pregunta es cuál es tu equivalente. Qué punto de tu flujo dejaste de verificar y empezaste a recitar. Qué ítem cantas mientras tu mano hace otra cosa. Qué verificación resolviste hace años que se podía hacer con el avión ya rodando, porque nunca ha pasado nada.
Y la segunda, que incomoda más: cuándo fue la última vez que volaste con alguien que no fuera tu compañero de siempre. Un procedimiento privado entre dos personas no tiene quién lo corrija. Los dos están de acuerdo, y ese acuerdo se siente exactamente igual que tener la razón.
El criterio
Una verificación que no puede fallar no es una verificación.
Si ejecutas un ítem, el resultado siempre es el mismo, y nunca te detienes a observar ese resultado, ya no estás verificando. Estás cantando. El ítem sigue en la lista, sigue en tu voz, y no está haciendo nada.
Para llevártelo a tu operación
Un texto del que no sales pudiendo hacer algo está mal escrito.
- Objetivo
- Identificar, en tu propio flujo previo al despegue, los ítems que ya solo recitas — y enunciar, para cada uno, qué verías si estuviera mal.
- La aplicación, esta semana
- En el primer flujo del día, en cada ítem, hazte una sola pregunta antes de cantarlo: ¿qué vería si estuviera mal? No cambies nada más. Los ítems que no tengan respuesta inmediata, anótalos al bajar. No es un ejercicio aparte: es el mismo flujo, con una pregunta encima.
- Cómo sabes que ya lo tienes
- Puedes recorrer tu flujo completo nombrando, para cada ítem, la falla observable que ese ítem detecta. Y cuando encuentras uno que no detecta nada, lo corriges o lo sacas — no lo dejas «por si acaso», porque un ítem hueco le quita atención a los que sí protegen.
- Errores comunes
-
- Contestar con la acción en vez de con la falla. «Muevo los controles» no es la respuesta. «Vería que el volante topa antes del recorrido completo» sí lo es.
- Hacerlo una vez y darlo por resuelto. La deriva no es un evento, es una pendiente. El que hizo este ejercicio hace un año probablemente ya está otra vez donde empezó.
- Aplicarlo solo a la lista de control. La mayor parte de lo que se recita no vive en la lista: vive en el flujo, que nadie lee y todos ejecutan de memoria.
- Dar por bueno que tu compañero de siempre lo canta igual. Dos personas de acuerdo no son una verificación. Son el mismo punto de vista, dos veces.
- Y una más, para el mes
- Busca volar con alguien distinto, o pídele a otro piloto que te observe un flujo completo sin intervenir. El hallazgo más incómodo del informe no fue lo que la tripulación hacía mal: fue que nadie de fuera había entrado a esa cabina en mucho tiempo.
Fuente: NTSB/AAR-15/03, Gulfstream Aerospace G-IV, N121JM, Bedford, Massachusetts, 31 de mayo de 2014. Todo lo afirmado aquí proviene del informe publicado.
Nada de lo aquí escrito sustituye la reglamentación vigente ni los manuales de su operación. Si algo contradice su SOP, gana su SOP.