Cómo y quién recuperó uno de los mayores desastres del desarrollo software: la web healthcare.gov. Lecciones de cómo trabaja un comité de crisis software

Quizá recordarás como hace poco más de un año comentábamos por aquí, por el blog, uno de los proyectos que ha tenido el privilegio de convertirse en uno de los mayores fracasos de la historia del desarrollo software, siendo, además, desarrollado en épocas recientes, hablamos de… la web healthcare.gov, aquella que implementa la reforma sanitaria de Obama, la “ObamaCare”.
En aquel post de 2013, Mala calidad software y la mala gestión de proyectos… tumban la “ObamaCare”, hablamos de cómo el desarrollo de la web healthcare.gov había entrado en el exclusivo club de los proyectos con problemas informáticos más costosos de la historia, una aplicación cuyo desarrollo inicial costó… 400 millones de dólares y que al poco tiempo se cayó.
En aquel post hablamos de diferentes errores de la aplicación y en la gestión del proyecto, también volvimos a sacar el tema tiempo después, contando algunas de las consecuencias (En EEUU los políticos responsables de aplicaciones informáticas que fallan dimiten).
Pero como suele suceder en estos casos, pasada la novedad del escandalo… poco más, las cosas se olvidan. Y casi nunca volvemos a tener noticias de “qué paso”, de si se arregló aquello, cómo, etc.
Pero en este caso la cosa ha sido diferente. Al parecer, después del batacazo de septiembre – octubre del 2013, se reunió a un grupo de expertos, a lo comando, que consiguieron recuperar la web healthcare.gov en diciembre 2013 – enero 2014.
Y no sólo sabemos que se recuperó, sino que además tenemos artículos que cuentan (tampoco con exceso de detalles, pero algo es algo) quién y cómo lo hizo. Concretamente, quien mejor lo cuenta es un muy interesante y extenso artículo en TIME, que cuenta, muy a lo película Americana (vamos, que parece pensado para el guión de una peli), ciertos detalles del “equipo de rescate”. Lo cual enriquece mucho la historia del desastre del la web healthcare.gov y nos aporta enseñanzas que generalmente no se suelen compartir.
Curiosamente, el artículo de TIME que cuenta la historia, que además se puede descargar gratuitamente, ha pasado bastante desapercibido por el sector, a pesar de que aporta datos muy interesantes.
No voy a sermonear nada más sobre lo poco que parece haberse leído el artículo, ya que yo lo he tenido casi sin leer, en el escritorio del portátil, desde antes de verano. Pero resulta que volviendo el viernes de semana pasada de Canarias, de estar en unos temas relativos a mejora de proyectos software (que no vacaciones, cosa que no me hubiera disgustado), aproveché el avión par terminar de leerlo y sacar algunas notas interesantes, que quiero compartir contigo en este post, por si tu también andas justo de tiempo para leerlo.

Los paracaidistas

Como te comentaba antes, se formó un grupo de expertos, mayormente traídos de Silicon Valley (lo que faltaba para aumentar la leyenda aún más) para que vieran si aquello tenía solución.
El artículo comenta todos los principales nombres en el equipo de rescate, por si lo quieres leer, pero entre ellos destaca un tal Mike Abbott, que fue quien arregló Twitter cuando salía día sí y día no la ballena (quizá sólo los viejos Tuiteros recordamos como cada x tiempo Twitter se quedaba colgado y mientras se recuperaba mostraba la imagen de una ballena). También había trabajado en Microsoft y Palm.

Primer objetivo: ¿Reparar o rehacer?

El primer paso fue decidir si arreglar el HealthCare.gov o tirarlo y empezar de nuevo.
Según comenta el artículo, decía Mike Abbott que «La primera bandera roja que buscas», para decidir si tirarlo o rehacerlo, «es si existe la voluntad por parte de la gente que lo hizo en colaborar con los externos que llegan para intentar arreglarlo. Sino, entonces yo diría que es más fácil de escribirlo de nuevo que entender el código. Pero en este caso los desarrolladores estaban deseosos de cooperar». Aún así, había que ver si tecnológicamente merecía la pena…

Los problemas de desarrollar (y poner en producción) en cascada

Según comentaban los miembros del equipo de rescate, muchos de los problemas del HealthCare.gov vinieron un error básico que no se puede hacer nunca: Nunca abrir un sistema de este tamaño a todos los usuarios al mismo tiempo.
“Lo abres en pequeños grupos y vas ampliando poco a poco, para un Estado primero, luego otro, etc., así si hay algún problema se arregla a pequeña escala».

La falta de Liderazgo

Típico. Según comentan, lo que el equipo nunca encontró fue quién realmente lideró el proyecto. Comentaban que nunca pudieron averiguar quién se suponía que había estado a cargo de la puesta en marcha HealthCare.gov.
En su lugar, lo que sí había era varios muchos proveedores (no todos públicos, pero muchos de ellos puedes verlos aquí) que se dedicaban a discutir entre sí y nadie tomaba decisiones.

Primeras soluciones

Lo primero que vio el equipo, agárrate, era un error evidente que podría mejorar mucho las cosas inmediatamente: no había cache de BBDD. HealthCare.gov había sido construido de manera que cada vez que un usuario tenía que obtener información de la gran base de datos… el software hacía una consulta directamente a la base de datos.
El equipo de emergencia comenzó a almacenar en caché los datos. El resultado fue que las páginas pasaron de tardar ocho segundos en cargar a dos. Malo, pero una mejora tal que los animó a tirar para adelante en vez de rehacer el sistema.
E incluso después de esto se comprometieron a poder solucionarlo en seis semanas, y, dejando una frase de esas para el recuerdo, dijeron… «Es sólo una web. No ir a la luna».

Los Stand-ups

Las Stand-ups, esas reuniones de pie, cosa que ayuda a hacer que las reuniones sean breves, concepto bastante típico en el mundo ágil, fueron bastante típicas durante la resolución de la crisis.
La primera Stand-ups fue el 24 de octubre. Se convocarían todos los días, incluyendo los fines de semana, de octubre y noviembre, a las 10:00 de la mañana y las 6:30 de la noche. Cada una de ellas fue de unos 45 minutos («lo que causó que algunos acabaron sentándose»).
Una línea telefónica abierta conectaba a las personas en otros lugares. De hecho, la línea permanecería las 24 horas del día para que todos pudieran hablar inmediatamente a los demás si había algún problema.

Las reglas a seguir

El equipo estableció las reglas, que quedaron colgadas en una pared:
Regla 1: «La sala y las reuniones son para la solución de problemas. Hay un otros lugares donde las personas dedican sus energías creativas a culpar a otros».
Regla 2: «Los que deberían estar hablando son las personas que más saben sobre un tema, no los que tienen el cargo más alto”.
Regla 3: «Tenemos que mantener la concentración en los problemas más urgentes, en las cosas que nos harán daño en las próximas 24 – 48 horas.»

Equipo de Errores a largo pazo

Había un grupo en separado, en una oficina cerca del Aeropuerto, dedicado a tratar las cuestiones a largo plazo, aquello que sería un problema en el futuro.

Y finalmente, después de unos meses duros…

El tráfico subió a 65.000 usuarios simultáneos y luego a 83.000. 129.000 altas el 23 de diciembre.

Moraleja…

Una de las lecciones de la caída y recuperación del HealthCare.gov es cómo se adjudican los contratos para el desarrollo de alta tecnología, como finalmente recaen en empresas cuya principal habilidad parece ser conseguir esos contratos en vez de saber desarrollar software.
¿Te suena?

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Cómo y quién recuperó uno de los mayores desastres del desarrollo software: la web healthcare.gov. Lecciones de cómo trabaja un comité de crisis software”

  1. Me suena y demasiado cerca ( tanto que hasta percibo claramente el efecto doppler ). Algunos que ya llevamos unos cuantos años en la industria, hemos tenido que sufrir ante la perpeljidad de la concesión de proyectos a empresas que básicamente venden humo ( y a muy altos precios ). Para los que hemos tenido la oportunidad de profundizar y desarrollar sistemas informáticos para la salud hace ya más de 12 años, sorprende aún el estado de precariedad de muchos hospitales públicos en los que uno sabe se han hecho grandes inversiones en el pasado. La diferencia es quen este país la palabra dimitir no forma parte del léxico de los responsables y esa es una de las razones por las que las operaciones ‘Lázaro’ como la que describes, no han tenido su oportunidad y dudo que la lleguen a tener.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *