Metodologías amigas – Metodologías enemigas

Supongo que fue a finales de los años ’90, que trabajando en el Banco Hipotecario con un equipo analistas y programadores a mi cargo, empecé a interesarme en el tema de las metodologías de desarrollo de software y de gestión de proyectos en general.

Resultaba evidente que para poder gestionar de manera eficiente el trabajo de muchas personas asignadas a muchos proyectos simultáneos, yo necesitaba establecer algún tipo de procedimiento “repetible” que nos permitiera ordenarnos (y sobrevivir).

Lección aprendida #1:
Un buen proceso metodológico es nuestro mejor amigo.

Por ese entonces – seguramente favorecido por la cultura bancaria y mi tendencia obsesivo-compulsiva – yo era partidario de aplicar el famoso proceso en cascada que incluso hoy en día se enseña en la mayoría de las universidades.

Por cada proyecto atravesábamos una serie de fases secuenciales, cada una con un entregable que permitiera avanzar a la etapa siguiente. Típicamente el ciclo incluía las siguientes etapas:
Priorización -> Relevamiento -> Análisis -> Diseño -> Desarrollo -> Testing -> Implementación

Sabíamos, sentíamos y sufríamos la limitación principal de este esquema de trabajo: Era habitual que los usuarios cambiaran de opinión durante cualquiera de las etapas por lo cual gran parte de nuestra energía se destinaba a la gestión del cambio. De más está decir que el proceso en cascada nos predisponía a resistirnos al cambio.

– “De vuelta cambiaron de opinión?”
– “Quéeeee? Tenemos que volver a revisar el documento de alcance del proyecto? Pero si ya lo actualizamos 3 veces!!!”
– “Desarrollémoslo como estaba originalmente planteado – incluso si no sirve para nada – y el mes que viene lo actualizamos”
– “Por qué habré decidido estudiar sistemas… debería haberme dedicado a la música” Continuar leyendo “Metodologías amigas – Metodologías enemigas”