HealthCare.gov: lo que salvó al sitio no fue solo meter más gente

Caso real y público. Hábil no participó en HealthCare.gov. Lo analizamos a partir de los informes del gobierno de Estados Unidos y de la prensa; las fuentes están al final.

Es medianoche del 1 de octubre de 2013. El personal contratado que opera el sistema de cuentas e identidad de HealthCare.gov ve arrancar el sitio. Acaba de abrir, y por él millones de personas deben comparar y contratar un seguro médico. Uno de ellos lo recordaría así ante los auditores: «Estábamos sentados en la oficina a medianoche cuando empezó a correr, y no se veía bien. Todo se estaba poniendo rojo en nuestras pantallas» [1].

Ese día llegaron al sitio 250,000 usuarios al mismo tiempo, muchas veces más de lo planeado. Las caídas empezaron dos horas después de abrir. Al final del día, según el informe del Inspector General del Departamento de Salud de Estados Unidos, solo seis personas lograron enviar una solicitud y elegir un plan [1].

Seis. En el sitio que debía atender a millones de personas en 36 estados [1].

Esta es la historia de cómo ese sitio se recuperó en unos dos meses. No la cuento por la política ni por el seguro médico. La cuento porque cualquier director de tecnología ha estado, a menor escala, en la misma sala: un sistema que no puede fallar, una fecha que no se mueve y alguien en la mesa que dice «metamos más gente». Lo interesante del caso es que eso ya se había intentado, y por sí solo no bastó. El sitio se recuperó cuando, además de sumar gente, cambió la forma de trabajar: un núcleo chico de ingenieros con experiencia, integrado en una sola mesa con la agencia y los contratistas, métricas de todo el sistema y prioridades recortadas sin piedad. Los auditores señalan varias causas, no una sola [1].

Setenta y dos horas antes

El problema no empezó el 1 de octubre. Los auditores del gobierno lo rastrean años atrás. El Inspector General (OIG, la oficina que audita al Departamento de Salud) entrevistó a 86 funcionarios y contratistas y revisó miles de documentos. Su conclusión principal cabe en una línea: lo más grave fue la ausencia de un liderazgo claro, que retrasó decisiones, dejó tareas mal definidas e impidió ver el tamaño del problema mientras crecía [1].

Los últimos días antes del lanzamiento parecen escritos para una película.

El 24 de septiembre, la responsable de seguridad informática de la agencia que construía el sitio (CMS, los Centros de Servicios de Medicare y Medicaid) advirtió que una pieza central no cumplía razonablemente los requisitos de seguridad. El 27, en vez de un permiso normal, la Administradora de CMS firmó una autorización provisional para operar seis meses [1].

El 26 de septiembre, a menos de cinco días del arranque, técnicos de CMS hicieron pruebas de carga y descubrieron que el sitio soportaba muchos menos usuarios simultáneos de los planeados. Manejaron directo a las oficinas del proveedor de infraestructura y le pidieron duplicar toda la capacidad en 72 horas. Un gerente del proveedor lo contó así: «La petición fue duplicar todo a 72 horas del lanzamiento. […] Rentamos aviones para traer equipo que estaba destinado a otros clientes» [1].

El 29 de septiembre, el sistema de cuentas e identidad, la puerta por la que debía pasar cada usuario, sufrió caídas. Ese mismo día, la Administradora de CMS escribió al director de tecnología de Estados Unidos que el sitio estaría listo el 1 de octubre [1].

Hay un detalle que el informe subraya y que vale para cualquier empresa: varios en el equipo creían que la fecha del sitio estaba en la ley. No lo estaba. La ley pedía que la cobertura empezara a más tardar el 1 de enero de 2014 y dejaba al Departamento de Salud fijar el periodo de inscripción, que por regulación arrancó el 1 de octubre de 2013 [1]. Encima pesaba la política: la Casa Blanca se había comprometido en público con esa fecha, y en el Departamento temían que un retraso diera argumentos a quienes buscaban derogar la ley en el Congreso [1]. La fecha que nadie se atrevía a mover no venía de la ley, sino de una regulación y de la política. Y nadie en la dirección de CMS discutió formalmente moverla [1].

Y otro más: no hubo pruebas completas de punta a punta. Un contratista lo resumió para los auditores: «Las pruebas de punta a punta son críticas. No hacerlas es un suicidio» [1].

Ya se había intentado sumar gente

Aquí está el dato que casi nadie cuenta del caso.

En agosto de 2013, dos meses antes del lanzamiento, CMS vio que el proyecto iba muy atrasado y reaccionó como reaccionaría casi cualquier organización: asignó temporalmente 60 personas más de otras áreas a las 51 que ya trabajaban en el sitio. Un aumento de 117 % [1].

No alcanzó. El propio informe recoge lo que sintieron algunos de los involucrados: que ya era tarde para sumar a otros por lo empinado de la curva de aprendizaje, y que les daba pena «meter a otros en un desastre» [1].

En 1975, Frederick P. Brooks Jr., que había dirigido el desarrollo del sistema operativo OS/360 en IBM, escribió en The Mythical Man-Month una frase que hoy se conoce como la ley de Brooks: «Agregar personal a un proyecto de software atrasado lo atrasa más» [5]. Su razonamiento: el trabajo no se reparte en pedazos independientes, cada persona nueva necesita que alguien le explique, y los canales de comunicación crecen más rápido que el equipo.

Conviene ser preciso. El informe del OIG no cita a Brooks, y no se puede afirmar que esas 60 personas atrasaran el sitio. Lo que sí documenta es que sumarlas tarde, sin un liderazgo claro y sobre un proyecto desordenado, no evitó el desenlace. La relación con Brooks es mía, y la ofrezco como lectura, no como hallazgo de los auditores.

Dos semanas a ciegas

Después del 1 de octubre, la primera reacción también fue mandar más gente. A los pocos días, personal de CMS y del contratista principal se instaló en el centro de mando del contratista en Herndon, Virginia, y otros contratistas se fueron sumando [1].

Pero había un problema de fondo: nadie veía el sistema completo. Cada contratista vigilaba su propia pieza y no podía ver las demás, aunque todas trabajaban juntas. Había varios «centros de mando» en lugares distintos, uno en Herndon y otro en Columbia, Maryland, cada uno con sus herramientas, y ningún líder o equipo con visión de todo el sistema y autoridad para actuar. Nadie fungía formalmente como integrador de sistemas [1].

Uno de los ingenieros que llegaría después lo dijo en una conferencia en 2014: «No había dónde ver si el sitio estaba arriba o no, salvo CNN, que literalmente fue como nos enteramos de los problemas buena parte del tiempo al principio» [1].

Para complicarlo más, la mañana del lanzamiento el gobierno federal cerró por falta de presupuesto. El cierre duró 16 días, y el personal de las oficinas clave del proyecto se redujo a cerca de un tercio [1].

Mientras tanto, el sitio casi no inscribía. Según TIME, en todo octubre se inscribieron 26,794 personas por el mercado federal [4]. Y la capacidad real, según un miembro del equipo que después lo arregló, era de «quizá unos cuantos miles de usuarios», cuando la cifra oficial hablaba de 50,000 [4].

17 de octubre: ¿parchar o tirar?

El 17 de octubre, según la reconstrucción del periodista Steven Brill en TIME, en la Casa Blanca se discutía si valía la pena reparar el sitio o desecharlo y empezar de cero [4]. Ese día, Todd Park, entonces director de tecnología de la Casa Blanca, cambió de trabajo sin cambiar de oficina: «El 17 de octubre pasé de CTO de la Casa Blanca a reparador de HealthCare.gov de tiempo completo» [4].

Park reclutó a un grupo de ingenieros que no habían participado en la construcción. El OIG los describe como «varios líderes e ingenieros de las principales empresas de tecnología» [1]. Entre ellos estaba Mikey Dickerson, ingeniero de confiabilidad de sitios en Google, es decir, alguien cuyo trabajo diario era que un sitio enorme no se cayera [4]. Un detalle del informe dice mucho de cómo llegaron: en gran parte donaron su tiempo, aunque, por las reglas de contratación del gobierno, se les pagó por hora a través de uno de los contratistas [1].

Lo primero que hicieron no fue programar arreglos. Fue medir. La noche del viernes 18 de octubre, según TIME, Gabriel Burt, director de tecnología de una empresa de análisis de datos, y otros pasaron unas cinco horas armando un tablero, porque el sitio no tenía una forma rápida de saber qué estaba pasando [4]. Con ese tablero encontraron uno de los primeros arreglos rápidos: la noche del 22 de octubre, el tiempo de carga de una página bajó de ocho segundos a dos [4].

Ese mismo 22 de octubre, la Secretaria de Salud anunció públicamente lo que llamó un «tech surge», una oleada tecnológica: Jeff Zients, administrador con experiencia en dirigir empresas, se sumaba como asesor de gestión, junto con «expertos y especialistas» del gobierno, de los contratistas y de la industria, «incluidos veteranos de las principales empresas de Silicon Valley» y «un puñado» de integrantes del programa Presidential Innovation Fellows de la Casa Blanca [3].

Primera decisión importante, tomada con ese grupo: refactorizar el código existente, no reconstruir desde cero. Empezar de nuevo habría costado un tiempo que no había, y el personal de la agencia y de los contratistas estaba dispuesto a trabajar con los recién llegados [1].

El cuarto de Columbia

A fines de octubre, el centro de mando se mudó a una sala de unos 370 metros cuadrados (4,000 pies cuadrados) que uno de los contratistas rentaba en un parque de oficinas en Columbia, Maryland [4]. Con el tiempo se convertiría en el centro de operaciones formal del sitio [1].

Dickerson convocó la primera junta de pie el 24 de octubre. A partir de ahí, todos los días, incluidos fines de semana, durante octubre y noviembre: a las 10:00 y a las 18:30, unos 45 minutos cada una, con una línea telefónica abierta las 24 horas para que quien trabajaba en otro lugar pudiera hablar con los demás en cuanto surgiera algo [4].

Las reglas las pegó en una pared, afuera de la sala de control. TIME las reproduce [4]:

1. «La sala y las juntas son para resolver problemas. Hay muchos otros lugares donde la gente dedica su energía creativa a echar culpas».
2. «Quienes deben hablar son las personas que más saben de un tema, no las de mayor rango».
3. «Hay que concentrarse en lo más urgente, como lo que nos va a lastimar en las próximas 24 a 48 horas».

El informe del OIG describe el mismo cambio con otras palabras. Se adoptó una cultura «sin gafete y sin cargo»: las tareas se asignaban por habilidad y disponibilidad, sin importar si la persona era empleada del gobierno o de cualquier contratista [1]. Por primera vez, el equipo técnico y el de políticas del programa trabajaban juntos. Uno de los ingenieros lo describió así: «Teníamos a la gente de políticas descifrando los mensajes de error. ¿Qué hacía o no hacía el código? ¿Qué se suponía que debía pasar?» [1]. Y la agencia contrató a un integrador técnico de sistemas, alguien cuyo trabajo era que todas las piezas se hablaran. Según el informe, eso mejoró la coordinación «a decir de todos» [1].

Hay una frase de un funcionario de CMS, recogida por los auditores, que resume el caso mejor que cualquier análisis: «CMS no necesitaba una oleada tecnológica; necesitábamos una oleada organizacional» [1].

¿Y la presión por meter más gente? Seguía ahí. Brill lo cuenta así: Zients tenía «carta blanca para agregar recursos», pero poner a diez personas en un arreglo que a un programador le tomaría diez días no lo convierte en un proyecto de un día. «Programar no funciona así» [4].

El reloj de noviembre

El 25 de octubre, Zients fijó públicamente una meta: el sitio funcionaría bien para la gran mayoría de los usuarios a fines de noviembre [1]. Los líderes técnicos de la sala dijeron después a los auditores que no los consultaron sobre esa fecha [1].

El camino a esa meta fue duro. A fines de octubre, dos fallas en el equipo del proveedor de infraestructura dejaron al sitio caído 24 y 36 horas [1]. Algunos durmieron en hoteles cercanos y trabajaron turnos de 24 horas [1]. «Fueron días oscuros», dijo un funcionario [1].

Pero los números empezaron a moverse. Según el informe de CMS del 1 de diciembre, que cita el OIG, el tiempo que el sitio estaba funcionando pasó de 42 % a inicios de noviembre a más de 90 % a fines de noviembre [1]. (TIME reportó 43 % y 95 % [4]; uso la cifra del informe oficial.) Al 1 de diciembre, el sitio aguantaba más de 35,000 usuarios simultáneos sin caerse, según el OIG; TIME habló de al menos 50,000 [1][4]. Ahora había tableros de desempeño de todo el sistema y, cuando la carga se desbordaba, una «sala de espera» que pedía al usuario aguardar o dejar su correo [1].

El plazo para tener cobertura el 1 de enero se extendió del 15 al 24 de diciembre. En el último día, el sitio recibió 49,156 usuarios simultáneos, según el OIG [1]; TIME reportó un pico mayor, de 83,000, el 23 de diciembre [4]. Al 28 de diciembre, unos 1.2 millones de personas habían elegido un plan por HealthCare.gov [1]. Al cerrar el primer periodo de inscripción, 5.4 millones de personas habían elegido un plan en el mercado federal [1].

De seis personas el primer día a más de un millón en diciembre.

Lo que costó

El rescate no borró la cuenta. El OIG reporta que seis contratos clave se estimaron al principio en 464 millones de dólares y, a inicios de 2014, ya se calculaban en 824 millones; el del sistema central pasó de 58 a 207 millones [1]. La Oficina de Rendición de Cuentas del gobierno (GAO) encontró que el sitio se lanzó sin verificar que cumpliera sus requisitos de desempeño, y que las obligaciones del contrato del sistema central crecieron de 56 a más de 209 millones entre septiembre de 2011 y febrero de 2014 [2].

En enero de 2014, CMS cambió de contratista principal. El contratista saliente, dice el OIG, se enteró por el Washington Post días antes de que llegara el nuevo [1].

Qué enseña este caso

1. Sumar gente no basta, y a veces estorba

Hubo dos oleadas de gente. La de agosto de 2013, 60 personas más sobre un proyecto sin liderazgo claro, no evitó el desastre [1]. La de octubre, que también sumó personal de la agencia, de los contratistas y del sector privado, la mayor parte en tres semanas [1], sí formó parte de la recuperación, porque llegó acompañada de liderazgo, métricas, integración y prioridades claras [1]. El caso no permite atribuir el resultado a un solo factor.

Seamos honestos con el dato: el rescate no se hizo con menos gente. Se hizo con gente distinta, organizada de otra forma. La diferencia no estuvo en el número, sino en quiénes llegaron, cómo se integraron y con qué instrumentos trabajaron. Brooks tenía razón en lo que advirtió, pero el caso no dice «nunca agregue personas». Dice: no espere que el número arregle lo que la organización no resuelve.

2. Un núcleo chico, experimentado e integrado

El núcleo que llegó a mediados de octubre era pequeño: «varios» ingenieros, según el OIG; «un puñado» de integrantes de ese programa de la Casa Blanca, según el anuncio oficial [1][3]. No llegaron a hacer el trabajo de todos. Llegaron con experiencia en sitios que no se caen, se sentaron con los ingenieros de los contratistas, que ya conocían el código, y los dirigieron. TIME habla de «decenas» de ingenieros, dispuestos y hasta entusiastas, que ese núcleo coordinó [4].

Ese núcleo fue una pieza, no toda la explicación. Entre los factores clave de la recuperación, el OIG destaca que todo el personal de CMS y de los contratistas trabajara como un solo equipo, sin gafete, y una «priorización implacable» que alineó el trabajo con las metas más importantes y alcanzables [1].

La palabra clave es integrado. Sin gafete y sin cargo: el que sabe, habla; el que puede, toma la tarea. Un ingeniero externo que llega a «auditar» desde fuera agrega una capa más. Uno que se sienta en la misma sala, con las mismas reglas, resta una.

3. Medir antes de arreglar

Lo primero fue un tablero armado en una noche [4]. Antes de eso, la mejor fuente para saber si el sitio estaba arriba era la televisión [1]. Sin métricas, cada persona nueva opina; con métricas, cada persona nueva ataca lo que el tablero señala.

4. Una sola mesa, con reglas

No una junta diaria más, sino la junta: un solo cuarto, dos cortes al día, 45 minutos, una línea abierta permanente y tres reglas en la pared [4]. Se discute lo que duele en las próximas 24 a 48 horas, habla quien sabe y no se buscan culpables. Es lo opuesto a varios centros de mando que no se ven entre sí [1].

5. Alguien dueño de que todo se hable

Antes del lanzamiento, nadie fungía como integrador de sistemas y cada contratista miraba su pieza [1]. En el rescate, la agencia contrató uno [1]. Cuando un sistema está hecho de muchas piezas y muchos proveedores, alguien tiene que ser dueño de las uniones. Si nadie lo es, el problema vive justo ahí.

6. La fecha que nadie mueve merece una pregunta

La fecha del 1 de octubre no la fijaba la ley: salió de una regulación y la sostenía un compromiso político, y nadie discutió formalmente moverla [1]. Antes de sumar gente para llegar a una fecha, vale la pena preguntar quién la fijó, qué pasa si se mueve y qué es lo mínimo que debe funcionar ese día.

Aplicación: dos ingenieros clave menos antes del Buen Fin

Escenario (ilustrativo, sin cliente ni caso real). Aplico las lecciones de HealthCare.gov a una situación que muchos directores en México reconocerán.

Es septiembre. Su comercio electrónico se prepara para el Buen Fin, el fin de semana de noviembre en que se concentra buena parte de la venta del año. En una misma quincena, renuncian los dos ingenieros que mejor conocen la integración entre la tienda, el inventario y los pagos. Quedan siete semanas.

La reacción natural es la de agosto de 2013: «contratemos cinco». Las lecciones del caso sugieren otro orden:

1. Primero, medir. Antes de que se vayan, pídales una sesión para dejar a la vista lo que solo ellos veían: qué alertas revisaban, qué tableros, qué procesos reiniciaban a mano. Si no existe un tablero del flujo de compra completo (de la tienda al pago y al inventario), ese es el primer entregable, no el último.
2. Después, sumar pocos y con experiencia. No cinco perfiles genéricos que hay que entrenar a siete semanas de la temporada alta. Uno o dos ingenieros que ya hayan trabajado en integraciones parecidas y en temporadas de alto volumen, que su equipo pueda entrevistar antes de empezar.
3. Integrarlos, no asignarlos. Que entren con las cuentas de su empresa, en sus repositorios, en su horario y a sus juntas. Sin «equipo del proveedor» y «equipo de la casa»: una sola mesa.
4. Una junta corta, con reglas. Dos cortes al día en las semanas previas, enfocados en lo que puede tirar la venta en las próximas 48 horas.
5. Recortar sin piedad. Lo que no sea indispensable para vender, cobrar y surtir ese fin de semana, se pospone.
6. Revisar la fecha de cada cambio, no la del Buen Fin. Esa no se mueve. Pero la del rediseño del carrito, la de la nueva pasarela o la de la migración de catálogo, quizá sí.

Así planteado, el Buen Fin no se gana con más gente. Se gana con la gente correcta, a tiempo y sentada en la misma mesa.

Cinco preguntas para su próximo comité

1. Si mañana se van los dos ingenieros que más saben de nuestras integraciones, ¿qué deja de funcionar, y alguien más lo sabe?
2. ¿Tenemos un tablero del flujo completo que importa al negocio, o cada área vigila solo su pieza?
3. ¿Quién es dueño de las uniones entre nuestros sistemas y nuestros proveedores?
4. Cuando sumamos personas a un proyecto atrasado, ¿cuánto tardan en ser útiles, y quién las integra?
5. ¿Las fechas que «no se pueden mover» están en un contrato, en una ley o en una presentación?

Si dos o más respuestas son «no sé», ahí puede estar su próximo octubre.

Qué hace Hábil cuando falta conocimiento crítico

Hábil es una consultora mexicana de ingeniería, fundada en 2006, que suma ingenieros senior a equipos de empresas en México y Estados Unidos. No mandamos «más gente»: presentamos perfiles con experiencia en integración, nube y sistemas regulados que usted entrevista y valida antes de empezar, y que trabajan dentro de sus controles: con la identidad de su empresa, en sus repositorios y en una ventana diaria de horario compartido con su equipo.

Puede empezar con uno o dos ingenieros que se integran a su equipo, con una célula que nosotros coordinamos o con un proyecto de alcance cerrado. Vea la página Sumar ingenieros a su equipo.

Pida su primera conversación, sin costo. Parte de qué necesita sostener o construir, qué perfil conviene y en qué forma de trabajo. Escríbanos por WhatsApp.

Preguntas frecuentes

¿Qué fue el «tech surge» de HealthCare.gov?

Fue el nombre que el Departamento de Salud de Estados Unidos dio, el 22 de octubre de 2013, al refuerzo para reparar el sitio: un asesor de gestión, Jeff Zients, y expertos del gobierno, de los contratistas y de empresas de tecnología [3]. El núcleo técnico lo reclutó la Casa Blanca con ingenieros que no habían construido el sitio [1].

¿Cuánto tardó el rescate?

El OIG concluye que CMS recuperó el sitio para un uso alto en unos dos meses: la meta de mejora se cumplió el 1 de diciembre de 2013 [1].

¿Qué dice la ley de Brooks?

En traducción libre: «Agregar personal a un proyecto de software atrasado lo atrasa más». Viene del libro The Mythical Man-Month, de Frederick P. Brooks Jr., publicado en 1975 [5]. Es una advertencia, no una prohibición: el costo está en el tiempo que toma integrar a cada persona y en la comunicación que se multiplica.

¿Entonces nunca conviene sumar ingenieros a un proyecto atrasado?

El caso no dice eso. En octubre de 2013 se sumó gente y el sitio se recuperó, pero esa gente llegó con experiencia, se integró en una sola mesa sin distinción de empleador y trabajó con métricas y prioridades recortadas [1][4]. El caso no permite atribuir el resultado a un solo factor. Lo que no bastó fue sumar sin liderazgo ni visibilidad [1].

¿Hábil participó en el caso HealthCare.gov?

No. Es un caso público, documentado por el gobierno de Estados Unidos y por la prensa. Lo usamos porque sus lecciones aplican a cualquier equipo que sostiene un sistema que no puede fallar.

¿Cuánto tarda en integrarse un ingeniero de Hábil a mi equipo?

Depende de tres cosas: el perfil que necesita, las entrevistas con las que su equipo lo valida y el tiempo que tarda su empresa en darle cuentas y accesos a sus repositorios. En la primera conversación definimos el perfil y le decimos qué tan pronto puede empezar en su contexto.

Las citas están traducidas del inglés. Las cifras son las que reporta cada fuente; cuando dos fuentes no coinciden, el texto lo dice y usa la oficial.