Proyectos Ágiles o Productos Ágiles

0

Cuando se habla de gestión del desarrollo de software ágil siempre se escucha la expresión “gestión de proyectos ágil”. Pero desde mi punto de vista no siempre son proyectos. De hecho cuando la gestión ágil del desarrollo muestra todo su potencial es cuando hablamos de desarrollo no orientado a proyectos, sino a productos.

Diferenciando entre gestión orientada a proyecto o a producto

Antes de comenzar, haré referencia a la definición de Proyecto según el PMBOK:

[Un proyecto] es un esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado único. Un proyecto es temporal en el sentido de que tiene un comienzo y un final en el tiempo, y por consecuencia también tiene definido un alcance y unos recursos. Y un proyecto es único en el sentido de que no es una operación rutinaria, sino un conjunto de operaciones diseñadas para cumplir un objetivo concreto.

Esta definición es clave y es necesario entenderla, para poder seguir el resto del artículo. Si el trabajo que hacemos tiene un inicio y un final marcados en el tiempo, un alcance y unos recursos  asignados, entonces podemos hablar de proyecto. Si en cambio es una tarea que se repite en el tiempo, hablaremos de una operación.

Normalmente se asume que el desarrollo no es una operación, que siempre es uno o más proyectos. Pero esto no es siempre cierto. En algunos casos una empresa tiene un producto que simplemente quiere mantener, en toda la extensión de la palabra mantenimiento, es decir, incluyendo mantenimiento adaptativo, perfectivo y evolutivo, además del correctivo. Hablamos de un producto en producción que continuamente se mejora añadiendo nuevas funcionalidades, mejorando el rendimiento y aumentando el valor proporcionado por el producto. No hay un inicio ni un final en el desarrollo. No hay un alcance definido. El alcance se define día a día. Hay organizaciones que fuerzan esta situación creando un proyecto tras otro. En cambio otras simplemente asignan un equipo de desarrollo al mantenimiento del producto. Este equipo irá desarrollando las funcionalidades a la velocidad que puedan. Cada día se desarrollarán nuevas funcionalidades, y cada día aparecerán nuevos requisitos. En este caso no hablamos de proyectos, hablamos de operación. Pero como la palabra “operación” normalmente connota a sistemas, me gusta más hablar de gestión orientada a producto.

La gestión ágil de proyectos

Cuando hablamos de gestionar los proyectos de forma ágil hablamos de adoptar determinadas metodologías para la gestión de los mismos. Pero las bases de la gestión de proyectos se mantienen. Es decir, tomemos como ejemplo el marco de trabajo SCRUM. Tendremos que desarrollar un acta de constitución de proyecto con un alcance de alto nivel (en SCRUM por ejemplo es el product backlog de alto nivel: la lista de épicas). Tendremos que hacer una estimación de los recursos necesarios (en SCRUM la hará el propio equipo con puntos). Y tendremos que hacer una planificación (en SCRUM la hace el Product Owner al asociar las historias de usuario a los distintos sprints).

Cuando hablamos de una gestión ágil de proyectos hablamos de modificar el ciclo de vida del proyecto. Hablamos de pasar de un modelo en cascada a uno iterativo. Hablamos de tener un proceso de gestión de cambios mucho más ágil. Hablamos de forzar al Project Manager (llámese Product Owner) a involucrar al equipo de desarrollo en la toma de decisiones, estimaciones de costes y muchas otras tareas de gestión del proyecto. Pero seguimos hablando de gestión de proyecto.

La gestión ágil de productos

Cuando tenemos una gestión orientada a producto, todo cambia. Ya no hay un alcance definido. Lo que tenemos es un conjunto de recursos y una lista de “deseos” de la organización. El alcance crece día a día, y se desarrolla día a día. La gestión de cambios prácticamente desaparece, ya que los requisitos cambian, aparecen y desaparecen al ritmo que cambian las necesidades del negocio. En la visión tradicional de proyecto se define un alcance y el gestor de proyecto estima los recursos necesarios y el tiempo que se tardará. Aquí es diferente, ya que los recursos ya sabemos cuales son y él tiempo es un continuo. Lo que queda por definir es el alcance. ¿Y cual será el alcance? Pues de toda la lista de deseos, aquellos de más valor que puedan realizarse.

Desde mi punto de vista este caso es mucho más común de lo que parece. De hecho suele ser el caso habitual de las empresas que desarrollan sus propios productos de software, ya sea para su consumo interno o para licenciar su uso. Al final hay un producto, y hay que mejorarlo aportando el máximo valor con los recursos que se tiene.

Negocio entonces puede entender mejor qué significa ese departamento de desarrollo que tiene internamente. Para negocio será como una máquina capaz de procesar requisitos a un ritmo. ¿Hay muchos requisitos por procesar? Invertiremos en ampliar el equipo y aumentaremos la velocidad de procesado. De esta manera el equipo ya no se enfoca en cumplir fechas de entrega, sino en adaptarse y aportar el máximo valor en todo momento.

La cuadratura del círculo

Este último caso de gestión ágil orientada a producto, como ya he dicho, es muy común. El problema que yo veo es que muchas compañías se empeñan en querer plantearlo como proyectos. Y exigen al departamento de desarrollo un compromiso en fechas y costes. Esto, se use metodología ágil o no, es un grave riesgo, porque al final el departamento de desarrollo se enfocará en cumplir el compromiso, con lo que se agarrará a lo que sea para poder cumplirlo. Esto implicará rechazo al cambio, exigir requisitos claros al principio y los problemas habituales de la gestión clásica de proyectos. Si en cambio somos capaces de darnos cuenta de que lo que tenemos no son proyectos, sino que “procesamos” requisitos, las cosas comenzarán a cambiar. Negocio verá su lisa de requisitos en fila, y se sentirá con libertad para reordenarlos, cambiarlos o hacer lo que le plazca con ellos. Y lo mejor es que desarrollo le dejará hacerlo.

Si nuestro modelo es el segundo y queremos ser ágiles de verdad, no nos empeñemos en definir proyectos.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios 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 y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, 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 Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Cinco Formas Fáciles de Motivar

Como gestores de TI, da igual si gestionamos proyectos o servicios, al final somos principalmente gestores de personas, y las personas no son simples herramientas ...