Muchas veces se usa la frase de la calidad no es negociable como argumento para hacer cualquier cosa que los técnicos queramos hacer.
Mi duda siempre ha sido… «¿pero qué es la calidad?». Hay muchas definiciones. En su momento, la famosa ISO9000 caracterizaba la calidad como poder repetir el mismo proceso para llegar al mismo producto dentro de una holgura determinada (más o menos…). Es decir, podías hacer un producto totalmente decepcionante usando las peores formas de trabajo pero tener un sello de calidad en él. Porque siempre lo haces igual de mal.
En realidad, la calidad es subjetiva. El consumidor tiene una visión y la ISO tiene otra. Obviamente, el equipo de desarrollo tendrá la suya y el cliente que les encarga el trabajo otra más.
Me ha llamado la atención el último artículo de Gojko Adzic sobre Mapas de efectos. Y no por la idea de los mapas (que es interesante) si no porque le dedica una sección al tema de la subjetividad en la calidad.
Es más, ataca esta subjetividad y sugiere que la calidad se defina explícitamente en función de quién es el beneficiario del valor que se está generando. De esta forma todos los implicados están alineados en sus objetivos. Además la definición no se realiza (sólo) a bajo nivel (esa definición podría ser el Definition of Done de cada tarea) si no que intenta que la definición sea de alto nivel para que pueda guiar el proyecto.
Lo curioso de definir así la calidad en un proyecto que incluye software es que el beneficiario del trabajo entiende qué es la calidad. No se basa en conceptos técnicos no relacionados con el negocio… no es opaca. Por otra parte, es muy posible que la definición de la calidad tal como la entienden muchos técnicos no sea importante a la hora de generar valor.
Demasiadas veces he oído cómo se usa la calidad (técnica) para justificar el retraso en las fechas de entrega o en la aproximación para resolver un problema del usuario. Crear una definición de calidad compartida desde el primer momento puede ayudar a evitar esto.
Y todo lo demás (pocos bugs, muchas pruebas, automatización del proceso de desarrollo) no es calidad. Es el sello de una buena ingeniería y lo que permite entregar la calidad que busca el cliente/consumidor/usuario.