Qué hacemos con el analista de negocio en un modelo Scrum

Hay un montón de roles tradicionales, que podemos encontrar en las empresas, que son «de toda la vida», que en frameworks como Scrum no existen (salvo que los metamos en el genérico grupo Stakeholders o en el grupo equipo técnico). Y me refiero a roles como el jefe de proyecto, calidad, etc., sobre qué sucede con ellos, qué lugar ocupan, en qué se re-convierten, etc.

Pero de todos estos hoy, por razones que habría que preguntarle a Mr. NoBody (y algo tendrá que ver que tenemos curso de Product Owner el 19 de febrero en Madrid), me voy a centrar en el «Business Analyst» o analista de negocio, y que posibles lugares puede ocupar en una gestión que usa Scrum como base. 

Para situarnos, los analistas de negocio son responsables de acortar la distancia entre tecnología y negocio, analizando procesos, lo que eran los antiguos requisitos, etc. en algunos sitios, gestionan ofertas con clientes, presupuestos, etc. 

¿Qué lugar ocupar un analista de negocio a la hora de trabajar con un equipo Scrum?

1 – Que el analista de negocio sea un Stakeholder

La primera, la más factible y típica, es que el analista de negocio sea un Stakeholder más, que interactúa con el Product Owner, de manera similar a cómo se hace en muchos sitios con la figura del jefe de proyectos. Y aquí estoy en el caso de, como te conté en según sea tu negocio… así puedes esperar que sea tu Agilidad, esas «transformaciones ágiles» que no son del todo puras y que tienen que gestionar trabajar en Ágil y tener, por ejemplo, clientes que hablan en proyectos y es imposible cambiarlo. 

Riesgo que tiene esta opción, que el Product Owner no pinte nada, el analista de negocio sea su jefe, que sea el cliente que frena, que el Product Owner sea un mero proxy, que se frene todo, etc.

2 – Desaparece el rol de analista de negocio

La segunda opción es que desaparece el rol de analista de negocio y las actividades que hacía pasan a ser actividades del Product Owner. Aquí el problema viene de si el Product Owner puede mantener sus tareas de Product Owner y las de analista de negocio. Esto funciona si las tareas de analista de negocio no son tantas que impidan que el Product Owner haga de Product Owner.

Riesgo que tiene esta opción, ojo en no caer en los Product Owner con apellidos: Business/Operational/Chief Product Owner, básicamente perder la esencia y lo que debe ser un product owner. 

Recuerda…

Las 7 responsabilidades vitales de un product owner y que tus Product Owners son, de verdad, Product Owners… si pueden decir «no»cuidado si el Product Owner se aburre o el Product Owner del lado oscuro y otros anti-patrones.

Ver este vídeo en YouTube.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba