Durante los últimos años, la popularidad que alcanzó Scrum generó varios preguntas sobre cómo funciona esta práctica. Y una pregunta recurrente es: ¿existe un lugar para el analista de negocio dentro de una organización Ágil?
Y para mi, la respuesta es un "si", aunque con una salvedad fundamental: se necesita un nuevo analista de negocio, un analista ágil, que tiene un grupo de responsabilidades y habilidades un poco diferentes a las de un analista tradicional.
La idea original, el problema actual
¿Cómo hace Scrum para ocuparse de la recolección de requerimientos de usuarios? Scrum tiene un rol bien definido para esto, llamado Dueño del Producto. El Dueño del Producto es la persona responsable de tomar decisiones clave y de representar las necesidades del negocio con respecto al proyecto. Y muchos piensan que el Dueño del Producto es quien debería ocupar el rol del analista de negocio.
De hecho, en varios proyectos el Dueño del Producto puede hablar directamente con los desarrolladores, estar presente para ellos, sin necesidad de un intermediario (el analista). Y es sin dudas una interpretación válida, útil y práctica para una implementación ágil, que ocurre muchas veces. Imaginen sino un proyecto pequeño, en donde el negocio está representado por una persona con una visión clara, y los desarrolladores comprenden el negocio y son buenos comunicadores.
Y este quizás sea el mejor (y quizás original) modelo ágil: una persona con una idea de negocio, una persona con la habilidad técnica. Y en general no es la situación en la que nos solemos encontrar. Tenemos grandes organizaciones con múltiples clientes y relaciones complejas entre los usuarios.
El analista como Dueño del Producto: una cuestión de autoridad
Las actividades de un analista de negocio tradicional son variadas, aunque existe un objetivo crucial: mejorar la comunicación entre los desarrolladores y los usuarios del proyecto. Y es por esta habilidad que el analista se convierte en un candidado ideal para ser Dueño del Producto: un analista es una persona que tiene la habilidad de entender a los usuarios y al negocio, y a la vez tiene la capacidad de comunicarse de forma efectiva con los desarrolladores.
Sin embargo, el Dueño del Producto necesita una característica más: la autoridad. Y esta cuestión de autoridad no es un tema menor. El Dueño del Producto necesita autoridad para tomar decisiones, para priorizar las historias, para crear, eliminar o modificar requerimientos. Y es en este punto, en la autoridad, es donde aparece el mayor escollo: los analistas de negocio tradicional no suelen tener autoridad para tomar decisiones. Y un Dueño del Producto no puede existir sin autoridad.
Entonces llego así a mi primera conclusión: desde mi perspectiva, el analista de negocio es un candidato ideal para ser el Dueño del Producto si tiene la autoridad necesaria para tomar decisiones sobre el proyecto.
Claro que ganar esta autoridad puede ser una cuestión dificil de lograr, sobre todo porque probablmente signifique una re-estructuración dentro de la empresa. En caso de no ser posible (o como transición hacia una nueva definición de roles), me imagino al analista de negocios como mano derecha de un Dueño del Producto: alguien que sea capaz de entender el negocio y transmitirlo, prepararando el camino para que el equipo ágil pueda desarrollar los requerimientos.
El analista ágil
Los analistas tradicionales suelen crear un "puente" entre los desarrolladores y los usuarios. Y si bien se logra una mejora en muchas situaciones, a la vez actúa como barrera: los usuarios y desarrolladores se comunican a través de este intermediario. Es hora de tomar el siguiente paso, y hacer que los analistas de negocio se conviertan en mentores/coach de comunicación para el equipo.
La ideal sería que el analista esté ubicado junto al equipo, y acué como otro miembro más del equipo, liderando los requerimientos y el análisis a medida que se necesita. Deberían actuar para facilitar la comunicación dentro del equipo, enseñando habilidades de análisis a los desarrolladores y quizás incluso enseñando cuestiones de desarrollo a los usuarios. Ron Jeffries dice en su artículo Business Analysis in Extreme Programming:
Esto comienza con un simple cambio de enfofque; pasar de "Vamos a ir a averiguar lo que el cliente quiere y lo traemos de vuelta" a "Vamos a ir a ayudar a que el cliente averigüe lo que necesita, para que nos lo pueda decir". Este cambio en foco le da el control al cliente, y hace toda la diferencia.
Una habilidad crítica de un analista de negocio ágil es la capacidad de investigar y entender cómo funciona el negocio en la realidad (a diferencia de como los desarrolladores creen o quieren que funcione) y es una habilidad que deberían ser capaces de transmitir. Un analista ágil también realiza tareas junto al equipo, como programación de a pares junto a un desarrollador en alguna parte de código crucial para el negocio, o trabajando con los usuarios para crear las pruebas de aceptación. De esta manera el analista ágil aumenta sus propias habilidades con el tiempo, y por lo tanto podrá ayudar a otros a hacer lo mismo.
Por otro lado, el analista ágil tiene preparado el análisis de las historias de 1 iteración por adelantado, máximo 2. Al tener preparado la siguiente iteración, le permite al equipo avanzar sin retrasos, evitando cualquier demora. Al limitar el análisis a (como máximo) 2 iteraciones, mantenemos la flexibilidad y disminuimos los desperdicios.
Una consecuencia de este enfoque es que dejamos de lado al "analista tradicional" en favor de un desarrollador con muy buenas habilidades para comunicarse. Esto es un reflejo de la filosofía ágil, en donde los buenos desarrolladores son personas que pueden comprender el ciclo completo del desarrollo de software y una o más especialidades: en este caso, el análisis del negocio.
Conclusión
Existen varios enfoques sobre el rol del analista en Scrum, que varian de acuerdo a las características de la organización. Y ahí está el tema: cada organización es única, y por lo tanto no existe una receta única y mágica para resolver los problemas.
Como escribe Mark Riversdale, "debemos recordar que la recolección y validación de requerimientos es una parte necesaria del trabajo, ya que sin esto ningún miembro del equipo (desarrolladores, diseñadores, testers, etc) tendría nada para hacer. Por supuesto, podemos decidir no tener un analsita de negocio dedicado a proyectos ágiles, pero alguien va a tener que cumplir ese rol".
Desde mi punto de vista, el analista tradicional debe reconvertirse para trabajar junto al equipo, estando presente en el día y a día, velando por el proyecto y su impacto en el negocio, ayudando a los miembros a que comprendan cómo encaja el proyecto en curso en la problemática más amplia del negocio. Y apuntar en todo momento a convertise en un verdadero Dueño del Producto, con las mejores herramientas para guiar al equipo durante el proyecto.
