Aprendizajes de un desastre aéreo aplicados al desarrollo de software

En el evento Lead Developer UK de 2016, Nickolas Means presentó una charla inolvidable titulada “How to crash an airplane”, en la que relató la historia del vuelo United Airlines 232 y extrajo valiosas lecciones aplicables al desarrollo de software.

Esta historia no es solo una narración impactante sobre un accidente aéreo, sino también un profundo análisis sobre liderazgo, comunicación y trabajo en equipo.

Veamos cómo esta tragedia aérea puede enseñarnos a ser mejores desarrolladores y a construir equipos de software más sólidos.

La división del vídeo por capítulos la tienes más abajo.

Puedes ver la historia completa del accidente en español en este vídeo.

La historia del vuelo United 232 ¶

El 19 de julio de 1989, el vuelo United 232, un DC-10, despegó de Denver con destino a Chicago. Todo parecía transcurrir con normalidad hasta que, en pleno vuelo, una explosión en el motor trasero causó la pérdida total del control hidráulico del avión. Esto significaba que los pilotos no podían controlar los sistemas principales de vuelo como el timón, los alerones o el estabilizador vertical.

A pesar de lo que parecía ser una situación imposible de resolver, el equipo de vuelo logró mantener el avión en el aire, realizando una maniobra de aterrizaje de emergencia en Sioux City, Iowa. El accidente resultó en la pérdida de 111 vidas, pero, sorprendentemente, 185 pasajeros sobrevivieron gracias a la extraordinaria actuación del equipo de vuelo.

La importancia del manejo de recursos en la cabina ¶

El punto central de esta historia es el uso del Crew Resource Management (CRM), o manejo de recursos en la cabina, implementado por United Airlines en la década de los 80. Hasta ese momento, la norma en la aviación era que el capitán tenía autoridad absoluta y sus decisiones no se cuestionaban. El CRM cambió este enfoque, fomentando una comunicación abierta y un trabajo colaborativo entre todos los miembros de la tripulación.

¿Qué es el Crew Resource Management (CRM)? ¶

El CRM se centra en la dinámica humana dentro de la cabina, promoviendo la colaboración, la comunicación y la toma de decisiones en equipo. En lugar de depender de un único “héroe” para salvar el día, el CRM enseña que la fortaleza del equipo reside en aprovechar la experiencia y las habilidades de todos sus miembros.

En el caso del vuelo United 232, el CRM fue crucial. El capitán Al Haynes, lejos de imponer su autoridad, escuchó a los otros pilotos y al ingeniero de vuelo, permitiendo que cada uno aportara sus ideas y conocimientos para manejar la situación.

Lecciones para el desarrollo de software ¶

1. Colaboración sobre heroísmo ¶

En el desarrollo de software, a menudo vemos cómo se destacan a ciertos “héroes” que aparentemente solucionan todos los problemas. Sin embargo, como mostró el CRM en el vuelo United 232, la colaboración y el trabajo en equipo son mucho más efectivos que depender de una sola persona.

En lugar de buscar héroes individuales, fomenta un entorno donde todos los miembros del equipo puedan contribuir y compartir sus ideas. Al igual que el capitán Haynes permitió que Denny Fitch, un piloto que estaba de pasajero, tomara el control de los aceleradores, los líderes de equipos de software deben saber cuándo dejar que otros miembros del equipo lideren ciertas tareas.

2. Escuchar todas las voces ¶

En el vuelo United 232, cada miembro de la tripulación tuvo voz, lo que permitió que se tomaran decisiones acertadas. Del mismo modo, en un equipo de software, es fundamental evitar que solo unas pocas voces dominen las discusiones.

Cuando se fomenta la participación activa de todos los miembros, se obtiene una diversidad de perspectivas que puede llevar a soluciones más efectivas y creativas.

Esto es especialmente importante con los desarrolladores junior, quienes necesitan espacio para aprender y equivocarse. Si solo se escuchan las voces más experimentadas, los miembros menos experimentados no tendrán la oportunidad de crecer ni aportar sus ideas frescas.

3. Prepararse para lo inesperado ¶

Aunque el vuelo United 232 enfrentó una falla que nunca se había considerado posible, la tripulación logró salvar vidas gracias a su capacidad de adaptación y su entrenamiento en simuladores.

En desarrollo de software, aunque la experiencia y la preparación son clave, la capacidad de adaptarse a escenarios inesperados es igualmente crucial.

Realiza ejercicios de simulación de crisis en tus proyectos de software, como responder a una caída de producción o a una vulnerabilidad de seguridad crítica. Esto ayudará a tu equipo a estar mejor preparado para manejar situaciones imprevistas y a desarrollar resiliencia.

4. Evita la mentalidad de autoridad absoluta ¶

En el pasado, los pilotos actuaban con la creencia de que el capitán siempre tenía la razón, lo que llevó a varios desastres aéreos.

Los líderes de equipo deben evitar imponer sus opiniones de forma absoluta. Aunque el líder tiene la última palabra, debe escuchar las ideas de todo el equipo antes de tomar decisiones.

Al permitir la participación activa de todos, se crean productos de software más robustos y se fortalece la cultura del equipo, similar a cómo el CRM mejoró la seguridad aérea.

Hábitos esenciales para equipos de software resilientes ¶

La charla de Nickolas Means deja claro que la clave para enfrentar una crisis está en los hábitos que el equipo cultiva día a día.

Estudiar errores pasados y extraer lecciones valiosas ¶

El hábito de analizar fallos previos, como hace Nickolas Means con los accidentes aéreos, es fundamental para el aprendizaje continuo.

Es común que se eviten las retrospectivas sinceras o los análisis post mortem debido a la incomodidad de hablar de errores. Sin embargo, estos ejercicios permiten identificar debilidades en procesos, fallos en el código y oportunidades de mejora.

Acción recomendada: Implementa sesiones de post mortem sin señalar culpables. Documenta los problemas, las soluciones y lo aprendido para evitar que se repitan en el futuro.

Fomentar la toma de decisiones compartida y la colaboración ¶

En lugar de depender de un líder o experto para todas las decisiones, fomenta una cultura donde las decisiones sean resultado de la colaboración. Tal como lo hizo el equipo del vuelo United Airlines 232, cada miembro debe tener un rol activo en la solución de problemas, compartiendo su conocimiento y perspectiva.

Acción recomendada: Utiliza metodologías ágiles como el pair programming y sesiones de planificación colaborativa donde todos los miembros del equipo pueden expresar sus ideas y preocupaciones.

Escuchar activamente y valorar aportaciones diversas ¶

En un entorno de alta presión, como el desarrollo de software, puede ser fácil ignorar o desestimar ideas de miembros menos experimentados.

Sin embargo, la diversidad de opiniones suele ser la clave para encontrar soluciones innovadoras y prevenir problemas ocultos.

Acción recomendada: Durante reuniones y stand-ups, asegúrate de que cada miembro del equipo tenga la oportunidad de compartir sus pensamientos. Usa técnicas como la “mesa redonda” para evitar que siempre hablen los mismos y fomenta un ambiente inclusivo.

Evitar la toma de decisiones jerárquica y fomentar la resolución colaborativa de problemas ¶

En muchos equipos, las decisiones suelen depender exclusivamente de los líderes o de los desarrolladores más experimentados.

Aunque esto puede parecer eficiente, también crea una cultura donde solo unas pocas voces son escuchadas. La historia del vuelo United 232 muestra que una decisión colaborativa es muchas veces más efectiva.

Acción recomendada: Implementa un proceso de revisión de código donde los pares evalúen y mejoren el trabajo de los demás, sin importar su nivel de experiencia. Promueve un entorno donde se valore la retroalimentación constructiva de cualquier miembro del equipo.

Animar a los nuevos miembros a expresar sus opiniones y aprender de sus errores ¶

Es fácil para los miembros más nuevos sentirse intimidados o temer equivocarse. Sin embargo, permitir que los desarrolladores junior cometan errores y aprendan de ellos es esencial para su crecimiento y para el fortalecimiento del equipo.

Acción recomendada: Establece un entorno seguro para cometer errores (“safe to fail”). Recompensa el aprendizaje obtenido de los fallos y celebra los esfuerzos por intentar nuevas soluciones, aunque no siempre funcionen.

Simular crisis y practicar la resolución de problemas inesperados ¶

Los pilotos de avión realizan entrenamientos constantes en simuladores para prepararse ante cualquier situación de emergencia. De la misma forma, tu equipo de software debería practicar cómo reaccionar ante problemas críticos como caídas del sistema, errores en producción o fallos de seguridad.

Acción recomendada: Realiza simulacros de incidentes, como ejercicios de “Game Day” o “Chaos Engineering”, donde el equipo debe reaccionar ante fallos simulados en el sistema. Esto fortalecerá su capacidad de respuesta y preparará al equipo para enfrentar crisis reales con mayor eficacia.

Momentos principales del vídeo ¶

1. Introducción y contexto (00:00-02:24) ¶

• Presentación de Nickolas Means, VP de ingeniería en Wellmatch Health
• Su fascinación por los accidentes aéreos, especialmente por la dinámica en cabina
• Mención del British Airways 5390 como ejemplo de su conocimiento
• Introducción al caso del United 232 como uno de los más fascinantes

2. El vuelo normal (02:24-05:39) ¶

• Descripción del día perfecto en Denver, 19 de julio 1989
• Detalles del DC-10, un avión veterano de 18 años
• 285 pasajeros y 11 tripulantes abordando
• Despegue rutinario y servicio de almuerzo a bordo

3. La crisis inicial (05:39-12:01) ¶

• Explosión del disco ventilador del motor número 2
• Primeras reacciones de la tripulación
• Intentos iniciales de seguir procedimientos estándar
• Descubrimiento de que los controles no responden normalmente

4. La situación se complica (12:01-14:26) ¶

• Pérdida total de los sistemas hidráulicos
• No existe procedimiento para esta situación
• Comunicación con control aéreo sobre la gravedad
• Preparación inicial para emergencia

5. Ayuda inesperada (14:26-22:30) ¶

• Intervención de Denny Fitch, piloto instructor que viajaba como pasajero
• Explicación técnica de los sistemas hidráulicos del DC-10
• Descripción de por qué la situación era considerada “imposible”
• Incorporación de Fitch al equipo de cockpit

6. La lucha por el control (22:30-32:37) ¶

• Control del avión usando solo los aceleradores
• Dificultades para hacer giros a la izquierda
• Comunicaciones con la torre de Sioux City
• Preparativos para un aterrizaje sin precedentes

7. El desenlace (32:37-35:25) ¶

• Descripción detallada del accidente
• Velocidad excesiva de aproximación (252 mph vs 125 normales)
• Impacto y volcamiento
• Primeros momentos del rescate

8. Análisis de resultados (35:25-36:29) ¶

• 185 sobrevivientes de 296 personas a bordo
• Contexto histórico: primer caso de supervivencia en pérdida total de controles
• Evaluación del NTSB sobre el desempeño excepcional de la tripulación
• Resultados de las simulaciones posteriores

9. Lecciones de gestión (36:29-42:30) ¶

• Explicación del Cockpit Resource Management
• Importancia del trabajo en equipo vs heroísmo individual
• Necesidad de dar voz a todos los miembros del equipo
• Rol del líder en facilitar la participación

10. Conclusiones y aplicación (42:30-43:07) ¶

• Paralelos entre la aviación y el desarrollo de software
• Importancia de la cultura de equipo
• Mensaje final sobre software como deporte de equipo
• Cierre y agradecimientos

Esquema de aprendizaje ¶

El software es un deporte de equipo ¶

La historia del vuelo United 232 nos recuerda que, al igual que en la aviación, el desarrollo de software es un deporte de equipo. No se trata solo de habilidades técnicas, sino también de la capacidad de comunicarse y colaborar efectivamente.

Como líder o miembro de un equipo de software, es tu responsabilidad fomentar un entorno donde todos tengan voz y puedan contribuir. Aprende de los errores del pasado y construye una cultura donde el equipo pueda enfrentar cualquier desafío juntos.

Si logramos aplicar estas lecciones de la aviación al desarrollo de software, podemos crear equipos más resilientes y capaces de alcanzar el éxito incluso en las situaciones más difíciles.