No solo en España se hacen famosos proyectos software estatales… por problemas de calidad software, grandes presupuestos, sospechosa gestión de proyectos, etc., (véase, a modo de ejemplo, aquella olvidada web del Senado), también en los USA “cuecen habas”.
La esperada salida al público de la web healthcare.gov, que implementa la reforma sanitaria de Obama, el “ObamaCare”, ya ha entrado en el exclusivo club de los proyectos de problemas informáticos más costosos de la historia, una aplicación que ha costado… 400 millones de dólares.
Críticas y descontento general de los usuarios
Cuando la gente ha accedido a la página, se ha encontrado con que ésta no funciona… como debería. En muchos casos, la navegación a lo largo de la página ha sido muy lenta, en otros, los usuarios no han podido registrarse para contratar los servicios. Además de que, entre otras cosas, la web muestra mensajes de error confusos y la información de ciertos formularios del sitio no se envía correctamente.
“Fallos informáticos intolerables”
Tanto Obama como el departamento de salud y servicios humanos (HHS), han anunciado que estos fallos informáticos son intolerables y que desde departamentos internos del gobierno y consultorías externas, están trabajando en mejorar el healthcare.gov.
La polémica está servida. A pesar de que fuentes oficiales del gobierno no se han pronunciado acerca de las causas de esta catástrofe informática (esta aplicación ha costado de momento 400 millones de dólares), distintos profesionales del ámbito informático no han tardado mucho en publicar en internet sus opiniones acerca de posibles motivos y soluciones; sin olvidarnos, además, de todas las bromas y parodias que se han generado en torno a la noticia.
Caso práctico de fallos, errores y mala gestión de proyectos software
Esta es una recopilación de distintos fallos encontrados en la web (y en todo el sistema asociado a ella) que se han ido publicando en internet a raíz de la puesta en producción de healtcare.gov:
1 – Problemas derivados de la estimación del proyecto
Distintas fuentes han confirmado que el equipo técnico encargado del desarrollo de la aplicación era consciente de que el funcionamiento del sitio web no era el adecuado y que tenía muchísimos fallos sin solucionar, pero la presión de las fechas (Obama se comprometió a que el 1 de Octubre saldría al público) y la posible repercusión política que se hubiera generado no terminar a tiempo, se ha traducido en el fiasco que ha supuesto la web.
El New York Times, señala que el funcionamiento del sistema era tan malo que Henry Chao, el «chief digital architect» del proyecto, habló con los ejecutivos, refiriéndoles que estaba muy preocupado por el comportamiento de la web cuando saliera al público. Según este periódico, sus palabras fueron: “Solo asegurémonos de que la experiencia, al usar la web, no sea del Tercer Mundo”.
2 – “Mythical Man Month”, añadir gente a un proyecto retrasado… hace que se retrase más
Ya hablábamos aquí de esto allá por el 2007, los mitos del «hombre-mes». Y un artículo de la revista Forbes se lo recuerda a Obama, la mítica ley del famoso libro “The Mythical-Man Month” de Fred Brooks: “Añadir más personal a un software que de por sí está retrasado, hace que el proyecto se retrase más”. Y eso es justamente lo que se está haciendo en el healthcare.gov, frente al retraso contratar más gente para el proyecto.
Esto ocurre, porque primero, es necesario que pase un tiempo hasta que la gente nueva conozca el sistema que tiene que implementar y segundo, al aumentar el tamaño del equipo se hace más complicada la comunicación entre sus miembros.
3 – Problemas derivados de la integración con otros sistemas
El sistema de healthcare.gov, debe conectarse con varios sistemas federales (en su mayoría, sistemas legacy) para determinar qué tipo de subsidio le corresponde al usuario que quiere contratar una cobertura sanitaria. Estos sistemas no se integran entre sí demasiado bien, provocando los distintos retrasos en la carga de las páginas.
4 – Problemas derivados de la arquitectura del sistema
Michael Barone en su post Obamacare IT mess, considera que la arquitectura empleada en sistema no es la más correcta, dado que emplear JavaScript en un sitio web tan complejo y masivo para tratar tantos datos no es lo más adecuado.
5 – Problemas de requisitos
Según npr.org, el sistema está permitiendo enviar solicitudes a gente que vive en estados que tienen su propio mercado de cobertura sanitaria, y que por lo tanto al gobierno federal no le corresponde encargarse de ellas.
6 – Pruebas de rendimiento
Avik Roy en Obamacare’s Website Is Crashing Because It Doesn’t Want You To Know How Costly Its Plans Are, detalla que la lentitud en la navegación de la página y los distintos fallos en los procesos de registro y login, vienen derivados de que la gente no puede ver los planes de precios sin que antes tenga que introducir sus datos personales para que el sistema compruebe el subsidio que pueda recibir por parte del gobierno federal (que como ya hemos comentado es un proceso muy complejo y lento).
Otros sistemas privados de comercio electrónico de planes de cobertura sanitaria, ofrecen la posibilidad de ver los planes de precios indicando solo un código postal y una edad, lo que acelera el proceso.
Accediendo a healthcare.gov, podemos ver que finalmente ya han agregado esta nueva funcionalidad.
No me extiendo más, que la cosa ha llegado incluso hasta Hitler…
Si quieres leer más…
- ObamaCare’s Web Site: Too Much Help Will Slow The Project
- Obamacare IT mess
- Obama Administration Addresses Health Care Website Fumbles
- Obamacare’s Website Is Crashing Because It Doesn’t Want You To Know How Costly Its Plans Are
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Es «bueno» ver que no sólo somos los españoles los que hacemos estas cosas (ejem renfe.com ejem). Creo que el problema es el de siempre: se subcontrata a una subcontrata que contrata (http://money.cnn.com/2013/10/21/technology/obamacare-website-contracts/) a unos desarrolladores que tienen que picar código como locos ya que ni se han definido los requisitos ni se han puesto plazos lógicos al proyecto haciendo que el proyecto se convierta en una Death March de manual.
Coincido contigo en que añadir más gente al proyecto, aunque sea un A-Team (http://reason.com/blog/2013/10/23/vid-kathleen-sebelius-brings-in-a-team-t) pero después de 400 millones gastados y unas consecuencias políticas importantes (recordemos que el website es parte del famoso plan para la reforma integral de la sanidad que provocó el lockdown del gobierno hace unas semanas) supongo que les han entrado las prisas y tienen que hacer algo de cara al público. Ya veremos cómo acaba esto pero sería un buen momento para que Kent Beck y unos cuantos más dijeran: dejadnos 50 buenos programadores y 5 sprints.
Un saludo!
Hola Javier, quería hacer una pequeña puntualización. En el punto «4 – Problemas derivados de la arquitectura del sistema» el problema no es el uso de JavaScript, sino de scripts de Java:
«Using Java scripts for a heavy duty production website was a bad move from a software design point of view.» – http://washingtonexaminer.com/article/2537452
Cierto, gracias, se ve que lo leí demasiado rápido…