¿Se puede recuperar un proyecto de ingeniería de software con problemas de planeación?

Ingeniería del Software II

Ensayo – Jesús Andrés Infante Páez

¿Se puede recuperar un proyecto de ingeniería de software con problemas de planeación?

¿Cómo salvar un proyecto de software y no morir en el intento?

Un proyecto de software al igual que cualquier otro proyecto enfocado en otra área corre el riesgo de presentar fallos determinantes a la hora de evaluar su correcto funcionamiento y por su puesto su viabilidad y fiabilidad en etapas finales o aun cuando se considere este terminado podrían no ser las esperadas y por lo tanto llegar a considerar el proyecto mal ejecutado, mal planeado y en percepción del cliente una mala inversión. Continuando con lo anterior se pueden añadir factores comunes entre proyectos de software que pueden causar fallas técnicas, retrasos en entregas y por su puesto costos fuera del presupuesto inicial, estos factores normalmente están relacionados con intentos fracasados con anterioridad, falta de gestión, planificación, productos defectuosos, perdida de los objetivos, mal ambiente laboral y/o pérdida de confianza del cliente hacia el equipo de desarrollo. Peores casos se presentan si mas de uno de estos factores se alinean simultáneamente pues llegaría el caso tal que no se podrían manejar todos al mismo tiempo y el proyecto entraría en una decadencia y finalmente en una pérdida total. “Para salvar un proyecto que se encuentra en problemas, unas pequeñas modificaciones no bastarán. Se necesita tomar una fuerte acción de corrección”. (McConell, 1997).

Asimismo es lógico pensar que para los jefes de proyectos este es un tema que no se puede tomar a la ligera pues el estudio de posibles fallos del proyecto debe estar como prioridad si lo que se necesita es cumplir con la planeación previamente acordada entre el equipo de trabajo y el cliente, por lo tanto si una planeación está mal estructurada o inalcanzable para los desarrolladores lo primero que se pensara es como conseguir terminar de la manera más rápida el proyecto, tomando caminos arriesgados, poco aconsejables y alejándose probablemente de los problemas reales que se llegaron o pueden llegar a presentar a raíz de este pensamiento, presentando una falta de control adecuado que no permitiría el éxito del software. Pero no todo estará perdido se debe generar la idea de que es el momento de redefinir el proyecto, estructurar de una mejor manera la planeación, evitar caer en los mismos errores y llevar a cabo un plan de recuperación pensado a partir de las personas, el proceso, el producto y las necesidades específicas del proyecto.

En primer lugar, se debe establecer que un plan de recuperación puede ser victorioso siempre y cuando se sigan una serie de pasos estructurados que permitan además de estudiar los fallos, conseguir soluciones rápidas que sin duda pueden llegar a incrementar la productividad del proceso. Por consiguiente (McConell, 1997)  propone que en este plan de recuperación se debe buscar, “Omitir unas cuantas prestaciones, aumentar la productividad como pueda y retrasar la planificación lo que sea necesario”. De tal modo que para atacar el problema la base del plan serán los resultados de los primeros pasos que de el jefe de proyecto, iniciando con una evaluación de la situación que determine qué tan crítica es esta, y a partir de la participación del equipo desarrollador y el cliente estudiar su verdadera viabilidad después de un plazo de entrega vencido, pues no es lo mismo un cliente que esté dispuesto a seguir con el proyecto hasta sus ultimas instancias que un cliente que probablemente no quiera seguir invirtiendo dinero ni tiempo y simplemente el proyecto muera en el momento que no se entregó en el tiempo estipulado. O por ejemplo al estudiar el caso que los que no quieran continuar con el proyecto sea el equipo desarrollador al no estar de acuerdo con las nuevas medidas tomadas a partir del fracaso de este o no estén dispuestos a generar cambios significativos para la evaluación del proyecto se debe llegar a la conclusión que ningún plan de recuperación será factible y el proyecto ha llegado a su fin, aunque no sea el esperado. Así pues al hacer un estudio detallado de las problemáticas del proyecto y su posible continuidad se debe ser realista y explicar correctamente el plan  al resto del equipo respondiendo todas las dudas y evitar dar una fecha exacta de la próxima entrega, además incluir al cliente y al equipo administrativo en la divulgación de los detalles para cumplir la meta, pues su opinión es importante y hay que recordar que un cliente satisfecho con el proceso podría incluso llegar a aceptar nuevos retrasos en la entrega, aunque claro está que lo ideal es no llegar a exceder el tiempo estimado de esta.

Tres de los factores mas importantes a la hora de llevar a cabo un plan de recuperación son; el personal que está trabajando en el desarrollo, pues son los programadores, analistas, cliente, administración y demás involucrados los que influyen en una construcción eficaz y eficiente del proyecto. El proceso, pues ayuda a identificar errores y corregirlos además de generar una planeación adecuada a partir de hitos que seguramente ayudaran a recuperar el proyecto. Y como tercer factor se podría considerar el producto, pues qué seria del proyecto sin tener una idea clara de lo que se quiere llegar a conseguir, también cabe resaltar que un estudio de lo que se ha logrado, se quiere lograr y como ha sido desarrollado el producto ayuda a establecer y reforzar los requerimientos iniciales y si se da el caso adaptar adecuadamente las actividades planeadas con el fin de mantener el producto en un estado de alta calidad y fiabilidad.

Retomando lo anterior e incluyendo en el plan de recuperación el personal, se deben tener en cuenta detalles que tal vez afectaron el éxito del proyecto, se debe generar un ambiente donde se proponga recuperar la moral del equipo e incentivarlos a seguir adelante, si es necesario aplicar nuevas normas de trabajo que sean mas flexibles evitando por ejemplo un cansancio emocional o a causa del estrés que seguramente llevaran al personal del equipo a renunciar tarde o temprano, es decir una moral alta entre los miembros del equipo podría determinar la  eficacia y calidad de su trabajo pero además una continuación exitosa del proyecto,  “Hay que asegurarse de que se están proporcionando al equipo factores de higiene. Elimine la presión excesiva en la planificación, las malas condiciones de trabajo, la manipulación por parte de la directiva, y otros destructores de la moral.” (McConell, 1997). Por otra parte, si es estrictamente necesario se podría pensar en aumentar el numero personal siempre y cuando los nuevos integrantes no interfieran en las actividades propias de los desarrolladores o personal que ya cuenta con un ritmo de trabajo claro y adecuado para el nivel de avance del proyecto. Por ejemplo, para un programador puede ser difícil y tedioso explicar su lógica y diseño del software al nuevo personal causando nuevos retrasos y posibles errores de compilación si no se cuenta con el conocimiento y habilidad adecuada para entender cómo se está desarrollando el software.