Hace más de año y medio que escribí un artículo dedicado a la Crisis del Software.
Desde entonces hasta ahora no cambia un ápice mi opinión sobre este asunto y me temo que si dentro de año y medio vuelvo a tratar el tema, la situación no cambiará. Para que todo esto cambie se requiere un cambio en la mentalidad tanto las organizaciones como en los que nos dedicamos a esto y no tengo muy claro que ni unos ni otros estén muy por la labor. Esta circunstancia provoca que los pasos que se dan sean tan pequeños que consigan dejar atrás la crisis del software.
Por regla general, el software que se entrega: incumple plazos, presupuestos y expectativas.
No toda la culpa es siempre del equipo de proyecto, también tiene mucha responsabilidad el área usuaria, pero tengo la convicción de que si el proceso de desarrollo de software se realizase siguiendo unos principios de ingeniería, con personal lo suficientemente formado y consciente de la importancia de hacer sus tareas de una determinada manera, se mejorarían indudablemente los resultados.
Lo anterior debe venir acompañado necesariamente por unos presupuestos y plazos acordes a la naturaleza del proyecto. Si no son realistas no se podrán conseguir milagros por muy buenas prácticas que se sigan y por muy bueno que sea el equipo de proyecto.
Con todo lo anterior podemos decir que una situación de partida a partir de la cual existe la posibilidad de que el proyecto salga bien, es la siguiente:
procedimientos + metodología + ingeniería + equipo de proyecto formado + usuarios con dedicación y responsabilidad en el proyecto + presupuesto adecuado + plazos asumibles.
Son muchas variables, ¿verdad? Pues habría decenas más. La idea es que cuentas más se cumplan, más posibilidades hay de que la situación de partida sea buena.
¿Por qué hablo de situación de partida y no del proyecto? Pues porque lo segundo se ve muy condicionado por lo primero. Sin una buena base el proyecto se tambalea.
En el desarrollo de software, nada asegura nada y por supuesto que una situación de partida adecuada no implica el éxito en el proceso de desarrollo de software, pero por lo menos ofrece un catálogo de oportunidades mucho mayor, lo suficiente para que el número de casos de éxito crezcan paulatinamente y para que esta forma de concebir el trabajo y los proyectos vaya calando y madurando y se produzca un efecto que realimente todo el proceso y vaya dejando atrás, esa lacra que nos acompaña desde que el desarrollo de software empezó a cobrar relevancia respecto a los sistemas físicos.
