Los cronogramas después del modelado

Todo proyecto de gestión de información debe plantearse un cronograma
guía. Pero los ajustes después del diseño detallado son obligatorios ya que
las estimaciones hechas antes del análisis de los detalles del problema y la
solución son poco confiables.

Muchas personas creen que el ideal de un gerente es el cumplimiento estricto de todos los cronogramas que se plantean al inicio de un proyecto. La realidad no es así en el desarrollo de sistemas de información. Como veremos en el post de hoy, un gerente que cumpliera de esa forma los cronogramas de inicio de proyecto no sería un buen gerente, sino uno muy malo. De hecho es muy probable que, independientemente de las relaciones de autoridad que mantenga, inherentes a su cargo, alguien así sea muy poco acreditado en el juicio interno de quienes se relacionen con él: colegas, trabajadores, proveedores, clientes. Independientemente de las opiniones que se expresen en forma abierta, seguramente entre los relacionados comentarán acerca de la inflexibilidad, testarudez y dudosos conocimientos de integración y del ciclo de vida de los proyectos del amigo en cuestión. Eso es porque efectivamente, aunque muchos no los puedan verbalizar adecuadamente, hay  elementos dinámicos, propios del ciclo de vida del desarrollo de sistemas donde de veras hay evolución y creación de conocimientos y éstos necesariamente impactan los cronogramas iniciales.

Cómo hemos visto en otras oportunidades (ver por ejemplo El ciclo de vida... y Desarrollo, Implementación y Producción...), toda  nueva solución recorre un camino signado por distintas  fases: definición, diseño, desarrollo, implantación y producción.

En la fase de Definición se conceptualiza inicialmente el problema de información, en la fase de Diseño se trabaja con los detalles del modelo de información que se requiere, en la fase de Desarrollo se realiza la construcción del prototipo inicial de la solución, siguiendo las pautas que marca la fase de diseño y en la de Implementación se realiza la transición de la solución desde el equipo de desarrollo hacia el equipo que se encargará de él en la fase de Producción.

Si el problema no es trivial, si no se trata de un proyecto para seguir haciendo más de lo mismo y por tanto dejando todo sin mayores cambios, lo natural es que en el proceso iterativo de la fase de diseño o modelado se obtenga una mayor comprensión del problema y la solución ya que sólo después de todas sus actividades se logra una definición completa del alcance de un proyecto no elemental. Desde que es concebido hasta que se coloca en producción cada detalle de la solución debe ser sometida a pruebas de concepto de Arquitectura de Información para asegurar la calidad en su definición y/o implementación y este tipo de ajustes son naturales y recomendables, ya que mejoran el conocimiento incluido y la eficiencia del modelo de información a implementar.

Lo anterior significa que cualquier cronograma que se hubiese hecho al inicio del proyecto, antes del diseño detallado, es un cronograma realizado en un momento en el que el tamaño de la solución no podía estar bien definido precisamente por el desconocimiento de todos los elementos que nacen del análisis detallado de la información y la especificación del modelo de gestión. Las ideas iniciales son siempre demasiado bastas como para hacer estimaciones serias. Así como es poco confiable un médico que hace sus estimaciones definitivas antes de la biopsia necesaria para caracterizar un aparente tumor, así es poco confiable el profesional de la información que estima los recursos en forma definitiva y que pretende no hacer cambios en sus ideas después de caracterizar los detalles del problema y la solución.

Siempre que se trabaja con seriedad, los detalles de un buen análisis nos sugerirán una solución más larga o más corta, resuelta mejor con un procedimiento o con otro y por eso los cronogramas de un proyecto bien realizado deben ajustarse después del diseño detallado. No es impecabilidad sino inflexibilidad y  tozudez el ligar el éxito al cumplimiento de lo que se creía cuando no se tenían los detalles. Sería como el médico que se empeña en trabajar con la idea presumida inicialmente de un mal benigno después que se encontró, en el análisis, que el aparente tumor de su  paciente era un linfoma.

Si el proyecto no es pequeño y trivial, si es de mediano tamaño y no se trata de un proyecto que deja todos los procesos más o menos iguales, sino de una auténtica mejora, la sapiencia de la experiencia profesional comienza a brillar en el modelado, ya el que sabe sólo afirma categóricamente después que conoce.