archivo

Archivos diarios: diciembre 7, 2011

Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en cascada, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.

¿Contingencias? Pues de todo.

Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos.

Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis.

¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar.

Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él.

No se trata de hacer tábula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta.

Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.