La calidad es esa parte del proyecto que muchas veces sufre, sobretodo cuando las fechas aprietan y el alcance no está claro. Hoy en día el perfil del Quality Assurance está de moda, sin embargo, seguimos viendo equipos que renuncian a la calidad para finalizar su proyecto.

¿Por qué no le damos importancia a la calidad?

Si vemos el famoso triángulo de hierro, la calidad ocupa el corazón del mismo.  Siempre decimos que de los cuatro parámetros la calidad no debería variar y que habría que jugar con los otros tres. Sin embargo, la realidad que nos encontramos es que trabajos en proyectos. Esto quiere decir que al final, lo que importa es el alcance y el tiempo, y la calidad pasa a un segundo plano.
Entonces aparece la frase: “Pero a la larga será más costoso”. Es cierto, a largo plazo todos sabemos que introducir un cambio en un software es costoso si acumulas deuda técnica y código deficiente.
No obstante ¿Para quién es costoso?

  • ¿Para el call center que lo fríen a llamadas? Pero eso no es problema del Jefe de Proyectos sino del responsable del call center.
  • ¿Para el equipo de mantenimiento? No es mi problema, el Jefe De Proyectos se centra en el coste del desarrollo.
  • ¿Para los próximos evolutivos? Puede ser, pero aquí aparece la manida frase “vamos a llegar a la fecha y luego ya veremos”.

Al final, con la mentalidad de proyecto te miden por la fecha y es en lo que vas a poner el foco. La mentalidad de proyecto nos lleva a que solo importe el alcance y el tiempo.

Además, he visto que muchas personas confunden calidad con cantidad. Creen que un software con calidad es aquel que contiene muchas funcionalidades, cuando puede ser incluso lo contrario. He visto a pocas empresas de mi entorno entender que quitar funcionalidad puede mejorar tu software.

Como dice Tobías Mayer, en un proyecto con una visión cortoplacista olvida la calidad, no aporta. La calidad no tiene sentido al no ser productiva. Cuando tenemos “poco” código las pruebas manuales no son tan costosas y los cambios no son tan complicados de introducir.

El final de todo esto es que, la deuda técnica se dispara, el código se enmaraña, y cuando los evolutivos o la fase 2, 3 o la que sea aparece… ¡Todo empieza a fallar! El final ya lo conocemos, un tiempo después acabamos por hacer otro proyecto para sustituir al actual y volvemos a cometer los mismos errores.

¿Cómo arreglamos esto?

La única manera de solucionar esto es tener la mentalidad de producto. Un producto sigue una estrategia, es largoplacista, la calidad importa porque conseguir desarrollar un software pronto pero no mantenible hace que el valor del producto se desmorone. Cada nueva funcionalidad debe de garantizar que deja sostenible el sistema.

No solo se ahorran costes de futuros evolutivos, ganamos en disminución de bugs, que en este caso es más importante porque al ser estratégico tenemos que retener usuarios y esto los espanta. También ahorramos costes cuando se incorporan nuevos desarrolladores al equipo. Una vez trabajé para una empresa de supermercados con unos criterios de calidad muy elevados. Cuando llegué, desarrollé una funcionalidad y rápidamente el sonar y el jenkins me avisaron de que había roto otras, lo que evitó un problema. ¡Gracias a que se invirtió en calidad!

Creo que todas las personas que hemos desarrollado software valoramos la calidad, pero abramos los ojos. Si estamos haciendo un proyecto, la calidad será la que de tiempo porque el alcance y la fecha mandan. Los desarrolladores valoramos la calidad pero también valoramos el irnos a nuestra hora y no tener que estar con la “lengua fuera” para llegar a una fecha. Nuestro sector necesita un cambio cultural orientado a producto y entonces la calidad tendrá un papel más relevante.  

Entradas relacionadas

Steve Kerr el Coach de la NBA

Steve Kerr el Coach de la NBA
0 (0)

Una de mis pasiones, además del mundo Agile, es el deporte en general. Y dentro del deporte, uno de los ...
¿Por qué la transformación no me funciona?

¿Por qué la transformación no me funciona?
5 (2)

¿Llevas tiempo inmerso en una transformación y no ves mejoras? ¿Lo has intentado todo has pasado por Scrum, Kanban, Safe, ...
¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar