Hace muchos años, como PM en una multinacional, tomé a cargo un proyecto para un sistema que iba a cambiar fuertemente la forma de trabajar de un sector, pero lo que cambió fue mi forma de ver a los proyectos.
En principio, era un sector crítico y el sistema tenía que resolver el día a día con operaciones de cientos de miles de dólares, y tenía además que ser en tiempo real, interactuando con varias fuentes de información externas, ya que trabajaba con cotizaciones en diferentes mercados del mundo que operaban las 24 horas.
Esto ya lo hacía complejo, pero aún había más.
La metodología de análisis era nueva en la compañía, con una herramienta CASE (Computer Aided Software Engineering, o Ingeniería de Software Asistida por Computadora) para el diseño.
El lenguaje seleccionado por mi jefe en ese momento era también nuevo y nunca usado en otro proyecto, contando con capacidad de prototipado.
A esta altura, podrán imaginarse la complejidad, pero todavía la complicamos un poco más, contratando una consultora externa para el desarrollo, que estaría bajo mi mando.
Por suerte, la relación con el usuario era inmejorable y comenzamos a trabajar en el proyecto con muchas ganas.
Las definiciones en la nueva herramienta llevaban mucho tiempo pero la calidad de lo producido era inmejorable.
Los primeros documentos llenaron de asombro a muchos (internos y externos), y a decir de la consultora contratada, era la primera vez que le entregaban algo tan bien definido y con tanta profundidad, cosa que repetía mi jefe en cuanta ocasión con sus superiores se le presentaba.
Uno podría decir que, con este panorama, la probabilidad de un proyecto exitoso era alta, aún a pesar de la complejidad, pero…
Como todos los proyectos de la compañía, se hizo utilizando una metodología de proyecto tradicional (Ciclo de Desarrollo de Sistemas o CDS), donde TODO debe estar definido desde el principio.
Era fácil porque los documentos de alcance eran exhaustivos, y la conformidad del usuario era total, sin embargo…
Cuando los primeros cambios comenzaron a llegar desde el sector usuario, y comenzaron los procesos burocráticos de la aprobación de esos cambios, los problemas aparecieron.
Se tardaba mucho en aprobar los cambios y si bien la herramienta de diseño era ágil para implementarlos y tenía análisis de impacto, había que generar nuevamente documentación para la consultora contratada, que muchas veces ya estaba trabajando o había terminado alguno de los módulos a cambiar.
Esto llevaba a procesos muy largos, muchos con impactos fuertes y mayores costos, lo que hacía que el usuario estuviera cada vez menos proclive a esperar por la aprobación de algo que aún no veía ni podía probar, y que no estaba seguro de que fuera el último cambio sobre el mismo tema, por la dinámica del negocio.
La resultante fue que los pedidos de cambio disminuyeron, no porque no hicieran falta, sino por la falta de respuesta tangible y las trabas para el usuario de cualquier cosa que pedía.
Sobre el final, un par de meses antes de la implementación (era un proyecto de 15 meses), se produjo un cambió de gerente en el área.
El nuevo, proveniente de la misma función en otra filial más pequeña, decidió utilizar un sistema más artesanal y con mucha carga manual, pero que él ya había usado en su posición anterior, y por consiguiente, el proyecto fue cancelado.
MORALEJA:
Este era un típico caso para la utilización de metodología ágil de proyectos.
Gran complejidad, muchos cambios, un alcance poco previsible, nuevas tecnologías, área crítica con necesidades urgentes, entre otros temas.
La metodología ágil nos hubiera permitido tener entregas parciales de módulos funcionando en períodos cortos (normalmente 30 días o menos) y esto hubiera descomprimido la labor manual de los operadores y el registro a destiempo, motivándolos mucho sobre el desarrollo del proyecto.
También hubiera permitido ir incorporando los cambios y priorizando los módulos a medida que se avanzara, sin que esto representara una carga burocrática ni un examen permanente para el usuario, dado que el cambio es parte del proceso y no una excepción en este tipo de metodologías.
Un ajuste tanto funcional como de prioridades en períodos cortos hubiese generado una excelente dinámica.
Por último, el tener partes funcionando hubiera hecho que todo lo generado tuviera valor para la compañía, y que la decisión de tomar un sistema nuevo, hubiese tenido que compararse contra funciones activas y no con una promesa futura, y la nada en la operación, evitando de esta manera un proyecto fallido.
Fue una lección aprendida, quizás con una pequeña excusa… en ese momento, las metodologías como SCRUM, o Agile Project Management, eran poco conocidas por estas tierras y estaban muy verdes en el mercado global.
Ahora, ya lejos de aquellos tiempos, en ROI Agile International hemos diseñado nuestra propia metodología ágil con base en SCRUM, Kanban, Lean y TCM, y preparamos a nuestros clientes en ésta y las mencionadas anteriormente, con muy buenos resultados, la mayoría de ellos inmediatos.
No fue fácil lidiar con el cambio de paradigmas, pero se fue haciendo en muchas organizaciones, y, por suerte, en esto podemos decir que no todo tiempo pasado fue mejor…
Si todavía no te sumaste a la agilidad, te invitamos a tener una charla y contarte los beneficios que puedes obtener de hacerlo.