¿Por qué no se detectó el error fatal del Mars Climate Orbiter antes del lanzamiento?

La NASA formó una junta para investigar la pérdida de la nave espacial y llegó a algunas conclusiones de alto nivel . La junta citó una serie de factores contribuyentes, que he filtrado para incluir los más relevantes para la pregunta:

• Los errores no se detectaron en los modelos informáticos terrestres de cómo se predijeron los pequeños disparos de los propulsores en la nave espacial y luego se llevaron a cabo en la nave espacial durante su viaje interplanetario a Marte.
• la función de ingeniería de sistemas dentro del proyecto que se supone debe rastrear y verificar dos veces todos los aspectos interconectados de la misión no fue lo suficientemente sólida, exacerbada por la entrega por primera vez de una nave espacial con destino a Marte de un grupo que la construyó y la lanzó a un nuevo equipo de operaciones multimisión
• algunos canales de comunicación entre los grupos de ingeniería del proyecto eran demasiado informales
• el pequeño equipo de navegación de la misión tenía un exceso de solicitudes y su trabajo no recibió la revisión de expertos independientes
• el personal no estaba lo suficientemente capacitado en áreas como la relación entre el funcionamiento de la misión y sus características detalladas de navegación, o el proceso de presentación de informes formales de anomalías
• el proceso para verificar y validar ciertos requisitos de ingeniería e interfaces técnicas entre algunos grupos de proyectos, y entre el proyecto y su contratista principal de la misión, fue inadecuado

También en el informe de alto nivel se encuentra esta cita:

Estas causas contribuyentes incluyen una consideración inadecuada de toda la misión y su operación posterior al lanzamiento como un sistema total, comunicaciones y capacitación inconsistentes dentro del proyecto, y la falta de una verificación completa de extremo a extremo del software de navegación y los modelos informáticos relacionados.

Parece que fue una falla de gestión y control de calidad en múltiples niveles. El informe completo también está disponible si desea una lectura ligera antes de acostarse.

El Mars Climate Orbiter fue una de las sondas en la iniciativa Faster Better Cheaper (FBC) del administrador Goldin, que obligó a presupuestos ajustados y plazos muy cortos en los proyectos, lo que ha sido controvertido desde entonces, ya que hubo varias fallas de naves espaciales atribuidas a fallas de gestión e ingeniería. debido a la iniciativa. Harvard Business Review tiene un gran artículo que resume lo que salió mal :

Al cambiar a FBC desde un enfoque de desarrollo lento, confiable pero costoso, la NASA obligó a sus gerentes de proyecto a inventar procesos y procedimientos radicalmente nuevos. FBC les impuso restricciones de presupuesto, cronograma y peso que no se podían cumplir con los enfoques tradicionales de la NASA para el desarrollo de naves espaciales. “La actitud era 'El libro no funciona. Así que tira el libro, prueba algo diferente y luego escribe un nuevo libro”, explicó un gerente de la NASA. Implícita en este enfoque estaba la necesidad de que los gerentes de proyecto aprendieran de las experiencias colectivas de la organización, adoptaran lo que funcionó y desecharan lo que no funcionó. Desafortunadamente, la NASA socavó este proceso de aprendizaje de varias maneras.

Primero, con el lanzamiento de cada misión FBC, la NASA exigió tiempos de desarrollo cada vez más rápidos y costos aún más bajos. Pero debido a que una nave espacial pequeña suele tardar más de cuatro años en pasar del tablero de dibujo a la misión completa, los gerentes se vieron obligados a cumplir con las demandas más estrictas de los nuevos proyectos mientras los proyectos anteriores aún estaban en progreso. Por lo tanto, no pudieron capturar todas las lecciones potenciales de una misión antes de pasar a la siguiente. En resumen, la NASA estaba subiendo el listón antes de ver si los gerentes de proyecto podían despejarlo donde estaba. Cuando la organización se dio cuenta de que había puesto el listón demasiado alto (alrededor de la época en que las primeras misiones de FBC comenzaron a fallar), la cartera de proyectos estaba llena de misiones que estaban potencialmente comprometidas. No sorprende que las misiones FBC posteriores fallaran con más frecuencia que las anteriores.

En segundo lugar, la NASA no se dio cuenta de que debido a que la iniciativa FBC dependía tanto del aprendizaje compartido, requeriría un enfoque más agresivo y sistemático para la gestión del conocimiento. Aunque la NASA había implementado una base de datos de "lecciones aprendidas" en 1995, una encuesta de 2001 encontró que solo una cuarta parte de sus gerentes contribuyeron a ella. Un número similar de gerentes ni siquiera sabían que el sistema existía. Además, mientras que las "revisiones del equipo rojo" (revisiones de progreso periódicas realizadas por los gerentes más experimentados de la NASA) resultaron invaluables en los primeros proyectos de FBC, la NASA realizó menos de estas evaluaciones en misiones posteriores. Como consecuencia, la transferencia de aprendizaje a través de la organización sufrió.

Finalmente, la NASA cayó presa del "aprendizaje supersticioso", la suposición de que hay más que aprender de las misiones fallidas que de las exitosas. Sin embargo, en el clima desafiante de la exploración espacial, la diferencia entre lo que hace que una misión tenga éxito y otra fracase puede ser sutil. No hay razón para creer que el éxito indica un proceso impecable, mientras que el fracaso es el resultado de una mala práctica atroz. Por ejemplo, se podrían haber cometido tantos errores en la célebre misión Pathfinder de 1997 como se cometieron en la fallida misión Polar Lander de 1999. Pero la NASA nunca lo sabrá. Al no realizar autopsias detalladas sobre sus misiones exitosas, la agencia espacial perdió la oportunidad de identificar problemas (y soluciones) que podrían haber ayudado a evitar fallas posteriores.

Un resumen de esto sería que, si bien no había nada malo en tratar de acelerar el ritmo de las misiones y reducir los costos, la forma en que se implementó obligó a las personas a tomar atajos. La estrategia dependía del aprendizaje compartido, con proyectos más nuevos que reutilizaban el código, el equipo, el conocimiento y las lecciones aprendidas de proyectos más antiguos, pero la agencia no implementó las herramientas adecuadas para hacer esto ni fomentó una cultura de intercambio. Las lecciones de proyectos anteriores no se aprendieron porque los proyectos anteriores no se completaron antes de que se iniciaran los proyectos posteriores. No revisaron los éxitos ya que la alta dirección no creía que hubiera nada que aprender. Hubo varias fallas de naves espaciales que se atribuyen a que esta estrategia resultó contraproducente, lo que llevó a la frase "Más rápido, mejor, más barato: puede tener los 2 que desee".

Hubo un buen número de posibilidades de detectar el error después del lanzamiento, que es en lo que se centran la mayoría de los informes sobre la misión. Para ver específicamente qué pruebas se realizaron antes del lanzamiento, este documento de la Sociedad Astronáutica Estadounidense tiene una descripción general decente, comenzando en la página 6: Las fallas del Mars Climate Orbiter y Mars Polar Lander: una perspectiva de las personas involucradas

1. Estaban modificando el código de una misión anterior, que tenía el factor de conversión de unidades pero lo enterró en las ecuaciones y no lo comentó para que la conversión fuera obvia.
2. Los tutoriales de código y requisitos no detectaron el factor de conversión faltante porque no era obvio en el código original y no entendieron la ecuación anterior en la medida necesaria para detectar la falta.
3. Las pruebas formales de aceptación de software utilizaron un archivo de "verdad" producido al calcular manualmente la ecuación que se codificó, no un archivo de datos de una fuente independiente (probablemente porque el equipo de navegación no se incorporó al proyecto hasta muy tarde en el desarrollo como un costo- medida de ahorro).
4. Las pruebas de integración consistieron en asegurarse de que el archivo se produjera y se pudiera mover al servidor correcto: no hicieron nada con los datos del archivo.

Gran parte de esto se redujo a que estaban reutilizando el código de una misión anterior, y había pasado por toda la validación allí, por lo que la gerencia (que estaba bajo presión para minimizar los costos) asumió que las modificaciones eran de bajo riesgo. Hicieron suficientes pruebas para sentirse cómodos, pero no tenían expertos disponibles para hacer pruebas independientes, por lo que no les ayudó mucho.

Aparte, esta falla en hacer pruebas de integración significativas significó que en el lanzamiento los archivos de datos producidos por el módulo de fuerzas pequeñas (el software con el error) estaban en el formato incorrecto y en realidad no podían usarse. Durante los primeros meses de la misión, el equipo de navegación estaba aplicando/calculando los resultados de los disparos de desaturación de momento angular manualmente en función de los correos electrónicos entre ellos y el contratista.

Las grandes organizaciones tienen grandes grietas para que las cosas se derrumben. La NASA tiene los problemas adicionales de:

• No hay mucha precedencia para la mayoría de las cosas que hacen.

• Solo tienen una oportunidad la mayor parte del tiempo.

En tal caso, los artículos caros suelen estar bien atendidos. Si está claro cuál es la pregunta y existe la posibilidad de que se equivoque, existen recursos para resolver el problema y ninguno responde hasta que pueda demostrar que funcionará.

Sin embargo, si no está claro cuál debe ser la pregunta que debe hacerse, posiblemente porque es muy obvio, si nadie lo está comprobando, todos los recursos del mundo no ayudarán.

Trabajé en los proyectos Midas y Samos en los años 50 y 60, y en el transbordador espacial hasta su desaparición en los años 80. En el primero, la garantía de calidad fue exhaustiva, se inspeccionaron todas las tuercas y juntas de soldadura. Básicamente, no había control de calidad en el transbordador, ¡me dijeron que los técnicos inspeccionarían su propio trabajo ! Lo que ahorraría mucho tiempo y dinero.

Como en la mayoría de los negocios, se trata de dinero. Siempre que las ganancias excedan las pérdidas, se considera aceptable.