Llevaba mucho tiempo queriendo escribir sobre un tema tan polémico y con visiones tan diferentes, como son las metodologías de gestión de proyectos en IT. La verdad, que es un tema que siempre lleva a grandes discusiones en nuestro sector. De hecho, desde mi punto de vista, se ha generado una burbuja comercial, que puede llegar a ser peligrosa.

Vivimos en una época convulsa, tanto desde el punto de vista tecnológico como el organizativo. A día de hoy, las planificaciones a años vista ya no son válidas. El negocio y las exigencias del mismo, son completamente cambiantes según las demandas de los usuarios y el mercado. Esto hace que nuestras compañías se deban adaptar de una forma tan rápida, que prácticamente no nos daría tiempo a usar el primer cartucho de tinta de una impresora doméstica.

PM agil

Los proyectos IT, no son ninguna excepción en esta realidad. Deben ser rápidos, tener la capacidad de adaptarse a las circunstancias de cada momento de la mejor forma posible y sobre todo, saber que nacen con un tiempo de vida limitado, que no deja de ser, el tiempo que nuestro negocio lo demande. Incluso, es aceptable un cierto grado de riesgo o incertidumbre en su puesta en marcha, en aras de facilitar esa agilidad que requiere el mercado. Ojo, no debemos confundir esto, con hacer las cosas de forma «chapucera», que es tremendamente fácil.

Es fácil saber que haremos en 6, o incluso, 12 meses. Pero nadie sabrá que estaremos haciendo dentro de 18, 24 o 36 meses.

Tengo la fortuna de trabajar en una compañía en la que, por suerte, creo que hemos sido capaces de adaptarnos a estos cambios o más bien, nacer con una forma de trabajo totalmente adaptada a estos conceptos y no con metodologías tradicionales. ¿Y cómo lo hemos hecho?. Pues si os soy plenamente sincero, ha ido surgiendo de una forma totalmente natural, aprendiendo y trabajando sobre la experiencia, pero muy adaptado a nuestros tipo de trabajo, muy especializado.

Si lo tuviese que explicar, podría resumirlo en una mezcla de BSQ + Design Sprint (el modelo de Google para validar prototipos o validar ideas), que os intento detallar más abajo:

  • Al principio del proyecto, se fijan unos Goals (o hitos), con unas fechas de cumplimiento que el equipo de trabajo (aquí incluimos a todos, clientes, otras empresas, etc…) considera factibles junto con timeline de qué y cómo. Cada uno de ellos tiene un responsable y su cumplimiento, depende de él. Por supuesto, esto es totalmente variable y como sabéis, empezamos por Z y muchas veces hay que terminar haciendo A.
  • A partir de aquí, comenzamos con el Design Sprint,  en la que orientamos el trabajo de cada semana a cumplir unos hitos y tratamos de que el viernes, podamos ver una evolución del trabajo realizado. En esa semana, nos centramos en el trabajo a cumplir esa semana, eso evita distracciones al equipo, aunque ya tenemos perfectamente planificado el futuro.
  • Comunicación. Cada semana hay una reunión de evolución con el cliente, se ve en que punto estamos y sobre todo, si hay variaciones respecto al plan original. Con el equipo implicado, normalmente, tratamos de hacer 2 reuniones diarias (muy tipo scrum), breves de no más 5 o 10 minutos. Por la mañana, se trata de ver que haremos durante el día y por la tarde, que hemos hechos y que no hemos hecho.

¿Porqué planificar por semanas?. Realmente no es así, planificamos el global del proyecto, pero dada la índole de los trabajos, en las que muchas veces no dependes de ti, pensar en trabajos a dos semanas vista, es como «hacer trampas jugando al solitario«, así que planificas lotes de trabajo en base a dichas semanas. Además es muy adaptable, te permite arrancar parcialmente proyectos enormes, por necesidades 🙂 Como muchos trabajos son en cascada, ya que dependen de uno anterior, siempre es interesante, tener una alternativa, sobre el plan original, por si en un momento dado, no se pudiese ejecutar por motivos varios.

week

Para mí y dada la naturaleza de nuestro trabajo es muy importante el marcar Goals para cada miembro del equipo, eso hace que cada uno tenga responsables y sobre todo, que la implicación en el proyecto sea muy alta.

Aunque no os lo he dicho, para que esto funcione es necesarios dos cosas básicas, que parecen sencillas, pero a veces no lo son tanto:

– Transparencia y colaboración plena con el cliente

– Un equipo de trabajo 100% profesional

Espero que no os hayáis dormido mucho con mi larga explicación, que a pesar de lo que parezca explica un modelo de trabajo muy sencillo, sin grandes nomenclaturas ni vueltas. Sencillo, directo, transparente y adaptable.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: