Analista funcional 2.0: cómo adaptar tu trabajo en un equipo Agile.

¿Eres analista funcional? ¿Cómo encaja tu rol dentro de un marco de trabajo Agile? Estas fueron las primeras preguntas que me hicieron mis compañeros/as de equipo cuando comencé a trabajar como analista funcional en Paradigma.

Hasta entonces había trabajado en proyectos con una metodología waterfall donde se invertía mucho tiempo en cerrar requisitos, definir funcionalidades y completar extensos documentos antes de comenzar cualquier desarrollo.

Las necesidades de un equipo Agile son totalmente distintas y adaptarse a estas necesidades es la clave para aportar valor dentro del equipo.

¿Cómo sé si necesito un analista funcional en mi equipo?

No todos los equipos que trabajan bajo un framework Agile necesitan un analista funcional. Hay una serie de factores que se deben tener en cuenta a la hora de decidir si incluir o no este rol dentro de un equipo:

• Envergadura y complejidad del producto: evaluar el tamaño del producto y analizar si tiene procesos complejos, integraciones con terceros o muchos stakeholders haciendo peticiones. Todos estos factores determinarán si es necesario incluir refuerzo en la etapa de descubrimiento del producto.
• Características del equipo de desarrollo: factores como el tamaño, los perfiles que lo componen y las habilidades de sus miembros, nos ayudarán a decidir si un equipo es totalmente autónomo para definir la funcionalidad que tiene que implementar o si necesitan apoyo en este aspecto.
• Dedicación del Product Owner: en ocasiones el Product Owner no puede dedicar todo el tiempo que debería a la gestión y mantenimiento del backlog, o incluso a veces, lo hace pero a alto nivel y la historia de usuario no está lo suficientemente detallada.

¿Por dónde empiezo?

Lo más importante cuando te incorporas como analista funcional en un equipo Agile es conocer las necesidades que tienen y saber cómo les puedes ayudar. El primer paso debería ser evaluar cómo está trabajando actualmente el equipo y en qué estado está el producto.

Por ejemplo, no es lo mismo incorporarse a un equipo y un producto que acaba de arrancar, donde puedes ayudar más en la definición inicial de los procesos, que incorporarte en un equipo con unos años de vida en donde el conocimiento funcional no está documentado y está en la cabeza de unos pocos miembros del equipo.

En ambos casos las necesidades son distintas.
Mi recomendación es tener una conversación con el equipo de desarrollo y el Product Owner para decidir entre todos en qué aspectos puedes apoyar, cuáles son las carencias que tienen actualmente y qué documentación necesitan.

Esta debe ser la base para adaptar nuestro trabajo a las necesidades del producto y del equipo para ser totalmente eficientes.

¿Cómo puedo ayudar al equipo de desarrollo?

Documentación

En un proyecto con una metodología tradicional el trabajo de un analista consiste, entre otras cosas, en generar la documentación que exige la metodología (toma de requisitos, análisis funcional y definición de casos de uso, planes de pruebas...) muchas veces sin poder evaluar si va a ser útil o no durante las fases de implementación y pruebas.

A menudo se generan documentos extensos en los que se invierte mucho tiempo en el análisis y que hasta que no están cerrados y validados al 100% no se empieza el desarrollo.

Por otra parte, nos encontramos también proyectos desarrollados bajo un marco de trabajo Agile en los que la documentación es prácticamente inexistente. Creo que es necesario buscar un equilibrio.

El objetivo debería ser generar la documentación óptima teniendo en cuenta lo siguiente:

• Menos es más: es mucho más sencillo para el equipo tener información útil y concentrada que extensos documentos que muchas veces por pereza, no se leen y acaban recurriendo a ti.
• Una imagen vale más que mil palabras: la mayor parte de las veces es mucho más fácil y más útil un diagrama o un esquema que párrafos y párrafos de explicación.
• La organización es la clave: organiza tu documentación y crea una estructura consistente, lo ideal es que una persona que acaba de aterrizar en el equipo sea capaz de encontrar la documentación que busca de forma intuitiva.
• Acuérdate de tu yo futuro: nuestra cabeza tiene una capacidad de almacenamiento limitada, por tanto siempre me pregunto si mi yo futuro necesitará una determinada información antes de decidir si invertir esfuerzo en documentar o no.

Apoyo en los refinamientos y planificación

Los refinamientos y la planificación son una parte clave para detallar y definir la funcionalidad que se va a implementar durante el próximo sprint y cómo la va abordar el equipo de desarrollo.

Es imprescindible acudir a estos eventos para participar activamente en la lectura y comprensión de las historias de usuario y en la resolución de las distintas problemáticas que puedan surgir cuando el equipo empieza a tomar decisiones sobre el alcance de las mismas y el trabajo que va a abordar.

Referente en el conocimiento del producto

Para el equipo debemos ser un referente en cuanto a conocimiento funcional del producto. Aunque hayamos generado una buena documentación, muchas veces hay puntos que no quedan totalmente claros o simplemente, al abordar el desarrollo, el equipo se plantea dudas o problemas que tú no te habías planteado.

Es importante tener la capacidad de poder reunirnos con el equipo, resolver esas dudas y en caso de que no sepamos, tener siempre un referente en el cliente al que podamos consultar.

¿Cómo puedo ayudar al Product Owner?

Acompañamiento en los descubrimientos

El descubrimiento de las necesidades y la ideación de posibles soluciones son una parte clave a la hora de definir el producto. Desde el nacimiento de una necesidad hasta que está lista para implementarse, hay un largo camino, muchas veces lleno de obstáculos.

Lo ideal es ayudar a recorrer este camino al Product Owner, estando muy presentes en las conversaciones con los distintos stakeholders guiándolos sobre lo que consideramos mejor para el producto.

Facilitar dinámicas como Customer Journey Map o User History Map o simplemente elaborar con ellos diagramas de flujo a alto nivel puede suponer una ayuda importante en esta fase. El objetivo es que tengamos la información lo más completa posible para que sea más sencillo abordar el desarrollo.

Definición de Historias de usuario

Definir una buena historia de usuario, requiere un tiempo y una dedicación que muchas veces el Product Owner no tiene. En este caso, podemos ayudarle a completar la definición de la historia y los criterios de aceptación, pero es muy recomendable que el Product Owner valide la información que hemos completado asegurándonos que estamos alineados.

Si el Product Owner sí puede invertir tiempo en detallar la historia, lo ideal en este caso sería hacer un primer filtro leyendo la historia, entendiendo la funcionalidad y planteando dudas antes de que llegue al equipo de desarrollo.

En ambos casos el objetivo debe ser que la historia esté lo suficientemente clara para que pueda ser abordada por el equipo sin problemas.

Referente en el conocimiento del producto

Al igual que para el equipo, para el Producto Owner también debemos ser un referente en cuanto a conocimiento funcional del producto. Lo ideal es ser ese primer punto de contacto ante cualquier duda funcional para evitar interrupciones al equipo de desarrollo.

En resumen...

Aunque el rol de analista funcional no suele ser común en un equipo ágil, en ocasiones es clave para aportar coherencia y simplicidad a su día a día. Nuestro objetivo debe ser facilitar el trabajo del equipo y apoyar al Product Owner, pero ante todo ser prácticos, anticiparnos y adaptar nuestro trabajo a las necesidades del producto para optimizar el desarrollo al 100%.

Agile surge como alternativa a metodologías que han demostrado ser ineficientes en ciertos aspectos. Como analistas, debemos evolucionar nuestra forma de trabajar a un marco que cada día adoptan más empresas. Solo así tendrá sentido nuestro rol.