Complejidad Ciclomática

Si hoy tuviera que volver a realizar el proyecto fin de carrera y con la experiencia de casi 2 años en el sector TIC, estudiaría más a fondo la gestión de proyectos informáticos.

Todas las etapas de gestión en este tipo de proyectos son muy complejas por motivos que comentaré en próximos post - espero-. Pero en este me voy a centrar en la etapa inicial; donde  se estima el alcance del proyecto para realizar un presupuesto.

En el entorno en el que me muevo, la cosa va de la siguiente forma: un gerente y un comercial se reunen una hora con el posible cliente y no tengo muy claro de lo que hablan. Tras la reunión se genera un documento con cajas que representan módulos del sistema y se pasa la oferta - que en el mejor de los casos se ha aplicado un porcentaje de riesgo-.El cliente acepta.Todos contentos ¿Qué sucede después? Tras la generalmente escasa etapa de análisis, se determina que el proyecto tiene un 50% de horas más de lo presupuestado. ¿Cómo se resuelve?  El personal haciendo horas extras y el sistema con un recorte funcional tremendo.

La alternativa ideal, en mi opiníon, sería realizar un análisis (cobrado al cliente) y con él realizar la estimación de diseño, implementación, pruebas etc.. Lamentablemente, los clientes en mi entorno no están preparados para que se les cobre un análisis del que van a obtener un documento. (Aunque haciéndolo así se reduce treméndamente la incertidumbre en el desarrollo).

La solución intermedia sería realizar 2 o 3 reuniones con presencia de personal técnico. De esta manera se alcanzaría una solución de compromiso. El coste de las reuniones se incluiría en el presupuesto.

Algún lector tiene alternativas para solucionar la problematica de la estimación de los proyectos informáticos (cuando no puede existir un análisis previo).

NOTA: He re-leido el post y creo que lo voy a re escribir este fin de semana. Las 1.34 pm no es buena hora.