Refinado, pero no agitado.

"Solo porque algo funcione no significa que no pueda ser mejorado", Black Panther.

Quiero compartir contigo algo que para mí ha sido muy importante y ha marcado una diferencia sustancial en el éxito de proyectos en los que me he embarcado. En este artículo me gustaría contar dos experiencias muy diferentes centradas en la importancia del refinamiento, el poder de las historias de usuario y el beneficio de establecer buenos hábitos con el cliente desde el inicio del proyecto. Y es que no podemos subestimar la importancia de establecer unos buenos hábitos con nuestro cliente en los primeros días. Así podremos satisfacer las necesidades de ambas partes y gestionar las expectativas de forma efectiva.

Proyecto de aplicación móvil

La primera experiencia fue un proyecto de una APP móvil para empleados. La recuerdo con especial cariño, en parte gracias a un gran equipo de desarrollo, un cliente totalmente implicado con el producto y donde ambas partes nos sentíamos como una unidad colaborando por obtener el mejor resultado posible.

Frases como: “Qué suerte tuviste de que el cliente estuviera comprometido, se sintiera uno más del equipo, etc.”, me recuerdan a alguna expresión que, inconscientemente, solía decir yo en mi época de desarrollador: “En mi local funciona”. No pretendo ser un troll, por supuesto que es más que probable que tuviera suerte con las personas junto a las que llevamos a cabo el proyecto. En toda fase inicial el compromiso de ambas partes debería ser total. Si no es así, estamos ante la primera alarma de riesgo de proyecto.

Arrancamos partiendo de una fase de descubrimiento o Sprint 0 (como lo conocemos en la casa) realizado con Paradigma. Esto nos allanó mucho el camino al tener como punto de partida unos bocetos y un primer backlog a alto nivel (solo con el título, sin ni siquiera con la estructura típica de las historias de usuario “cómo, quiero, para”). Pese a todo el trabajo del que partíamos, aún quedaban muchas incógnitas por despejar. Aparecían las primeras dudas técnicas ante el folio en blanco que nos ofrecía el cliente. Algunos ejemplos fueron: ¿Cómo gestionar el proceso de autenticación del empleado si se conecta desde el móvil en su casa, sin VPN, como hace hoy en día con el portátil? ¿Qué nube usar, Azure, AWS, etc.? ¿Cuál es el contexto de preparación del cliente para integrar y mantener estas tecnologías? Y también sobre la experiencia de usuario: ¿Cuál es el comportamiento esperado a nivel de experiencia de usuario cuando usemos esta funcionalidad?

Es en este punto es donde se hace necesario unir la idea de negocio (cliente) con las inquietudes técnicas (equipo de desarrollo). Estas conversaciones para unir ambos mundos son críticas para sacar a la luz problemas, impedimentos, mejoras y una buena gestión de expectativas de forma anticipada. En nuestro caso, las 3 primeras semanas fueron intensas, con reuniones cada 2 días con el cliente para despejar la incertidumbre técnica que detectamos en la confección de la infraestructura y tecnologías que se iban a implantar. En cada reunión nos llevábamos tareas para analizar y poner en común en la siguiente. En este proceso implicamos a cualquier persona que fuera necesaria, aunque no estuviera en el proyecto.

Cuando el borrador de la infraestructura empezó a coger forma, comenzamos a tener sesiones en paralelo de ámbito más funcional con la Product Owner, acompañada siempre de 2 personas que la ayudaban a tomar decisiones. Estas sesiones de refinamiento se organizaban cada 2 o 3 días, de cara a establecer así un hábito. El objetivo era aterrizar la mayor parte de los ítems del backlog, lo que daba inicio a un dual track.

Estas sesiones de refinamiento habitualmente las realizaba un analista, en ausencia de este perfil las llevamos a cabo un QA y un agilista. El objetivo era entender el comportamiento esperado del cliente (happy path) para continuar con nuestra ronda de preguntas incómodas de los “multiversos posibles”. Un ejemplo sería: ¿Qué comportamiento esperarías si en mitad del proceso se perdiera la conexión a Internet? Hay muchos más escenarios de los que puedes llegar a imaginar, créeme.

Algunas preguntas no tenían respuesta en esa sesión y quedaban pendientes como tarea para la siguiente. Tras estas conversaciones, traspasamos esta información a una primera versión de historia de usuario (3 C’s de Ron Jeffries) y detallamos cada comportamiento con sus criterios de aceptación. Para ello siempre nos apoyamos en textos y material gráfico en aquellos puntos que consideramos necesarios.

Con esta primera versión de la historia de usuario, con sus criterios de aceptación, se revisaba con alguien del equipo de desarrollo para asegurarnos que estaba bien escrita y no generaba dudas que no hubiéramos identificado. De esta forma, el equipo entendía el comportamiento esperado a nivel del usuario. A esta reunión ya llevábamos resueltas algunas dudas técnicas como, por ejemplo, el origen de los datos, posibles problemas de integración, etc., con el fin de tener respuestas a las posibles dudas que surgieran.

Uno de los acuerdos establecidos con el cliente fue el tener su validación de la historia de usuario antes de empezar a desarrollar. El objetivo era evitar re-trabajar y hacer eficiente el proceso desde el primer momento, así como registrar toda conversación en la página de su funcionalidad correspondiente. Este acuerdo es crítico y no siempre es fácil conseguirlo.

Tras las distintas reuniones de refinamiento, se hacía una última revisión en una sesión con todo el equipo y cliente cuando la historia de usuario ya había sido revisada por todas las partes. Era una manera de ver si quedaba alguna duda pendiente, surgía alguna duda nueva y obtener la aprobación del Product Owner. Sin su OK escrito en la propia historia no se incluía como candidata a la siguiente reunión de Sprint Planning.

El resultado final de este proyecto fue un éxito para el cliente, para el usuario y para el equipo, que superó un reto tecnológico en un contexto desconocido y, además, con un ambiente inmejorable entre equipo y cliente.

Proyecto de una plataforma educativa

La segunda experiencia se centra en un proyecto educativo por el que pasé hace poco, que se encontraba en su fase final cuando llegué como relevo. Como en toda relación no es lo mismo aplicar unos hábitos al inicio que cuando ya se lleva un cierto tiempo y, en el caso de las empresas, sucede lo mismo. Al fin y al cabo la comunicación depende de personas y, por nuestra naturaleza una vez que nos acomodamos, somos reticentes al cambio.

En este proyecto el resultado no fue el mismo que en el anterior y me pregunto: ¿Cómo habría sido de haber aplicado las mismas sesiones de refinamiento con unos buenos hábitos desde el principio? Estoy totalmente convencido de que el impacto generado habría sido mayor. A veces, la labor de hacer entender al cliente la importancia de algunos flujos y hábitos no es nada fácil. Es nuestro mayor reto desde el primer día.

En muchos casos, nuestros clientes tienen más disponibilidad al inicio del proyecto, pero la cosa se complica en fases más avanzadas. Para evitar problemas establece un calendario desde el comienzo que tenga en cuenta las necesidades del equipo y el proyecto. Es fundamental para que el cliente entienda la importancia del refinado.

Conclusiones

Si has llegado hasta aquí seguro que eres de esas personas que se quedan en el cine a esperar el easter egg después de los créditos. No tengo escena final que dejarte, pero sí algunos consejos que te ayudarán en tu próximo proyecto (o eso espero).

1. Aprovecha la fase inicial del proyecto para establecer unas reglas o buenos hábitos con el cliente. Nos cuesta cambiar nuestra rutina, pero cuando comenzamos algo nuevo estamos más dispuestos a aceptar cambios. Cuanto más tiempo pase más difícil será conseguirlo.
2. Es vital juntar cuanto antes la comunicación de negocio con la técnica. Son dos idiomas muy diferentes y la traducción simultánea se obtiene en las sesiones de refinamiento. Hay que trabajar la confianza entre ambas partes antes de estas sesiones.
3. Lleva las sesiones con el cliente trabajadas con antelación. Al menos 1 persona del equipo debe revisarlas antes de la sesión conjunta con todas las partes implicadas. Te ayudará a que la conversación esté más atada y la reunión sea más fluida.
4. No te preocupes si no te da tiempo a ver todo lo que querías en esa sesión. Lo importante es que haya quedado claro lo que se ha visto y debatido. Siempre habrá algún punto menor que se pueda resolver por correo electrónico o al principio de la siguiente reunión.

Para terminar me gustaría preguntarte:

• ¿Alguna vez has estado en un proyecto que no tuviera historias de usuario con criterios de aceptación y diseños detallados (si aplican)?
• ¿Cuál fue el resultado?
• ¿Tal vez derivó en que el equipo tuviera que repetir o corregir funcionalidades?
• ¿Surgió el eterno debate de si es un bug o un cambio de alcance a mitad de proyecto?

Si alguna de estas preguntas te suena, es momento de preguntarse si no estableciste unos buenos hábitos con el cliente. Solo tú tienes la respuesta y puede llevarte a una reflexión muy útil.