Empoderamiento del rol de Product Owner
Contenido del curso
Empoderamiento del rol de Product Owner
Contenido del curso
Luciano Vicidomini
María Jimena Rodríguez Contreras
Gonzalo Galvano
Juliana Aristizabal Hernandez
Yeni Alexandra Espinosa
Yangetze González
Company_admin
Diana Elena Bedoya Bustamante
Company_admin
Pablo Hurtado
Vanessa Amaya
Profesor
Eduardo David De la Cruz Cutipa
JULIAN ANDRES TEJADA CHICA
Felipe Bernardo González Barranco
Edwar Y. Castillo B.
Alejandro Palacio Wilches
Company_adminJonathan Quiros Barquero
Cindy Castillo
CLAUDIA ANDREA CAMPO GRIJALBA
Vanessa Amaya
Profesor
Alvaro Angel
Carlos Roberto Doblado Ochoa
Omar Caires
Sandra Sierra
Gian Michael Esteves Ramirez
Susana Martínez Magallanes
Susana Martínez Magallanes
MA DEL PILAR GARCIA SERRANO
Alejandro Palacio Wilches
Company_admin
Ezequiel Alejandro Barrales
Yobana Sandoval Parra
EMPODERAMIENTO DEL PRODUCT OWNER:
.
.
• Necesitamos conocimiento del negocio
• Conocimiento relacionado al contexto de usuario: el usuario solicitante no siempre es el usuario final. Tenemos que pensar en las personas que realmente usaran el producto.
• Conocimiento del producto: como lo podemos partir en partes, cual parte es la más valiosa? Como hacer para mejorarlo? Un product owner no levanta el pedido, el product owner analiza, y para tomar decisiones necesita de este tipo de conocimientos. El conocimiento del dominio empresarial.
• Análisis de negocio: el análisis de negocio se aplica para entender un problema de negocio, proponer alternativas de solución y definir el alance de la solución seleccionado considerando todos los recursos de la organización.
• Habilidades:
o Negociación: tenemos que estar todo el tiempo negociando con el cliente y con el equipo.
o Abstracción: poder abstraer y categorizar toda la información proveniente de muchas fuentes de información. El PO abstrae la información y la hace más entendible al equipo.
o Facilitación: no es solo facilitar una reunión, es facilitar el entendimiento del producto, el trabajo en equipo entre perfiles técnicos y de negocios, facilitarle la vía al equipo que va a hacer realidad el producto
o Influencia: no es lo mismo que jerarquía. El PO tiene que maximizar la influencia positiva en el equipo.
o Comunicación. Fomentar la conversación que llegue a conclusiones productivas, que las juntan no sean aburridas y que la gente no se vaya de una reunión confundida.
• Herramientas:
o Colaborativas
o Visual Thinking
muchas gracias
Gracias por el aporte
Según el caso de estudio se plantea lo siguiente:
La estrategia de Sergio en el Escenario 2 es muy valida porque busca atacar las necesidades del ejecutivo de ventas y adicional la finalidad y objetivos de un crédito, donde también es importante garantizar el pago de este por parte de los usuarios.
El análisis funcional entre Luz, Gustavo y Alejandro es muy importante realizarlo de forma adecuada y teniendo presente las estrategias de Sergio, para no perder el hilo de entregas en ese Sprint.
Hay un fallo en no incluir a las personas en las reuniones, dado que la metodología Scrum indica que todos los integrantes del equipo pueden estar en la capacidad de responder a las necesidades que se presentan y evitar esto por reuniones largas, va retrasar o afectar las entregas del Sprint. Lo ideal es implementar conversaciones cortas y detalladas de la novedad o problema y que todos los miembros del equipo lo tengan en cuenta.
Sandra al ser la encargada de generar sinergia en todo el equipo, debe buscar métodos de trabajo que integren a todos los participantes, mejorar la metodología de las retrospectivas y propiciar espacios de conversación amenos para mejorar la comunicación que no se esta dando.
La problemática : Desconocimiento total de la necesidad del cliente interno para ejercer bien su labor.
De acuerdo contigo Yeni.
Completamente de acuerdo contigo
En SCRUM con el PO, siempre me quedan las dudas siguientes:
¡Hola Pablo!
Tus dudas son muy válidas y creo que es por ello que a partir de la más reciente guía de Scrum, ya no aparecen como roles sino como responsabilidades, es decir, más que cambiarle de nombre al rol, que quede claro quién va a llevar las 3 responsabilidades base en el proyecto.
El PO en cualquier caso representa la voz del cliente y es quien se encarga de especificar al equipo con claridad los objetivos y las funcionalidades que se buscan.
Sobre los escenarios que planteas, mi opinión es esta:
El PO debería de estar en la empresa contratante, porque de ese lado estaría la persona que puede darle las especificaciones al equipo y quien puede representar mejor la voz del cliente.
Si no tiene capacitación como PO, aquí el Scrum Master es quien le ayuda a entender su responsabilidad dentro del equipo. En este escenario ocurre mucho que la persona designada no asume sus responsabilidades de PO porque no las comprende o porque como mencionas, al no tener capacitación al respecto, no sabe ni como especificarle al equipo de una manera efectiva. Así que otra opción para el 2do escenario es considerar un Analista de negocio (Business Analyst) de apoyo para el PO que si sepa como especificar. Este BA preferentemente debe de estar del lado de la empresa contratante, pero si no lo está el riesgo es muy alto y por ello recomiendo que la empresa contratada asigne a alguien que sea el BA.
He visto con frecuencia que en el 2do escenario, le terminan asignando al Scrum Master las responsabilidades de PO también o el PO le delega trabajo al SM. Esto solo provoca más retrasos y poca efectividad.
Hola Vanessa, permíteme hacer una consulta sobre el escenario planteado por el compañero Hurtado.
Si la empresa contratante solicita a la contratada asignar el PO.. ¿tendríamos mayor posibilidad de fracaso y asumidos la responsabilidad total del mismo?
Basado en los escenarios que se plantean en el caso de estudio considero fundamental reforzar estos conocimientos en el Scrum Team:
Conocimiento del negocio: si bien cada persona es experta en un tema, en algunas situaciones siento que la de marketing piensa con un foco de buyer persona diferente al que tiene por ejemplo Sergio por tal motivo deben alinear estas perspectivas tomando como referencia los lineamientos de la alta dirección.
Conocimiento relacionado con el contexto del usuario: En esto debemos crear un balance dentro del equipo de Scrum para poder fortalecer la idea de que el desarrollo final se hace para satisfacer a nuestros potenciales clientes, también cumpliendo las expectativas de nuestros ejecutivos de ventas que para el caso se convertirían en clientes internos también del desarrollo
:clap: :clap: :clap:
Gracias por tus esquemas, súper útiles. ¿Que herramienta usas para esquematizar?
1) Problemática del caso
El caso presenta varios retos típicos en la adopción de Scrum, que son los siguientes:
2) Conocimientos y herramientas ágiles necesarias
Para atacar estas problemáticas, el equipo debería fortalecer lo siguiente:
a) Gestión del Product Backlog
Herramienta útil: User Story Mapping para visualizar el flujo del usuario (ejecutivo de ventas) y ordenar backlog.
b) Roles y eventos Scrum
Herramienta útil: Retrospective formats (Mad/Sad/Glad, 4L’s, Starfish).
c) Colaboración UX y Dev
Herramienta útil: Design Sprint o UX Storyboards.
d) Enfoque en valor y métricas ágiles
Herramienta útil: OKRs alineados con el backlog.
e) Priorización en entornos de restricción
Herramienta útil: Impact Mapping o Value vs Effort Matrix.
Caso de Negocio Problemática: Falta de sinergia en el equipo. Los conocimientos que se requieren para el caso de estudio son los siguientes:
Buenas tardes profesora, me gustaría pedir ayuda para los dos últimos escenarios, podría darme una guía por favor? Adjunto la respuesta de los primeros 8 escenarios:
Conocimientos necesarios para resolver la problemática: Desarrollar habilidades en marco de trabajo Scrum Obtener conocimiento del negocio, abstracción, comunicación Obtener habilidades en Scrum
Conocimientos necesarios para resolver la problemática:
Contexto del negocio, contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Influencia Comunicación
3.Hallazgos:
No están usando SCRUM, trabajan de forma independiente No existe presencia de roles, ni de artefactos ni de eventos Santiago trabaja en proyectos diferentes al de App Credit
Conocimientos necesarios para resolver la problemática:
Conocimiento y aplicación del marco de trabajo Scrum
Contexto del negocio, contexto del usuario final
Contexto del producto
Negociación
Abstracción
Facilitación
Influencia
Comunicación
Manejo de herramientas
Conocimientos necesarios para resolver la problemática:
Marco de trabajo Scrum
Contexto del negocio, contexto del usuario final
Contexto del producto
Abstracción
Facilitación
Influencia
Comunicación
Uso de herramientas de trabajo colaborativas y visual thinking
Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Comunicación
Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Comunicación
Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Influencia Comunicación
Conocimientos necesarios para resolver la problemática: Conocimiento de Scrum Contexto del usuario final Contexto del producto Negociación Abstracción Influencia Facilitación Comunicación
Gracias
Hola! Está muy bien enfocado cómo hiciste tu ejercicio
Caso de estudio
¿Cuál es la problemática? ¿Qué conocimientos harían la diferencia para resolver el problema?
—
Hallazgos
Conclusiones
Habilidades:
Ø Negociación
Tenemos que estar representando la voz del cliente y estar negociando con muchas personas alrededor para maximizar el valor. La mayoría de las conversaciones de un Product Owner recaen en una negociación y es muy importante esa habilidad.
Ø Abstracción
Poder abstraer y categorizar y diferir toda la información proveniente de muchas fuentes de información. El PO abstrae la información y la hace más entendible al equipo.
Ø Facilitación
No es solo facilitar una reunión, es facilitar el entendimiento del producto, el trabajo en equipo entre perfiles técnicos y de negocios, facilitarle la vida al equipo que va a hacer realidad el producto.
Ø Influencia
No es lo mismo que jerarquía. El Product Owner tiene que maximizar la influencia positiva en el equipo, equipos que hagan sinergia.
Ø Comunicación
Fomentar la conversación que llegue a conclusiones productivas, que las juntan no sean aburridas y que la gente no se vaya de una reunión confundida.
Esta muy bueno el curso! Gracias. Me doy cuenta que mas que Project Manager he sido un Product Owner con disciplina de Gerencia de Proyecto. Gracias!
Hola, mis respuestas al caso de estudio:
En escenario 1 El problema es que no han trabajado juntos y no todos tienen experiencia con scrum. Entonces se requiere el conocimiento del marco de trabajo, y buscar una estrategia para cohesionar al equipo, quizás una actividad presencial en donde se conozcan y empiecen a generar lazos de confianza.
En escenario 2 Se requiere unificar la visión de Susana y Sergio, por lo tanto tener más contexto del usuario los llevará a confirmar cual de las dos estrategias es la adecuada, precisamente porque identifican quien va a usar la app.
En escenario 3 Se requiere reforar el marco de trabajo, pues no se está haciendo participe a todo el equipo en el análisis funcional. Adicionalmente, uno de los integrantes - Santigo - no tiene foco total en el proyecto,
En escenario 4 Se requiere contexto del usuario y contexto de producto, ya que no hay alineación de la visión del proyecto.
En escenario 5 Se requiere conocimiento del negocio y contexto del usuario.
En escenario 6 Se requiere cohesionar de nuevo al equipo, elevar la confianza de los integrantes, que en las planning todo el equipo participe activamente. El Scrum master debe procurar que este entorno de trabajo sea productivo.
En escenario 7 Aunque aparentemente Alejandro está haciendo bien su trabajo, el no es quien tiene la responsabilidad de Product Owner, por lo tanto el SM debe reforzar con Sergio esta responsabilidad.
En escenario 8 Reforzar la cohesión del equipo, el pensamiento lean porque se han aumentado los malos entendidos, la comunicacion no fluye.
En escenario 9 y 10 Nuevamente priorizar dadas las restricciones que hay, basado en el conocimiento del negocio, contextode usuario, producto y dominio empresarial
;) Apuntes de la clase
Problemáticas:
Objetivos cambiantes, vistos desde varios puntos de vista sin consenso, cada uno partiendo de sus propias necesidades.
En algún punto se habla de refinar las funcionalidades y de un trabajo incremental, lo que habla de falta de definición en el alcance de la primera versión de la aplicación – Si continúan sumando funcionalidades o mejorando cada detalle, el desarrollo se volverá eterno.
Pérdida de motivación por constante iteración que da la sensación de estancamiento y retrabajo por parte del equipo.
Es probable que la mancuerna entre Sergio y Alejandro esté siendo ineficiente: Alejandro debería operar y Sergio decidir, y aún así Sergio debe estar involucrado en todo. Estas dinámicas sólo crean retrabajo y duplicidad de rol.
Prioridades:
En el escenario 10, me enfocaría en priorizar cuestiones que realmente resuelvan problemáticas actuales, no que mejoren lo que actualmente ya funciona (estas mejoras podrán ser planeadas para la versión 2.0 de la aplicación, con base en los retos experimentados por los usuarios):
- Cambiar la aplicación actual de la que se está pagando licencia para la validación de huellas digitales ya que la que se está usando suele presentar problemas de desempeño.
- Se ha presentado comportamiento inestable con Active Directory y muchas veces tarda en arrancar la aplicación por errores de conectividad con AD.
- Mejorar la interfaz porque los menús quedaron con muchas opciones y los ejecutivos se pierden al utilizarla.
El caso de estudio compartido es la documentación del proyecto en sí?
No exactamente, Susana. El caso de estudio es un escenario práctico para analizar y poner a prueba las decisiones del rol, no la documentación técnica o funcional del proyecto en sí.
¿Qué aspecto específico del caso de estudio te genera dudas sobre su propósito?
En muchas ocasiones quien orienta funcionalmente es la gerencia pero el usos lo hacen colaboradores de base, como conciliar esta conversación en rol de product owner
Lo paradójico del rol de PO es que la carga detrás de este rol inhiben salir a conversar con clientes. No obstante hay que salir porque de otra manera no podemos generar valor a los usuarios.
Conocimiento del negocio:
No es nada más el producto, sino que tiene que conocer el negocio del producto, la línea del negocio sobre la cual va el producto.
Contexto del usuario:
¿Quién va a utilizar mi producto? No confundir al cliente solicitante con el usuario final. Tenemos que saber la diferencia de cuál es cuál y quién finalmente va a usar lo que estamos desarrollando. (Muchas veces quien me "PAGA" mi producto jamás lo termina utilizando porque eso queda en mano de sus empleados).
Herramientas:
El problema es que el proceso es lento y confuso; lo que más marcará la diferencia es que el PO use priorización de backlog, herramientas de foco en usuario y comunicación clara para que el equipo entregue primero lo que resuelve los dolores más críticos.
