archivo

Archivos diarios: diciembre 1, 2011

Trabajamos en muchas ocasiones bajo planificaciones imposibles ya sea porque desde el principio la batalla estaba perdida o porque el propio devenir del proyecto ha dado lugar a situaciones que han provocado que la planificación inicial ya no sirva y quienes tienen poder de decisión no han querido o podido cambiarla.

Es decir, se puede partir de situaciones de alto riesgo de que no se cumpla la planificación o que estas situaciones sean sobrevenidas por contingencias en el proceso de desarrollo.

Debemos tener en cuenta que los proyectos presentan esa incertidumbre y que antes de que nos demos cuenta lo que parecía que estaba controlado, deja de estarlo. En esos momentos es cuando nos acordamos de los días de trabajo perdidos, ya sea por tareas que eran prescindibles, por decisiones equivocadas, porque tuvimos un mal día o porque se cayeron los servidores. Da igual la causa, los recordaremos.

En general es una mala política dejar los esfuerzos para el final, en el desarrollo de software es nefasto, por eso es fundamental mantener una regularidad en la productividad del equipo de trabajo e ir cumpliendo en lo posible los hitos establecidos.

Y es que los días perdidos no vuelven, ya lo dicen Tom DeMarco y Tim Lister en la siguiente reflexión: “Hay millones de maneras de perder un día de trabajo pero ninguna que te lo devuelva”.

Timothy R. Lister lleva en el negocio casi cuarenta años, cuando comenzó como programador en lenguaje ensamblador allá por el año 1972, más tarde, el año 1982, fundó junto a Tom DeMarco y otros profesionales la consultora The Atlantic Systems Guild, la cual sigue en funcionamiento en la actualidad. Y es en el sector de la consultoría, las conferencias y las publicaciones sobre la gestión de proyectos y la gestión del riesgo donde ha centrado la línea principal de su actividad.

La definición que realiza de gestión del riesgo en el proceso de desarrollo de sofware, me parece muy próxima a la realidad, según Tim Lister: “la gestión del riesgo es el proceso de desenterrar la incertidumbre y el riesgo en los proyectos, para ello se pregunta cuáles son las posibles consecuencias no deseadas de un evento o de una decisión. La esencia de la gestión de riesgos en el software es ayudarnos a decidir si tratamos con los problemas antes de que aparezcan o si esperamos hasta que claramente salgan a la luz y entonces tratarlos mediante una gestión de problemas”.

El único inconveniente que le puedo poner a la definición es la utilización de la palabra desenterrar, personalmente, hubiera considerado más adecuada, minimizar las consecuencias, minimizar el impacto o simplemente reducir la incertidumbre y riesgo en los proyectos.

De igual forma que la gestión de expectativas se me antoja esencial (de hecho es un riesgo y serio, no tenerla en consideración o no realizarse de manera adecuada), también resulta muy importante la gestión del riesgo, ya que si se producen aquellos que se consideran críticos, probablemente se ponga en riesgo y de manera sensible el éxito del proyecto.

La gestión del riesgo debe ser algo vivo, ya que las circunstancias de riesgo pueden variar a lo largo del proyecto, su impacto y la forma de anticiparnos a ellos o de reducir su impacto.

La comunicación y la información resulta fundamental en este tipo de gestión, de manera que todas las partes sepan cuáles son los riesgos que existen en cada momento, cuáles son sus consecuencias y qué actuaciones se realizan o hay que realizar frente a cada uno de ellos.