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?.

20 comentarios sobre “En el software, la calidad, no es opcional”

  1. Hace unos dias comentabamos esto mismo con unos compañeros de trabajo y yo les dije q me parecia q algo ha cambiado en el mercado de la informatica. Ahora podemos encontrarnos con clientes que exigen calidad en el producto final que se les entrega, pero lo mejor de esto es que entienden el coste de la calidad.

    A donde voy, usualmente cuando alguien deseaba una solucion, entre las opciones que ofrecia el mercado, siempre estaban las «mas baratas» q (aunq no lo admitian) sacrificaban calidad en la entrega, al disminuir los recursos con los q trabajaban. Afortunadamente, ahora podemos encontrar casos (como en el q m encuentro ahora) donde nuestro interlocutor nos exige mucho, pero conoce el coste de esta exigencia.

    Porq me gusta esto? creo que la respuesta es obvia. Aunque es una pena, que algunas personas entreguemos productos de calidad solo porq está en nuestra forma de ser, cuando poseemos todas las herramientas para lograr este resultado.

    Lindo post, me ha hecho hablar un rato con algunos compañeros que trabajan en esas grandes multinacionales, que poseen cuartos llenos de certificaciones, pero q no conocen el concepto de calidad en el producto final.

    Saludos

  2. Aupa Bruno!!!

    Me alegro de que mi post haya fomentado que hables con tus compañeros sobre calidad del software. A menudo imparto cursos sobre Gestión de Proyectos de Software y creo que es uno de los temas en los que la gente tiene las ideas más equivocadas. Es un tema que seguiré tratando regularmente en mi blog.

  3. Lo que a mi modo de ver es brillante, es la estrecha relación que existe entre el coste y la calidad.
    Esta frase la enmarco:
    «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.»
    ¡Cuantas veces he discutido yo de esto mismo en algunas de las empresas en las que he trabajado!
    Pero… claro… cuando uno no lo quiere ver ni entender…

  4. Si Jorge, el problema es claro, en todas las industrias excepto en el software la calidad encarece el producto. Es dificil que gestores que no han crecido como tales en el mundo del software vean esta ‘paradoja’.

    A mi me gusta resumirlo con la siguiente frase: «La manera más rápida y económica de desarrollar software es hacerlo bien».

    Lo curioso es que toda la bibliografía sobre Gestión de Proyectos de Software y Calidad del Software esta llena de estudios que respaldan esta máxima. Creo que mientras quien este al mando de las empresas de desarrollo no hayan sido previamente desarrolladores la situación no cambiará. Construir software es algo radicalmente diferente a construir cualquier otro producto, pero los gestores ser resisten a verlo. Por eso seguimos sufriendo intentos fallidos de formalizar el desarrollo de software, como RUP o CMMI, sin dejar parcela a la creatividad. Se tiende al olvidar que desarrollar software es esencialmente ‘diseño’ y no ‘construcción’. Cada línea de código que escribe un desarrollador en una decisión de diseño.

  5. ¡Sensacional una vez más Rodrigo! 🙂
    Creo que al hilo, voy a escribir un comentario en mi blog sobre la Calidad [Arquitectura], algo que también me encanta. 🙂

  6. estoy total acuerdo, en la empresa donde prestada asesoría para desarrollar un software, me dieron el tiempo para planear todo, todo iba bien, una buena arquitectura, patrones de diseño claro y definido; cuando todo se empieza a caminar y comienzo a desarrollar el aplicativo, me cuenta al mes que tienen la obligación de terminar el software el 1 enero de este año. QUE BARBARIDAD!!!!!!, un software en dos meses???, ese el problema de un jefe que no sabe de software…y lo más triste es que le presto asesoría MEDIO-TIEMPO.
    La crisis de software se dá en dos puntos:
    -el programador conformista(nunca se pregunta como optimizar o mejorar lo que hace, solo si funciona, dejemoslo así).
    -el jefe que sabe más chatear que de arquitectura de software.

    Saludos de COLOMBIA.

    p.d: este es el blog que más frecuento, excelente.
    p.d2: lo del problema mencionado arriba, tocó(obligatorio) quitarle las buenas arquitecturas, aunque se aplicaba el desarrollo más rápido, en dos meses no era lo mejor, si hubiese más tiempo, la paradoja que menciona es aplicable, siempre que sean más de 4 meses, ya que uno gasta los primeros meses en la arquitectura.

  7. Justo buscando sobre calidad de software una materia que tengo y me parece muy bueno su articulo pero me gustaria saber como medir la calidad del software , estoy utilizando la metrica 9126 .Si ud. posee algunos ejemplos me gustaria que los compatiera aqui mi correo:
    wilfolightfire18@hotmail.com

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *