En Scrum, ¿deberían los desarrolladores hablar directamente con los clientes (sin pasar por el PO)?

¿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

Tengo que estar de acuerdo con usted en que el propietario debe ser el único punto de contacto entre el desarrollo y el cliente. No estoy de acuerdo con que hacer innecesario al propietario del producto sea la razón, o que sea más rápido omitir el rol. Lo pondré de esta manera: en un proyecto con 10 desarrolladores, no desea que 10 personas hablen constantemente con el cliente y negocien funciones. Primero, molesta al cliente, segundo, le lleva tiempo desarrollarlo. Si se bloquea en todas las tareas porque necesita más información, debe corregir la fase de captura de requisitos y no tratar de corregir la propiedad.

— Patrick Hughes

"Cuando claramente sería la solución más rápida ..." Solo quiero señalar lo obvio: más rápido no es necesariamente mejor.

— Eric King

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.

— Doc Brown
fuente

"La idea general del desarrollo ágil es: no apegarse a un culto de carga o libro de texto, sino encender su cerebro y hacer lo que funcione mejor en un proyecto": Cierto, pero esta idea no es específica de ágil.

— Giorgio

+1 si se hace scrum de forma ágil, entonces un experto en negocios probablemente sea parte del equipo y esté disponible de todos modos ...

— Marjan Venema

Derecha. El PO nunca debe ser un guardián de la puerta. En cambio, el PO es el último responsable del producto.

— Gort the Robot

@StevenBurnap eso significaría que el PO debe ser un experto en el campo desde el principio ... en mi experiencia, ese no es siempre el caso.

— tizenegy

@Giorgio: absolutamente, en mi humilde opinión, "desarrollo ágil" es solo una palabra de moda que incorpora algunos buenos hábitos que son mucho más antiguos que el término, y no se limita a sí mismo.

— Doc Brown

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.

— Ewan
fuente

El objetivo para todos debería ser entregar el mejor producto posible dentro del presupuesto y en el objetivo. Es solo cómo hacerlo eso es una fuente potencial de discusión.

— Jwenting

sin embargo, no seamos ingenuos. La compañía podría preferir hacer la especificación mínima contratada y pasar a un proyecto más rentable, por ejemplo. O, lo que es más probable, según mi experiencia, el cliente querrá agregar funciones y ampliar el alcance manteniendo el precio igual

— Ewan

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 :)

— jwenting
fuente

"Las líneas no pueden ser más cortas que tener a tu futuro usuario sentado a tu lado mientras codifica :)": Si esto siempre es bueno es cuestionable.

— Giorgio

@Giorgio, por supuesto, depende de las personas involucradas. Pero es lo que SCRUM (y las prácticas ágiles en general) promueve, líneas cortas, toma de decisiones rápida. En nuestro caso, funciona porque el cliente está realmente entusiasmado y quiere que el producto tenga éxito, pero también es lo suficientemente realista como para darse cuenta de que no todo es posible (ciertamente no dentro de los límites presupuestarios y técnicos con los que tenemos que trabajar).

— 2015

Claro, y creo que también depende del tipo de proyecto. Algunos proyectos requieren comentarios más a menudo que otros. Además, en algunos proyectos / productos, desea conservar cierta información para usted. Pero sí, para ciertos proyectos, tener al cliente sentado con usted en la misma oficina y seguir el desarrollo es probablemente la mejor configuración posible.

— Giorgio

@Giorgio: "El propietario del producto es un usuario final experimentado y un experto en dominios con plena autoridad para autorizar decisiones de diseño en el acto". Parece que su OP puede responder a casi todas las preguntas que los desarrolladores puedan tener. Me refería a una situación diferente: una OP que todavía no tiene el mismo nivel de experiencia que los propios clientes y, por lo tanto, necesita comunicarse con ellos regularmente para responder preguntas más difíciles.

— tizenegy