¿Por qué fracasan los proyectos? Fase I: Captura de requisitos

En este post quería analizar los principales puntos que a mi entender son claves en el fracaso de un proyecto. En esta primera entrada quería centrarme en los fallos que se cometen en la primera fase del proyecto: La captura de requisitos y el análisis.  Los fallos cometidos durante esta fase serán los fallos más graves porque serán arrastrados hasta el último día del proyecto y durante toda la vida útil del software por eso es la fase más importante del proyecto.

Desde mi punto de vista estos son los fallos más comunes:

1.- Análisis de requisitos insuficientes.

Para poder terminar un proyecto es necesario recopilar los requisitos funcionales de éste, si esta captura no se realiza formalmente durante esta primera fase tendrá que hacerse durante la fase de diseño o peor aún durante la fase de desarrollo. Ya hay un término que describe esto: IKIWISI (I’ll know it when i see it). El cliente no sabe lo que quiere o no se le involucró lo suficiente durante la captura de requisitos, y las consecuencias son que el cliente querrá cambiar o añadir nuevos requisitos cuando vea el trabajo ya finalizado, es decir, al final de la fase de desarrollo.

Si la gestión del proyecto se basa en esta anti-metodología IKIWISI del prueba-error será imposible que el proyecto no se retrase y se multipliquen los costes. Si comparamos este proyecto software con un proyecto más simple, por ejemplo, pintar una habitación, en esta anti-metodología el pintor empezaría a pintar la habitación sin que el cliente se involucrase en la decisión de elegir el color. Cuando el pintor haya terminado de pintar 3 paredes en azul se las enseñaría al cliente, y este opinará que el color es muy frío,  preferiría uno más cálido, ahora el pintor si quiere contentar al cliente tendrá que lijar las 3 paredes y decide pintarlas de rojo, cuando ya están terminadas se las enseña de nuevo al cliente, pero por desgracia el rojo le parece demasiado cálido. Después de varios días de tensión porque se multiplican los costes y se retrasa el proyecto, acuerdan pintar la habitación en naranja y cerrar el proyecto. Después de una semana de retraso,  el pintor termina las cuatro paredes en naranja y el cliente por fin está medio contento. Es lo que al final quería, pero tras un retraso considerable, y unos costes que se multiplicaron por 3. Si se hubiese realizado adecuadamente la captura de requisitos, ambos se hubieran ahorrado los retrasos y los sobrecostes.

2.-Cambios frecuentes en los requisitos.

Al no haber un documento  funcional donde se describa lo que se acordó, el cliente tiene total libertad para cambiar los requisitos a su libre albedrío y cuantas veces quiera. Si hubiese un documento formal donde se describan los requisitos sería mucho más fácil para el jefe de proyecto oponerse a estos cambios, si no tiene nada, al final acabará cediendo a todos los cambios y nuevos requisitos porque no tiene a qué agarrarse.

3.-Planificación no realista.

Incluso teniendo en cuenta el mejor de los casos, donde hay un análisis de requisitos bien documentado, no se suelen tener en cuenta muchas series de factores que van a influir seguramente en la planificación. Estos factores pueden ser: vacaciones del personal, fiestas, posibles bajas, posibles inclemencias del tiempo, fallos técnicos, etc…

Para contrarrestar estos imprevistos los jefes de proyecto pueden añadir más presión al equipo de programadores, pero esto será sólo un parche y no conseguirá hacer mejor software mediante esta estrategia, aparte de otros muchos inconvenientes que pueda tener. Los programadores bajo presión trabajan más rápido, pero no trabajan mejor.

“People under time pressure don’t work better; they Just work faster.”

Tom DeMarco & Timothy Lister.

Referencias:

http://www.joelonsoftware.com/articles/fog0000000036.html

http://www.joelonsoftware.com/articles/PickingShipDate.html

https://garciagonzalezdavid.wordpress.com/2008/08/12/the-art-of-project-management/

https://garciagonzalezdavid.wordpress.com/2006/10/31/peopleware-productive-projects-and-teams/

http://es.wikipedia.org/wiki/The_Mythical_Man-Month

Anuncios
Esta entrada fue publicada en Gestión y etiquetada . Guarda el enlace permanente.

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