Impact Mapping

¿Cómo aseguramos que las entregas de software acercan o alejan a la empresa del cumplimiento de sus objetivos?

¿Debería la empresa continuar invirtiendo en funcionalidad que corresponde a un tema en particular?

¿Dónde están los “quick wins”, riesgos o suposiciones clave y cómo se podrían validar lo más rápido posible? ¿Cuál es el retorno de la inversión de las entregas?

¿Cómo sabemos si la funcionalidad es la correcta? ¿Cómo podemos visualizar el camino hacia el cumplimiento de los objetivos? ¿Qué alternativas tenemos?.

Las respuestas a estas preguntas se podrían facilitar teniendo el “big picture” a través de Impact Maps.

“Impact Mapping” o “Mapeo de impacto” o “Mapas de Impacto” (¡como prefieran llamarlo!) es una técnica colaborativa creada por Gojko Adzic para visualizar conexiones y tomar decisiones en base a los objetivos del negocio, actores y los impactos que se desea generar en su comportamiento a través de entregables tangibles.

Esta técnica intenta en primer lugar descubrir los objetivos del negocio y las métricas necesarias para medir el cumplimiento de estos objetivos en el tiempo. Con los Impact Maps estamos cambiando de un enfoque operativo a un enfoque estratégico logrando así mejores resultados.

Entregar software de calidad predeciblemente utilizando Lean, Kanban o Scrum no es suficiente. No solo se trata de resultados rápidos, de lo que se trata es de tener la capacidad de cambiar rápidamente de dirección cuando se descubra que el camino es incorrecto teniendo a los objetivos del negocio (no necesariamente del producto) en contexto.

Es como un GPS que recalcula la ruta cuando se escoge otra alternativa o se equivoca la calle a medida que uno se aproxima a su destino.

Objetivo (Why?) – ¿Para Qué?

El enfoque es en identificar los objetivos y luego cuestionar el “por qué”. Para clarificarlos preferiría preguntar “para qué”. Este último es un término que abre más posibilidades.

El “para qué” implica entender los objetivos para mas adelante identificar la manera mas rápida de cumplirlos irrespectivamente del ámbito del software por lo que no necesariamente están relacionados a la construcción de productos o entrega de funcionalidad.

Se presenta como el problema a resolver. Es especifico, es decir está expresado en términos positivos y claros, es medible y responderá a la pregunta: ¿Cómo se sabrá que se logró? ¿Como resultado va a generar ahorro, ganancia o proteger el capital? (aquí la relevancia del “para qué”).

Se trata de llevar el objetivo a $$$ en la medida de lo posible. El objetivo está contextualizado:

• ¿Cuándo se quiere lograr el objetivo y qué recursos se tienen disponibles para lograrlo?
• ¿Cuáles son los recursos mas útiles? (físicos/intelectuales/económicos/tiempo
• ¿Qué recursos faltarían?
• ¿Es realista el objetivo?.

Todas estas preguntas son válidas para descubrir y entender los objetivos. Es importante dedicar el tiempo necesario para asegurar que sean SMART.

Actores (Who?) – ¿Quiénes?

Influencian en el éxito del proyecto.

• ¿Quiénes pueden producir/obstruir el efecto deseado?.
• Podrán ser usuarios finales, personal interno, tomadores de decisiones, inversionistas, stakeholders, etc.

Identificar actores primarios y secundarios.

Impactos (How?) – ¿Cómo?

Coloca a los actores en la perspectiva de los objetivos.

• ¿Cómo debería cambiar el comportamiento de los actores?
• ¿Cómo nos podrían ayudar a alcanzarlos? o de lo contrario,
• ¿Cómo podrían causar obstrucción en el cumplimiento de los objetivos?

Priorización: ¿Qué impactos ayudan a entender mejor los riesgos? La idea aquí no es tratar de listar todo lo que el actor quiera lograr, sino lo que está alineado a los objetivos.

Entregables (What?) – ¿Qué?

Aquí se mapean entregables a objetivos del negocio a través de los impactos y actores. ¿Qué podemos hacer como organización o equipo para soportar los impactos?

Se incluye funcionalidad de software y actividades de valor. Se refina iterativamente. Aquí se podrían mapear épicas (épica es una historia de usuario muy grande) del backlog e incluso ir bajando de nivel hasta desagregarlas en historias de usuario a varios niveles.

Podrían incluirse actividades que no tengan nada que ver con el producto que estamos construyendo en la medida que puedan ayudar a alcanzar los objetivos.