¿Cómo debería un propietario de producto en scrum lidiar con preguntas muy detalladas del equipo con respecto a las características que están implementando y que no puede contestar instantáneamente? ¿Cuándo sería claramente la solución más rápida para el desarrollador hablar directamente con el cliente?
Me pregunto si la comunicación directa entre el equipo y el cliente socava el papel del propietario del producto. Siento que la orden de compra debe representar exclusivamente al cliente y, por lo tanto, responder a todas las preguntas sobre los requisitos, incluso si eso lleva más tiempo. Omitirlo parece debilitarlo y eventualmente hacerlo superfluo ...
¿Existe una mejor práctica en scrum?
scrum
communication
product-owner
tizenegy
fuente
fuente
Respuestas:
Siempre es una buena idea (especialmente en los llamados proyectos ágiles) no apegarse a algún culto de carga o libro de texto que le diga "quién debe (no) hablar con quién", sino encender su cerebro y hacer lo que funcione mejor en un proyecto.
Aunque la comunicación entre PO y el cliente debe ser el estándar (debido a las razones expuestas por @PatrickHughes en su comentario), puede enfrentar una situación en la que se debe aclarar un requisito comercial complejo y la comunicación directa entre un desarrollador y un experto en negocios acelerará mucho las cosas. En tal situación, uno debe evitar jugar "susurro chino" con el PO en el medio, y dejar que el desarrollador y el experto en negocios se comuniquen directamente entre sí, para este contexto restringido.
Sin embargo, la orden de compra nunca debe pasarse por alto. Idealmente, él participa en esa conversación, probablemente como moderador. Puede verificar que el cliente no mencione requisitos completamente nuevos en la mesa durante la charla, o requisitos contrarios a lo acordado anteriormente.
Esto depende también de las personas involucradas y la situación. El PO puede confiar lo suficiente en el desarrollador específico y en el experto del cliente, como para dejar que los dos hablen solos sobre un tema específico, y dejar que informe lo que se dijo después. En otra situación, con otras personas involucradas, él podría preferir tomar una parte más activa. Tomar las decisiones correctas es el núcleo de una buena gestión de proyectos.
fuente
Debe recordar que el cliente de la empresa que lo emplea como desarrollador tiene objetivos diferentes a los de la empresa que lo emplea.
El propietario del producto tiene que representar los objetivos de su empresa y no los objetivos del cliente. Entonces, si los desarrolladores van directamente al cliente, pueden socavar su propia empresa.
fuente
Para los desarrolladores, el propietario del producto ES el cliente. Idealmente (y sé que eso no siempre es posible) el propietario del producto debería ser un representante directo del cliente, un experto en el dominio y un futuro usuario del sistema.
Esa es la mejor manera de garantizar que tenga información directa y correcta disponible y las líneas más cortas posibles en sus procesos.
El ejemplo ideal es probablemente el equipo con el que estoy trabajando ahora. El propietario del producto es un usuario senior y experto en dominios con plena autoridad para autorizar decisiones de diseño sobre el terreno (y la disposición y la capacidad para hacerlo). Es una parte integral del equipo y ayuda directamente al analista y diseñador a escribir las historias de los usuarios, así como a los programadores y evaluadores en la construcción del producto al proporcionar comentarios casi instantáneos sobre preguntas de implementación y escenarios de prueba.
Las líneas no pueden ser más cortas que tener a tu futuro usuario sentado a tu lado mientras codificas :)
fuente