El otro día volvió a pasar. Sí. Otra vez alguien que me cuenta aquello de “no nos han dejado tiempo ni presupuesto para temas de calidad software”. Los mismo que me lo contaban, semanas antes habían realizado una pequeña prueba de “calidad software” con la herramienta PMD y encontraron de todo, cosas realmente horribles, código sobre el que había que ponerse de manera seria a controlar su “calidad” o ya iba a ser muy tarde.
Y lo será, será tarde, porque nadie se va a poner a enmendar aquello, porque “no hay presupuesto para -calidad software-”.
Quienes no conocen lo que es un desarrollo y un proyecto software (y que generalmente son los que deciden si hay o no presupuesto para “calidad software”) quiero entender que al escuchar la palabra “calidad” les viene a la cabeza conceptos que para ellos son sinónimos de “lujo”, “estar por encima de la media”, “comodidad”, etc. Y en cualquier caso, “calidad” es “algo prescindible”, “optativo”, “para tiempos en los que sobre el dinero”.
Quizás este sea un caso más de lo que nos ha tocado (y tocará) sufrir en esta profesión las constantes comparativas con cómo se construyen casas y coches. Supongo en la industria o en arquitectura hablar de “materiales de calidad” si que (supongo) que se acerca más a “lujo”, “por encima de la media”, “comodidad”, “algo prescindible”, “optativo”, “para tiempos en los que sobre el dinero”.
Pero en software no. No, en software “calidad” es más cercano a “necesidad”, o “supervivencia”, en software no tener calidad es sinónimo de “hacer las cosas mal”, y no es sinónimo de “hacerlas de manera normal”. No “calidad software” significa software “como un churro” que luego te va a hacer gastar el doble en mantenerlo.
Es por ello que propongo eliminar las palabras “calidad software”, jamás volver a utilizarlas. Y en su lugar, sustituirlas por “no hacer software mal”.
Así, en vez de cursos de “calidad software” (que suena a “lujo”, “por encima de la media”, “comodidad”, “algo prescindible”, “optativo”, “para tiempos en los que sobre el dinero”) tendríamos cursos sobre cómo “no hacer software mal”. Entonces, habrá gente a la que no le han autorizado a ir a un curso sobre «cómo no hacer software mal”, y no habrá dinero para formar a la gente en «cómo no hacer software mal” (en vez de formarlas en «calidad software»).
Creo que la nueva acepciónes mucho más sincera y deja las cosas mucho más claras: desde ahora en vez de decir «en este momento la calidad software no es una prioridad» habría que decir «en este momento dejar de hacer software mal no es una prioridad».
Si te parece muy duro usar “no hacer software mal”, también podemos sustituir “calidad software” por “hacer software mínimamente bien”.
Así, si ahora alguien piensa que “no hay tiempo ni presupuesto para temas de calidad software”, desde este momento tendría que decir que “no hay tiempo ni presupuesto para hacer software mínimamente bien”.
En cualquier caso, por lo que a mí respecta, siempre que pueda, desde ahora voy a dejar de usar las palabras “calidad software”, sustituyéndolas por “no hacer software mal” o por “hacer software mínimamente bien”.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Javier,
¿Y qué tal si en lugar de dejarlo en un adjetivo calificativo («bien», «mal») pasamos a algo más tangible como un verbo: «acabar/finalizar el software» o «dejar sin terminar».
Nuestra labor sería la de ir introduciendo el concepto que para terminar de construir nuestro software, se necesita una tarea imprescindible (no opcional), como es el verificar su calidad.
Hacer bien o mal las cosas, es algo que depende de la voluntad de las personas / responsables.
El no terminarlas, ya tiene otras connotaciones: es entregar «Algo que no está terminado». Eso suena distinto.
Es una propuesta.
Luis,
No es mala idea… «no calidad» = «no terminado»
Gracias!
«Definition of done» 😉
No Javier, por desgracia, en la construcción y en la industria la palabra calidad no ha cambiado. Existen unas normas de calidad mínima para la construcción, y existen especificaciones de calidad para cualquier producto industrial. De hecho, existen regulaciones locales, nacionales e internacionales para la mayoría de estándares que comento. Han falseado el significado de la calidad los que han vendido software «de calidad», sabiendo que decirlo es gratis.
La gente no quiere pagar más por «casas de calidad». Pero si le dices que la casa se puede caer si no tiene una calidad mínima, se le cambia la cara. Y la casa no se cae porque seamos buenos ingenieros, ni porque haya o no calidad. No se cae porque hay regulaciones y estándares que tratan de impedirlo, y que hay que respetar.
El error principal, y perdóname si peco de presuntuoso aquí, es que entendemos que ya hacemos las cosas bien, y que «calidad» es hacer las cosas mejor. Y no es así. Calidad es saber cómo hacemos las cosas porque tenemos una vara de medir: está la calidad «mala», «buena», y los términos medios. Y hasta que no tengamos la humildad de usar esa vara de medir…y aceptar lo que veamos…no hay calidad.
Gracias por el post, Javier.
Hola Roberto,
Entendemos que ya se hacen bien, y mucha gente no entiende/acepta que se hagan mal! típico ejemplo… «si yo compro un coche no espero que me lo den con desperfectos». Pero lo nuestro no funciona así, y verlo es un tema cultural.
Saludos
Tan optativo es que en algunos sitios me he encontrado que los desarrolladores desactivan en el Eclipse los plugin de PMD,…para «codificar» más rápido y cumplir los ANS. El resultado imagínate cual és…
Ole!
Javier
No sé si estás jugando como el EVOLE o simplemente a partir de ahora lo que dices acerca de eliminar de tus argumentos técnicos la expresión “calidad del software”.
Las sentencias : “no hacer software mal” o “hacer software mínimamente bien”, son tan ambiguas que si aparecen en una petición de oferta, en un PPT, u otro documento de proyecto, alguien (a estas alturas de más de 30 años diseminando, formando, usando….en asociaciones profesionales, centros de desarrollo, compradores, universidades , ministerios ,…), va a tener serios problemas de credibilidad profesional.
“Mínimamente bien” tiene dos términos ambiguos :
– Mínimamente: ¿cual es la métrica, escala ….a utilizar para entenderse?
– Bien: ¿qué criterios se establecen para definir una métrica nominal: Bien , muy bien, mal , regular muy mal?
………..desde ahora voy a dejar de usar las palabras “calidad software”, sustituyéndolas por “no hacer software mal” o por “hacer software mínimamente bien”………….
Es una vuelta a un pasado ya lejano y no es coherente una terminología aceptada de ingeniería ni de gestión del desarrollo de productos complejos y caros.
Coloquialmente puede ser aceptado usar entre colegas o amigos tales expresiones pero no más allá.
Julio, hablas de la no precisión de las frases «hacer software mínimamente bien» o «no hacer software mal» como si «calidad software» fuera algo más claro y preciso.
El hecho es que yo he oido como el CTO de mi empresa definía al equipo de QA como el «equipo que pone palos en las ruedas para que no podamos avanzar rápido» o sea, que muy claro no parece estar quedando tampoco
Hola me ha gustado el post. Y la moraleja que encierra. Y mas allá de cambios de palabras es el cambio de paradigma o punto de vista respecto a la calidad de la que habla el post. Me gusto.
leo esto un poco tarde (algunos meses), pero después de pensarlo y ver que tienes más razón que un santo, se me ocurre proponer sustituir «calidad» por «fiabilidad». de esta manera, estás puntualizando la no-prescindibilidad del tema. se está diciendo que el listón es 10, o el software no es (con)fiable, lo que es un sinónimo de problemas.
qué os parece?
hola
Los santos no se caracterizan precisamente por sus razonamientos sino por actitudes de fé.
La propuesta de Alex es un brutal “recorte” al concepto de calidad (refiriéndonos siempre aquí solo al sw) que se ha ido consolidando en modelos conceptuales y cuya expresión más internacional y por tanto conocida y referenciada es la serie ISO 9126 y su evolución la serie actual ISO 25000/SQUARE de requisitos de calidad de producto.
Antes de estas series tuvieron una muy amplia aceptación los modelo de McCall y de Boehm de los que se derivaron multitud de variantes.
El desarrollo de cualquier ingeniería requiere cuantificación con el nivel de granularidad necesario para avanzar en el comportamiento y otros aspectos relevantes de los productos o artefactos diseñados y construidos.
Un sw fiable siempre es un atributo deseable pero insuficiente . Así un sw puede tener una fiabilidad alta pero poco eficiente y difícil de mantener.
En cualquier caso lo que hay que tener además de sentido común es un conocimiento y acuerdo interno o con los clientes para establecer los términos de entendimiento cuando utilizamos el termino de calidad y no eliminarlo como solución .
Saludos
JulioGonzález
Yo creo que se debe seguir usando el termino «Calidad en el Software» , pero agreguemos el argumento de «La calidad es gratis» porque lo que inviertas en prácticas para mejorar la calidad del software, siempre será menor que lo que tendrás que invertir en corregir los defectos que se te vayan a TEST, o más caro aun resolver defectos que se te vayan a producción.
Pues yo creo que al respecto PMBOK da una buena definición de la calidad: «Calidad es cumplir los requerimientos».
De hecho, un software en el minuto 1 de su puesta en producción puede que no contenga errores de funcionamiento (cubre sin errores las funcionalidades previstas) y que sea absolutamente horrible si lo analizas.
El problema, a mi modesto entender, es que entre los requerimientos no suelen estar (o se obvian) cosas como:
– Software sostenible (que pueda evolucionar «facilmente», con medios y en tiempo razonables, con bajo riesgo)
– Software de bajo riesgo: los cambios no implican que a más de uno se le ponga el corazón en la boca cada vez que hay una subida a producción
Saludos