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.
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.
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.
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.
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.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Lo que viene a ser el stakeholder analysis de toda la vida de PMI y (más todavía) de PRINCE2
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.
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.