Desarrollo de software. Cuando el proceso se convierte en fin

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.

Anuncios
1 comentario
  1. Es curioso como se considera y se evalua la “calidad” por la mera existencia de documentos, y salvo que estemos hablando de miles de diagramas UML no veo como esos maravillosos documentos aseguren un buen software, o mejor dicho el problema es que algunos lo crean asi (aunque mi impresion es que la creencia tiene poco que ver con software), pongo como excepcion el UML pero tendria que estar a tal nivel de detalle que rozaria la estupidez (y no, no me creo lo del MDA), una cosa buena del agilismo es que viene a decir “no te enganyes”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: