Hitos, hitos, hitos, son muchos los proyectos que llevamos a cabo a lo largo de un año, pero no todos tienen la misma importancia, impacto en negocio, número de interesados, ¿todos aportan los mismos beneficios?, ¿mejoran sustancialmente los productos de nuestra empresa?.
Hay ciertos proyectos, que son más relevantes para los roles de producto, business, dirección de la empresa, y como todo interesado, cada cierto tiempo preguntará: ¿cómo va esto?, ¿qué nos queda pendiente de estos cambios? ¿qué hemos dejado ya entregado al cliente? ¿cuándo puede estar esta idea nueva que se nos ha ocurrido hoy?. Incluso si no pregunta, el product owner debe ir dando cierto feedback del estado de los proyectos.
Un equipo de trabajo, consigue mediante técnicas de visual management un panel con la visión completa del trabajo que está desarrollando, identificar mejor el impacto que tiene una historia de usuario no prevista en una iteración y presentar de una forma más eficaz el estado del desarrollo.
¿Por qué un rol de negocio no puede aprovecharse de todas estas ventajas? Es posible enfocar la gestión visual de acuerdo a las necesidades e intereses de estos miembros de nuestra empresa, no mostrarles todo lo que está pasando en cada producto, en cada equipo, pero sí presentarles la visión completa de qué está terminado, en qué estamos trabajando y qué está aún pendiente, es decir, la big picture del producto e hitos más relevantes del negocio de nuestra empresa.
Un equipo Scrum, puede tener un panel con las User-Story definidas por el PO.
Un gerente, puede tener un panel con las Business User-Story que ha definido con el PO.
¿Por qué hacer un Roadmap de forma visual?
Si yo fuera un rol de negocio, que tengo mil cosas en la cabeza, a la hora de ponerme al día sobre en qué estamos trabajando, me gustaría ver algo sencillo que me aporte toda la información que necesito rápidamente, para invertir mi tiempo en pensar cuál es la mejor decisión.
En caso de tener una nueva idea de negocio, si el equipo me enseña el estado actual del producto, en qué están invirtiendo el tiempo, puedo decidir mejor cómo priorizarla para no interrumpir el flujo trabajo actual.
En caso de que nuestra línea de negocio dé un giro y la empresa decida cambiar el enfoque de algunos de los proyectos ya propuestos, visualmente se podrían apreciar qué proyectos están aun por empezar, para quitarlos del roadmap y en su lugar, introducir los nuevos cambios.
En definitiva, si trabajamos sobre una representación visual del estado actual de nuestros proyectos, podremos:
- obtener información y hacer cambios, siempre de una manera más fácil.
- ver el impacto de nuestras decisiones gráficamente.
- tomar éstas con suficiente información como para asumir las consecuencias de las mismas.
Qn vs Estados de los proyectos
Para lograr una buena aceptación de este tipo de paneles, es importante que sean sencillos, fáciles de entender y sobre todo, que contengan la información que los interesados desean conocer, única y exclusivamente. Veamos el siguiente panel:
En el eje Y podemos presentar las Qx (o trimestres del año) y en el eje X los estados de las tareas. Cada color de tarjeta, podría representar un proyecto, linea de negocio, producto, departamento, aquello que identifique ‘entrega’ o ‘hito’ relevante para el interesado en este panel. También podemos usar las tarjetas del mismo color y marcar con pegatinas de colores el proyecto involucrado.
Lo que podemos apreciar en este panel:
- son los proyectos que la empresa había planificado inicialmente para determinadas QX y cómo a medida que ha pasado el tiempo, los ha trasladado a otra.
- algunos proyectos de la QX anterior que no han salido adelante.
- algunos proyectos ya han sido entregados.
¿Es posible saber si un proyecto involucra a varios equipos o lineas de negocio?
En este caso, podríamos poner una marca en la tarjeta que alerte de que es un proyecto con dependencias, y que su replanificación tendrá un gran impacto.
Si por ejemplo, movemos de cuadrante un proyecto con dependencias a Marketing, y en el cuadrante destino vemos que Marketing está saturado, podemos plantearnos esta situación y ver si hay que hacer más o menos cambios, para conseguir poner la prioridad del proyecto en su lugar. La ventaja es, que obtenemos un feedback visual, y observamos el impacto de cada decisión, pudiendo tomar cada una con más criterio.
¿Qué nos podemos plantear en esta situación?
- Puede que alguno de los proyectos que están pendientes de la Q1 son más importantes de los que había preparados para la Q2 o Q3, por lo que nos podemos permitir priorizar y mover éstos proyectos sobre el panel.
- Desechar los proyectos de la Q1 que no se han empezado, pues han podido salir otras ideas mejores, que debemos introducir en el Roadmap.
- Sobrecarga de trabajo en un proyecto, pues tiene más hitos en la cola que otros, y quizá tengamos que revisar las prioridades por si no podemos completar todo el trabajo deseado.
Qn vs Proyectos
Ahora podemos darle otro enfoque al panel, centrándonos en las historias deseadas para cada proyecto en cada Qx.
El eje X representa las Qx, el eje Y los proyectos, y en cada cuadrante están estos definidos. La forma de determinar su estado es ubicando una etiqueta encima de la tarea.
En este panel podemos tener una ‘desventaja’ respecto el anterior, y es que los proyectos con dependencias, tendrían la misma tarjeta multiplicada.
¿Y vosotros como hacéis reporting en vuestra empresa?
¿Cómo abordáis los cambios de planificación en proyectos de alto impacto?
¿Cómo véis los que habéis conseguido o dejado de lado cada año?
Artículos relacionados:
Vanesa Tejada 
Hola Vanesa,
Me ha gustado la primera parte de tu propuesta. Ver el estado de los proyectos por trimestre es muy útil. La segunda propuesta no me ha gustado tanto. Lo siento. 🙂
Pero me gustaría hacer un par de comentarios al respecto de la primera:
* Usar colores para distinguir proyectos no escala. Lo normal es tener muchos más que cinco colores. Mejor piensa en Departamentos o tipos de proyectos (en cuyo caso igual estamos hablando de un kanban un poco más complicado donde podamos ver el flujo/estados por los que pasa ese proyecto)
* No he terminado de ver qué propones hacer con las tarjetas de proyectos que no se han acabado en Qn. No tengo muy claro cómo funcionarían mejor: que pasen a Qn+1 refleja la situación actual, que se queden en Qn refleja que van retrasados. Si yo tuviera que elegir, me quedaría con reflejar la situación actual porque encaja mejor con un «inspect and adapt». Al final de Qn hacemos una replanificación de todo el porfolio. (Mejor al final de cada iteración de negocio, ¿un mes, dos semanas?)
* Cuando hablas de dependencias entre proyectos me viene a la cabeza INVEST. Cuantas más dependencias entre tarjetas más mal rollo en un Scrum de desarrollo de software. Gestionar un porfolio de proyectos no debería ser muy diferente. Aunque no digo que no haya dependencias. ¿Cómo gestionarlas entonces? IMHO aumentando el nivel de abstracción y cambiando la manera de de agregar/desagregar los proyectos. (Creo que esto daría para un artículo entero)
* No sé si lo tienes previsto, pero sería un artículo muy interesante hablar de estimaciones y cómo inspeccionar y adaptar. Me gustaría mucho conocer tus experiencias ahí.
Muchas gracias por compartir, Vanesa.
Un abrazo
JMB
Gracias por tu comentario Jose.
A mi tampoco me gusta tanto la segunda, pero no deja de ser una propuesta que al verla, hace que tengan más ventajas las otras, las comparaciones son odiosas y útiles. De hecho, tengo algunos otros casos de fracaso de representaciones, que publicaré porque son los que transformándolos, te llevan luego a uno que sí puedes manejar.
* Tal y como dices, a la hora de ver más departamentos, habría que ampliar flujos/estados. En el artículo quiero hablar de que se puede empezar a hacer esta gestión visual, desde los estados y flujos mínimos, luego habría que adaptarlos a tu contexto, productos, empresa, espero poder publicar algún caso más real, donde no se vea sólo IT. Será una evolución de la idea inicial del artículo.
* Qué hacer con las que no pasan. A mi me gusta dejarlas ahí, lo que quisimos y no pudimos, creo que dejar esta constancia puede permitirte hacer un mejor balance en la revisión. ¿Quizá pedimos más de lo que podíamos obtener? Tambien, puedes tener una columa con lo que no hemos hecho este año, y en una retrospectiva pensar por qué. Quizá cuando sacas una tarjeta de la Qn o decides no hacerla, puedes poner detrás lo que pasó para tomar esa decisión. Respecto la periodicidad de las Qn, creo que esto debe ser decidido por la periodicidad con la que tu negocio varía y los proyectos que tienes plasmados, algunos pueden ser dos semanas, otros una, otros 2 meses. A mi personalmente me gusta poner por ejemplo revisar cada 2 semanas, y cuando llega esa meeting ver con el equipo de Prodcut Owners, si algo ha cambiado respecto la última vez, si nos tenemos contar algo, porque si no hay nada, nos ahorramos una sesión y tiempo.
* Las depedendecias son a veces inevitables, y los Product Owner deben trabajar para que sean las mínimas posibles o inexistentes, pero existen, y de alguna manera hay que mostrarlas. La verdad es que un artículo de esto podría ser muy muy interesante.
* Pues con tus comentarios, me han venido cosas en las que pensar y trabajar.
Muchas gracias a ti, por el tiempo que has dedicado a leer y comentar, por dar una vuelta más de tuerca al artículo, eso hace que vengan más ideas.
Un abrazo