Evaluación del propietario de un producto [cerrado]

¿Cómo evalúa al dueño de un producto? Más específicamente, ¿cómo se llevaría a cabo una evaluación del desempeño del propietario de un producto? ¿Qué cualidades o características miraría uno al revisar el propietario de un producto?

— ManRow
fuente

¿Cuál sería el propósito de evaluar al dueño de un producto?

— Andres F.

@AndresF. Quizás el propietario del producto o la alta gerencia desearían saber cómo se desempeña el propietario del producto en su función. En el proceso ágil, la OP tiene responsabilidades con el grupo de desarrollo a pesar del hecho de que a menudo la OP desempeña el papel del incuestionable Lord y Emporer del software. No se supone que sea así aunque sea común.

— maple_shaft

@maple_shaft Tiene sentido. ¿Por qué esta pregunta se cerró como fuera de tema, entonces? Si evaluar al propietario de un producto es parte de un proceso ágil, ¡entonces la pregunta es muy sobre el tema!

— Andres F.

@AndresF. Estoy completamente de acuerdo y en desacuerdo con el cierre de la comunidad de esto. Lo volví a abrir, pero invito a la comunidad a volver a cerrar o iniciar una meta conversación si sienten que me equivoqué al hacer esto. Si se cierra de nuevo, no volveré a abrir.

— maple_shaft

Respuestas:

Solicite comentarios de los desarrolladores que formaron parte del equipo que desarrolló el producto que 'poseía'. Podrías hacer preguntas como:

¿Fue capaz de responder preguntas relacionadas con los requisitos de manera oportuna?
Cuando se le presentaron múltiples alternativas con respecto a una característica, ¿fue capaz de tomar una decisión clara con respecto a lo que quiere?
¿Con qué frecuencia cambió los requisitos? Esto es algo que siempre sucede. Ser capaz de hacer frente a esto es lo que significa ser ágil. Sin embargo, si esto sucede con mucha frecuencia, es una señal de que el propietario del producto no tiene idea de lo que realmente quiere
¿Pudo proporcionar comentarios claros durante las sesiones de demostración?

— Ioan Alexandru Cucu
fuente

Como preguntas que considero útiles:

Cuando se crea una nueva historia, ¿cuánto trabajo se está haciendo para asegurar su calidad? ¿Hay mucho trabajo para los desarrolladores antes de trabajar en algo o es bueno ir una vez que el PO ha escrito la solicitud?
¿Cuán disponible para preguntas y aclaraciones ha estado la OP en el transcurso del período de evaluación?
¿Cuán receptivo a la retroalimentación ha sido el PO en términos de la evolución del proceso y el equipo en el transcurso de varios sprints?

Desde un nivel superior, esto es lo que estaría viendo:

Toma de decisiones. Desde priorizar el trabajo atrasado hasta aclarar los requisitos de una historia, hay muchas decisiones que pueden ser manejadas por la OP. ¿Fue esto un problema para el equipo en términos de entrega de trabajo? ¿Hubo retrasos frecuentes en hacer las cosas?
Comunicación. ¿Cuán bien se comunicaron las prioridades? ¿Hubo demostraciones de funcionalidad en las que la OP proporcionó comentarios directamente o trajo a los clientes para que revisaran la nueva funcionalidad para asegurarse de que fuera el resultado deseado?
Visión. Esto va un poco en la mano con la comunicación, pero la idea aquí es saber qué fechas importantes se avecinan, cómo se está revisando el trabajo y en qué dirección se dirige el equipo.

— JB King
fuente