Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

Empoderamiento del rol de Product Owner

3/12
Recursos

Aportes 30

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

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

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.

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

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

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.

Caso de estudio

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

Hallazgos

  1. Primera vez que todo el equipo trabaja junto. Algunos no tienen experiencia en el marco de trabajo Scrum.
  2. 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.
  3. 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.
  4. 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.
  5. No hay una alineación clara del Product Goal.
  6. 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.
  7. No hay claridad de lo que se está haciendo en las Daily Scrum. O si se están haciendo estas reuniones.
  8. 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

  1. 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.
  2. Se debe identificar cada miembro responsable: un Product Owner (Sergio), un Scrum Master (Sandra) y el Developer Team.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Debe existir claridad con el Sprint Backlog y el Sprint Goal. Sergio deberá colaborar eficientemente con Sandra y el Dev Team.
  8. 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.
  9. 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.
  10. Debe existir un análisis de negocio claro. Las estrategias formuladas por Susana y Sergio no están coordinadas.
  11. Implementar herramientas colaborativas y de visual thinking.
**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

  • 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
Hola, aquí mis análisis por cada escenario del caso. ![](https://static.platzi.com/media/user_upload/image-f377c0e7-7ded-4dd3-b329-0c984b272043.jpg) ![](https://static.platzi.com/media/user_upload/image-f3a339b0-7d94-4966-9d99-18e91b0edc70.jpg) ![](https://static.platzi.com/media/user_upload/image-87eabe09-7703-4314-8e46-3d85a34fd954.jpg) ![](https://static.platzi.com/media/user_upload/image-7fcd5392-0568-4512-8fb5-5f3e671a3833.jpg)
¿No se suponía que el Scrum Master era el encargado de agendar las reuniones? Estoy empezando a creer que el Scrum Master como tal es algo innecesario o no es fundamental dentro del equipo.
![](https://static.platzi.com/media/user_upload/3-9fd120e2-64d0-457a-a91b-e196c9b4b654.jpg)![](https://static.platzi.com/media/user_upload/4-85445f48-1dee-46ed-8340-a8c359ac6864.jpg)
**Herramientas:** Ø **Colaborativas:** Herramientas digitales que nos permitan colaborar en entornos remotos, independientemente el tipo de trabajo debemos fomentar la colaboración y hay muchas aplicaciones cuya naturaleza es ser colaborativas y poder llegar a decisiones y acciones juntos, unir perspectivas. Ø **Visual Thinking**: o pensamiento visual, herramientas que te ayudan a visualizar o esquematizar, abstraer y facilitar el conocimiento hacia tu equipo.
**Conocimientos:** Ø Necesitamos conocimiento del negocio No es nada más el producto que va a hacer tenemos que ver algo en relación con el negocio con relación al producto sino nos va a faltar el contexto para tomar decisiones de priorización Ø Conocimiento relacionado al contexto de usuario: El usuario solicitante no siempre es el usuario final, debemos tener presente ambas figuras. 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. Ese producto y ese negocio se mueve sobre un dominio empresarial que es importante conocer. Esta parte empodera mucho a quien porta esta responsabilidad porque lo conecta con su arquitectura 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.
El reto de esta clase se enfoca en identificar la problematica del caso, se debe seleccionar y priorizar los conocimientos necesarios para que el problema pueda salir mucho mas facil? Para esto propongo lo siguiente: 1. Asegurar que todos los miembros del equipo tengan claro como se trabaja bajo una metodologia Agil como SCRUM 2. Susana y Sergio tienen el mismo enfoque 3. Sergio se enfoca en los ejecutivos de venta lo cual es lo adecuado ya que ellos son los consumidores finales del producto que se desarollara 4. Todas las personas deberian ser incluidas en las reuniones diarias y hacer parte de los sprint. El SCRUM MASTER (Sandra) es la persona encargada de quitar "distractores" como trabajo en diferentes proyectos como en el caso de Santiago 5. Se deberian realizar actividades de engagement dentro del equipo para incrementar la fluidez en la comunicacion
Si el product owner no posee conocimiento del negocio ?, entonces no podria entregar el alcance al equipo scrum?.
En la nueva interfaz no aparecen los recursos que se mencionan en las clases.

EMPODERAMIENTO DEL PRODUCT
Tiene que tener el conocimiento del negocio que va el producto.
debe tener contexto del usuario, contexto de producto, conocimiento del dominio esto empodera mucho a quien porta esta responsabilidad, analisis del negocio para entender, proponer y definir.

Reto: Identificar y priorizar conocimientos que nos faciltarian salir del problema en el caso de estudio.
Problematicas
Equipo que no se comunica bien y no se relacionan con confianza, por tanto no hay una participacion activa
No había una alineación en el equipo sobre el analisis funcional del producto o sobre las necesidades de los usuarios . Lo priorizaria asi…

  1. Es necesario mejorar la habilidad de comunicación y visual thinking
  2. Conocimiento y habilidad de facilitación
  3. Conocimiento del usuario final y sobre el negocio

Para ser un PO empoderado se necesita …

  1. Conocimiento: Conocer el negocio relacionado con el producto. Conocer el contexto del usuario final (quien lo va a usar) y del cliente. Conocer el mercado. Conocer el contexto del producto. Partes valiosas y como hacerlo disruptivo. Conocer el Dominio empresarial. Disciplina de Análisis de negocio.
  2. Habilidades: Negociación - Abstracción - Facilitación - Influencia - Comunicación
  3. Herramientas colaborativas - Visual thinking

En mi opinión, la habilidad de liderazgo puede sustituir y ampliar la habilidad de influencia. Aunque el liderazgo incluye la influencia en su definición, el término nos proporciona una idea más precisa de lo que implica.

++Problemática: ++Demoras en el proceso de gestión y aprobación de créditos.

++Herramientas que harían la diferencia: ++

  • Análisis de mercado en herramientas que cumplan con los requerimientos para gestión de créditos.

  • Integración del equipo de infraestructura para mejorar tiempos de respuesta y estabilidad en las integraciones con los diferentes sistemas.

Habilidades por desarrollar:

  1. Negociación: representamos la voz del cliente, y negociamos con muchas personas para lograr el objetivo.

2.Abstracción: Categorizar y digerir toda la información que recibe de muchas fuentes. Debe hacer que la info se mas entendible para el equipo.

  1. Facilitación: Facilitar la vida el equipo que va a hacer realidad su producto.

  2. Influencia: No importa la jerarquia que tengas, puedes influir en el resultado.

  3. Comunicación: Fomentar desde la responsabilidad del PO, conversaciones productivas.

Según el estudio del caso se plantea:
Los miembros del equipo es la primera vez que trabajan todos juntos. Sergio y Alejandro ya han trabajado en 3 proyectos juntos. Susana tiene mucha experiencia en marketing, pero es su primer proyecto en esta empresa. El equipo de Desarrollo ya ha trabajado todos juntos. Sandra tiene experiencia como líder de equipo sin embargo es la primera vez que está en un proyecto bajo marco ágil trabajando por Sprints.
Se requiere:

  • el PO hacer mas entendible al equipo el problema, mediante la comunicación, negociación, facilitación e influencia
  • conocimiento del producto y relacionado al contexto de usuario.
  • análisis de negocio ya que las estrategias formuladas por Susana (mas colocación de ventas a crédito) y Sergio (bajar la morosidad) van en distinta preocupación.
  • Implementar herramientas colaborativas y de visual thinking

Actividad: Dentro de caso de estudio, identificar los conocimientos que hacen la diferencia para que el problema se pueda solucionar mucho más fácilmente.

En mi opinión los conocimientos mas importantes en este aspecto son los que tienen Sergio y los que está adquiriendo Alejandro.

Sergio: Es el experto en la línea de negocio. Se encarga de hacer que se cumpla la estrategia de Susana y cuidar que el equipo permanezca orientado a los usuarios finales de la aplicación.

Alejandro: Apoya a Sergio generando análisis desde varias perspectivas, levanta información y se encarga de analizarla y esquematizarla para que tanto Sergio como el resto del equipo tomen decisiones y Sergio pueda priorizar el trabajo del equipo.

Es claro que todo el equipo no tiene conocimientos de SCRUM. Eso ocasiona deficiencias en las áreas del negocio, Por lo tanto todos deben tomar el curso Profesional de SCRUM en Platzi (jaja) es en serio!!.
Una vez tomado el curso === tendrán sinergia, puestos definidos, actividades definidas y claridad en objetivos.
Y el Product Owner = el curso de Fundamentos de Product Owner.

Problematica: No tener claro el valor que brindará la solución al cliente, ya que en algunos perfiles no se tiene un conocimiento profundo de negocio.

Conocimientos requeridos:

Conocimiento de negocio
Contexto del usuario
Contexto del producto

Habilidades que se requieren:

Abstracción; esto permitiria al equipo entender realmente que le duele al cliente y en donde se puede generar valor, ademas de comprender el perfil de usuario

Negociación e influencia: Sergio al conocer más el negocio, tiene la posibilidad de negociar con Susana los features de la app e influir de manera positiva para que el producto genere valor

Problemática: demoras en el proceso de solicitud de créditos para vehículos.

Conocimientos requeridos:

  • De la compañía de autos, la gestión de créditos, bases de datos, conocimiento de requerimientos técnicos de la aplicación a desarrollar y el equipo de ventas.
    *Herramienta colaborativa Intranet.

Product owner debe entender el negocio , conocer el contexto del usuario, el contexto del producto y el conocimiento del dominio empresarial