¿Qué tal suena mantener el número de errores en el código por debajo del 5%? ¿Del 1%? Nos hemos acostumbrado a unas tasas de error espantosas en el desarrollo de software que se admiten como inevitables. Hay que coger perspectiva: el 5% de errores significa que 23.000 vuelos se estrellarían en Barajas cada año.
En Marzo de 1991, Natalie Gabel publicó un artículo sobre control de calidad en Training Magazine titulado «Is 99’9% good enough?» (¿Es el 99’9% suficientemente bueno?). En él se citaban diversas estadísticas para poner de relieve la gravedad de rebajar las expectativas de acierto en varios sectores. Por ejemplo, un 0’01% de error significa que 1.314 llamadas telefónicas se cortarían o harían mal CADA MINUTO.
Este artículo se ha citado en muchas ocasiones a lo largo de los últimos 20 años, siendo una de las referencias clásicas de la gestión de proyectos. Lo que me ha extrañado es que nadie se haya preocupado en actualizar los datos. Retomando el ejemplo de Barajas, si pusiéramos ese objetivo del 99’9% de precisión en los objetivos de calidad del aeropuerto, cada año «sólo» se estrellarían cinco aviones.
Vamos a ver algunos ejemplos del artículo original. Con el 99’9% de aciertos:
- 22.000 operaciones bancarias se anotarían de forma incorrecta CADA HORA.
- 2.000.000 de documentos se perderían en Hacienda cada año.
- 12 bebés se devolverían a los padres equivocados cada día en las guarderías.
Estas son cifras referidas a la población de Estados Unidos hace 20 años. Pero hace 20 años no había Internet, la población de Estados Unidos no es la de España y la actividad económica ha cambiado mucho en este tiempo. Vamos a tratar de dar cifras más cercanas, aparte de los vuelos en Barajas. Con el mismo objetivo del 99’9% de precisión:
- 3.946 entradas de la Wikipedia estarían totalmente equivocadas.
- 86.000 líneas de código de Mac OS X 10 tendrían errores.
- 46 intervenciones quirúrgicas hechas en el hospital de La Paz saldrían mal cada año.
- 101.754 pasajeros no llegarían a su destino en el metro cada año.
Quiero añadir un dato que yo mismo calculo en los cursos de administración de sistemas que doy: un porcentaje de funcionamiento del 99’9% en servidores se traduce en que, a lo largo de un año, las máquinas estarían detenidas casi 9 horas. ¿Podría alguien calcular el dinero que se puede perder si…
- … un proveedor de hospedaje como Arsys deja de funcionar 9 horas?
- … la Bolsa de Madrid deja de cotizar durante 9 horas?
- … el sistema de venta de entradas para espectáculos de La Caixa deja de vender 9 horas?
Porque lo importante de este ejercicio mental es calcular el dinero que se pierde por aceptar una tasa de error del 10%, del 1% o del 0’1%.
Voy a plantear la duda de otra forma: ¿Cuánto puede invertir una empresa en implantar un sistema de calidad para la producción de software? Porque este es el problema original, que cuando te llaman para hacer una consultoría de gestión y dices que hay que reducir el margen de error en las predicciones de presupuesto a menos del 10%, todo el mundo se lleva las manos a la cabeza.
Coja el presupuesto del último proyecto, calcule el 10% y multiplíquelo por el número de proyectos que pueda hacer en los próximos 3 años. Esa cifra es el dinero que va a PERDER de dos formas: o porque habrá que rehacer el trabajo y no se puede volver a cobrar, o porque perderá el cliente. Y aquí no incluimos los costes de pérdida de prestigio y oportunidades.
Claro, la respuesta típica que recibo de los Jefes de proyecto y «expertos» comerciales es que las técnicas de mejora no se pueden aplicar al desarrollo de software, porque la programación es una tarea «artesanal y creativa». Un estudio publicado en 1997 por el SEI demostraba que, tras la implantación de un método de gestión del trabajo personal para programadores, la tasa de errores en el código se reducía un 86%.
Dejo a la iniciativa de cada uno calcular el número de horas de programador que NO tendría que repetir si redujese en un 86% el número de errores que debe corregir en cada entrega de software.