¿Puede el cliente ser un propietario de producto SCRUM en un proyecto?

7

Acabo de tener una discusión con un colega sobre la función de Propietario del producto: en un proyecto en el que una organización de clientes ha traído una organización de desarrollo de software (proveedor), ¿puede la función de Propietario del producto ser asumida exitosamente por la organización de clientes o ¿Siempre debe estar a cargo del proveedor?

Siempre me imaginé que el PO era el tipo de organización proveedora. El tipo que se aseguró de que el cliente esté contento y que se alimente continuamente con una nueva funcionalidad de alto valor empresarial, pero que aún sea una parte integral de la organización de desarrolladores. Sin embargo, tal vez he visto el rol de PO demasiado como el gerente de proyecto de cascada.

Mi colega me hizo pensar: si la organización de clientes es lo suficientemente madura y profesional, ¿por qué no permitir que una persona de su campamento priorice el retraso? Eso pondría el rol de la OP mucho más cerca del negocio, por lo que sería (en teoría) mejor evaluar el valor comercial de los elementos de la cartera de pedidos. Para mí, ese es un pensamiento intrigante. Pero, ¿cuáles son las implicaciones de dicha configuración?

Espero sus comentarios.

    
pregunta Morten 22.11.2011 - 16:38

4 respuestas

4

Lo que ha descrito @Thomas Owens es una explicación común de PO. Estoy de acuerdo con esto como una buena teoría, pero la práctica en mi experiencia a menudo está muy lejos. ¿Por qué? Porque:

  • Participante voluntario: al menos durante la duración del proyecto, el PO es un trabajo a tiempo completo. Esto puede ser un problema grave para la mayoría de los clientes. Al trabajar con el equipo de 5 a 7 miembros, la OP puede pasar fácilmente la mitad del día discutiendo las historias de usuario que actualmente desarrolla el equipo (recuerde que la historia del usuario es solo una promesa de comunicación futura) y la mitad del día manteniendo y refinando la cartera de productos para definir las historias de usuario para los próximos sprints. La OP OHO también debe verificar las historias de usuario completadas durante el sprint como el paso necesario para que estén "listas" y listas para la reunión de revisión donde se presentarán estas características completas al cliente y las partes interesadas (¡no a la OP!).
  • Además, el PO se puede considerar como una posición de trabajo real (de la misma manera que Scrum Master). En tal caso, no puede esperar obtener una buena OP calificada en el 99% de los clientes.
  • Responsabilidad financiera: la OP tiene responsabilidad financiera por el proyecto. Incluso en Scrum, alguien tiene la responsabilidad y, como generalmente no hay un gerente de producto o de proyecto, la responsabilidad generalmente está en la orden de compra. Responsabilidad financiera significa responsabilidad para el éxito del proyecto, para la correcta implementación y comprensión de las necesidades, expectativas y requisitos del cliente. Esto puede parecer una situación ideal para la OP del lado del cliente, pero la organización de entrega también necesita a alguien involucrado en el proyecto con responsabilidad financiera.

Scrum no es un enfoque estandarizado, es solo un plano con muchas variantes. Por este motivo, puede encontrar proyectos en los que el PO es del lado del cliente o donde el PO es de la organización de entrega. Una vez que tenga un PO del lado del cliente, asegúrese de que realmente haga su trabajo. He visto situaciones en las que la orden de compra oficial era del lado del cliente, pero al final solo quedaba un título vacío para satisfacer las expectativas de la gerencia de la organización de entrega y la mayor parte de su trabajo fue realizada por un miembro del equipo que jugó en secreto su poder. Obviamente, eso fue malo porque el resultado del sprint a menudo dependía de la comprensión del proxy para las necesidades comerciales de los clientes.

Según mi experiencia con los clientes (esto puede ser solo local) una vez que un cliente realmente exige tener su propia orden de compra, también significa que ellos mismos liderarán el proyecto, no buscan que la organización de entrega dirija el proyecto. Buscan una organización que les pueda vender a los desarrolladores = no entregar la implementación sino una fuerza laboral.

    
respondido por el Ladislav Mrnka 23.11.2011 - 00:03
11

Recomendaría, siempre que sea posible, que el propietario del producto sea un representante del cliente. El rol de la OP es ser la voz del cliente, para asegurar que lo que el equipo está produciendo agrega valor comercial, y escribe y prioriza las historias de los usuarios. ¿Quién mejor para desempeñar estos roles que un participante dispuesto de la organización del cliente? Las palabras clave son participantes dispuestos: deben estar dispuestos y ser capaces de participar en el entorno Scrum si esa es la metodología de proceso utilizada por el equipo.

Esto tampoco es exclusivo de Scrum. El concepto de un representante del cliente (con un representante en el lugar a menudo favorecido) también forma parte de la Programación Extrema.

    
respondido por el Thomas Owens 22.11.2011 - 16:46
3

El buen propietario del producto debe responder algunas preguntas fundamentales:

  1. ¿Estaré disponible para el equipo lo suficiente para la planificación y la revisión?
  2. ¿Podré trabajar constantemente en la próxima versión & preparación de sprints?
  3. ¿Podré aprobar la funcionalidad implementada lo suficientemente rápido? En el caso ideal, significa que se completó inmediatamente la funcionalidad.

En mi experiencia, es mejor tener un propietario del producto que sea TU miembro del equipo.

  • Necesita a alguien que entienda lo que dicen los desarrolladores, pero también lo que el cliente necesita.
  • el propietario del producto debe trabajar con su contabilidad, venta, etc.
  • los desarrolladores deben ver & sentir que el propietario del producto está en 'el mismo barco'
  • a veces tendrá que decir NO al cliente para que le diga lo que piensa.
respondido por el Dusan Kocurek 27.11.2011 - 11:50
1

Algunas cosas a considerar para permitir que el cliente sea el PO:

  1. Si no están completamente comprometidos, puede detener todo el proceso de desarrollo. La gran mayoría de los clientes no quieren este tipo de participación, algunos piensan que sí, pero cuando se trata de eso, la mayoría no quiere ese compromiso.

  2. Toma un proceso que está bajo su control y le da ese control al cliente. Según mi experiencia, no tener el control del 100% de un proyecto para un cliente es más peligroso que el riesgo de no entregar exactamente lo que está pidiendo. OTOH si se produce un requisito faltante, la culpa la tiene el cliente por no cumplir este requisito, no pueden culparlo por ello.

  3. Si está desarrollando un producto que usted o su organización no tienen intereses o derechos para cambiar, usar o vender a otros clientes, esto puede funcionar. De lo contrario, si está desarrollando un producto para su empresa que quizás desee personalizar y adaptar a otros clientes en el futuro, podría crear una catástrofe para usted en el futuro. En este caso, la orden de compra debe ser alguien dentro de SU compañía porque está desarrollando un producto que está destinado a reutilizarse para múltiples clientes.

respondido por el maple_shaft 22.11.2011 - 17:04

Lea otras preguntas en las etiquetas