La imagen del desarrollo de software
Nuestra profesión, por lo menos desde que yo me dedico a esto, no pasa por sus mejores momentos y me temo que esto viene de mucho más atrás, ya que el concepto de crisis del software, plenamente vigente en nuestros días (en mi opinión) no surgió por casualidad sino como consecuencia de los continuos fracasos en los proyectos de desarrollo de software.
El fracaso no es que no se llegue a terminar un producto, fracaso también es que una vez implementado no lo consigas implantar, que te cueste más del doble de lo que debería, que cada año sea una sangría económica mantenerlo, que en lugar de ayudar suponga un obstáculo para el proceso o procesos que automatiza.
Estos hechos, que son incontestables, han mermado nuestro prestigio. ¿Cuántas veces nos hemos preguntado por qué otras empresas de servicios cobran esas tarifas y las nuestras otras que están muy por debajo? La calidad media de los trabajos que se realizan tiene mucho que ver.
La calidad no solo llega a través del método, si bien los resultados finales están muy condicionados por la opción que se elija. La calidad se consigue realmente a través del equilibrio entre la metodología, el presupuesto, los plazos y las personas (desarrolladores, usuarios y los jefes de ambos).
La voracidad por conseguir contratos destroza los precios y eso no es gratis ya que afectará directamente a la calidad de los trabajos ya que se podrá producir cualquiera de estos factores (o la suma de muchos de ellos):
– Asignación de personal que no está lo suficientemente cualificado o que no tiene la suficiente experiencia.
– Overtime. Todos podemos aguantar picos de trabajo, pero muy pocos pueden aguantar cargas de trabajo elevadas durante mucho tiempo sin que se vea mermada la calidad de la ejecución de sus trabajos (al final, cuando se ve todo muy oscuro, solo importa terminar sea como sea, por muy buena intención que se tenga).
– Desgaste en las relaciones, dentro del propio equipo de proyecto, de estos con sus jefes, del equipo de desarrollo con el cliente, del responsable técnico del cliente con los usuarios.
– Se reduce o desaparece la revisión técnica y funcional de los trabajos.
– Reducción del alcance del proyecto.
Esta es solo una muestra de situaciones que pueden pasar. Si el proyecto se convierte en un Death March Project (que es lo más probable cuando se oferta fuera de mercado), nos encontraremos con muchísimas de ellas llevadas incluso a situaciones bastante extremas.
El problema de todo esto es que ocurre con más frecuencia de lo que debiera.
La solución a todo esto es complicada ya que pasa por un cambio en la mentalidad del sector y para que eso ocurra habría que adherirse y cumplir un manifiesto (o una guía de estilo o cualquiera que sea la forma que adopte el acuerdo) donde las organizaciones que se dedican a esto respeten una serie de reglas encaminadas a garantizar unos umbrales mínimos exigibles de calidad en los diferentes trabajos que se realicen.
Esto puede resultar utópico, pero cada vez somos más los profesionales que no aguantamos más esta situación. Esto ha dado lugar a diferentes movimientos en el ámbito de enfoque del trabajo y las relaciones como ha sido el manifiesto ágil y la consolidación de todo su juego de metodologías y en el propio concepto de empresa donde no solo importa el factor económico, sino que cobra mucha importancia el grado de satisfacción por el trabajo que se realiza.
Jummp 