Lycka Bonita

La calidad es el conjunto de propiedades y características de un producto, servicio o proceso que le confiere su aptitud para satisfacer las necesidades establecidas o implícitas.

Una vez entregado el producto, se debe seguir dedicando recursos a la calidad para conseguir una Mejora Continua, es decir mejorando las características del producto, servicio o procesos de forma continua y con ello la percepción del cliente y su satisfacción.

La Gestión de la Calidad son las tareas encaminadas a que el producto a entregar como resultado del proyecto cumpla dichas especificaciones, así como a mejorarlas con el tiempo.

Qué bonito! Pero cómo conseguirlo ? Hay toda una batería de tareas relacionadas con calidad que deberíamos de llevar a cabo, procesos, documentación, reuniones… Pero una forma muy fácil de elevar la calidad de tu trabajo es aplicar a todo lo que hagas estos 2 principios, que retrasarán su entrega pero lo harán más duradero y fiable :

• Mantenlo simple (Keep it simple), es paradójico lo complicado que es hacer que las cosas sean y parezcan simples.
• Verifica cuando lo termines que efectivamente es correcto. Es sorprendente la gran cantidad de personasque no verifican que su trabajo es correcto, es un gran medidor de la profesionalidad.

 En este proyecto en concreto…

… como ya he comentado, la calidad no es ni alta ni es baja : simplemente ha sido inexistente en las primeras fases ya que no se han definido las propiedades a cumplir por el producto.

• Ha sido la gran sacrificada para "abaratar" el proyecto, y sin embargo como todos podéis suponer lo único que se consiguió es abaratar un poco el desarrollo y encarecer un mucho el mantenimiento.
• En mi opinión este problema ha sido ahondado por mí, suponiendo mi mayor demérito, ya que no he conseguido un producto simple ni verificado correctamente por razones ajenas a mí, pero también por errores propios.

El impacto de abandonar la calidad en las primeras fases del desarrollo se ha visto amplificado ya que como he comentado anteriormente las especificaciones del producto han sido incompletas e inestables, dando como resultado que:

• El cliente no tenga claro a dónde quiera llegar, y por tanto el equipo tampoco : se abandona el camino recto para pasar a un camino más espiral, constantemente se añade, quita y modifica código, el código no es claro ni está documentado, siendo el origen de numerosos bugs y errores, y dificultando el posterior mantenimiento.
• Se crea una diferencia entre los resultados esperados por el cliente y los resultados entregados por el equipo.
• Es imposible poder definir e implementar un juego de pruebas. Tengo que mencionar las ventajas de tener un juego de pruebas y validarlo en cada subida a test o producción? Implica dedicar un tiempo a tareas "improductivas" que no hacen avanzar el proyecto, pero a medio plazo ese tiempo y coste han sido sobradamente rentabilizados. Además soy partidario de  desarrollar primero las pruebas y luego desarrollar el negocio, ya que así se tiene más claro qué se necesita para no caer en los errores anteriormente mencionados.
• La ausencia de un diseño único e invariable : se partió de otro existente para una aplicación similar, que unido al alto grado de independencia concedido a los integrantes del equipo el resultado es una elevada heterogeneidad de diseños.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Antoine de Saint-Expury

Por qué abandonar las buenas prácticas?

Sólo hay dos respuestas posibles a esta pregunta : quieres perder dinero o aunque sabes que te va a costar más en el futuro, hoy no tienes más tiempo o dinero (cómo pedir un préstamo).

En el mundo ideal de las buenas prácticas nos deberíamos de haber levantado de la mesa, desmontado el equipo recolocando a unos y despidiendo a otros, esperar al día en que esa documentación aumentase en volumen y concreción, y si ese día llegase intentar montar otro equipo, formarlo y arrancar el proyecto bien.

En el mundo real, el cliente realmente necesitaba completar ese proyecto en el plazo estipulado por razones estratégicas y de mercado, y nosotros (empresa pequeña) no podemos permitirnos abandonar el cliente que supone un % notable de la facturación de la empresa y perder parte de los activos más importantes que tenemos : personas probadas a fuego.

Los beneficios de abandonar las buenas prácticas eran superiores que los costes para todos los involucrados, así que se tomó la opción más mundana, que debería de ser temporal hasta que dispusiésemos de tiempo (y presupuesto) para arreglar los desaguisados causados.

Consecuencias del abandono de las buenas prácticas

Con el tiempo el proyecto fue mutando hacia un monstruo descontrolado que aún hoy estamos domando, en el que hay funcionalidades entregadas sin código que las implemente, errores detectados en producción tras más de 9 meses, código que nunca se utiliza… Pero seguíamos sin ser capaces de convencer al cliente de que el proyecto necesitaba más recursos, volver a la senda de las buenas prácticas y rebajar la indefinición.

El colmo llegó al final de un desarrollo, cuando deberíamos de optar por desmontar el equipo con la problemática de encontrar más adelante tan buena gente como la que teníamos y además con los conocimientos técnicos y de negocio. En ese momento se nos pidió una ampliación de cientos de jornadas para ayer… partiendo de 14 páginas de documentación de las cuales 5 eran modelos de cartas a enviar, que por supuesto cambiaron y se hicieron multiidioma.

Y durante todo este tiempo me he sentido como un demente predicador del fin del mundo, avisando de que esta forma de trabajar no es sostenible, que entendía que las circunstancias obligaban pero que era necesario buscar un momento para parar y hacer bien lo que simplemente estábamos haciendo como podíamos…

El apocalipsis va a llegar

Y el mañana inexorablemente se convertirá en presente.

Retomando el control

Poco a poco comprendí que no había más remedio como ya comenté que ir colando tareas de calidad entre las tareas de desarrollo, desarrollar más despacio y entregar bien cada tarea para tener que hacerla únicamente una vez, quedándose en mi toda la responsabilidad y presión con la que he aguantado. 

Además quería eliminar de mis tareas los dos extremos de la cadena, requisitos+análisis+diseño por un lado y calidad por el otro, para poder dedicar más tiempo a gestión, propuestas, control… Cada uno de los dos extremos de la cadena fue asignado a una persona distinta, quienes en aras de fomentar la participación de todo el equipo y mantener una comunicación fluida y horizontal, disfrutaron de un alto nivel de libertad y autogobierno, limitando mis tareas en estas áreas a dar soporte a estas tareas.

Probablemente mi mayor error ha sido delegar la supervisión de estas tareas, nunca debí hacerlo. En su momento no tuve más remedio que confiar y aligerarme de trabajo ya que estaba siendo un cuello de botella importante. Por qué un error? Quizás era una buena idea y las personas no eran las apropiadas, quizás no supimos llevarlo a la práctica correctamente, pero los resultados no fueron los esperados, casi podríamos decir que fueron negativos. En el futuro prefiero aumentar la burocracia y poner escalones a menos que previamente me demuestren que no es necesario.

Después de un par de meses pude evaluar los resultados, y fueron decepcionantes. Sí, las incidencias (medida objetiva de la calidad del producto) bajaron sobre todo gracias al esfuerzo del equipo de desarrollo en corregir errores previos pero aún eran insostenibles e inaceptables y sobre todo no había seguridad y confianza (media subjetiva, pero basada en la experiencia) en el funcionamiento de cada nueva entrega.

Me he visto obligado a incorporar estas tareas a mi listado de responsabilidades, y cambiar de dirección es una de las cosas que más me disgustan. El resultado, he recuperado la confianza en los nuevos desarrollos (la del cliente…), no tenemos nuevas incidencias en producción desde hace un par de meses, únicamente estamos dando soporte a los gestores (que consumen más tiempo del que me imaginé) por lo cual el cliente está más tranquilo y contento, y nosotros disponemos de más tiempo para desarrollar… y para calidad

Oportunidades de mejora para el futuro

• Antes de escribir el código, se escriben las pruebas. Después de obtener la confirmación de los requisitos, obtener la confirmación de los casos de prueba por parte del cliente.

Imprescindible para el futuro

• Bajo ningún concepto abandonar la calidad, aunque el cliente lo quiera. Se puede dedicar menos tiempo, pero hay tareas innegociables como la automatización de pruebas.
• Poner límite a la gestión del proyecto por parte del cliente : los profesionales somos nosotros, y nosotros sabemos mejor cómo hacer un producto eficaz y eficiente. Si no, no nos contratarían.
• No delegar la supervisión de la etapa inicial (toma de requisitos, análisis y diseño) ni de la etapa final (calidad) de un desarrollo.

También te puede interesar:

• 04 – Revisión de Siniestros 1.0 – Calidad (2/2) Para asegurar la calidad en un producto/servicio se precisa : Una clara especificación y uso de estándares. Las buenas prácticas aquí eran conocidas pero ignoradas....
• 01 – Revisión de Siniestros 1.0 – Alcance (1/2) En todo momento del ciclo de vida de este proyecto el alcance ha sido siempre la variable más indefinida y cambiante : ha habido fases...
• 02 – Revisión de Siniestros 1.0 – Tiempo (1/2) La Gestión de los Tiempos del proyecto ha sido algo impuesto sobre todo por el cliente y el mercado, en la que nosotros como proveedores...
• 03 – Revisión de Siniestros 1.0 – Costes La Gestión de los Costes es a priori una de las más importantes, no? Trabajamos por dinero, y los clientes nos contratarán porque hacemos un...
• 07 – Revisión de Siniestros 1.0 – Comunicación La Gestión de la Comunicación es siempre complicada porque no depende enteramente de una única persona, sino de dos o más partes. En tu mano...