NOTAS BASADAS EN LA EXPERIENCIA REAL DE GESTIÓN DE LA DEMANDA, LEJOS DE UNA VISIÓN ACADÉMICA DE LA MISMA
Este post estaba previsto como uno de los últimos de la serie. Pero cuando trabajas en una compañía como Xeridia, que incluye en su forma de hacer las metodologías y herramientas que se agrupan en el concepto Agile, hay que responder más pronto que tarde a algunas preguntas: ¿cómo encaja esta visión tradicional de la Gestión de la Demanda y las nuevas metodologías de desarrollo ágil que se utilizan en muchos de los proyectos? ¿Podemos hablar de una Gestión de la Demanda Agile? O Incluso ¿es necesaria una Gestión de la Demanda?
El desarrollo que haré a continuación me llevará a mantener la Gestión de la Demanda sin la inclusión de ningún calificativo. El concepto de gestión se debe mantener mientras las necesidades sean mayores que los recursos, o incluso por el hecho de que esos recursos son costosos y hay que optimizar su uso.
Los antecedentes teóricos y prácticos del desarrollo Agile tienen bastante antigüedad, suficiente para hacer factible un desarrollo paralelo a la Gestión de la Demanda. Antes de continuar con lo que nos atañe, quiero sintetizar en el siguiente gráfico los hitos que han permitido definir el contexto Agile tal y como lo conocemos en la actualidad:
En el artículo ¿Realmente necesito una nueva solución para la gestión de la demanda? enumeraba una serie de requisitos o preguntas para determinar la necesidad de Gestión de la Demanda. Simplificando, los agruparía en dos bloques:
- Participación de todos los intervinientes en la demanda. Con énfasis especial en los peticionarios y sus responsables.
- Información precisa y actualizada para todos los ámbitos de decisión.
Las metodologías ágiles se alinean y cumplen con estas especificaciones formalizando la participación de los responsables del negocio. Siguiendo la terminología de Scrum, el Product Owner es una persona que entre otras funciones, representa al negocio y a la comunidad de usuarios. Es precisamente la presencia continua y el papel del Product Owner lo que garantiza precisión en las planificaciones y exactitud en el ROI de los proyectos.
«La presencia continua y el papel del Product Owner garantiza lo importante de las planificaciones y el ROI de los proyectos«
Las mejoras en la información dependen en gran medida de las herramientas utilizadas y de su integración con el sistema actual de desarrollo y operación de las aplicaciones. Es conveniente que se soporten las metodologías utilizadas, ágiles o predictivas, y que la falta de integración no sea un continuo problema.
En cambio, sí podría considerarse como un problema la visión a corto plazo de proyectos cuando son desarrollados con metodologías ágiles. Tenemos una valoración precisa de lo que vamos a hacer en la próxima semana o el próximo mes, pero difusa de la totalidad del proyecto. Y lo más probable es que la dirección o los equipos gestores de la demanda requieran una “visión global” de todo el proyecto.
En esta situación, ¿Qué riesgos existen y cómo los podemos solucionar? Básicamente existen dos (uno de enfoque y uno principal), y ambos con fácil solución:
- Riesgo por el enfoque metodológico.
Podría suceder que estemos haciendo con metodologías ágiles proyectos que deben ser predictivos por tener requisitos muy estables, ser un producto que no va a requerir modificaciones, tratarse de sistema ultra críticos, etc. O incluso que la propia organización esté lejos de la agilidad al tener perfiles profesionales más junior, estructuras de funcionamiento verticales, desarrollos más orientados a procesos, etc. La mitigación del riesgo en este caso es fácil: se deberá hacer un breve análisis para que los proyectos se realicen con la metodología adecuada. - Riesgo por error en valoración.
En una compañía orientada a la agilidad, la valoración exacta del proyecto a largo plazo resulta menos relevante, ya que se cuenta con la garantía semana tras semana de que el desarrollo se está haciendo con orientación al negocio y con un ROI adecuado.
¿Podría valer con una aproximación, al tener la certeza de que las desviaciones sobre el proyecto global están disponibles de manera temprana? Sí. Además, según mi experiencia, esta valoración será más aproximada que en los desarrollos predictivos, donde una de las fuentes principales de desviación son las pérdidas de tiempo a causa de los desajustes en la dedicación de los especialistas técnicos.
Y si todo esto no fuera suficiente, en los desarrollos predictivos ya debe existir un mecanismo para la gestión de cambios de alcance, que se utiliza cuando se tienen que hacer ajustes en la valoración por desviaciones en planificación o ejecución. En el desarrollo ágil se podría utilizar el mismo mecanismo de revisión y aprobación para desviaciones superiores a un importe o volumen determinado del proyecto.
Concluyo por tanto que el encaje entre gestión de la demanda y desarrollo ágil es bueno y que no serán necesarios nuevos nombres ni roles. Y dependiendo del proyecto y de la compañía, el desarrollo ágil hará más eficiente la Gestión de la Demanda. Lo importante es gestionar con la metodología adecuada, tener herramientas que permitan los desarrollos en ambos modelos, y que aporten la información en tiempo y con el detalle apropiado.
La experiencia de Xeridia en proyectos ágiles con Jira y Confluence de Atlassian nos permite garantizar una adecuada Gestión de la Demanda, y también un desarrollo de proyectos óptimo. Conoce nuestros servicios de gestión de la demanda de TI.
Avelino Carrizo es Gerente de Consultoría de Sector Financiero en Xeridia
