Planificando de forma Ágil (1)

El problema

En una de las entrevistas de trabajo que hice hace tiempo me preguntaron que herramienta usaba para diseñar. Yo, ni corto ni perezoso, le respondí: Papel y boli. El entrevistador pareció sorprendido, quizás esperaba una respuesta del tipo “Uso Rational Rose junto con Together más {ponga aquí su herramienta favorita}”. Seguro que estas herramientas son muy útiles, de hecho yo las he utilizado más de una vez, pero creo que en este mundillo hay una sobrevaloración de las herramientas frente a las personas. Parece que es más importante saber utilizar el Rational Rose que saber hacer buenos diseños.

¿Y por qué cuento todo esto? Porque en el terreno de las planificaciones de software hay una herramienta, de esas “imprescindibles”, llamada MS Project que todo Jefe de Proyecto “debe” de conocer. Se usa para todo: Las ofertas llevan un project asociado, una vez iniciado el proyecto el jefe del proyecto se hace otro project, a su vez este pide a sus desarrolladores un project. ¡Y ya tenemos el belén montado! Nadie actualizará esas planificaciones en la vida, su único objetivo era el de aparecer en un papel para justificar que la entrega es sí o sí para el día X.

Las planificaciones con Project nacen viciadas desde su origen. Primero nos ponen una fecha y nosotros hacemos el paripé para calzar todo lo que tenemos que hacer en esa planificación.

Me encantan esas planificaciones del tipo:

  1. Análisis (2 meses) (Consultor Pepito)
  2. Diseño (4 meses) (Analista de 2ª Juanito)
  3. Desarrollo (4 meses)
    1. Web (2 meses)
      1. Gestión de usuarios (2 semanas) (Programador Menganito)
      2. Portal de acceso al empleado (2 semanas) (Becario Fulanito)
      3. Procesos de backend (1 mes) (¿Adivinan? ¡Fulanito y Menganito!)
      4. etc.
  4. etc.

¡Que bien!, nuestra planificación está lista y milagrosamente cumple los plazos acordados con el cliente (O aquella moto que vendió el comercial de turno tomándose unas cañas plácidamente con el cliente).

Pero analicemos detalladamente esta planificación:

  • Nace viciada de origen. Nuestro único objetivo fue cumplir los plazos, por eso utilizamos una herramienta basada principalmente en fechas (Gantt).
  • No está basada en criterios racionales: ¿En que nos basamos para planificar los procesos de Backend en un mes? ¿Hemos tenido una revelación divina? ¿Rappel está en nuestro equipo de proyecto? Este tipo de planificaciones me recuerda a un tipo de mi barrio, un poco raro, que decía que iba a hacer un software de diseño de circuitos que iba a ocupar…¡ 14 diskettes! ¡Y no sabía programar! La diferencia entre esta persona y nosotros es que, nosotros no vemos una media de 5 ovnis al día cuando tomamos el café en la terraza, ni creemos en puertas interestelares (¿No dije que era un tipo raro!!??). Y por tanto debemos ser más serios con lo que hacemos.
  • No es detallada: Por la causa anterior. Una planificación no se debe hacer nunca a semanas, ¡ Y menos a meses! Hacer una planificación no detallada es como decirle al cliente “Mira, no tengo ni idea de cuanto vamos a tardar, pero te voy a mentir para que te quedes más tranquilo. El proyecto ya se retrasará luego, como todos” (¡Lo peor es que con muchos clientes funciona!).
  • Es una referencia/restricción, no una herramienta: Una vez hecho, rara vez se actualizará (siendo muy optimistas). Solo servirá como herramienta de presión para los integrantes del equipo (esto daría para otro post). ¿Cual es el estado del proyecto? ¿Cuanto falta para acabar? ¿Que desarrollador tiene más carga de trabajo? Nuestro project no nos responderá a ninguna de estas preguntas. No está actualizado y esta lleno de suposiciones (benditos eufemismos). Vaya paradoja, ¡La herramienta de planificación no nos sirve para planificar!
  • No tenemos soporte para feedback: Al planificar nos vamos a confundir. Seguro. No existen las planificaciones que encajan como anillo al dedo. Solo podemos minimizar el desvío. ¿Crees que puedes hacer una planificación para el año que viene el mismo día a la misma hora? Cuando planificamos a grandes escalas de tiempo es inevitable confundirse. Influyen muchos motivos: No conocemos bien los requisitos, la tecnología es nueva, etc. Aunque en los siguientes proyectos no podremos presagiar muchos de los problemas que encontraremos, si que podemos prever ciertos desvíos. Por ello es importante almacenar las horas que realmente se imputaron a cada tarea. Debemos aprender de nuestros errores.

Entonces, ¿No vale para nada el MS Project? ¿Hay que huir de ellos como el demonio? Yo no llegaría a tanto, simplemente hay que tener en cuenta sus limitaciones y las implicaciones que tiene. En ciertos proyectos grandes, con muchas dependencias, puede estar justificado su uso. Pero para proyectos pequeños y medianos existen mejores herramientas. ¡Pero esto lo dejo para el siguiente post!

2 Responses to Planificando de forma Ágil (1)

  1. […] Después de un breve descanso bloggero (manda narices, después de escribir solo un post :D) prosigo con la segunda parte del post sobre planificación ágil. Si no leíste el primer post sobre planificación ágil, te recomiendo encarecidamente que lo leas. Lo puedes consultar aquí. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: