Las 3 mentiras que dice la gente ágil sobre los proyectos

0

Desde que el desarrollo ágil irrumpió en nuestras vidas, se ha ido creado una comunidad de seguidores acérrimos de esta tendencia, un núcleo duro. Para esta gente todo lo que suene a antiguo es descartable por norma. Y si hay un concepto con el que no tragan de ninguna manera es la palabra “Proyecto”.

Continuamente veo artículos en los que directamente se demoniza el concepto de proyecto, como la antítesis de la agilidad. Y sinceramente creo que toda esa gente que lo hace no entiende lo que realmente es un proyecto. Creo que ven una manera de gestionar proyectos y lo extrapolan. Pero el hecho de que se se hayan gestionado los proyectos de una manera no impide que se puedan gestionar de otra, ni impide que el concepto de proyecto entre en nuestra organización ágil. Es más, podemos ir a las buenas prácticas de gestión de proyectos y, sin dinamitarlas, ver como estas realmente se pueden aplicar a nuestro entorno ágil.

Se que a estas alturas de artículo a muchos de vosotros ya os están dando ganas de vomitar. “¿Qué está diciendo este gilipollas?” Seguro que alguno ya lo habéis pensado. Antes de criticar, leedlo entero y luego me ponéis verde (que sé que muchos tendréis ganas).

Así que después de esta introducción vamos a ver tres cosas que se entienden mal de los proyectos, o lo que es lo mismo, 3 mentiras que se suelen decir.

Mentira 1: Un proyecto es una fecha de inicio y una fecha fin

Es cierto que un proyecto está delimitado en el tiempo. Un proyecto se empieza un día y se acaba otro. De hecho estos días (inicio y fin) están definidos. Pero esto es lo que se entiende mal.

Cuando se dice que un proyecto tiene definido un inicio y un fin, es a posteriori. Es decir, llega un momento en el que se puede decir “hemos acabado”. Lo que no quiere decir, es que haya que definir ese día al principio y cumplirlo a fuego. No quiere decir que tengamos un compromiso de entrega en una fecha y que ese compromiso hay que cumplirlo, por encima del valor aportado y de la calidad de lo entregado.

Un proyecto tiene un alcance. Por ejemplo podría ser: “Añadir la opción de contratar servicios post-venta en nuestra web de ventas”. Básicamente planteamos un alcance y llega un momento en el que ese objetivo se cumple. No dice que no podamos hacer entregas iterativas. No dice que los requisitos estén definidos el primer día. Y no dice que una fecha en concreto tenga que estar acabado y entregado. Lo que dice es que llega un momento en que el proyecto ha acabado. Que sepamos de antemano qué día es ese es algo que no define el concepto de proyecto.

Sinceramente no hay mucha diferencia entre una épica de Scrum y un proyecto. Las épicas tienen un alcance y unos objetivos de negocio a cumplir. Y llega un momento en el que las cerramos. En el fondo una épica es un proyecto (por muchas arcadas que esto les de a los agilistas).

Mentira 2: Gestión de proyectos es sinónimo a desarrollo en cascada

Cuando se define un proyecto se inicia definiendo un alcance. Pero este alcance es aproximado. Así como el resto de estimaciones que se hacen al arrancar, como cuanto tiempo creemos que tardaremos. Son medidas de orden de magnitud y es algo más parecido a “en unos meses” que a decir que el 5 de Abril se entrega.

El alcance que se define en un proyecto es similar a definir una épica y las historias de usuario principales que contendrá. Aparecerán nuevas, dentro del mismo alcance.

Lo que no obliga la gestión de proyectos es a definir todos los requisitos al principio y cerrarlos. De hecho se suele definir el “ciclo de vida del proyecto” y “en cascada” es sólo un ejemplo de ciclo de vida. Se puede hacer iterativo, redefiniendo en cada momento el alcance.

Lo que sí recomienda la gestión de proyectos es que estimemos los recursos y tiempo necesarios para lo que nos proponemos. Y esto ya lo he dicho en muchísimas ocasiones: estimar no es comprometerse. Cuando negocio pide que quiere poner en la web la opción de contratar servicios post-venta necesita una guía de cuanto va a costar. Le diremos que el equipo a dedicación completa esperamos que lo tenga en 4 sprints de 2 semanas, pero que puede que más o menos. Pues la gestión de proyectos no pide más que eso. A medida que avance se irá viendo si esto se cumple o no, e iremos modificando las estimaciones y el alcance.

Y sé que muchos me vendréis con que el alcance es cerrado en la gestión de proyectos, que incluso hay un control de cambios para cuando el alcance se modifica. Pero es que en el mundo ágil esto también es así. Volvamos al ejemplo de que nos piden añadir los servicios post-venta a la web. Hacemos la primera entrega tras 2 sprints y ya tenemos servicios de precio fijo disponibles. En ese momento se le enciende la luz a un director comercial y nos pide que también quiere vender seguros y extensiones de garantía, que en el fondo son servicios post-venta. Y a la que le hacemos dos preguntas sobre el tema vemos que eso va a complicarlo todo. ¿Lo aceptamos sin más, o le decimos que eso hará que lleve más tiempo? ¿Preguntamos a los otros interesados a ver si quieren que hagamos eso, aunque esto retrase el comienzo de otras épicas? Claro que lo hacemos. ¿Y qué es eso sino un control de cambios?

Mentira 3: Gestión de proyectos es “entrego y me olvido”

Que un equipo acabe un proyecto no implica necesariamente que ese equipo no lleve el mantenimiento de lo entregado. De hecho no implica que el equipo deba orientarse sólo a un proyecto, en vez de al producto.

Podemos tener equipos orientados a producto y que cuando empezamos un proyecto (o épica) usamos varias técnicas de gestión de proyectos para coordinarnos mejor con producto. Ese equipo, cuando acaba, es como cuando acaba una épica, sigue con otra cosa de ese producto, y sigue manteniéndolo. Una cosa no quita la otra.

Creo que hoy en día lo más acertado es asociar equipos a los productos. E incluso más acertado es asociar a los equipos a las distintas líneas de negocio, de forma que lleven productos afines a esa línea. Pero eso no impide que se nos presenten proyectos.

Conclusiones

Hay muchas más mentiras que se dicen por ahí de los proyectos. Por supuesto que si entiendes que un proyecto es cerrar coste y tiempos al iniciarlo, que es cerrar unos requisitos y hacer desarrollo en cascada, y que significa que la gente asignada al proyecto luego se pira a otra cosa mariposa; odiarás los proyectos.

Pero si apartas las ramas del camino y ves un poco más lejos, veras que un proyecto es simplemente un objetivo. Es una épica. O es una nueva gran funcionalidad de nuestro producto.

Cuando le perdemos el miedo al concepto proyecto y estudiamos lo que ya se sabe sobre ellos podemos aprender muchísimas cosas que nos serán de gran utilidad, sin perder un ápice de agilidad. Podremos aprender de gestión de interesados. De gestión de riesgos. De evitar que una épica se nos eternice porque siempre se añaden cosas y que eso genere frustración. aprenderemos conceptos como el acta de constitución, que aplicado a la definición de épicas es un arma poderosísima (y que se tarda 10-15 minutos en completar) del product owner para poner de acuerdo a equipo e interesados. Y muchas cosas más.

Eso sí, la mayoría que os hable de gestión de proyectos se quedará en la superficie y querrá aplicar lo que vosotros teméis. Así que tenéis todo el derecho del mundo a seguir odiando el concepto de proyecto.

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios