El desarrollo del boom: ¿el peor día del proyecto?

Una prueba en tierra del Hoist, sistema encargado de desplegar y recoger el boom, revel un fallo que impeda garantizar su recuperacin en vuelo. A dos semanas del primer despliegue, previsto para el 31 de octubre de 2006, tres ingenieros del Equipo B comprobaron que el cable se trababa y destrua el conjunto. El hallazgo oblig a abandonar esa fecha, pero evit que el problema apareciera en el aire. Tres meses despus se realiz el primer vuelo de despliegue.

En el artculo anterior hablbamos de una idea fundamental: los ensayos en tierra no sirven nicamente para demostrar que algo funciona. Sirven, sobre todo, para descubrir cmo puede fallar antes de que el avin est en el aire. A veces esos fallos aparecen despus de miles de ciclos, en complejas campaas de ensayo o bajo condiciones cuidadosamente preparadas, y otras veces basta una pesa de cinco kilos y una maana de sbado.

Faltaban dos semanas para el 31 de octubre de 2006: la fecha prevista para el primer despliegue en vuelo del boom y de la que se cumplen ahora 20 aos. Era sbado y la factora de Airbus de Getafe estaba casi vaca. Entre semana, una factora aeronutica tiene un ruido propio: coches entrando, puertas metlicas, llamadas, carretillas, conversaciones en los pasillos, tcnicos, ingenieros, pilotos, reuniones que empiezan tarde y cafs que saben igual a cualquier hora. Un sbado es distinto. Hay menos ruido. Menos gente y, por alguna razn, los problemas parecen ms serios.

Tres ingenieros del Equipo B haban ido aquella maana para realizar una prueba especial del Hoist. No era una actividad espectacular. No haba cmaras, ni clientes, ni una tripulacin esperando junto al avin. Solo un equipo de ensayo, un cable de acero y una preocupacin que no se quitaban de la cabeza. El primer vuelo estaba previsto en dos semanas y la operacin del Hoist tal y como estaba definida les planteaba dudas muy preocupantes.

Durante meses haban trabajado para recuperar el desarrollo del boom. Las nuevas controladoras funcionaban, el software de la Boom Control Unit (BCU) avanzaba, los bancos de ensayo estaban dando resultados, el A310 empezaba a estar preparado. La Direccin apoyaba totalmente al equipo. El programa avanzaba, incluso mejor de lo previsto, pero el actuador del Hoist no se dejaba dominar.

El sistema que tena que traer el boom de vuelta

El Hoist era el sistema encargado de desplegar y recoger el boom, pero, adems, cuando el boom estaba en vuelo, el cable deba acompaar continuamente sus movimientos, soltando y recogiendo con rapidez sin interferir en el movimiento del boom. Como una correa de perro, pero con motores soltando y recogiendo un cable de acero de una pulgada de seccin.

Con el diseo de Hoist que haba en ese momento, si se ordenaba soltar cable, "alguien" tena que tirar de l porque si la bobina se quedaba sin tensin, entonces se empezaba a hinchar, el cable se trababa y terminara quedndose bloqueado entre el tambor y la camisa exterior. Si eso pasara, ya no sera posible izar el boom. Tendramos que aterrizar con el boom desplegado y, a las velocidades de aterrizaje, las aletas del boom no generaran suficiente sustentacin. La prtiga quedara 30 grados por debajo de la horizontal y sera la primera parte del avin en tocar la pista. En el mejor de los casos eso significara el final del programa.

Desde haca meses era nuestra pesadilla. Por eso se haba decidido realizar una ltima prueba en tierra. Una prueba muy artesanal. El Hoist estaba montado en altura. Un canaln guiaba el cable para que pudiera subir y bajar sin golpear elementos del edificio. En el extremo haban colocado una pesa de cinco kilos. Una controladora, como la del avin, permita automatizar ciclos de subida y bajada. Antes del primer vuelo queramos tener el sistema funcionando sin parar durante das para poder confiar en l.

Primeros ciclos

El tambor comenz a girar, la carga subi, se detuvo, baj, volvi a subir. Un ciclo, despus otro y otro. Todo sonaba normal. El sonido era regular, casi tranquilizador.

Los tres ingenieros se separaron para continuar con otros trabajos. Eso tambin era normal en aquella poca, siempre haba varias cosas sucediendo simultneamente y demasiado poco tiempo. El ensayo qued funcionando. Pas un rato y entonces uno de ellos en un despacho oy pasos rpidos. No eran pasos de alguien que viene a comentar una duda, eran pasos de problema.

"Tenemos un problema". No dijeron nada ms.

Subieron inmediatamente y al llegar junto al Hoist, bast una mirada para entender que el ensayo haba terminado. No porque el sistema estuviera parado, que lo estaba, sino por la postura de la mquina. S. Las mquinas tambin tienen postura y esta deca que ya no perteneca al mundo de los ensayos normales.

La bobina se haba hinchado, el cable se haba trabado y se haba encajado entre el tambor y la carcasa. Las controladoras, obedientes y perfectamente capaces de hacer lo que se les haba ordenado, haban seguido aplicando fuerza hasta destruir el conjunto. La camisa exterior del Hoist estaba reventada. Durante unos segundos nadie dijo nada.

El mecanismo de suelta y recogida del cable no era fiable y haba necesitado muy pocos ciclos para demostrarlo. Nuestros temores tenan sentido, aunque eso no era ningn consuelo. Uno de los ingenieros rompi finalmente el silencio:

"No podemos volar as. Si esto pasa en el aire no recogemos el boom".

Cuatro palabras: "no recogemos el boom". Todo el programa pareca caber dentro de ellas.

La fecha del primer vuelo desaparece

Durante meses el equipo haba ido resolviendo problemas: controladoras, software, instalaciones de ensayo, pruebas, organizacin Muchos problemas haban podido atacarse con nuevas ideas, ms anlisis o formas distintas de trabajar, pero aquello era diferente. Era el sistema fsico diciendo que no. Y cuando la fsica dice que no, la situacin es grave.

Los tres ingenieros saban lo que significaba aquello. Era aceptar que la solucin an no exista y que la fecha del primer vuelo haba desaparecido. Era volver a mirar al precipicio cuando ya empezaban a creer que se alejaban de l. Bajaron despacio. El silencio dentro del edificio pareca ahora distinto.

Una cerveza en el polgono

No haba nada ms que hacer all y decidieron tomar una cerveza en uno de los pocos bares abiertos del polgono. Sencillamente haba que salir de all. El local tena luz fra y una televisin encendida sin volumen. Pidieron cerveza. Durante un rato casi no hablaron.

La situacin era muy incmoda. No por el lugar, sino por la sensacin de derrota provisional. Esa clase de derrota que todava no puedes ensear al equipo entero porque ni siquiera sabes cmo vas a salir de aquello. En un proyecto complejo, un fallo grave no es solo un problema tcnico. Es tambin un golpe emocional. Se puede provocar la percepcin de que el proyecto no tiene futuro y no hay que olvidar que el desnimo tiene propagacin en cadena.

Ese tipo de momentos rara vez aparecen en las historias de innovacin. Despus, cuando todo sale bien, se recuerdan las soluciones brillantes, los vuelos, los hitos alcanzados y las celebraciones, pero en los proyectos reales tambin existen sbados como aquel. Momentos en los que nadie sabe todava qu hacer.

Uno de ellos dijo finalmente: "Lo vamos a resolver". Otro mir el vaso. "Seguro".

No son demasiado convencido y estuvo bien que fuera as. Hay momentos en los que la pica sobra.

El desastre que no ocurri

Aos despus, la interpretacin de aquel da es muy diferente. Lo que aquel sbado pareci un desastre haba sido, en realidad, un golpe de suerte provocado. El verdadero desastre habra sido no hacer la prueba. En tierra habamos roto un equipo, pero en el aire habra sido algo mucho peor.

En el artculo anterior defenda que las pruebas en tierra sirven para aprender antes de que el vuelo cobre el precio completo. Aquella maana lo aprendim