Empoderamiento del rol de Product Owner

Clase 3 de 12 • Curso de Fundamentos de Product Owner

Luciano Vicidomini

student•

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

María Jimena Rodríguez Contreras

student•

muchas gracias

Gonzalo Galvano

student•

Gracias por el aporte

Juliana Aristizabal Hernandez

student•

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.

Yeni Alexandra Espinosa

student•

La problemática : Desconocimiento total de la necesidad del cliente interno para ejercer bien su labor.

Conocimiento del negocio, con este entendimiento se pueden crear estrategias adecuadas para solucionar la problemática.
Conocimiento del contexto de usuario: Donde se debe dar foco principal en quien va a usar la herramienta que se va a desarrollar.
Contexto del producto: Buscar que el producto cumpla con el objetivo de lograr ventas efectivas y en el menor tiempo posible.

Yangetze González

company_admin•

De acuerdo contigo Yeni.

Diana Elena Bedoya Bustamante

company_admin•

Completamente de acuerdo contigo

Pablo Hurtado

student•

En SCRUM con el PO, siempre me quedan las dudas siguientes:

Si yo son una empresa de desarrollo y otra empresa (digamos de manufactura) me contrata para hacer el desarrollo de una aplicación, ¿quién designa al PO? ¿la empresa contratante o nosotros?
Si el PO es asignado dentro de la empresa contratante y no tiene capacitación de PO, ¿Qué se debe hacer?

Vanessa Amaya

teacher•

¡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.

David De la Cruz

student•

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?

JULIAN ANDRES TEJADA CHICA

student•

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

Felipe Bernardo González Barranco

student•

:clap: :clap: :clap:

Cindy Castillo

student•

Caso de Negocio Problemática: Falta de sinergia en el equipo. Los conocimientos que se requieren para el caso de estudio son los siguientes:

Contexto del usuario: Es importante tener como base el o los usuarios que van a utilizar el producto debido a que nos ayudará a satisfacer sus necesidades, en el caso de estudio Sergio y Susana tenían estrategias totalmente diferentes por la falta de conocimientos de los usuarios y este conocimiento los ayudaría alinearse para establecer un objetivo en común.
Conocimiento del negocio: El conocimiento del negocio ayuda al equipo a conocer la línea de negocio sobre la cual va el producto, esto ayudaría mucho a Sergio y Alejandro a tomar decisiones acertadas en la priorización de los elementos.

Edwar Y. Castillo B.

student•

CLAUDIA ANDREA CAMPO GRIJALBA

student•

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:

Hallazgos: Primera vez que trabajan juntos. Susana tiene experiencia, pero es su primer proyecto en la empresa Sandra no ha trabajado Agilidad antes.

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

Hallazgos: Susana y Sergio trabajando en contextos diferentes Susana y Sergio reportando al director de nuevos productos de forma individual

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

Hallazgos: La visión de Santiago no es lo que Luz debe comprender Deben basarse en un producto backlog Como refinar algo que no existe desde el principio?

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

Hallazgos: No se esta teniendo en cuenta que los incrementos se presentan al usuario final y no a los accionista o directores, tampoco se entregan resultados que permitan medir desempeño del equipo de trabajo. Aquí no se observa a un usuario final interactuando con el producto final del sprint terminado. Además, en esta entrega se debe contar con un miembro del equipo de desarrollo.

Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Comunicación

Hallazgos: No se esta teniendo en cuenta que los incrementos se presentan al usuario final y no a los accionista o directores, tampoco se entregan resultados que permitan medir desempeño del equipo de trabajo. Aquí no se observa a un usuario final interactuando con el producto final del sprint terminado. Además, en esta entrega se debe contar con un miembro del equipo de desarrollo.

Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Comunicación

Hallazgos: Alejandro no es el encargado de realizar las comunicaciones al equipo, el refinamiento de los criterios de aceptación se debería realizar en conjunto con cualquier miembro del equipo de desarrollo, no se está teniendo en cuenta que los incrementos se presentan al usuario final y no a los accionista o directores, tampoco en Scrum se entregan resultados que permitan medir desempeño del equipo de trabajo. Aquí no se observa a un usuario final interactuando con el producto final del sprint (incremento) terminado. Además, en esta entrega se debería contar con un miembro del equipo de desarrollo y no solo que lo haga el P.O.

Conocimientos necesarios para resolver la problemática: Contexto del usuario final Contexto del producto Negociación Abstracción Facilitación Influencia Comunicación

Hallazgos: No existen los pilares ni valores de Scrum, falta el Scrum Master, y el desarrollo de sus Eventos y Artefactos, las reuniones de planificación concluyen sin que los integrantes del equipo tengan claridad total del trabajo a desarrollar, no hacen uso de las herramientas de trabajo colaborativo, ni visuales, y la opción de co-crear esquemas no es responsabilidad del equipo.

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

Vanessa Amaya

teacher•

Hola! Está muy bien enfocado cómo hiciste tu ejercicio

Alvaro Angel

student•

Caso de estudio

¿Cuál es la problemática? ¿Qué conocimientos harían la diferencia para resolver el problema?

—

Hallazgos

Primera vez que todo el equipo trabaja junto. Algunos no tienen experiencia en el marco de trabajo Scrum.
La estrategia de marketing difiere un poco de la estrategia de ventas. No hay sinergia. Dos personas tienen la misma jerarquía (existen jerarquías) y reportan al Director de nuevos productos.
Miembros del Dev Team están ‘sueltos’, no hay compromiso en el trabajo, ya que desde un comienzo no hubo un Sprint Planning. — Al no identificarse un Product Owner, no se pudo organizar el Product Backlog y los miembros del equipo priorizan trabajos sin un objetivo claro.
No se tiene claro el usuario final. No existen Historias de Usuario en el Product Backlog; no existe o no hay transparencia en el Product Backlog.
No hay una alineación clara del Product Goal.
No existe una comunicación efectiva en las reuniones del equipo. No existe un ‘Scrum Master’ que facilite los procesos e influya en la generación de valor del producto. Los integrantes del equipo no pueden comunicarse de forma efectiva lo que ‘esconde’ conflictos internos y genera impedimentos.
No hay claridad de lo que se está haciendo en las Daily Scrum. O si se están haciendo estas reuniones.
Miembros del equipo trabajan en remoto. Al existir una falta de madurez e integración dentro del equipo, esto no se debería permitir. Mientras consiguen la madurez necesaria, el equipo debe trabajar junto, debe existir un contacto físico.

Conclusiones

No se identificó desde un principio el marco de trabajo ágil que se iba a implementar. Si suponemos que se va a trabajar con Scrum, no se identificaron los miembros del equipo. Se empezó muy mal.
Se debe identificar cada miembro responsable: un Product Owner (Sergio), un Scrum Master (Sandra) y el Developer Team.
Una vez se tenga el marco de trabajo claro, cada quien debe empezar a hacer su trabajo, iniciando con una excelente Sprint Planning, donde en conjunto se pueda empezar el primer Sprint.
Debe existir Transparencia, Inspección y Adaptabilidad en cada evento del Sprint. — Sandra debe ser una persona muy activa en el cumplimiento del marco de trabajo Scrum.
Al tener claro el marco de trabajo, se sabrá que se eliminan las jerarquías y cada miembro es igual de importante, cada miembro aporta y genera valor. Existe una comunicación y escucha efectiva.
Sandra se encargará de colaborar con Sergio y el Dev Team. Cumplirán cada ceremonia del marco de trabajo Scrum y refinarán las historias de usuario una vez a la semana. — Los Sprints deberán ser de 1 a 2 semanas.
Debe existir claridad con el Sprint Backlog y el Sprint Goal. Sergio deberá colaborar eficientemente con Sandra y el Dev Team.
En general se requiere el conocimiento de un marco de trabajo ágil; en este caso puede ser Scrum. Iniciar las iteraciones de acuerdo a como manda el proceso para evitar impedimentos, falta de comunicación y problemas en el Product Goal.
El PO debe hacer mas entendible el problema al equipo. El uso de la comunicación efectiva, negociación, facilitación e influencia. También debe tener conocimiento del producto y habilidad para relacionarlo al contexto de usuario.
Debe existir un análisis de negocio claro. Las estrategias formuladas por Susana y Sergio no están coordinadas.
Implementar herramientas colaborativas y de visual thinking.

Carlos Roberto Doblado Ochoa

student•

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.

Omar Caires

student•

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!

Sandra Sierra

student•

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

Gian Michael Esteves Ramirez

student•

;) Apuntes de la clase

Bases del Product Owner
- Necesitas conocimiento del negocio
- Necesitas conocimiento del comprador y usuario final
- Necesitas conocimiento del producto
- Necesitas conocimiento de administración de proyecto
Habilidades del Product Owner
- Negociación
- Adquirir grandes cantidades de información y transmitirlo de forma sencilla al equipo
- Facilitador
- Influencia
- Comunicación
Herramientas:
- Colaborativas
- Visual Thinking

Ezequiel Alejandro Barrales

student•

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:

Colaborativas:
- Explorar herramientas con visual thinking.

Jonathan Quiros Barquero

student•

1) Problemática del caso

El caso presenta varios retos típicos en la adopción de Scrum, que son los siguientes:

Desalineación de expectativas de negocio
- Marketing (Susana) piensa en el consumidor final.
- Ventas (Sergio) está enfocado en los ejecutivos que usan la app. → Esto genera confusión en la priorización del backlog.
Backlog poco refinado y no orientado a valor
- Hay muchas ideas técnicas y de diseño (OCR, integraciones, performance, UX), pero falta ordenarlas en función del impacto real al negocio y al usuario.
Problemas de colaboración y roles difusos
- Sandra actúa como líder técnica, pero también cubre tareas del Scrum Master.
- Alejandro apoya, pero no tiene clara su interacción con Sergio.
- Faltan mecanismos para que todos participen en las ceremonias (ejemplo: algunos no se sienten cómodos en las retrospectivas).
Falta de cocreación UX – desarrollo
- Santiago (UX) y los front-end (Luz, Gustavo) no logran integrarse a tiempo, generando retrabaljo.
Limitación de presupuesto y presión por resultados
- Se debe decidir en el último Sprint qué funcionalidades maximizan valor con recursos limitados.

2) Conocimientos y herramientas ágiles necesarias

Para atacar estas problemáticas, el equipo debería fortalecer lo siguiente:

a) Gestión del Product Backlog

User Stories bien definidas (formato: Como [rol] quiero [funcionalidad] para [beneficio]).
Acceptance Criteria / Definition of Done claros.
Técnicas de priorización ágil: MoSCoW, WSJF (Weighted Shortest Job First), Kano, o simplemente valor de negocio vs esfuerzo.

Herramienta útil: User Story Mapping para visualizar el flujo del usuario (ejecutivo de ventas) y ordenar backlog.

b) Roles y eventos Scrum

Claridad de roles: Sergio (PO), Sandra (SM), equipo dev autoorganizado.
Scrum Master debe fomentar seguridad psicológica en retrospectivas y reuniones (por ejemplo, dot voting o retros con notas anónimas).
Daily Scrums enfocados en inspección y adaptación, no en reportes.

Herramienta útil: Retrospective formats (Mad/Sad/Glad, 4L’s, Starfish).

c) Colaboración UX y Dev

Involucrar a UX desde la planificación y refinamiento, no al final.
Usar prototipos en Figma/InVision antes de pasar a desarrollo → validación rápida con usuarios.

Herramienta útil: Design Sprint o UX Storyboards.

d) Enfoque en valor y métricas ágiles

Definir Objetivos del Sprint (Sprint Goals) ligados a resultados de negocio.
Usar métricas ágiles como Velocity, Burndown Chart, Lead Time, y métricas de producto (adopción por ejecutivos, reducción de tiempo de captura, menos rechazos de documentos).
Preparar Release Planning con entregas incrementales.

Herramienta útil: OKRs alineados con el backlog.

e) Priorización en entornos de restricción

Con poco presupuesto → se necesita foco en MVP (Producto Mínimo Viable).
Ejemplo: dejar performance avanzado o “nice to have” para después, y enfocarse en la captura y validación básica de documentos.

Herramienta útil: Impact Mapping o Value vs Effort Matrix.

Yobana Sandoval Parra

student•

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.

Gilberto Ehecatl Melo Alvarez

student•

Hola Vanessa, disculpa hay 2 conceptos que se presentaron en clase pero no tengo contexto de su significado: El Dominio Empresarial y la arquitectura empresarial, podrías comentarme con más detalle a que se refieren?

Vanessa Amaya

teacher•

Hola Gilberto! El Dominio empresarial es una representación parcial de la arquitectura empresarial. El Dominio es el alcance que se tendrá dentro de la arquitectura.

Nicolas Rodriguez

student•

Qué libros recomiendan para profundizar en el rol de Product Owner?

Vanessa Amaya

teacher•

El IIBA (International Institute of Business Analysis) sacó un libro muy completo sobre Product Ownership. Es gratis para miembros del IIBA, recomiendo mucho la membresía. https://www.iiba.org/

Paola Rivero

student•

Con respecto a la pregunta planteada para el caso de estudio ¿A qué se refiere? ¿A los problemas dentro de los escenarios o al proyecto per ce?

Brian David Pajares Correa

student•

Creería al problema de los escenarios.

Mariana Di Salvatore

student•

Problemáticas / necesidades identificadas en los distintos escenarios:

-Necesidad de establecer un marco de trabajo conjunto entre todos los miembros de un equipo, definiendo métodos de comunicación, responsabilidades, alcance, etc.

-Necesidad de acompañamiento a perfiles inexpertos o recién incorporados en cuanto a la filosofía de la empresa así como para facilitar su integración.

-Susana y Sergio tienen puntos de vistas valioso pero faltaría saber si para el cliente interesa un público específico (consumidores o ejectutivos). En caso de que sean ambos, definir qué se quiere priorizar, qué puntos hay en común para ambas visiones, etc.

-Definir el tiempo que cada uno de los itnegrantes puede dedicar al proyecto y en función de eso ver qué capacidad existe realmente.

-El diseño y la funcionalidad de la app no pueden plantearse de forma separada.

-Necesidad de mecanismos que permitan conocer el estado del equipo, sus relaciones, etc.

-Modelos establecidos donde se da mayor protagonismo a determinados perfiles contra la idea de que el equipo participe y trabaje en conjunto.

-Falta de un análisis inicial profundo que permitiese entender lo que se requería, así como la priorización en función de experiencias personales y criterios no compartidos. Además impacta no haber tenido en cuenta el presupuesto y el tiempo de entrega previsto para revisar si era viable lo que se pedía y lo que planteó el equipo.