De la especificación a la conversación

Esto me sigue dando vueltas en la cabeza, como un péndulo… entre la esperanza y la decepción. Así que aquí vamos de nuevo.

En los entornos complejos y de alta incertidumbre que sirven como manto al desarrollo lean y ágil de productos, ir de un enfoque basado en especificaciones a uno conversacional es clave para que los equipos logren entender el trabajo a realizar, alinearse y entregar valor. Mientras que los métodos tradicionales de desarrollo de productos [de software] promueven prácticas que conllevan a generar gran cantidad de documentación y especificaciones detalladas, con el pensamiento Ágil adoptamos flexibilidad, comunicación y colaboración. Una de las prácticas fundamentales en el núcleo de Ágil y Lean es el uso de historias de usuario, no como requisitos fijos sino como alarmas o avisos para sostener conversaciones.

Practiqué desarrollo de software con tales métodos tradicionales durante 2 décadas. Pero la transición de especificaciones de requisitos (con casos de uso) que implicaban generar gran cantidad de documentación escrita, y sobre lo cual escribí y publiqué un par de libros de los cuales ya no me quiero acordar, a un entorno donde las conversaciones fueran el eje principal del desarrollo, resultó una banalidad, algo sencillo de lograr. Por eso quizás no entiendo por qué hoy, muchos años después, incluso en equipos que nacieron luego de la pandemia, se sigue manteniendo la práctica de las especificaciones escritas como algo natural y común y, sobre todo, obligatorio, por aquello de “buscar responsables” de quién dijo qué y cuándo, lo que continúa fomentando una cultura de culpa y de poca o ninguna confianza en la organización.

Así que aquí voy una vez más en mi intento por ayudar a cruzar el abismo. Centrándome en las historias de usuario como medio, analizo cómo ir de una mentalidad de especificación a un enfoque conversacional en iniciativas y equipos ágiles y haré énfasis en cómo las conversaciones en torno a las historias de usuario ayudan a los equipos a lograr dos resultados fundamentales:

1. Estar conscientes y seguros de que todos los involucrados y comprometidos entiendan lo que se hará. El producto. Y
2. Tener la plena certeza de que todos entiendan lo mismo.

Es definitivo, las conversaciones son más efectivas que la documentación para lograr un entendimiento compartido, incluso en esta era digital de la comunicación virtual y los emojis.

El problema con las especificaciones escritas

Las especificaciones suelen considerarse la fuente de la verdad en la gestión tradicional de proyectos, en los cuales dedicábamos un esfuerzo superlativo a definir los requisitos durante las primeras de cambio y a escribirlos en detalle para entregarlos al equipo de desarrollo. Sin embargo, la historia nos demostró que estas especificaciones estáticas no lograban captar la naturaleza dinámica del desarrollo de productos. De toda mi experiencia pasada y presente he concluido que las especificaciones:

• Carecen de flexibilidad a medida que evolucionan los requisitos.
• Dejan espacio para malas interpretaciones.
• Retrasan la toma de decisiones hasta que se hayan acordado todos los detalles.

Pero lo más crítico es que las especificaciones escritas inhiben las conversaciones necesarias para descubrir las necesidades reales que se esconden detrás de los requisitos establecidos, el problema detrás del problema, la causa raíz. Y peor aún, con frecuencia este tipo de especificaciones hace que se levanten barreras para la colaboración y el entendimiento entre desarrolladores, interesados y usuarios.

Entran las conversaciones por doquier

Cuando lo hacemos a la usanza ágil, por el contrario, nos abrimos camino gracias a cortos ciclos iterativos de conversación y retroalimentación. Las conversaciones crean oportunidades para aclarar expectativas, sacar a la luz supuestos ocultos y refinar los requisitos del producto a medida que llega nueva información y la entendemos mejor, a profundidad.

Las conversaciones en torno a las historias de usuario actúan como base para que todos entendamos lo mismo. Ron Jeffries, uno de los pioneros del desarrollo Ágil, nos legó el concepto de las 3 C: Carta, Conversación, Confirmación. Esta estructura enfatiza que una historia de usuario es un apuntador a futuras discusiones, en lugar de un requisito fijo.

Sobre este tema he disertado mucho, primero en los artículos que dieron origen al libro Historias de usuario: una visión pragmática, especialmente en:

De historias de usuario, culturas y del arte de narrar historias

 y luego en publicaciones como:

De historias de usuario a historias de persona

Y en: Cómo tener conversaciones efectivas sobre historias de usuarios en equipos Scrum.

He aquí por qué las conversaciones importan más que las especificaciones:

• Permiten la colaboración: las conversaciones entre Dueños de producto, desarrolladores y usuarios crean un espacio para que todos compartan sus perspectivas.
• Estimulan la claridad: los malentendidos salen a la luz y se abordan rápidamente durante los diálogos, en lugar de hacerlo después de semanas de desarrollo.
• Fomentan la innovación: casi siempre, las conversaciones colaborativas conducen a ideas y soluciones que casi nunca emergen de documentos estáticos.

Como marco reiteradamente en las publicaciones que mencioné hace unos instantes, una historia de usuario “bien” hecha genera discusiones que determinan detalles clave de la funcionalidad, criterios de aceptación y limitaciones técnicas.

De lo estático a lo dinámico: conversaciones sobre historias de usuario

En la práctica, el paso de la especificación a la conversación se puede lograr centrándose en el modelo de las 3 C:

1. Carta

La historia del usuario en sí es sencilla: una o dos frases que describen quién es el usuario, qué quiere lograr y por qué es importante. Por ejemplo:

Como cliente, quiero iniciar sesión en mi cuenta para acceder a contenido personalizado.

La carta o tarjeta es deliberadamente breve porque no pretende contener toda la información. Sirve como recordatorio para una futura conversación con todos los interesados.

2. Conversación

Este es el elemento más importante del proceso. Las conversaciones tienen lugar durante la planificación del sprint, el refinamiento del backlog y durante todo el ciclo de desarrollo. Las piezas clave que se analizan incluyen:

• El contexto de la necesidad del usuario.
• Posibles soluciones.
• Riesgos y dependencias.
• Aclaraciones sobre la intención del usuario y los resultados deseados.

En la era de la comunicación virtual, las conversaciones cara a cara siguen siendo el método más eficaz para generar entendimiento, como lo sugiere el Manifiesto Ágil. Las herramientas digitales como las videollamadas, las plataformas colaborativas e incluso los tableros simples pueden salvar las brechas cuando las discusiones en persona no son posibles. ¡Las cosas así, no lo retrases más, enciende la cámara!

3. Confirmación

Una vez que entendemos por completo la historia del usuario, definimos los criterios de aceptación y tanto el equipo de desarrollo como los demás interesados confirman el alcance del trabajo. Estos criterios de aceptación ayudan al equipo a medir si hemos cumplido con las necesidades del usuario y a garantizar que las expectativas de todos coincidan.

Si todavía estas 3 C no son suficientes, desde hace algunos años propuse la cuarta C. Pueden encontrar más de esto en: Las historias de usuario se cuentan con C de Contexto.

Técnicas para fomentar conversaciones efectivas

1. Mapa de historias de usuario

El mapeo de historias ayuda a los equipos a visualizar el recorrido del usuario y priorizar las funciones de manera eficaz. Fomenta la colaboración al hacer que la experiencia del usuario sea el foco central e impulsar conversaciones sobre qué historias brindan el mayor valor desde el principio.

Más sobre esto en: User Story Mapping – Una introducción.

2. Ejemplos sobre especificaciones

En lugar de escribir requisitos exhaustivos, usualmente fomento que los equipos trabajen con ejemplos que ilustren la intención del usuario. La práctica del desarrollo conducido por el comportamiento (BDD) es una excelente manera de convertir las historias de usuario en escenarios que se analizan y perfeccionan con el aporte de los interesados.

Publiqué sobre este asunto en: Historias de usuario basadas en el comportamiento.

3. Personas de usuario

Para evitar la abstracción de los roles de usuario típicos, recomiendo elaborar personas: estas son descripciones detalladas de usuarios típicos con necesidades, preferencias y comportamientos específicos. He comprobado cómo esta práctica ayuda a fundamentar la conversación en la realidad, lo que facilita que los equipos empaticen con los usuarios y elaboren mejores soluciones.

Este es un ejemplo de una Persona:

4. Inspecciones frecuentes

Los equipos ágiles deben revisar periódicamente las historias de usuario con los interesados para garantizar que la comprensión se mantenga alineada a medida que surge nueva información. Las sesiones de refinamiento del backlog son ideales para estas conversaciones continuas.

Sobre refinamiento puedes encontrar en: Sobre el Incremento de Producto y el Refinamiento.

En Cómo tener conversaciones efectivas sobre historias de usuarios en equipos Scrumexplico más sobre todo esto.

Ejercicios para cambiar a una mentalidad conversacional

Para ayudar a los equipos a pasar de una mentalidad de especificación a una mentalidad de conversación, pruebe estos ejercicios:

• Talleres de historias de usuario: realiza sesiones en las que los equipos creen historias de usuario juntos, seguidas de conversaciones en las que jueguen roles como desarrolladores, Dueños de producto y usuarios para aclarar las historias. He desarrollado un taller al que precisamente llamé “Conversation-Driven Development” y que te puede servir. Mientras lo hago público, contáctame para conocer los detalles.
• Planificación de sprint basada en conversaciones: comienza las sesiones de planificación de sprint discutiendo historias de usuario y haciendo preguntas aclaratorias antes de finalizar el trabajo.
• Integración de la retroalimentación de clientes: incorpora con frecuencia la retroalimentación de los usuarios finales en las conversaciones para refinar las historias de usuario y reordenar las funciones basado en las necesidades reales.

¿Y los desafíos en entornos virtuales?

Sí. De acuerdo. En la cultura actual de trabajo remoto, los equipos pueden verse tentados a sustituir las conversaciones por mensajería digital o herramientas de colaboración. Sin embargo, como he enfatizado en distintas publicaciones y entornos, la comunicación basada en texto carece de la riqueza de las conversaciones en tiempo real y puede dar lugar a malentendidos. Si bien las herramientas virtuales como Slack, Zoom, Jira o MS Teams son útiles, deberían complementar, no reemplazar, las conversaciones verbales. Los equipos deberían intentar recrear el flujo de las discusiones en persona a través de videollamadas y sesiones de tableros en línea.

Entra la inteligencia artificial (IA)

Es infructuoso desligarse de este asunto, pero no seré condescendiente sobre el papel que juega la IA en la transición de una mentalidad de especificación a una de conversación.

Si bien es cierto y he comprobado que la inteligencia artificial puede desempeñar un papel clave al ayudar a los equipos ágiles a pasar de una mentalidad centrada en especificaciones a una basada en conversaciones, agilizando y mejorando las interacciones, también puede, al menos en el estado actual de las cosas, llevarnos por caminos inútiles plagados de limitaciones y consideraciones que debemos tener en cuenta.

La IA puede ser útil para:

1. Automatizar conversaciones rutinarias: He utilizado chatbots potenciados por IA para gestionar consultas repetitivas y mantener conversaciones dentro de equipos distribuidos. Por ejemplo, la IA me recuerda reuniones de refinamiento o me ayuda a solicitar aclaraciones cuando una historia de usuario no está clara. Nada nuevo aquí.
2. Mejorar la colaboración en tiempo real: Con herramientas de IA, podemos transcribir, resumir y resaltar puntos clave de reuniones, lo que facilita la retención de ideas y la reflexión posterior sobre las conversaciones. Además, la IA puede analizar estas interacciones y señalar desalineaciones o sugerir acciones basadas en conversaciones anteriores. ¡Esto sí que es algo que merece exploración y uso! Recomendado.
3. Análisis basado en datos: La IA nos ofrece perspectivas analíticas al procesar datos históricos de historias de usuario, ciclos de desarrollo y retroalimentación. Con esto, hemos tomado decisiones más informadas durante las discusiones. La productividad aumenta considerablemente. Sin el efecto colateral del estrés.

Pero ojo, la IA no nos sirve para:

1. Empatizar y lidiar con los matices humanos: La IA no tiene la inteligencia emocional necesaria ni suficiente para entender el contexto humano, la intención o el tono. Las conversaciones que requieren empatía, como entender necesidades de usuario más sutiles o resolver conflictos, dependen de mi intervención directa. ¡Comprobado!
2. Facilitar de conversaciones profundas: Aunque la IA me ayuda a procesar información, no es adecuada para fomentar las discusiones profundas y creativas que son esenciales para la innovación. Estas charlas requieren diversas perspectivas emocionales y contextuales que la IA no puede replicar. ¡Es definitivo!

Entonces, cuando se trata de IA, estás son las precauciones que debes tomar:

1. Depender en exceso de la IA: A ver, repite conmigo: “No debo depender demasiado de la IA para tomar decisiones o resolver problemas”. La IA debe complementar, no reemplazar, la interacción humana. En el desarrollo lean de productos, las conversaciones significativas son esenciales, y si delego demasiado en la IA, puedo perder puntos de vista valiosos o, peor aún, debilitar la colaboración.
2. ¡Cuidado con los sesgos! Los modelos de IA se basan en datos históricos y, sin duda alguna, estos modelos contienen sesgos. Son sesgos que influyen en las conversaciones limitando el pensamiento creativo o reforzando patrones de comunicación desactualizados.

Así que, aunque la IA puede mejorar la productividad y agilizar procesos rutinarios, como seres humanos debemos preservar el núcleo de Ágil: la conversación efectiva entre personas. Cuando se trata de inteligencia artificial, no subestimes tu poder humano y “humanizante” de pensar. ¡Funciona para mí!

En el cierre

Me extendí algo lo sé. Pero se los dije al inicio, esto me sigue dando vueltas en la cabeza, como un péndulo… Sin embargo, cada oscilación me acerca un poco más a encontrar mi equilibrio. De hecho, pueden solicitarle a una IA que les haga un resumen con los puntos más relevantes. O simplemente se pueden quedar con esta última reflexión, a manera de epítome:

La transición de una mentalidad basada en especificaciones a una mentalidad conversacional ayuda a los equipos a crear mejores productos más rápido. Al enfocarnos en las conversaciones sobre las historias de usuario, logramos alineación y claridad, al tiempo que fomentamos la colaboración y la innovación. Las conversaciones, no las especificaciones escritas, son la herramienta más poderosa en el desarrollo lean de productos para garantizar que todos entiendan lo mismo y que el producto brinde un valor real a los usuarios.

Después de todo, Ágil no consiste en hacer más documentación, sino en tener mejores conversaciones. Me gusta escribir, lo disfruto y es una de mis pasiones desde que tengo memoria, pero cuando se trata de crear y desarrollar productos es mejor conversar que escribir. ¡Empecemos a hablar!