En otros posts, hemos podido repasar diferentes herramientas y labores que puede realizar un Product Owner que no viene indicado en la Scrum Guide. Una de las herramientas que descubrí hace unos años y que me parece brutal es el Impact Mapping. Desde hace mucho tiempo, llevo combatiendo el cambio de paradigma de muchas organizaciones que basan el éxito de un equipo en la entrega de software en una fecha concreta (lo que define el PMI como proyecto) versus la entrega de valor constante (modo producto). El Impact Mapping es una herramienta que nos puede ayudar en este cambio. Os desmenuzamos el libro que escribió su autor Gojko Adzic.
¿Qué es el Impact Map?
La definición formal es la siguiente: “Un Impact Map es una visualización del alcance y los supuestos subyacentes, creados en colaboración por personas de alto nivel técnico y de negocio. Es un mapa mental que crece durante una discusión facilitada respondiendo las siguientes cuatro preguntas: ¿Por qué? ¿Quién? ¿Cómo? ¿Qué?”
Por tanto, es un ejercicio visual en el que las personas de negocio y tecnología colaboran estrechamente sobre lo que vamos a construir. Para mí, es una técnica potente que nos permite sacar a la luz el negocio y relacionarlo con la tecnología. Esto nos permite hacer un mejor Scrum, porque podemos iterar en torno al negocio y no al alcance en fecha. Y además, el Impact Map nos permite alinear expectativas de los diferentes interesados en nuestro producto.
Para poder usar esta técnica, lo que hacemos es realizar cada una de las cuatro preguntas anteriores en orden para ir profundizando en nuestro producto. ¡Repasamos cada una de ellas!
¿Por qué?
Según el autor, muchas personas no entienden el objetivo de negocio esperado por su organización. Y ocurre, muchos desarrolladores no entienden el papel de su producto en la empresa, y cómo están ayudando a la misma. Es vital conocer el valor de negocio ya que Scrum se basa en maximizar el valor que genera el Scrum Team.
Para poder sacar a la luz estos objetivos, utilizamos la pregunta “¿Por qué?”. A veces, los objetivos y la visión del producto ya existe, pero están en la cabeza de las personas de negocio, no siendo compartida con el resto. Por tanto, es importante co-crear el Impact Map para que después el Product Owner la utilice con los interesados de negocio de la organización de cara a gestionar expectativas.
El autor nos recomienda que para definir los objetivos, usemos la regla SMART (Específicos, Medibles, Orientados a la acción, Realistas y con Tiempo). Además, debemos evitar que el objetivo esté escrito en forma de “alcance”, por ejemplo: “queremos XXX para la fecha YYY”. Esto no es un objetivo de negocio. En productos comerciales, tratamos de definir objetivos que estén relacionados con el dinero, por ejemplo: “incrementar la conversión de usuarios un 20% en tres meses”.
¿Quién?
El siguiente paso relacionamos a las personas afectadas o relacionadas con ese objetivo que hemos definido: los actores. Para ello, Adzic nos propone una serie de preguntas que debemos ser capaces de responder:
- ¿De quién queremos cambiar su comportamiento?
- ¿En quién deseamos producir un efecto?
- ¿Quién puede bloquearlo?
- ¿Quién es el usuario o el consumidor de nuestro producto? ¿Quién será impactado por él?
Entender al usuario es entender el valor que espera recibir. Muchos modelos de toma de requisitos ignoran al usuario, solo se centran en lo que el software hace, pero no en el beneficio que genera y en quién lo genera. Además de tener en cuenta al usuario, debemos de gestionar las expectativas de todas las personas que pueden ser afectadas por nuestro producto. Puede aparecer un actor con poder de decisión que nos pare el desarrollo por lo haberlo tenido en cuenta.
El Impact Map piensa en todos los tomadores de decisiones, grupos de usuarios y segmentos de clientes. Mapeando los diferentes actores, podemos trabajar mejor, por ejemplo, satisfaciendo primero a los actores principales. Para realizar este mapeo, Adzic nos define tres niveles de actores
- Primarios: aquellos que son impactados directamente.
- Secundarios: aquellos que proveen servicios.
- Terciarios: los que tienen interés pero no están directamente relacionados.
Un ejemplo muy típico es una casa de apuestas. Nuestros jugadores serían actores primarios, los administradores de la plataforma serían secundarios y hacienda sería de tipo terciario.
¿Cómo?
Ahora llegamos a la parte más interesante: los impactos. Los impactos tratan de responder a diferentes preguntas “cómo”, el autor nos propone las siguientes:
- ¿Cómo deberían nuestros actores cambiar su comportamiento?
- ¿Cómo pueden ellos ayudarnos a conseguir el objetivo?
- ¿Cómo pueden bloquearnos o prevenirnos para conseguir el éxito?
Es decir, debemos impactar en nuestros actores para que alcancen los objetivos.
Antes de seguir, hagamos un pequeño apunte sobre la pregunta “cómo”. En Scrum los responsables del “cómo se hace” es el Development Team. Esto, sigue sin cambiar, en el Impact Map distinguimos entre “cómo impactar” (labor del Product Owner) de “cómo desarrollar” (Development Team).
En este nivel estudiamos los cambios deseados en el comportamiento de los actores. Diferentes actores podrían ayudarnos o bloquearnos de muchas maneras en nuestro camino para conseguir nuestros objetivos de negocio. Algunos impactos pueden concurrir, otros ser conflictivos y otros complementarios. Definiendo estos impactos, podemos determinar cuales son más relevantes para conseguir el objetivo y tendremos que atender en primer lugar. ¡Tendremos que priorizar!
A la hora de definir impactos, es mejor evitar escribir todo lo que un actor podría querer lograr. Escribe solo los impactos que realmente nos ayudan en la correcta dirección del objetivo que queremos conseguir. Un impacto no es una funcionalidad de un producto, evitar escribir lista de requisitos, hay que centrarse en los objetivos.
Un impacto ideal, se centra en cómo cambia el comportamiento, no en el comportamiento en sí. Tratamos de mostrar cómo la actividad cambia, por ejemplo, en vez de escribir “vender tickets”, podemos poner “vender tickets cinco veces más rápido”. También es buena idea considerar impactos negativos.
Ejemplos de impactos pueden ser: invitar más amigos o vender tickets sin que haya llamadas al call center.
¿Qué?
Una vez tenemos los objetivos, actores e impactos, podemos hablar del alcance. Este nivel debería poder definir el qué vamos a hacer para conseguir esos impactos, ¡los entregables!
Cuando tenemos un análisis funcional tradicional, acabamos teniendo un listado de cosas sin ningún contexto que explique por qué son importantes. Con un Impact Map podemos saber qué objetivo de negocio queremos acometer, sobre qué usuarios impactamos y cómo lo hacemos. De esta manera facilitamos la capacidad de un Product Owner a la hora de priorizar lo que es importante y de lo que no.
Un Impact Map pone todos los entregables en el contexto del impacto que tratan de ayudar a realizar. Esto nos puede ayudar a seleccionar los entregables que tendrán un gran valor de manera temprana. Con todo ello, un Product Owner puede gestionar mejor las expectativas de los interesados.
Este nivel es el menos importante de un Impact Map, no intente empezar por este nivel. Trate de iterar y refinarlo contínuamente. No es buena idea entrar en mucho detalle de manera temprana, los entregables son opciones, no todo lo que se escriba se desarrollará.
Ejemplos de entregables pueden ser: venta de tickets por internet u optimizar los scripts del call center.
¿Métricas?
Una de las partes más interesantes del Impact Map es la definición de métricas para saber si conseguimos los objetivos. De esta manera, si disponemos de métricas, podemos obtener los impactos necesarios para conseguirlo. Por tanto, todos los objetivos deben ser medibles, en vez de escribir “tener más usuarios”, escribir “tener 5.000 usuarios nuevos”.
El primer consejo es evitar métricas de vanidad, es decir, aquellas que hacen que la gente se sienta bien pero que realmente no aportan valor, como por ejemplo el número de horas imputadas del equipo. Debemos de tener métricas que lleven al equipo a la acción.
A la hora de definir métricas es bueno identificar diferentes datos relevantes:
- ¿Qué queremos medir? – Jugadores activos mensualmente
- ¿Cómo lo vamos a medir? – Nuestra base de datos
- ¿Cuál es la situación actual? – 350.000
- ¿Cuál es el mínimo valor para que sea rentable? – 750.000
- ¿Cuá. es el valor deseado? – 1.000.000
De esta manera, no se trata sólo de definir métricas y números deseados, se trata de estudiar bien nuestros objetivos.
Cómo escribir y consejos para hacer un taller de Impact Mapping
A la hora de escribir un Impact Map, los pasos que se recomiendan son los siguientes:
- Escribir en profundidad un objetivo concreto (el más relevante): objetivo, actor principal, impacto y entregables.
- Escribir alternativas en cada nivel, de manera que valores otras opciones.
- Hacer una votación a nivel de impactos para descubrir cuál podría ser más relevante acometer.
- Profundizar en más entregables de los impactos más votados.
A la hora de desarrollar un taller para construir un Impact Map debemos tener cuidado con algunos errores comunes. Por un lado, cuidado con invitar a demasiadas personas en la primera construcción. Si muchas personas deben participar, es mejor hacer una primera sesión con un grupo reducido (menos de 10 personas) y una segunda sesión con el resto. Hacer un Impact Map de cero con muchas personas puede ser poco productivo.
Otro consejo esencial es tratar de no invitar a las personas erróneas. Es esencial mezclar a personas técnicas con las personas que toman las decisiones. Sin estas últimas, puede ser un ejercicio inútil. Si no invitamos a gente técnica, puede salir un producto maravilloso qué no se puede desarrollar. Lo ideal es contar con personas de alto nivel que puedan opinar, pero a veces solo querrán listar las funcionalidades del producto. Si ves que no tienen mucho interés en participar, es mejor cortar el taller y buscar otras alternativas.
Es esencial disponer de una sala que nos permita tener espacio para pensar, que podamos dibujar, escribir y borrar. Disponer de pizarras blancas es una de las mejores opciones donde podamos discutir; se recomienda en este tipo de talleres evitar monitores o presentaciones en PowerPoint.
No trates de alcanzar la solución final muy rápido, intenta que haya momentos de divergencia que nos permita disponer de opciones, así se generarán discusiones más ricas que nos lleven a un mejor producto.
En grupos donde haya una persona que lidere todas las discusiones, trate de dividir el grupo en otros más pequeños que trabajen por separado y así evitar que las ideas sean dirigidas.
La importancia del Impact Mapping
Hacer un Impact Map puede parecer un taller más de los muchos que existen como el User Story Mapping o el Work Breakdown Structure. Para mí, la diferencia estriba en el foco en los objetivos. En mi experiencia, muy pocas veces teníamos claro porqué hacíamos algo, y esto puede facilitar esa conversación. El éxito de un equipo Scrum es que pueda iterar sobre el negocio y esto supone dar soluciones de manera contínua a los usuarios de nuestro producto. Para que esto pueda ocurrir, debemos saber el objetivo de nuestro software, que tratamos de mejorar o de conseguir. Por tanto, recomiendo este tipo de prácticas sobre otras que pongan el foco en el alcance como un listado de cosas a hacer.
Y tú, ¿cómo sacas a la luz los objetivos de negocio?
Genial artículo Javier donde se explica perfectamente ¿Por qué?, ¿Quién?, ¿Cómo?, y ¿Qué? se quiere obtener y realizar un Impact Mapping. Muchas gracias por compartir.