¿Estás buscando una técnica para ordenar y activar las ideas que surgen al crear/modificar/rehacer un producto? En este post te cuento en qué casos puedes usar Impact Mapping.

Impact mapping es una actividad que puedes realizar para todo aquello a lo que quieras dedicar un esfuerzo, y que tenga tal entidad que se te haga un mundo saber por dónde empezar.

Puedes usarlo a nivel de equipo o a nivel individual, para ti mism@ o para ayudar a cualquier persona que se vea perdida en un mar de ideas.

Con el Impact Mapping, trabajamos para conseguir una serie de acciones concretas que van a ayudar a focalizar el trabajo hacia un objetivo.

Si te estás preguntando en qué ocasiones te puede servir, ahí van unas cuantas ideas:

Usos del Impact Mapping

Para reinventar un producto

Estás trabajando en un producto determinado. Todo va bien. Pero… (siempre hay un pero 😉), podría ir mejor. Esto significa que aunque se estén cumpliendo los objetivos marcados (juntamente o no con la parte de negocio), hay algo que no acaba de enganchar al cliente. Se han realizado algunas encuestas y hay variedad de respuestas que no aclaran el problema.

La necesidad en este caso sería «Enganchar al cliente final»

Para plantear una refactorización técnica

Cuántas veces nos ha pasado que el producto se esté quedando obsoleto, técnicamente hablando. No vamos a entrar en el detalle de qué tipo de refactorización sería necesario, pero estaremos de acuerdo en que sea la que sea se nos hace siempre una montaña… además que podría pasar que en el equipo se crearan discusiones sobre cuál sería la mejor solución, cada una con sus ventajas y sus inconvenientes. Así pues, una vez decidida a través de técnicas de priorización cuál sería la refactorización a tener en cuenta, podrías usar Impact Mapping.

Con Impact Mapping generarás el orden y las acciones suficientes para llegar a acuerdos útiles.

La necesidad en este caso sería: «Refactorizar XXX»

Para cubrir una necesidad específica

A veces en las propias retrospectivas salen acciones que parece que no puedan llevarse a cabo a muy corto plazo, tan corto como para ponerlas en el siguiente sprint.

Imaginemos un caso muy concreto: hemos detectado errores repetitivos que en la mayoría de los casos no son por problemas técnicos sino por cómo el usuario introduce sus datos o cómo diferentes bases de datos guardan ciertos valores. Las acciones al respecto pueden llevar toda una serie de pasos a trabajar con otros equipos e incluso departamentos. Para tener claro quien puede intervenir, cómo podemos ayudarles y qué hacer, podemos usar esta actividad.

La necesidad en este caso sería «Minimizar errores repetitivos ajenos a nuestro código»

¿Podemos usar Impact Mapping para generar backlog?

Raramente sucede, pero podría pasar. Generar backlog no debería ser una necesidad tal como para realizar este tipo de actividad, sino que podríamos investigar primero qué necesidades creemos que tenemos en nuestro producto, a través de feedback en encuestas, entrevistas directas, métricas de calidad, etc… y tras listarlas y priorizarlas, trabajar el Impact Mapping con la que consideremos más prioritaria.

¿Podemos usar Impact Mapping para empezar un producto desde cero?

En este caso yo no lo recomendaría. Desde mi punto de vista para empezar con un producto es mejor realizar una «Inception Deck», en la que podemos invitar directamente a todos las personas o equipos involucrados de manera que ya empezaríamos desde cero compartiendo la necesidad y el conocimiento. Creando entre todos.

Práctica

Usando Impact Mapping puedes conseguir abrir un abanico de opciones y posteriores acciones concretas que te servirán para plantear hipótesis y probarlas.

Si has decidido que ésta es la técnica que cubrirá tu necesidad, aquí tienes como hacerlo.

La técnica trata básicamente de contestar cuatro preguntas:

  1. ¿POR QUÉ?: Basta con saber qué nos ha traído a realizar esta actividad. El facilitador puede dar el título de la necesidad, pero el valor lo aporta el hecho que todos los participantes trabajemos cubriendo la misma expectativa. Por este motivo normalmente suelo pedir que cada uno escriba por libre el motivo de lo que queremos conseguir. ¡CUIDADO! No se trata de dar soluciones, sino de explicar el objetivo al que queremos llegar. Este punto termina cuando compartimos todos nuestras expectativas y llegamos a un acuerdo.
  2. ¿QUIÉN?: En este punto, los participantes deberán pensar en personas o equipos que puedan hacer algo sobre los motivos que nos traen aquí. Si no tenemos dependencias externas de ninguna clase parecerá que todo recae sobre nosotros mismos, pero estamos hablando de un producto, y puede que podamos involucrar a otros equipos técnicos, stakeholders, usuarios finales… Incluso pueden estar en la sesión si lo consideramos necesario.
  3. ¿CÓMO?: Aquí lo que pretendemos contestar es ¿Qué camino debemos seguir para que las personas/equipos/roles de la segunda pregunta puedan conseguir lo de la primera? El riesgo de esta pregunta es tirar pelotas fuera 🙁 por lo que recomiendo que lo pensemos desde un punto de vista de colaboración para con ellos.
  4. ¿QUÉ?: Para terminar nos preguntaremos para cada una de las ideas del tercer punto, ¿Qué acción/es en concreto podemos hacer para conseguir esas ideas con las personas/equipos/roles del segundo punto?

Tras obtener todas las acciones podemos también priorizarlas: por ejemplo, a través de una matriz de impacto vs esfuerzo, de forma que pudiéramos detectar rápidamente los «quick wins» (aquello que impacta más y tiene menos esfuerzo)

Espero que os sea una actividad muy útil. Ya sabéis que podéis usar los comentarios para dejar vuestra experiencia o si os surge alguna duda y os atenderé encantada.

Como siempre, ¡un placer compartir mi experiencia con vosotros!

5 (2 votos)

Deja un comentario