archivo

Archivos diarios: julio 13, 2012

El peligro de la implantación de una gestión orientada a procesos en los proyectos de desarrollo de software es que una vez que se supera la barrera de su adopción (al principio siempre suele haber quejas ya que se pasa de un margen de maniobra importante a la hora de afrontar los proyectos a estar sujeto a unas serie de reglas y procedimientos que pueden ser más o menos rígidas) se corre el riesgo de caer en la comodidad que proporcionan.

¿Cómodo un proceso?, ¿cuándo?. No me refiero a su seguimiento, que requiere una cierta disciplina hasta que con el tiempo ya se considera algo natural, sino a lo tentador que resulta centrarse en el cumplimiento de los diferentes hitos del proceso en lugar de en el objetivo final: un producto que satisfaga las expectativas de los usuarios.

¿Qué es centrarse en los hitos? Limitarse a cubrir el expediente cumpliendo con todos los entregables que tiene el proceso, de esta forma siempre podrá utilizarse la excusa (que podrá ser más efectiva o no) de que el trabajo se ha hecho, otra cosa es que el proyecto haya salido mal.

Esconderse tras el proceso y sus hitos es muy tentador y la gestión orientada a procesos te lo pone en bandeja. No quiero decir que esto tenga que ser así pero sí que es una puerta que está ahí y como tal, más pronto que tarde, pocos o muchos terminarán traspasando.

¿Qué fáctores hacen que más o menos personas traspasen esa línea roja? Pues el hecho de que los directores o responsables de establecer las políticas de desarrollo den más importancia a los procesos de lo que realmente la tienen, creyendo ciegamente en que el seguimiento de los procesos lleva al éxito. Esto en otras industrias funciona, en el desarrollo de software no necesariamente porque independientemente de que se haya acertado en la definición de procesos después hay que saberlo ejecutar bien y el hecho de cumplir con los hitos no quiere decir que dichos hitos se hayan realizado correctamente.