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”

Lección aprendida #2:
Por más que no nos guste, los requerimientos siempre cambiarán sobre la marcha.
Podemos resistirnos con todas nuestras fuerzas, pero eso no impedirá que el cambio igual suceda.

50 reasons not to change

A esto se agregaba que nuestro equipo debía atender los pedidos de todas las gerencias del banco. Teníamos más de 1000 usuarios internos y en distintas ubicaciones geográficas. Además cada gerente tenía su lista de prioridades que, obviamente, no concordaban con las prioridades de los demás gerentes.
Nosotros éramos 40 personas con una lista de más de 1000 requerimientos. Un 30% de mi tiempo lo destinaba a negociar con los gerentes qué proyectos podíamos o no podíamos comprometer para la siguiente versión del producto.

Una de las decisiones más inteligentes que tomamos en ese momento con mi ex-jefe y actual-amigo Marcelo Rosatti, fue la implementación de un paso formal para la solicitud de nuevos requerimientos. La gerencia que quisiera agregar un proyecto a la lista debía enviarnos un memorando numerado, detallando en 2 párrafos lo que deseaba que programemos. El memorando debía venir firmado por el gerente del área.

Esta dosis de burocracia redujo drásticamente la cantidad de pedidos que recibíamos.
Como el interesado debía destinar 10 minutos a la confección del memorando y debía pedirle a su gerente que lo firmara, sólo nos llegaban los proyectos que realmente justificaran esos 10 minutos de dedicación.
Me creen si les digo que el volumen de nuevos proyectos se redujo a la mitad? Insólito!
Esto significaba que antes de esta medida la mitad de los requerimientos que recibíamos ni siquiera valían 10 minutos de su propio tiempo!

Lección aprendida #3:
Hacer un requerimiento debe implicar un mínimo costo para el solicitante.
Si es totalmente gratuito nos inundaremos de proyectos que no son más que “expresiones de deseo”.

Para organizarnos internamente, implementé una pieza de software llamada Microsoft Team Manager 97, producto que luego fue discontinuado y jamás reemplazado por otro.
El Team Manager nos resultaba práctico porque se integraba al Outlook y permitía distribuir tareas a la lista de Tasks de cada uno de los integrantes del equipo. Además el producto permitía que diariamente cada uno actualizara el estado de sus tareas, indicando porcentaje de avance o tiempo restante, para luego concentrar todas las novedades en un repositorio central.
El mismo concepto fue luego utilizado por Microsoft Project Server, pero de manera más compleja y especialmente apropiada para proyectos más grandes.

Yo pasaba otro 30% de mi tiempo actualizando la lista de requerimientos, cambiando las prioridades, asignando las tareas a las personas del equipo y recordando a los más desordenados que aún no me habían enviado su reporte del día anterior.

El 40% restante de mi tiempo lo dedicaba a acompañar a los líderes, analistas y desarrolladores en los proyectos concretos. Yo entendía que mi tarea principal como manager era “correr los muebles del camino para que no estorbaran su paso”, es decir, resolver cualquier obstáculo para que mi equipo trabaje lo mejor posible. Además debía interactuar con los sectores de Tecnología, Seguridad Informática, Auditoría, Homologación, para lograr que los proyectos se aprobaran y llegaran a estar productivos.

Era un proceso burocrático el que teníamos?
Si, un poco… pero no era un proceso rígido. Sabíamos adaptarlo a cada situación.
Después de todo estábamos construyendo sistemas que manejaban el dinero de los clientes del Banco. Cometer un error no era una opción. Establecer muchos puntos de control intermedio nos forzaban a seguir un proceso secuencial, a pesar de que no siempre resultara óptimo en términos de productividad.

BurocraciaLuego de algunos años trabajando de esta manera, un nuevo gerente de Sistemas decidió contratar una consultora amiga para implementar una nueva metodología de gestión de proyectos.
La misma proponía la realización de muchísimas más etapas y sub-etapas, con muchísimos más documentos a completar que nunca serían leídos, la incorporación de Primavera Enterprise como software de gestión de proyectos… y empecé a sentir que nuestro objetivo dejaba de ser la mejora del producto y pasaba a ser el cumplimiento de los procesos.

Yo creo que las metodologías nos deben servir para ordenar nuestro trabajo, mejorar la comunicación interna y externa, optimizar nuestra productividad, mejorar la calidad de nuestros desarrollos, reducir los tiempos y costos… pero sin perder de vista que en definitiva el objetivo final es mejorar el producto para responder a la estrategia del negocio.

Cuando esto deja de suceder y la totalidad de nuestro esfuerzo está destinado a asegurar que hemos completado todos los pasos de un proceso – incluso los que no son necesarios para algún proyecto específico – y el éxito o fracaso se mide en base al grado de cumplimiento de los procesos y no al incremento funcional del producto, entonces es el momento de preguntarnos cómo es que nos hemos desviado tanto del camino.

Lección aprendida #4:
Un mal proceso metodológico es nuestro peor enemigo.

Luego la vida me llevó a trabajar en distintos entornos y descubrí que cada negocio, cada empresa, cada grupo humano, requiere su propio método, hecho a medida. Yo creo que los resultados son superiores a aplicar recetas “enlatadas” sacada de los libros.

No es simple. Siempre se encuentran resistencias, pero los beneficios al final del recorrido bien valen el esfuerzo.
Al menos a mí siempre me ha resultado fascinante este aspecto de la profesión.
Las mayores satisfacciones laborales las he logrado cuando mi equipo confía en mi, yo confío en mi equipo, y nos decidimos a recorrer juntos el camino para mejorar la forma de hacer proyectos.

3 opiniones en “Metodologías amigas – Metodologías enemigas”

  1. Hola, me gusto mucho tu articulo, solamente que no encontré final feliz, yo se que cada proyecto es totalmente distinto, pero me imagino que debe de haber una metodología que pueda ser flexible y se acople a cada proyecto para acercarnos lo más posible a los requerimientos del mismo, sin que, como tu mencionaste, se realize un proceso extremadamente burocratico y papeleo que nunca se leerá.
    En tu opinión personal, ¿Que metología utilizas para administrar tus proyectos?

  2. Hola Fernando.
    Gracias por tu comentario… es cierto, en este post no incluí un final feliz. La idea es publicar otro post hablando de Metodologías que si me han resultado, como ser SCRUM.
    Saludos.

Deja un comentario