Descubriendo el qué: Mapas de Impacto

En estos últimos meses, desde 233 hemos estado trabajando en proyectos utilizando BDD (Entendiendo que es BDD 1/5), lo que nos ha llevado a entender el proceso mucho mejor, y hemos ido descubriendo técnicas y aprendiendo nuevas formas de descubrir QUÉ es lo que se quiere desarrollar.
Después de haber pasado ya por unas cuantas empresas, hay una cosa que no falla, es el clásico de los clásicos y es que todo el mundo sabe que hay que hacer algo, pero muy pocos, o prácticamente nadie tiene claro QUÉ es lo que se va a desarrollar. Todos tienen una vaga idea del producto que se necesita, y en la mayoría de casos saben algunas de las funcionalidades que quieren, pero en el momento de definir algo específico, de definir historias de usuario, pantallas y ejemplos siempre nos topamos con las mismas dificultades.
Desde nuestro punto de vista, el técnico, esto siempre es fuente de frustración. Hay formas de ayudar a negocio a definir estos escenarios y de presentárselo de forma que no le provoque rechazo (Tidy-Gherkin: Cómo convencer y venderle a tu jefe el uso de ATDD – BDD – Gherkin), pero esto solo ayuda a que ellos describan lo que quieren, el problema es que ellos averigüen QUÉ es lo que quieren, y que esto esté alineado con sus necesidades y que aporte valor real.
Hay diferentes técnicas que ayudan en este aspecto, ya hablamos de los Agile inceptión, que ayudan al inicio de un proyecto a hacer las preguntas correctas y despejar aquellas incógnitas que pueden descarrilar un proyecto, pero en este caso quiero hablaros de otra técnica visual desarrollada por Gojko Adzic, los mapas de impacto, que se puede utilizar en conjunto con el Inception.

Mapas de impacto

Un mapa de impacto es un mapa mental construido durante una conversación, o serie de conversaciones entre stakeholders y miembros del equipo de desarrollo. La conversación se centra alrededor de cuatro tipos de cuestiones:

  • ¿Porqué?
  • ¿Quién?
  • ¿Cómo?
  • ¿Qué?

La primera pregunta que hay que hacerse para construir correctamente software es ¿Porqué?, es decir, ¿cuales son los objetivos de negocio? Visualmente, cada mapa de impacto empieza con un objetivo de negocio en el centro.
why
La segunda pregunta es: ¿Quién?, hay que averiguar quienes son los interesados a los que les afecta el producto, los usuarios del producto, quién se beneficia de los resultados, quienes son tus clientes… Es importante hacer este ejercicio para conseguir un objetivo de negocio hay que entender correctamente el contexto en el se está realizando el desarrollo.
who
La siguiente cuestión que hay que preguntar es ¿Cómo?, es decir, cómo pueden los usuarios y los stakeholders contribuir a conseguir este objetivo de negocio. Aquí es donde se analiza cómo el sistema podría ayudar a los stakeholders a contribuir al objetivo de negocio, como se puede influir en su comportamiento y animarles a que contribuyan de otras maneras.
how
La última cuestión a plantear es ¿Qué?, ¿qué puede hacer tu aplicación para apoyar los impactos listados en las tres etapas mencionadas previamente? En el contexto del desarrollo software el “qué” corresponde a funcionalidades de alto nivel, que probablemente haya que dividir en características más detalladas mientras va avanzando el entendimiento de estas necesidades, hasta que se obtenga un tamaño aceptable. En un proyecto ágil, estas características son buenos candidatos para historias de usuario de alto nivel o épicas.
what
Los mapas de impacto ayudan a visualizar cómo las características y los entregables contribuyen a un objetivo de negocio. También ayudan a destacar cualquier suposición que estés haciendo, dado que se pueden visualizar.
Es importante recordar que los mapas de impacto no son planes, son iterativos, documentación viviente que te ayuda a visualizar suposiciones y relaciones entre características y objetivos de negocio. En el momento que se haga una entrega y una salida a producción, se deberá de poder validar estas suposiciones y comprobar las que son erróneas.
Los mapas de impacto son simples y son un acercamiento conveniente para construir un esbozo de lo que se quiere conseguir con un proyecto. Los mapas de impacto son visuales e intuitivos, rápidos de dibujar y accesibles tanto para gente de negocio como el equipo técnico.
Los mapas de impacto pueden utilizarse también con otro propósito, de forma bastante efectiva. Hagamos la suposición de que ya se tiene un set de características propuestas: un product backlog en un proyecto ágil, un set de casos de uso, o incluso un set de requisitos de alto nivel. Supongamos además que las características provienen de distintos stakeholders, que están convencidos de que “su” característica debería de hacerse la primera.
En este caso, un mapa de impacto sirve para iniciar la conversación entre stakeholders. Se ponen las características en un tablero, y se identifica quién se va a beneficiar y cómo, trabajando hasta averiguar los objetivos de negocio subyacentes. Finalmente se obtendrá un grafo que muestra una serie de objetivos, con una ilustración relativamente clara de cuál característica se relaciona con cuál objetivo. Gracias a esto se podrá iniciar una discusión sobre cuál es el mérito relativo de cada objetivo y de cada característica lo que facilitará mucho la priorización de las diferentes características de forma objetiva.
En definitiva, esta técnica es especialmente efectiva a la hora de despejar esa maraña de intereses que se forma al tener un desarrollo con múltiples stakeholders.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Descubriendo el qué: Mapas de Impacto”

    1. No es lo mismo, dado que el stakeholder analysis pone el énfasis en los stakeholders, priorizándolos y viendo cómo les va a afectar el proyecto (de forma muy resumida).
      Los mapas de impacto ponen el énfasis en el producto, definiéndolo con trazabilidad hacia los objetivos de negocio.
      Son técnicas que tienen objetivos distintos.

      1. A mí me sigue dando la impresión de que es lo mismo.
        PRINCE2 gestiona por productos y uno de sus principios es la justificación comercial continua.
        Del manual oficial «Managing Successful Projects with PRINCE2»:
        The purpose of a project is to fulfil stakeholder
        expectations in accordance with the business
        justification, and to do this there must be a
        common understanding of the products required
        and the quality expectations for them. The purpose
        of a project can be interpreted in many different
        ways unless there is an explicit understanding
        of the products to be produced and the criteria
        against which they will be individually approved

        Y sobre el Business Case:
        The Business Case presents the optimum mix of
        information used to judge whether the project is
        (and remains) desirable, viable and achievable, and
        therefore worthwhile investing in.
        The Project Board and stakeholders must have
        confidence at all times that the project remains
        viable. In PRINCE2, the Business Case provides the
        vital test of the viability of the project. It provides
        the answer to the question: is the investment in
        this project still worthwhile?
        Since this viability question is ongoing, the Business
        Case is not static. It should not be used only to gain
        initial funding for a project, but should be actively
        maintained throughout the life of the project and
        be continually updated with current information
        on costs, risks and benefits.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *