La importancia de las etapas tempranas del proceso de desarrollo

"Los sistemas deben servir a las necesidades de negocio para las cuales fueron requeridos y el subordinar el método de implantación y desarrollo a una necesidad de planificación presupuestaria en el origen, es un error"


Durante años de consultoría tecnológica y desarrollo de sistemas, me ha correspondido asesorar clientes que permanentemente se quejan de los retrasos de los proyectos desoftware y de problemas de calidad. El mercado está lleno de historias de terror y los dardos siempre apuntan a uno u otro proveedor o a las áreas de sistemas de las organizaciones en forma indistinta.

Dado que los problemas normalmente se detectan en etapas finales de prueba o en los pasos a producción, el efecto halo hace que el análisis post-mortem apunte a la mala codificación, a lainexperiencia de los programadores o a su desconocimiento de negocio como causa de los retrasos y de la calidad, pero ¿Es esto correcto? ¿Es posible encontrar la causa en algún otro punto que permita tomar acciones correctivas a tiempo?

Los esfuerzos en esta línea han ido a fortalecer la gestión, incorporando oficinas de gestión de proyecto (PMO) y estándares como PMI, ISO9000, ITIL o CMMi. Muchas deesas iniciativas apuntan en la dirección correcta, pero nuevamente una pregunta ¿Es posible que un proyecto mal concebido en su estructura y metodología, llegue a buen puerto solo fortaleciendo la gestión? La respuesta parece bastante inmediata, sin embargo siendo la respuesta tan obvia, este tema continúa siendo una asignatura pendiente.

¿Cuáles son la soluciones estándares ante los problemas?• Incorporar más gente en el momento de la crisis: Esto si bien es tranquilizador desde el punto de vista del cliente final, trae aparejado otros problemas: curvas de aprendizaje y problemas de gestión, lo cual muchas veces hace que el retraso sea aún mayor y la calidad se deteriore aún más.
• Acelerar el inicio de la codificación: También esto da una sensación de tranquilidad inicial, peropuedo asegurar que mientras antes parte el código, más se demora en terminar.

¿Cuáles son las soluciones que se deberían ocupar?

Acá no hay muchas novedades, pero como dice el adagio popular “hay cosas que por sabidas se callan y por calladas se olvidan”.

Cuando se llega a la codificación del software, prácticamente todo el trabajo creativo debería estar realizado. Un error en estasetapas tempranas previas a la codificación, puede obligar a recodificar parte importante de la aplicación en etapas tardías, provocando inconsistencias, código muerto y pérdida de estandarización. Finalmente se culpará a la calidad del código por los problemas y se olvidará la responsabilidad de los analistas, usuarios y todo el equipo que participó de las definiciones. Por otra parte, si lasetapas tempranas son realizadas de buena forma, un error de codificación, es simplemente eso, un error de codificación, que se resuelve con bajo nivel de esfuerzo.

Veamos una analogía con otra disciplina: Si se falla en la etapa de elaboración de los planos y especificaciones de cálculo de una construcción en su etapa de diseño, por ejemplo un puente, el error detectado en etapas tardías, podríaobligar a reconstruir parte importante del mismo o incluso, podría llegar a detener la obra por ser más cara la solución (recodificación) que comenzar nuevamente desde cero (existen muchos ejemplos de estos “elefantes blancos” en la historia).

Entonces, si es tan importante esta etapa ¿Por qué acelerar la codificación? ¿Por qué no asignar el tiempo y la prioridad necesaria a las etapastempranas? Al parecer, se ve tan lejano el final del proyecto a estas alturas, que el compromiso con el desarrollo del mismo aún está en una fase preliminar y hay una sensación que ante cualquier indefinición, queda mucho tiempo para resolverla. Por otra parte las ansias de tangibilizar los deseos, hace acelerar el proceso de codificación.

Adicionalmente suele ocurrir una doble paradoja:

• Los...