¿Ha escuchado el de la desaparición del almacén? Un día, desapareció, no de la vista física, sino de los ojos vigilantes del sistema de distribución automatizada de un conocido minorista. Un error de software de alguna manera había borrado la existencia del almacén, de modo que los bienes destinados al almacén se desviaban a otro lugar, mientras que los bienes en el almacén languidecían. Debido a que la compañía estaba en problemas financieros y había estado cerrando otros almacenes para ahorrar dinero, los empleados del almacén «desaparecido» se mantuvieron en silencio. Durante tres años, no llegó ni se fue nada. Sin embargo, los empleados seguían recibiendo sus cheques de pago porque un sistema informático diferente manejaba la nómina. Cuando el fallo del software finalmente salió a la luz, la mercancía en el almacén se vendió, y la alta dirección les dijo a los empleados que no dijeran nada sobre el episodio.
Esta historia ha estado flotando en la industria de la tecnología de la información durante unos 20 años. Probablemente sea apócrifo, pero para aquellos de nosotros en el negocio, es totalmente plausible. ¿Por qué? Porque episodios como este suceden todo el tiempo. En octubre pasado, por ejemplo, el gigante minorista de alimentos británico J Sainsbury PLC tuvo que cancelar su inversión de 526 millones de dólares en un sistema automatizado de gestión de la cadena de suministro. Parece que la mercancía estaba atascada en los depósitos y almacenes de la compañía y no estaba llegando a muchas de sus tiendas. Sainsbury se vio obligado a contratar unos 3000 empleados adicionales para abastecer sus estantes manualmente .
Este es solo uno de los últimos en una larga y triste historia de proyectos de TI que salieron mal . La mayoría de los expertos en TI están de acuerdo en que tales fallas ocurren con mucha más frecuencia de lo que deberían. Es más, los fracasos no tienen prejuicios universales: ocurren en todos los países; en grandes y pequeñas empresas; en organizaciones comerciales, sin fines de lucro y gubernamentales; y sin tener en cuenta el estatus o la reputación. Los costos empresariales y sociales de estos fracasos, en términos de dólares desperdiciados de contribuyentes y accionistas, así como de inversiones que no se pueden hacer, ahora ascienden a miles de millones de dólares al año.
El problema solo empeora a medida que se vuelve ubicuo. Este año, las organizaciones y los gobiernos gastarán aproximadamente 1 billón de dólares en hardware, software y servicios de TI en todo el mundo. De los proyectos de TI que se inicien, del 5 al 15 por ciento se abandonarán antes o poco después de la entrega por ser irremediablemente inadecuados. Muchos otros llegarán tarde y excederán el presupuesto o requerirán una reelaboración masiva. En otras palabras, pocos proyectos de TI tienen éxito de verdad.
La mayor tragedia es que el fallo del software es en su mayor parte predecible y evitable. Desafortunadamente, la mayoría de las organizaciones no ven la prevención del fracaso como un asunto urgente, a pesar de que esa visión corre el riesgo de dañar a la organización y tal vez incluso destruirla. Entender por qué persiste esta actitud no es solo un ejercicio académico; tiene enormes implicaciones para los negocios y la sociedad.
EL SOFTWARE ESTÁ EN TODAS PARTES. Es lo que nos permite obtener dinero en efectivo de un cajero automático, hacer una llamada telefónica y conducir nuestros autos. Un teléfono celular típico ahora contiene 2 millones de líneas de código de software; para el 2010 es probable que tenga 10 veces más. General Motors se estima que para entonces sus coches tendrán cada uno 100 millones de líneas de código.
La empresa promedio gasta entre el 4 y el 5 por ciento de los ingresos en tecnología de la información, y las que dependen en gran medida de TI, como las empresas financieras y de telecomunicaciones, gastan más del 10 por ciento en ti. En otras palabras, ahora es uno de los mayores gastos corporativos fuera de los costos de los empleados. Gran parte de ese dinero se destina a actualizaciones de hardware y software, tarifas de licencia de software, etc., pero una gran parte es para nuevos proyectos de software destinados a crear un futuro mejor para la organización y sus clientes.
Los gobiernos también son grandes consumidores de software. En 2003, el Reino Unido había más de 100 de los principales proyectos de IT que totalizaron $20.3 millones. En 2004, el gobierno de los Estados Unidos catalogó 1200 proyectos de TI civiles que costaban más de 60 mil millones de dólares, más otros 16 mil millones de dólares para software militar.
Cualquiera de estos proyectos puede costar más de 1.000 millones de dólares. Para tomar dos ejemplos actuales, se proyecta que el esfuerzo de modernización de computadoras en el Departamento de Asuntos de Veteranos de EE.UU. costará 3 3.5 mil millones, mientras que la automatización de los registros médicos del Servicio Nacional de Salud del Reino Unido costará más de 1 14.3 mil millones para el desarrollo y otros 5 50.8 mil millones para el despliegue.
Estos proyectos de megasoftware, una vez raros, ahora son mucho más comunes, ya que las operaciones de TI más pequeñas se unen en «sistemas de sistemas».»El control del tráfico aéreo es un excelente ejemplo, porque se basa en conexiones entre docenas de redes que proporcionan comunicaciones, clima, navegación y otros datos. Pero el truco de la integración ha obstaculizado a muchos desarrolladores de TI, hasta el punto de que los investigadores académicos creen cada vez más que la informática en sí puede necesitar ser repensada a la luz de estos sistemas masivamente complejos.
Cuando un proyecto falla, pone en peligro las perspectivas de una organización. Si el fracaso es lo suficientemente grande, puede robar todo el futuro de la empresa. En una crisis estelar, un sistema de planificación de recursos mal implementado llevó a FoxMeyer Drug Co., una compañía de distribución de medicamentos al por mayor de 5 5 mil millones en Carrollton, Texas, que cayó en bancarrota en 1996.
El fracaso de TI en el gobierno puede poner en peligro la seguridad nacional, como lo ha demostrado la debacle de los Archivos Virtuales del FBI. El sistema VCF de $170 millones, una base de datos con capacidad de búsqueda destinada a permitir a los agentes «conectar los puntos» y hacer un seguimiento de piezas de inteligencia dispares, terminó hace cinco meses sin que se desplegara ningún sistema .
Las fallas de TI también pueden atentar contra el crecimiento económico y la calidad de vida. En 1981, la Administración Federal de Aviación de los Estados Unidos comenzó a buscar la mejora de su anticuado sistema de control de tráfico aéreo, pero el esfuerzo por construir un reemplazo pronto se vio plagado de problemas . En 1994, cuando el organismo finalmente abandonó el proyecto, el costo previsto se había triplicado, se habían gastado más de 2.600 millones de dólares y la fecha de ejecución prevista se había retrasado varios años. Cada pasajero de avión que se retrasa debido a las vías aéreas bloqueadas aún siente esta cancelación; el impacto económico acumulativo de todos esos retrasos solo en las aerolíneas estadounidenses (sin importar los pasajeros) se acerca a los 5 50 mil millones.
En todo el mundo, es difícil decir cuántos proyectos de software fallan o cuánto dinero se desperdicia como resultado. Si define fracaso como el abandono total de un proyecto antes o poco después de su entrega, y si acepta una tasa de fracaso conservadora del 5 por ciento, entonces se desperdician miles de millones de dólares cada año en software defectuoso.
Por ejemplo, en 2004, los estados UNIDOS el gobierno gastó 6 60 mil millones en software (sin contar el software integrado en los sistemas de armas); una tasa de fallas del 5 por ciento significa que probablemente se desperdiciaron 3 3 mil millones. Sin embargo, después de varias décadas como consultor de TI, estoy convencido de que la tasa de fallas es del 15 al 20 por ciento para proyectos que tienen presupuestos de 1 10 millones o más. En cuanto a la inversión total en nuevos proyectos de software, tanto gubernamentales como corporativos, en los últimos cinco años, estimo que los fracasos de los proyectos probablemente le han costado a la economía estadounidense al menos 2 25 mil millones y tal vez hasta 7 75 mil millones.
Por supuesto, esos 7 75 mil millones no reflejan proyectos que exceden sus presupuestos, lo que la mayoría de los proyectos hacen. Tampoco refleja los proyectos entregados con retraso, que en su mayoría lo son. Tampoco tiene en cuenta los costos de oportunidad de tener que comenzar de nuevo una vez que se abandona un proyecto o los costos de los sistemas llenos de errores que tienen que ser reelaborados repetidamente.
También está el costo de los litigios de clientes iracundos que demandan a proveedores por sistemas mal implementados. Cuando se suman todos estos costos adicionales, la pestaña anual de software fallido y problemático se ejecuta de manera conservadora en algún lugar de 6 60 mil millones a 7 70 mil millones solo en los Estados Unidos. Por ese dinero, podría lanzar el transbordador espacial 100 veces, construir y desplegar todo el Sistema de Posicionamiento Global de 24 satélites, y desarrollar el Boeing 777 desde cero, y aún tener unos pocos miles de millones de sobra.
¿Por qué los proyectos fallan tan a menudo?
Entre los factores más comunes:
por supuesto, los proyectos rara vez fracasa por una o dos razones. El proyecto VCF del FBI sufrió de muchos de los problemas mencionados anteriormente. La mayoría de los fallos, de hecho, pueden atribuirse a una combinación de decisiones técnicas, de gestión de proyectos y de negocios. Cada dimensión interactúa con las demás de formas complicadas que exacerban los riesgos y problemas del proyecto y aumentan la probabilidad de fracaso.
Considere una tarea de software simple: un sistema de compras que automatiza el pedido, la facturación y el envío de piezas, para que un vendedor pueda ingresar el pedido de un cliente, verificarlo automáticamente con los requisitos de precios y contratos, y organizar que las piezas y la factura se envíen al cliente desde el almacén.
Los requisitos para el sistema especifican cuatro pasos básicos. En primer lugar, está el proceso de ventas, que crea una factura de venta. Esa factura se envía a través de un proceso legal, que revisa los términos y condiciones contractuales de la venta potencial y los aprueba. En tercer lugar, el proceso de provisión, que envía las piezas contratadas, seguido del proceso financiero, que envía una factura.
Digamos que a medida que se escribe el primer proceso, para ventas, los programadores tratan cada pedido como si se hubiera colocado en la ubicación principal de la empresa, a pesar de que la empresa tiene sucursales en varios estados y países. Ese error, a su vez, afecta cómo se calculan los impuestos, qué tipo de contrato se emite, y así sucesivamente.
Cuanto antes se detecte y corrija la omisión, mejor. Es como tejer un suéter. Si detecta una puntada perdida justo después de hacerla, simplemente puede desentrañar un poco de hilo y seguir adelante. Pero si no captas el error hasta el final, es posible que tengas que desenredar todo el suéter solo para rehacer esa puntada.
Si los programadores de software no detectan su omisión hasta la prueba final del sistema, o peor aún, hasta después de que el sistema se haya implementado, los costos incurridos para corregir el error probablemente serán muchas veces mayores que si hubieran detectado el error mientras aún estaban trabajando en el proceso de venta inicial.
Y a diferencia de una puntada perdida en un suéter, este problema es mucho más difícil de identificar; los programadores verán solo que están apareciendo errores, y estos pueden tener varias causas. Incluso después de que se corrija el error original, tendrán que cambiar otros cálculos y documentación y luego volver a probar cada paso.
De hecho, los estudios han demostrado que los especialistas en software dedican entre el 40 y el 50 por ciento de su tiempo a trabajos de repetición evitables en lugar de lo que llaman trabajo de valor agregado, que básicamente es trabajo que se hace bien la primera vez. Una vez que una pieza de software llega al campo, el costo de corregir un error puede ser 100 veces más alto que lo que habría sido durante la etapa de desarrollo.
Si abundan los errores, la reelaboración puede comenzar a inundar un proyecto, como un bote en una tormenta. Lo que es peor, los intentos de corregir un error a menudo introducen otros nuevos. Es como si estuvieras rescatando ese bote, pero también estás creando fugas. Si se producen demasiados errores, el costo y el tiempo necesarios para completar el sistema se vuelven tan grandes que continuar no tiene sentido.
En los términos más simples, un proyecto de TI generalmente falla cuando la reelaboración excede el trabajo de valor agregado para el que se ha presupuestado. Esto es lo que le sucedió a Sydney Water Corp., el proveedor de agua más grande de Australia, cuando intentó introducir un sistema automatizado de información y facturación para clientes en 2002. Según una investigación realizada por el Auditor General de Australia, entre los factores que condenaron el proyecto se encontraban la planificación y las especificaciones inadecuadas, lo que a su vez dio lugar a numerosas solicitudes de cambio y a importantes costos y demoras adicionales. Sydney Water abortó el proyecto a mitad de camino, después de gastar AU 6 61 millones (US 3 33,2 millones).
Todo lo cual nos lleva a la pregunta obvia: ¿por qué ocurren tantos errores?
Los fallos de los proyectos de software tienen mucho en común con los accidentes aéreos. Así como los pilotos nunca tienen la intención de estrellarse, los desarrolladores de software no pretenden fallar. Cuando un avión comercial se estrella, los investigadores analizan muchos factores, como el clima, los registros de mantenimiento, la disposición y el entrenamiento del piloto y los factores culturales dentro de la aerolínea. Del mismo modo, necesitamos analizar el entorno empresarial, la gestión técnica, la gestión de proyectos y la cultura organizacional para llegar a las raíces de los fallos de software.
Los principales factores de negocio son la competencia y la necesidad de reducir costos. Cada vez más, los altos directivos esperan que los departamentos de TI hagan más con menos y lo hagan más rápido que antes; ven los proyectos de software no como inversiones, sino como costos puros que deben controlarse.
Las exigencias políticas también pueden causar estragos en el calendario, el costo y la calidad de un proyecto de TI. Cuando el Aeropuerto Internacional de Denver intentó implementar su sistema automatizado de manejo de equipaje, los líderes políticos estatales y locales mantuvieron el proyecto en un calendario poco realista tras otro. La falta de entrega del sistema a tiempo retrasó la apertura del aeropuerto en 1995 (entonces el más grande de los Estados Unidos), lo que multiplicó el impacto financiero.
Incluso después de que el sistema se completó, nunca funcionó de manera confiable: masticaba el equipaje y los carros utilizados para transportar el equipaje se descarrilaban con frecuencia. Finalmente, United Airlines, el principal inquilino del aeropuerto, demandó al contratista del sistema, y el episodio se convirtió en un testimonio de los peligros de la conveniencia política.
La falta de apoyo de la alta dirección también puede arruinar una empresa de TI. Esto abarca desde no asignar suficiente dinero y mano de obra hasta no establecer claramente la relación del proyecto de TI con el negocio de la organización. En 2000, el minorista Kmart Corp., en Troy, Michigan. lanzó un $1.4 mil millones de esfuerzos de modernización de TI dirigidos a vincular sus sistemas de ventas, marketing, suministro y logística, para competir mejor con su rival Wal-Mart Corp., en Bentonville, Arkansas. Sin embargo, Wal-Mart resultó demasiado formidable, y 18 meses después, Kmart, con poco efectivo, recortó la modernización, cancelando los 1 130 millones que ya había invertido en ÉL. Cuatro meses después, se declaró en bancarrota; la compañía continúa luchando hoy.
Con frecuencia, los gerentes de proyectos de TI ansiosos por obtener fondos recurren a una forma de póker de mentirosos, prometiendo en exceso lo que hará su proyecto, cuánto costará y cuándo se completará. Muchos, si no la mayoría, proyectos de software comienzan con presupuestos demasiado pequeños. Cuando eso sucede, los desarrolladores tienen que compensar el déficit de alguna manera, por lo general tratando de aumentar la productividad, reduciendo el alcance del esfuerzo o tomando atajos riesgosos en las fases de revisión y prueba. Todo esto aumenta la probabilidad de error y, en última instancia, de fracaso.
Un sistema de reserva de viajes de última generación encabezado por un consorcio de Budget Rent-A-Car, Hilton Hotels, Marriott y AMR, la empresa matriz de American Airlines, es un ejemplo de ello. En 1992, tres años y medio y 165 millones de dólares en el proyecto, el grupo lo abandonó, citando dos razones principales: un calendario de desarrollo excesivamente optimista y una subestimación de las dificultades técnicas involucradas. Este era el mismo grupo que había construido anteriormente el exitoso sistema de reservas Sabre, demostrando que el rendimiento pasado no es garantía de resultados futuros.
Después de que los investigadores del accidente consideran el clima como un factor en un accidente de avión, miran al avión en sí. ¿Había algo en el diseño del avión que causó el accidente? ¿Llevaba demasiado peso?
En los fallos de los proyectos de TI, invariablemente surgen preguntas similares con respecto a los componentes técnicos del proyecto: el hardware y el software utilizados para desarrollar el sistema y las propias prácticas de desarrollo. Las organizaciones a menudo son seducidas por el canto de sirena del imperativo tecnológico: el impulso incontrolable de usar la última tecnología con la esperanza de obtener una ventaja competitiva. Con la tecnología que cambia rápidamente y las nuevas y fantásticas capacidades prometedoras, es fácil sucumbir. Pero el uso de tecnología inmadura o no probada es una ruta segura al fracaso.
En 1997, después de gastar 4 40 millones, el estado de Washington cerró un proyecto de TI que habría procesado licencias de conducir y registros de vehículos. Funcionarios de vehículos automotores admitieron que se vieron atrapados en la búsqueda de tecnología en lugar de concentrarse en implementar un sistema que cumpliera con sus requisitos. La debacle de TI que derribó a FoxMeyer un año antes también se debió a la adopción de un sistema de planificación de recursos de última generación y luego empujarlo más allá de lo que era factible.
El tamaño de un proyecto es una fuente de fracaso. Los estudios indican que los proyectos a gran escala fracasan entre tres y cinco veces más que los pequeños. Cuanto más grande es el proyecto, más complejidad hay tanto en sus elementos estáticos (las piezas discretas de software, hardware, etc.) como en sus elementos dinámicos (los acoplamientos e interacciones entre hardware, software y usuarios; conexiones a otros sistemas, etc.). Una mayor complejidad aumenta la posibilidad de errores, porque nadie realmente entiende todas las partes que interactúan del todo o tiene la capacidad de probarlas.
Aleccionador pero cierto: es imposible probar a fondo un sistema de TI de cualquier tamaño real. Roger S. Pressman señaló en su libro Ingeniería de software, uno de los textos clásicos en el campo, que » las pruebas exhaustivas presentan ciertos problemas logísticos….Incluso un pequeño programa de 100 líneas con algunas rutas anidadas y un solo bucle que se ejecuta menos de veinte veces puede requerir de 10 a la potencia de 14 rutas posibles para ejecutarse.»Probar todos esos 100 billones de caminos, señaló, asumiendo que cada uno podría evaluarse en un milisegundo, tomaría 3170 años.
Todos los sistemas de TI son intrínsecamente frágiles. En un gran edificio de ladrillos, tendrías que quitar cientos de ladrillos colocados estratégicamente para hacer que una pared colapse. Pero en un programa de software de 100 000 líneas, solo se necesitan una o dos líneas defectuosas para producir problemas importantes. En 1991, una parte de la red telefónica de ATandamp;T se apagó, dejando a 12 millones de suscriptores sin servicio, todo debido a un solo carácter mal escrito en una línea de código.
Las prácticas de desarrollo descuidadas son una fuente rica de fallos y pueden causar errores en cualquier etapa de un proyecto de TI. Para ayudar a las organizaciones a evaluar sus prácticas de desarrollo de software, los EE. El Instituto de Ingeniería de Software, en Pittsburgh, creó el Modelo de Madurez de Capacidades, o CMM. Califica las prácticas de una empresa contra cinco niveles de madurez creciente. Nivel 1 significa que la organización está utilizando prácticas de desarrollo ad hoc y posiblemente caóticas. El nivel 3 significa que la empresa ha caracterizado sus prácticas y ahora las entiende. El nivel 5 significa que la organización comprende cuantitativamente las variaciones en los procesos y prácticas que aplica.
A enero, casi 2000 organizaciones gubernamentales y comerciales habían notificado voluntariamente niveles de MMC. Más de la mitad reconoció estar en el nivel 1 o 2, el 30 por ciento estaba en el nivel 3, y solo el 17 por ciento había alcanzado el nivel 4 o 5. Los porcentajes son aún más sombríos cuando te das cuenta de que este es un grupo autoeleccionado; obviamente, las empresas con las peores prácticas de TI no se someterán a una evaluación de MMC. (La MMC está siendo reemplazada por la integración de MMC, que tiene como objetivo una evaluación más amplia de la capacidad de una organización para crear sistemas con uso intensivo de software.)
Las prácticas de TI inmaduras condenaron a los Estados Unidos. El esfuerzo de modernización de Internal 4 mil millones del Servicio de Impuestos Internos en 1997, y han continuado asolando la modernización actual de 8 8 mil millones del IRS. Puede ser intrínsecamente imposible traducir el código tributario en código de software: la ley tributaria es compleja y se basa en una legislación a menudo imprecisa, y cambia todo el tiempo. Desde el punto de vista de un desarrollador de TI, es una pesadilla de requisitos. Pero el IRS no ha sido ayudado por la hostilidad abierta entre los programadores internos y externos, una subestimación ridícula del trabajo involucrado y muchas otras malas prácticas.
LAS ACCIONES DEL PILOTO JUSTO ANTES de que un avión se estrelle son siempre de gran interés para los investigadores. Esto se debe a que el piloto es el máximo responsable de la toma de decisiones, responsable de la operación segura de la nave. Del mismo modo, los gerentes de proyecto desempeñan un papel crucial en los proyectos de software y pueden ser una fuente importante de errores que conducen al fracaso.
En 1986, la Bolsa de Londres decidió automatizar su sistema de liquidación de transacciones de acciones. Siete años más tarde, después de gastar 600 millones de dólares, descartó el desarrollo del sistema Taurus, no solo porque el diseño era excesivamente complejo y engorroso, sino también porque la gestión del proyecto era, para usar la palabra de uno de sus propios gerentes sénior, «delirante».»Como revelaron las investigaciones, nadie parecía querer saber el verdadero estado del proyecto, a pesar de que aparecían más y más problemas, se incumplían los plazos y los costos se disparaban .
La función más importante del gestor de proyectos de TI es asignar recursos a diversas actividades. Más allá de eso, el gerente de proyecto es responsable de la planificación y estimación del proyecto, el control, la organización, la gestión de contratos, la gestión de calidad, la gestión de riesgos, las comunicaciones y la gestión de recursos humanos.
Las malas decisiones de los gerentes de proyecto son probablemente la mayor causa de fallos de software en la actualidad. Una mala gestión técnica, por el contrario, puede conducir a errores técnicos, pero generalmente pueden aislarse y corregirse. Sin embargo, una mala decisión de gestión de proyectos, como contratar a muy pocos programadores o elegir el tipo de contrato equivocado, puede causar estragos. Por ejemplo, los desarrolladores del condenado sistema de reservas de viajes afirman que se vieron obstaculizados en parte por el uso de un contrato de precio fijo. Tal contrato supone que el trabajo será de rutina; el sistema de reservas resultó ser cualquier cosa menos.
Las decisiones de gestión de proyectos a menudo son complicadas precisamente porque implican compensaciones basadas en conocimientos difusos o incompletos. Estimar cuánto costará un proyecto de TI y cuánto tiempo tomará es tanto arte como ciencia. Cuanto más grande o novedoso sea el proyecto, menos precisas serán las estimaciones. Es una broma corriente en la industria que las estimaciones de proyectos de TI estén en el mejor de los casos dentro del 25 por ciento de su verdadero valor el 75 por ciento del tiempo.
Hay otras formas en que una mala gestión de proyectos puede acelerar la desaparición de un proyecto de software. Un estudio realizado por el Instituto de Gestión de Proyectos, en Newton Square, Pensilvania., demostró que la gestión de riesgos es la menos practicada de todas las disciplinas de gestión de proyectos en todos los sectores de la industria, y en ningún lugar se aplica con más frecuencia que en la industria de TI. Sin una gestión de riesgos eficaz, los desarrolladores de software tienen poca información sobre lo que puede salir mal, por qué puede salir mal y qué se puede hacer para eliminar o mitigar los riesgos. Tampoco hay una manera de determinar qué riesgos son aceptables, lo que a su vez hace que las decisiones del proyecto con respecto a las compensaciones sean casi imposibles.
La mala gestión del proyecto adopta muchas otras formas, incluida la mala comunicación, que crea una atmósfera inhóspita que aumenta la rotación, no invierte en la capacitación del personal y no revisa el progreso del proyecto a intervalos regulares. Cualquiera de estos puede ayudar a descarrilar un proyecto de software.
La última área que los investigadores investigan después de un accidente de avión es el entorno organizacional. ¿La aerolínea tiene una sólida cultura de seguridad o hace hincapié en cumplir con el horario de vuelo por encima de todo? En los proyectos de TI, una organización que valora la apertura, la honestidad, la comunicación y la colaboración es más propensa a encontrar y resolver errores lo suficientemente pronto como para que el trabajo de repetición no se vuelva abrumador.
Si hay un tema que recorre la torturada historia del software defectuoso, es un fracaso para confrontar la realidad. En numerosas ocasiones, el inspector general del Departamento de Justicia de los Estados Unidos, un panel externo de expertos y otros le dijeron al jefe del FBI que el sistema VCF era imposible según lo definido, y sin embargo el proyecto continuó de todos modos. Las mismas actitudes existían entre los responsables del sistema de reservas de viajes, el sistema Taurus de la Bolsa de Londres y el proyecto de control del tráfico aéreo de la FAA, todo indicativo de culturas organizacionales impulsadas por el miedo y la arrogancia.
Un informe reciente de la Oficina Nacional de Auditoría del Reino Unido encontró numerosos casos en los que se recomendaba que los proyectos de TI del gobierno no avanzaran y continuaran de todos modos. El Reino Unido incluso tiene un departamento gubernamental encargado de prevenir las fallas de TI, pero como señaló el informe, más de la mitad de las agencias que supervisa el departamento ignoran rutinariamente sus consejos. A este tipo de comportamiento lo llamo escalada irracional del proyecto: la incapacidad de detener un proyecto incluso después de que sea obvio que la probabilidad de éxito se acerca rápidamente a cero. Lamentablemente, tal comportamiento no es de ninguna manera único.
En el análisis final, las grandes fallas de software tienden a parecerse al peor accidente de avión imaginable, donde el piloto era inexperto pero extremadamente imprudente, voló en una tormenta de hielo en un avión no probado y trabajó para una aerolínea que daba un servicio de labios a la seguridad mientras reducía el entrenamiento y el mantenimiento. Si lees el informe del investigador después, estarías sacudiendo la cabeza y preguntando: «¿No era inevitable un accidente así?»
Así también, las razones por las que los proyectos de software fallan son bien conocidas y han sido ampliamente documentadas en innumerables artículos, informes y libros . Y, sin embargo, los fracasos, los casi fracasos y el software defectuoso de antaño siguen plagándonos, mientras que las prácticas conocidas para evitar errores son rechazadas. Parecería que conseguir programas informáticos de calidad a tiempo y dentro del presupuesto no es una prioridad urgente en la mayoría de las organizaciones.
No parecía estar en Oxford Health Plans Inc. en Trumbull, Connecticut., en 1997. El sistema de facturación automatizada de la compañía era vital para sus resultados finales, y sin embargo, los gerentes sénior estaban más interesados en expandir el negocio de Oxford que en garantizar que su sistema de facturación pudiera satisfacer sus necesidades actuales . Incluso cuando surgieron problemas, como el envío de facturas con meses de retraso, los gerentes prestaron poca atención. Cuando el sistema de facturación colapsó efectivamente, la compañía perdió decenas de millones de dólares y sus acciones cayeron de $68 a 2 26 por acción en un día, eliminando 3 3,4 mil millones en valor corporativo. Los accionistas presentaron demandas, y varias agencias gubernamentales investigaron a la compañía, que finalmente fue multada con 3 3 millones por violaciones regulatorias.
Incluso las organizaciones que se queman por experiencias de software erróneas parecen incapaces o no dispuestas a aprender de sus errores. En un informe de 2000, la Junta de Ciencias de la Defensa de los Estados Unidos, un órgano asesor del Departamento de Defensa, señaló que varios estudios encargados por el Departamento de Defensa habían formulado 134 recomendaciones para mejorar el desarrollo de su software, pero solo se habían aplicado 21 de esas recomendaciones. Los otros 113 seguían siendo válidos, señaló la junta, pero estaban siendo ignorados, incluso cuando el Departamento de Defensa se quejaba del mal estado del desarrollo de software de defensa.
Algunas organizaciones se preocupan por la calidad del software, como lo demuestra la experiencia de la empresa de desarrollo de software Praxis High Integrity Systems, en Bath, Inglaterra. Praxis exige que sus clientes se comprometan con el proyecto, no solo financieramente, sino como participantes activos en la creación del sistema de TI. La compañía también dedica una enorme cantidad de tiempo a comprender y definir los requisitos del cliente, y desafía a los clientes a explicar lo que quieren y por qué. Antes de escribir una sola línea de código, tanto el cliente como Praxis están de acuerdo en lo que se desea, lo que es factible y los riesgos involucrados, dados los recursos disponibles.
Después de eso, Praxis aplica un enfoque de desarrollo riguroso que limita el número de errores. Una de las grandes ventajas de este modelo es que filtra a los muchos posibles clientes que no están dispuestos a aceptar la responsabilidad de articular sus requisitos de TI y gastar el tiempo y el dinero para implementarlos correctamente.
Algún nivel de falla de software siempre estará con nosotros. De hecho, necesitamos verdaderos fracasos, en lugar de errores evitables, para seguir progresando técnica y económicamente. Pero demasiados de los fracasos que ocurren hoy en día son evitables. Y a medida que nuestra sociedad llega a depender de sistemas de TI que son cada vez más grandes, más integrados y más caros, el costo del fracaso puede llegar a ser desastrosamente alto.
Incluso ahora, es posible apostar sobre dónde ocurrirá la próxima gran debacle del software. Uno de mis principales candidatos son los sistemas de TI que resultarán de la Comunidad de Información de Salud Estadounidense del gobierno de los Estados Unidos, una colaboración público-privada que busca definir estándares de datos para registros médicos electrónicos. La idea es que, una vez que se definan los estándares, se construirán sistemas de TI para permitir que los profesionales médicos de todo el país ingresen digitalmente a los registros de los pacientes, dando a los médicos, hospitales, aseguradoras y otros especialistas de atención médica acceso instantáneo a la historia médica completa de un paciente. Los expertos en atención médica creen que un sistema de sistemas de este tipo mejorará la atención al paciente, reducirá los costos en un estimado de 7 78 mil millones por año y reducirá los errores médicos, salvando decenas de miles de vidas.
Pero este enfoque es una mera quimera si las prácticas de software y las tasas de falla se mantienen como son hoy en día. Incluso según las estimaciones más optimistas, crear un sistema de registros médicos electrónicos requerirá 10 años de esfuerzo, $320 mil millones en costos de desarrollo y expenses 20 mil millones por año en gastos operativos, suponiendo que no haya fallas, sobrecostos, errores de programación, problemas de seguridad o software de mala calidad. Esto no es un escenario realista, especialmente porque la mayoría de los expertos en TI consideran que la comunidad médica es la menos experta en informática de todas las empresas profesionales.
En última instancia, los pacientes y los contribuyentes pagarán el precio por el desarrollo, o el fracaso, de este tipo de problemas. Dadas las prácticas de TI de hoy en día, el fracaso es una posibilidad clara, y sería una pérdida de magnitud sin precedentes. Pero luego, los países de todo el mundo están contemplando o ya están trabajando en muchas iniciativas de tamaño e impacto similares, en aviación, seguridad nacional y ejército, entre otros ámbitos.
Al igual que la electricidad, el agua, el transporte y otras partes críticas de nuestra infraestructura, se está convirtiendo rápidamente en algo intrínseco a nuestra existencia diaria. En unas pocas décadas, una falla de TI a gran escala se convertirá en algo más que un inconveniente costoso: pondrá en peligro nuestra forma de vida. En ausencia del tipo de cambios en toda la industria que mitiguen las fallas de software, ¿cuánto de nuestro futuro estamos dispuestos a apostar por estos sistemas enormemente costosos y complejos?
Ya sabemos cómo hacer bien el software. Puede que finalmente sea el momento de actuar sobre lo que sabemos.