Paso a producción, implantación. La importancia de entregar software de calidad

Entregar por entregar una versión de un producto es algo que desgraciadamente estamos muy habituados a ver.

La entrega de software de baja calidad tiene consecuencias negativas, muchas más que si no hubieras entregado el producto a tiempo (por regla general):

– Cuando se entrega un software y se rechaza no solo estás perdiendo tiempo y dinero tú, sino también el cliente.

– Cuando se entrega un software con un elevado número de errores se incrementa la probabilidad de que alguno de ellos y de importancia llegue a producción, lo que puede provocar la liberación de un nuevo parche o de una serie de parches. Con eso también pierde dinero el cliente (mucho más ya que ha podido dejar bloqueado total o parcialmente un proceso, lo que ha provocado que una serie de trabajadores estén por debajo de su rendimiento habitual) y también lo perderás tú.

– Cuando se entrega un software con una deuda técnica alta estás condicionando su evolución, aquí también pierde dinero el cliente por el coste extra que tendrán las tareas de mantenimiento y por los posibles efectos colaterales que provoquen las nuevas versiones (si el software se encuentra muy acoplado y el testing no es suficiente) y también lo perderás tú, sobre todo si trabajas en proyectos a coste fijo.

Entregar software a la ligera por el simple hecho de cumplir una fecha o por pensar que no pasa nada, que ya se corregirán los defectos hace mucho daño, no solo al proyecto, ya que cuando se generalizan esas prácticas también se hace mucho daño a la profesión. Si queremos mejorar nuestras condiciones y la percepción que terceros tienen de nosotros necesitamos que no se nos vea como chapuceros.

Anuncios
4 comentarios
  1. Germán dijo:

    Estoy de acuerdo en lo que comentas pero pienso que hay que realizar algunas apreciaciones importantes.

    1) ¿Que es software de calidad?. ¿Aquel que funciona? ¿Aquel que está muy documentado?

    2) ¿Cuanto tiempo tarda una organización en saber que su software no es de calidad?

    Es decir, combinando las preguntas anteriores y yéndonos a los casos extremos:

    1) Podemos tener software funcionando que no es de calidad y ni siquiera saberlo.
    2) Podemos tener software de gran calidad que no funcione por cuestiones de configuración y creer que nuestro software no es de calidad porque no funciona.

    Para ello algunas organizaciones incluyen una Oficina de Calidad, pero claro no todas tienen estos conceptos claros ni todas son bien dirigidas hacia estos conceptos.

    • jummp dijo:

      No hay una definición válida para todo el mundo de lo que es software de calidad porque cada cual tiene en su cabeza una definición distinta, por ese motivo cuesta tanto ponerse de acuerdo sobre cómo gestionar la calidad y cómo medirla.

      Yo te doy la mía, que alguna que otra vez ya he puesto en algún artículo, si bien no te aseguro que dentro de unos meses la matice o tenga un enfoque totalmente distinto, como sabes, en el desarrollo de software no paras de aprender y de encontrarte nuevos contextos, conceptos y personas que te hacen replantearte parte del background que utilizas a la hora de gestionar o enfocar un proyecto de desarrollo de software.

      Para mi la calidad supone satisfacer las expectativas del usuario (hablo de expectativas no de requisitos ya que las expectativas van mucho más allá) siempre y cuando el producto sea mantenible (con una deuda técnica acorde a las características del producto), robusto, seguro y tenga un consumo de recursos acorde también a las características del producto. ¿Valen todas estas variables lo mismo? No. ¿Valen todas estas variables siempre lo mismo? No, depende del tipo de proyecto y su contexto.

      Como ves no hago referencias a aspectos metodológicos porque la metodología o los procesos son instrumentos al servicio del proyecto, del producto y de la organización. No digo que no crea en las metodologías y los procesos, sí creo en ellos pero como un background que permita armonizar los desarrollos en una organización pero lo suficientemente flexible como para admitir excepciones (motivadas) y adaptarlo a las necesidades del proyecto en el que estoy trabajando y su contexto actual.

      También hay un matiz interesante que dejo en el aire: Supongamos que un producto es de calidad, ¿es por ello el proyecto un éxito?.

      • jummp dijo:

        Una pequeña matización, ¿qué papel desempeña la documentación en todo esto? Como he comentado he indicado que el producto sea mantenible y lo he ligado sobre todo a la deuda técnica, pero no es solo eso.

        A veces para poder mantener o seguir desarrollando(porque, ¿dónde está realmente la frontera entre el mantenimiento y el desarrollo cuando estamos aplicando una aproximación iterativa e incremental en el proceso de desarrollo? un producto es conveniente disponer de cierta documentación, ¿qué documentación? la que requiera el producto y el contexto del proyecto. En unos casos será más y en otros casos menos.

        Por otro lado, como indico que también creo en la existencia de un background de procesos también creo que se debe respetar la documentación que determine el proceso siempre y cuando sea proporcional a las características del proyecto y del producto y aporte valor.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: