En el software, la calidad, no es opcional
Me escribía, hace unos días, uno de los asistentes a la ponencia sobre Calidad del Software y Team System que impartí en los Cursos de Verano de la UPNA. Me comentaba que lo visto en mi ponencia le había causado muy buena impresión y que había decido poner en práctica algunas de las técnicas y herramientas allí comentadas. El problema que se le presentaba, es que en su empresa, un pequeño ISV, sus jefes no percibian la calidad como algo importante, es más importante para ellos tener un mayor número de características que un software de mayor calidad. El razonamiento es simple, la calidad no se puede poner en un anuncio o en una oferta. Esta mentalidad podría ser razonable para muchos productos, pero no lo es para el software. Trataré de explicar el por qué.
Si tu produces, por poner algo simple, bolígrafos, puedes decidir que tu segmento del mercado es el de los bolígrafos baratos, de baja calidad. Y sin duda te puede ir muy bien, no todo el mundo necesita un pluma Du Pont, para firmar su hipoteca. Tendrás un motón de clientes que solo ven en el momento de la compra de un bolígrafo su precio, y que además en el momento de la compra no van a evaluarlo a fondo. Además, reducir la calidad, en el caso de la gran mayoría de los productos manufacturados, tiene el efecto directo de abaratar los costos de producción. Muchos de los directivos actualmente al mando de empresas que construyen software han sido formados en sectores ajenos a la informática, una industria muy nueva, y a menudo caen en el error de pensar en la producción de software desde los parámetros habituales en otras industrias. Este es un error habitual, la producción de software es muy diferente, es un proceso creativo no un proceso manufacturero.
La principal diferencia cuando 'fabricamos' software es que la calidad no es opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Ese enfoque no funciona por varios motivos:
Primero: Puedes hacer bolígrafos de baja calidad que hagan su labor aceptablemente, pero no puedes hacer software de baja calidad que funcione y cumpla su misión aceptablemente. Además, los usuario cada vez son menos tolerantes con los errores en las aplicaciones. Pensemos en como ha evolucionado la calidad del software que todos tenemos en común, el sistema operativo. Todos recordamos la pantallas azules de la muerte de Windows NT, alguna vimos en 2000 y luego llego Windows XP y la mejora fue notable. Lo mismo a ocurrido en otros sistemas operativos, como Linux, donde cada vez es más dificil ver un Kernel Panic. Al ser el sistema operativo el software que todos usamos, es el que se combierte en patrón de calidad. Con Windows 95 no era importante que nuestros programas 'cascasen' con cierta frecuencia, el usuario estaba acostumbrado a que el sistema operativo fallase y era más o menos permisivos con nuestros fallos. Con la mejora de la calidad de los sistema operativo el usuario esta subiendo el listón de la calidad y si queremos seguir vendiendo nuestro software más que el de la competencia la calidad del mismo se esta convirtiendo en un factor vital.
Segundo: Antes de comprar un software o contratatar la realización software con una compañia de desarrollo, el usuario compara a fondo. Y a menudo el precio no es el factor principal. Nunca venderemos un software si el instaldor de nuestra demo falla con solo ejecutarlo con un usuario que no es administrador, por barato que sea, el usuario no se va a tomar un segundo más en seguir evaluando nuestro software. Ni venderemos un proyecto de desarrollo si a los oidos del comprador llega una mala experiencia de una empresa que nos contrato con anterioridad, por economica que sea nuestra oferta. Solo centradonos en la calidad lograremos evitar este tipo de problemas. Nadie recuerda quien hizo un buen software, pero nadie olvida que hizo uno que no funciona correctamente porque lo sufre a diario.
Tercero: Quiza el factor más importante y menos evidente es que añadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos. La reducción de costes se produce porque con un adecuado proceso de desarrollo, que tenga la calidad del software como un factor central, se descubre antes los errores. Y los errores, de cualquier indole, son más costosos cuanto más tarde se descubren, además estos coste se incrementan siguendo un función exponencial. Descubir que nuestra arquitectura no es capaz de gestionar el número requerido de transacciones por segundo, es infinitamente más costoso de corregir si se descubre durante las pruebas de aceptación que durante la revisión de la arquitectura. La reducción del tiempo de desarrollo se produce porque es mucho más facil construir software sobre software estable que sobre software que no es estable. Hoy en día todos los procesos de desarrollo de software son en mayor o menor medida iterativos e incrementales. Es imposible construir un incremento de funcionalidad si la base de ese incremento no es estable.
Dicho esto, es curioso ver las situaciones paradójicas que se dan en cuanto a la calidad en los proyectos y las empresas de desarrollo de software. He visitado empresas, generalmente para impartir formación, con grandes carteles en recepción del estilo "La calidad es nuestra esencia" o "La calida al servicio del cliente" y con todas las certificaciones habidas y de por haber de 'calidad' que no tienen ni un solo especialista en calidad del software, ni un solo especialista en probar aplicaciones. ¿Se imaginan una empresa de industrial, que se tome en serio el mantenimiento de sus maquinas, sin un solo experto en mantenimiento?, pues esto es la norma en las empresas de desarrollo, dicen preocuparse por la calidad pero no cuentan con un solo experto en el tema. Y no, lo desarrolladores, no son expertos en calidad y pruebas. Pero este es otro tema, que sin duda abordaré en el futuro. ¿Por qué se dan estas paradojas en el desarrollo de software?.