¿Cuál es el rol/responsabilidad del Product Owner en una prueba de concepto con un proveedor externo?

El rol de Propietario del producto, tal como lo define la Guía Scrum , no dice nada sobre trabajar con un proveedor.

¿Existen otras responsabilidades que esa OP deba tener en esta situación?

Eso depende de una serie de factores, que incluyen:

• El conjunto de habilidades del propietario del producto
• Cuanto tiempo tienen disponible
• Si están interesados ​​y quieren involucrarse en actividades de propietarios de productos no tradicionales
• Las capacidades de otros miembros del equipo.

¿O el gerente de producto o el maestro de scrum son dueños de esa parte?

Nuevamente, el rol de Scrum Master como se define en la Guía Scrum no dice nada sobre trabajar con un proveedor.

Mi sugerencia sería la siguiente:

• El Propietario del producto continúa desempeñando su función según lo definido, a menos que desee involucrarse específicamente en el trabajo con el proveedor.
• El Scrum Master cumple su función habitual en el equipo: apoyar el proceso Scrum y ayudar a facilitar la eliminación de impedimentos.
• El equipo de desarrollo asume la responsabilidad de tratar con el proveedor.

Si el equipo de desarrollo no tiene el conjunto de habilidades necesario para trabajar con el proveedor, puede valer la pena considerar agregar un miembro del equipo con la capacidad requerida. He trabajado con Equipos Scrum que incluían a alguien con experiencia en Gestión de Proyectos, y a menudo eran ellos los que se involucraban con proveedores/clientes.

En un POC, el propietario del producto debe ser quien toma las decisiones, la persona que evaluará la idoneidad del producto que se está evaluando y hará o recomendará la compra, o alguien designado por los tomadores de decisiones. Es muy importante que mantengan el enfoque del equipo en demostrar la evidencia requerida o aprender las lecciones para las que está destinado el POC.

También sugeriría que Scrum puede no ser la mejor opción para un POC a menos que la duración esperada sea más de, digamos, un mes. Para un trabajo más corto, Kanban puede ser más apropiado. La naturaleza de un POC es que se trata de descubrir, aprender y adaptarse continuamente sobre la marcha. Scrum tiene que ver con la entrega iterativa, la cadencia y funciona bien solo si el resultado de cada sprint se puede definir durante la planificación del sprint; habría pensado que sería difícil de lograr en un POC corto.

PO parece ser la persona adecuada para hacerse cargo de la relación con el proveedor. La colaboración y la adaptabilidad suelen ser más valiosas que la planificación, pero eso puede depender de la naturaleza del trabajo y la relación con el proveedor. No hay Project Manager en Scrum porque el PO es responsable de establecer el alcance y las prioridades y el equipo en su conjunto es responsable de la planificación.

Una prueba de concepto (POC) no se puede estimar en términos de puntos de la historia, horas o cualquier tamaño que use, ya que se trata de probar si un modelo sugerido funciona o no. Por eso, no se puede incluir en un Sprint.

Según tengo entendido, la necesidad de incluirlo en los Sprints surge por:

1. algunos de los desarrolladores del equipo Scrum trabajarán en ese POC
2. el resultado del POC serán epopeyas, historias y/o tareas para el Equipo Scrum

Debe abordar este POC de la misma manera que aborda un error del entorno de producción; tenga un tablero Kanban para este tipo de actividades y agregue el POC allí. En términos de la carga de trabajo de los miembros del Equipo Scrum, puede usar el mismo modelo que usa cuando un miembro usa tiempo libre pagado (vacaciones).

Recomendaría que el PO haga la comunicación entre los equipos externo e interno porque el POC se realiza principalmente para el PO; los resultados de la misma definirán lo que debe hacerse. Mientras que el PO hace la comunicación, puede hacer la planificación para actuar más rápido.

En primer lugar, diría que no existe un POC en una organización ágil. Simplemente crea una iteración del producto con la solución del proveedor. Luego, si no le gustan los resultados, la próxima iteración saca esa solución.

El enlace es fácil. El PO y el equipo juntos solo crean las historias de los usuarios para su parte del proceso, creando especificaciones para darle al proveedor, evaluando los resultados después de que la solución está lista, y ponen impedimentos ("bloqueadores") en los que no pueden hacer hasta que el vendedor entregue algo. Cualquier miembro del equipo puede asumir el papel de responder a las preguntas de los proveedores; la lógica sugiere que sea la persona con los conocimientos técnicos más relevantes. Luego concéntrese en otras cosas hasta que el proveedor entregue algo, eliminando los bloqueos en las historias posteriores a la entrega.

El Manifiesto ofrece algunas respuestas en las líneas "Individuos e interacciones..." y "Colaboración del cliente...". No hay necesidad de un "plan", y no importa qué título de trabajo haga qué. Por su parte, solo necesita dividir el proceso de mapeo de datos en historias lo suficientemente pequeñas como para entregar una parte dentro de un sprint y, si se ve obligado a hacer puntos, solo haga una estimación para esa historia. (Dicho esto, a su empresa le falta el punto de los puntos si incluye el tiempo requerido en la consideración. Pero entonces, ¡dejé de usar puntos hace años!)

Finalmente, no es trabajo de la OP evaluar la solución. Los equipos se autogestionan, lo que significa que es decisión del equipo . El PO es solo una voz igual en esa discusión.

Una prueba de concepto (PoC) es una demostración de la viabilidad básica de un proyecto basado en TI para uno o más casos de uso representativos. Una PoC bien planificada y bien ejecutada garantiza que la funcionalidad técnica de una nueva solución de TI funcione como se espera. El linaje de un producto y el núcleo del liderazgo del producto es el propietario del producto. El PO tiene poder sobre el tipo de características y funcionalidades a construir, así como el orden en que deben construirse. El PO también se encarga de proporcionar al equipo una visión clara.

El PO es el único responsable del éxito general de la solución que se produce o mantiene como propietario del producto. Ya sea un producto externo o una aplicación interna, el enfoque es el mismo. No obstante, el propietario del producto es responsable de garantizar que siempre se complete la mayor parte del trabajo posible, incluido el trabajo técnicamente centrado. El propietario del producto se relaciona con el scrum master y el equipo de desarrollo para garantizar que lo que el equipo desarrolle cumpla con los requisitos.

En el marco de scrum no se menciona que el propietario del producto se ponga en contacto con el proveedor, pero eso no significa que si el propietario del producto tiene las habilidades para hacerlo, no debería hacerlo.

Las responsabilidades de un propietario de producto incluyen, pero no se limitan a: Participación en la planificación, Administrar la economía, Preparación de la acumulación, Colaborar con el equipo de desarrollo, Colaborar con las partes interesadas, Transmitir y la visión al equipo y liderar el equipo, Priorizar el trabajo en función del negocio. valor, el propietario del producto negocia con el equipo, etc. (motivo de mi comentario anterior)

Por otro lado, el ingeniero de software y el gerente de proyecto complementan sus habilidades y colaboran en tareas comunes. El enlace organizacional, la gestión del personal y el seguimiento y control del proyecto son las tres responsabilidades clave del director del proyecto.

El rol del administrador de proyectos como intermediario entre el equipo técnico y los agentes no técnicos se analiza en la parte de "Enlace" de la administración de proyectos (como patrocinadores de proyectos, usuarios, administración de SI, proveedores, etc.).

Algunas personas pueden argumentar que el propietario del producto no tiene negocios con el proveedor, sino que un gerente de proyecto es la mejor razón, principalmente porque: El gerente de proyecto (y SE) crean un documento de solicitud de propuesta (RFP) para obtener ofertas de posibles proveedores. . Se debe negociar un contrato una vez que se ha elegido un proveedor. Las negociaciones pueden tener lugar con el comercializador, pero también pueden tener lugar con un representante financiero o el gerente del comercializador. Del mismo modo, el gerente del proyecto puede manejar la totalidad o parte de las negociaciones con la ayuda de un experto financiero o su gerente.