En los últimos años son muchas las empresas que están incorporando
metodologías ágiles en sus procesos de
gestión y producción, especialmente en entornos
TI. Junto con el cambio cultural que supone, el reto principal al que se enfrentan las organizaciones es disponer de las personas y las capacidades adecuadas para llevar a cabo con éxito sus proyectos. Y sin duda, una de las capacidades críticas que deben estar presentes (y no solo en entornos ágiles) es el
Business Analysis como función de enlace entre el negocio y las soluciones tecnológicas.
Como formador y mentor en Análisis de Negocio, me encuentro frecuentemente respondiendo a preguntas respecto a quién debe realizarlo en entornos ágiles. ¿La responsabilidad del análisis de negocio recae en el
Product Owner? ¿debe haber alguien con el título de Analista de Negocio? ¿dado que no se escriben requisitos, solo Historias de Usuario, no hacen falta analistas?. En este artículo intento
arrojar un poco de luz acerca de estas cuestiones.
En primer lugar, creo que es importante entender que más que de personas hablamos de
competencias, de conocimientos y habilidades. En proyectos ágiles, como en el resto, las competencias de análisis de negocio son
claves para el éxito del proyecto. Por lo tanto, éstas deben estar presentes. A veces centralizadas en una única persona y normalmente distribuidas entre las personas del equipo. No olvidemos que
Agile es un enfoque orientado a trabajo en equipo, colaborativo.
Nadie gana, si no ganamos todos.
Dicho esto, según la
Scrum Guide de Scrum Alliance, el “
Product Owner es responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo”. Es una única persona y tiene la responsabilidad sobre la gestión del Product Backlog. Esto lo convierte en una pieza clave y crítica, y seguramente el rol más difícil de encontrar.
Según la propia guía, puede ser una única persona el que realice la gestión del backlog, o puede estar ayudado por otros, pero sigue teniendo la responsabilidad completa.
Es un rol decisor. En el ámbito del producto y del Proyecto en el que trabaja, puede tomar las principales decisiones relativas a la evolución del producto. En otras palabras, es un
gestor de alcance del proyecto. Identifica y decide qué debe estar incluido en el producto en cada iteración, y valida que el resultado aporte el valor esperado. Eso sí, consultando con las partes interesadas que considere.
De alguna manera es “
la voz del cliente” dentro del equipo. Es un rol equivalente al que otras metodologías ágiles como XP llaman Customer Representative, o Business Ambassador en DSDM. Aunque seguramente existirán otros roles vinculados al producto y al negocio, no directamente formando parte de equipos de proyecto sino con una visión más estratégica, como Product Manager, Business Visionary o Business Sponsor.
Para llevar a cabo su función, un Product Owner debe tener las siguientes características:
- Debe ser conocedor del negocio
- Un comunicador efectivo
- Capaz de analizar e integrar las opiniones de los diferentes interesados
- Facultado para tomar decisiones
- Claro en la visión del producto
- Capaz de definir requisitos y User Stories
- Capaz de definir cómo debe ser un resultado exitoso
- Disponible para el equipo de desarrollo
En definitiva,
cuanto más analista de negocio, mejor Product Owner será.
Pero,
¿Cuántas personas conocemos que puedan reunir todas estas características? Seguramente pocas.
En los cursos, además, insisto que un analista
no es el que tiene las respuestas, sino el que hace las mejores preguntas. Un analista, por definición de rol, no tiene capacidad de decisión, sino que permite que se tomen las mejores decisiones para el negocio. Un Product Owner debe definir requisitos y luego validarlos. Es una especie de Juez y parte de todo el proceso, lo que también hace más complicado que este rol recaiga en una única persona. Es decir,
el rol de Product Owner no es (solo) .un rol de analista de negocio.
Es por eso que una estructura habitual, especialmente cuando empezamos a trabajar en Agile, es disponer de un
proxy, alguien que ejerza de enlace entre equipo y Product Owner, que aporte skills de análisis y método, aunque el Product Owner sigue manteniendo su capacidad de decisión. Este
proxy sí, seguro, es un analista de negocio.
Por último, me gustaría también insistir en que definir requisitos en proyectos ágiles no es solo escribir Historias de Usuario. Los requisitos, más o menos formales, acabarán teniendo diferentes formas como historias de usuario, casos de uso, diagramas de clase, workflows… por eso, el trabajo de análisis estará en el Product owner, pero también en el equipo, con independencia de que haya un analista designado como tal o no.
Y para acabar el artículo, a modo de conclusiones, podríamos responder a las preguntas planteaba al principio:
¿La responsabilidad del análisis de negocio recae en el Product Owner?
No solo en él. Puede existir más personas, dentro o fuera del equipo de desarrollo, que aporten los conocimientos y
skills necesarios para identificar requisitos, analizar y diseñar la solución, y validar el producto.
¿Debe haber alguien con el título de Analista de Negocio?
No es imprescindible. Los títulos no son tan importantes como que las capacidades estén presentes. Hay frameworks ágiles, como DSDM que si incluyen de manera explícita el rol Agile BA como parte del equipo de proyecto.
¿Dado que no se escriben requisitos solo Historias de Usuario, no hacen falta analistas?
No es cierto que todos los requisitos acaben en forma de Historias de Usuario. Las historias de usuario son una manera de estructurar, priorizar y gestionar el trabajo a realizar en cada iteración, y permiten iniciar una conversación productiva entre negocio y IT para asegurar que la solución aportará el valor esperado. Para entender mejor el trabajo, analistas de negocio y equipo necesitarán aplicar otras técnicas de análisis (por poner ejemplos conocidos, Diagramas de Casos de uso, workflows, o Diagraas de Clases).
