¿Quién es el responsable de hacer X? Aquel que más sabe de ello… (y no al revés)

Cuando estoy con alguien que está implantando un modelo ágil, o en alguna conversación, charla o similar, hay un conjunto de preguntas, inquietudes, cuestiones, que siempre se repiten. Sabes que no es la primera vez que comparto contigo alguna de estas cuestiones repetitivas, hoy voy con otra… “¿A quién le toca hacer X?”
En la X puedes poner un montón de cosas, muchas, y hay por ahí un montón de recursos, pdfs, con repartos de responsabilidades que puedes usar, pero hay una que es un clásico: la estimación (¿A quién le toca estimar?).
Y hay otra que es un clásico que nadie pregunte, con la importancia que tiene: las decisiones de negocio sobre el detalle de qué se debería implementar y cómo debería funcionar (funcionalmente hablando). ¿A quién le toca especificar las decisiones de negocio con el detalle de qué se debería implementar? Llámalo especificar las necesidades, las funcionalidades, a nivel de negocio qué hay que implementar, aunque no sea la palabra correcta, pero para que me entiendas, los requisitos, mejor aún… la historias de usuario.
¿Quién debería encargarse de los anteriores? Una regla fácil… quién más sabe (o debiera saber) de ello. Parece lógico ¿no? quién más sabe lo hará mejor, llegará a mejores decisiones.
Según esta simple regla, ¿quién debería estimar?, el equipo, que es quién más sabe la complejidad de aquello que se quiere implementar. Según esto, ¿quién debería detallar la necesidad de negocio que hay que implementar? (ojo, no te hablo del cómo técnico, te hablo de cómo funcional), el Product Owner que tiene la responsabilidad de interactuar con los “Stakeholders” para conocer sus necesidades o introducir hipótesis sobre las mismas (Hypothesis-Based Development, desarrollo basado en Hipótesis).

Pero el mundo muchas veces trabaja al revés…

Ahora viene lo “interesante”, ¿quién suele hacer los anteriores? en demasiadas ocasiones ocurre al revés… lo hace quién menos sabe.
Es decir, se invierte el modelo, el Product Owner (o alguien de negocio), alguien que no va a hacer el trabajo… estima.
Y, por otro lado, al equipo le toca decidir cómo funcionan (a nivel funcional, valga la redundancia) las necesidades de negocio que hay que implementar, porque, típicamente, el Product Owner (o alguien de negocio) no las detalla lo suficiente, las deja muy generales (epics en vez de historias), y a la hora de implementarlas aquel, o aquellos, al que le toca tiene que decidir cómo espera el usuario que funcionen tienen que decidirlo.
Recuerda que una historia de usuario es lo mínimo, mínimo, que aporta valor al usuario o al negocio. Como Product Owner no puedes eludir  la responsabilidad de descomponer al máximo, y esto hace que le llegue el “qué” al equipo de manera mucho más simple y le quita al equipo de tener que tomar decisiones de negocio.

Deja un comentario

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

Share This
Ir arriba