Entre las reseñas de “Ingeniería de Software Ágil” hay un artículo de Roberto Canales en www.adictosaltrabajo.com con algunos comentarios sobre la calidad que hace tiempo que quería comentar. Roberto Canales no está de acuerdo en que la calidad no sea negociable porque según explica:

“Todo producto tiene gamas. Y cada gama un mercado objetivo. Las tendencias inciden sobre las gamas y se crean nichos que se pueden aprovechar.”

En primer lugar agradezco todos los comentarios sobre el libro, compartamos o no el mismo punto vista sobre todo, que es casi imposible en una temática como la Ingeniería de Software porque cada persona tiene su opinión. En realidad yo he tratado de no sacar de mi cosecha demasiadas opiniones, sino más bien de documentar qué es lo que dicen los gurus sobre cada cosa.

Al respecto de la calidad el guru para mi es Masaaki Imai, entre otros muchos como Edwards Deming o Phil Crosby, y lo que dicen estas personas es que si comparamos el coste de la calidad con el coste de la no-calidad, la no-calidad siempre acaba resultando más cara. Por esto yo afirmo en libro que la calidad no es negociable.

Kent Beck en su libro “Extreme Programming Explained” también hace este balance del coste que tiene la no-calidad:

“Temporarily sacrificing internal quality to reduce time to market in hopes that external quality won’t suffer too much is a tempting short-term play. And you can often get away with making a mess for a matter of weeks or months. Eventually, though, internal quality problems will catch up with you and make your software prohibitively expensive to maintain, or unable to reach a competitive level of external quality.”

Es decir, no tiene sentido ahorrar en calidad porque a la larga acaba saliendo más caro. De hecho, la calidad ahorra costes. Se que esto suena un poco sorprendente porque la mayor parte de la gente piensa que la calidad cuesta dinero. El propio Masaaki Imai lo comentaba en una entrevista:

“Most companies still subscribe to the old paradigm which says that better quality costs more money. The real challenge to management is to improve quality while reducing cost because that is what today’s customers want.”

Yo creo que las personas que piensan que la calidad cuesta dinero en realidad no se refieren al mismo concepto de calidad. En el libro ya comento que no debe confundirse calidad con lujo, pero probablemente es algo que deba redactar mejor en el futuro. Las definiciones de calidad son un poco engañosas porque si tomamos como calidad la “satisfacción del cliente”, está claro que a mayor lujo, o a mejor gama o equipamiento de un producto, mayor satisfacción del cliente.

Sin embargo, si un cliente entra en un concesionario dispuesto a comprar un utilitario por 12.000 euros, la calidad no consiste en ofrecerle un Lexus por 40.000. Al cliente por supuesto le encantaría tener ese coche, pero la oferta no cumple con sus expectativas ya que él lo que necesita es algo que pueda comprar por 12.000.

La RAE define calidad como aquellas propiedades que permiten apreciar una cosa como mejor o peor que las restantes de su especie. La parte importante aquí es “que las restantes de su especie”, es decir, dentro de su misma gama y segmento de mercado. No tiene sentido comparar gamas de mercado distintas.

Algunos autores como Phil Crosby relacionan la calidad con el cumplimiento de unos requisitos. Es decir, fijados unos determinados requisitos, dentro de una gama concreta, un determinado nivel de lujo y un precio máximo que el cliente está dispuesto a pagar, hay diferentes grados de cumplimiento con esos requisitos.

Para mi la diferencia fundamental es que el lujo cuesta dinero, mientras que la calidad, como afirma Masaaki Imai, en realidad ahorra costes. Hacer las cosas bien no cuesta nada. Hacer las cosas mal, por el contrario, y como Kent Beck explica, acaba incrementando los costes. Por esto la calidad no es un lujo. El lujo es hacer las cosas mal, como no respetar los estándares de codificación, no contar con una batería de pruebas automatizadas o no refactorizar. Respetar los estándares de codificación no cuesta nada. Automatizar las pruebas ahorra muchísimo trabajo. La refactorización simplifica enormemente el mantenimiento del código. Y si no haces todo esto no ahorras nada porque a medio plazo el código se vuelve inmantenible y repleto de bugs, por lo que es imposible mantener ninguna calidad.

Obviamente todo está relacionado. Al mejorar la calidad y reducir los costes más fácil es introducir opciones y mejoras para un mismo precio, lo que permite diferenciar el producto de la competencia y que sea apreciado como mejor. Pero una cosa es la calidad con que se cumplen unos requisitos y otra los requisitos en sí, que pueden ser mejores o peores. Si haces las cosas mal siempre tendrás más costes que la competencia y tu producto será peor porque no podrás ofrecer las mismas prestaciones a un mismo precio.

Creo que diferenciando estos conceptos ahora sí estaremos de acuerdo en que la calidad no es negociable, y en que la calidad en realidad no cuesta dinero sino que ahorra costes. De todas formas vuelvo a recordar lo que he dicho al principio: no es que yo opine que la calidad no es negociable, sino que se trata de un mantra repetido constantemente por los autores con mayor autoridad en dicho tema.

Por otra parte, dicho todo esto debo advertir que hay que ser muy cuidadosos antes de justificar todo tipo de esfuerzos bajo el lema de que la calidad no es negociable. En Europa predomina un enfoque de la calidad que no tiene nada que ver con hacer las cosas bien ni con nada de lo que he hablado, sino con rellenar papeles y dejar evidencia documental de ciertas cosas, independientemente de cómo salga el producto. La calidad no debería costar esfuerzo, sino ahorrar esfuerzo. Si algo que promete mejorar la calidad en la práctica está incrementando los costes, ocasionando más trabajo o demorando el producto, entonces no está mejorando la calidad, sino todo lo contrario.