Guía Scrum | 7. Los errores más comunes del Product Owner

En la publicación de hoy nos centraremos en los desafíos más comunes que enfrentan los propietarios de productos. También le diremos cómo prepararse para las situaciones en las que estos errores del propietario del producto ocurren con mayor frecuencia.

Errores del Dueño del Producto – índice:

1. Lo que puede salir mal entre el propietario del producto y el cliente
2. Desafíos que enfrenta el Product Owner con respecto al resto del Scrum Team
3. Resumen

Lo que puede salir mal entre el propietario del producto y el cliente

El Dueño del Producto es la persona personalmente responsable de las fallas del Equipo Scrum. Debido a esta posición más allá de las actividades del equipo, se considera que el Product Owner es el único cuello retorcido . En otras palabras, es el Product Owner quien sufre más cuando el Scrum Team falla. Entonces, ¿cómo lidiar con situaciones problemáticas cuando aparecen o, mejor aún, evitar que sucedan en primer lugar?

Para responder a ese punto, proporcionamos un análisis claro y profundo de algunos errores importantes de los propietarios de productos y clientes en la siguiente tabla, junto con una discusión detallada de cada uno.

Incapacidad para priorizar

El error de no saber priorizar es la perdición de muchos Product Owners. ¿Por qué la priorización de tareas es una competencia central? Porque cuando todo se vuelve igual de importante, el Objetivo del Producto desaparece. Ese es el efecto previsto de la actividad del Equipo Scrum.

El problema comienza ya durante las primeras conversaciones con los clientes sobre el Objetivo del Producto. El cliente normalmente quiere que todas sus ideas se realicen de la forma más rápida y económica posible. La tarea del Product Owner es establecer una lista de prioridades. Su tarea es crear una lista de expectativas claras y factibles clasificadas de la más importante a la menos importante, con base en las expectativas no estructuradas del cliente.

El problema con la priorización se origina en la mayoría de los casos por no comprender las expectativas del cliente. Aparece cuando el Product Owner no es capaz de extraer información sobre los Objetivos reales del Producto del Cliente. Esa es la respuesta a la pregunta de a qué necesidades se supone que responde el producto.

Entonces, ¿cómo te proteges de este error? Primero: escuche atentamente al cliente. En segundo lugar, aprenda a hacer preguntas sobre el objetivo y cómo funciona cada característica del producto. Tercero – negociar y limitar los Objetivos a alcanzar. Y para ello, necesitarás asertividad.

Cuando el Product Owner tiene una lista de tareas por hacer, existen métodos probados para mejorar su progresión y elaboración. Por ejemplo, se utiliza la llamada matriz de Eisenhower para priorizar tareas según criterios de importancia y urgencia.

Falta de asertividad del propietario del producto

El problema que está íntimamente relacionado con la incapacidad para priorizar es la falta de asertividad. Da como resultado tareas en cola inapropiadas y conduce a bloquear la realización del objetivo del producto al combinarlo con tareas excesivas. Por lo tanto, la capacidad de decir no al cliente es crucial.

La asertividad del Product Owner debe basarse en tres pilares:

• conocimiento de las capacidades del equipo,
• conocimiento de las soluciones utilizadas y desarrolladas por el equipo,
• conciencia de su rol y valor en función de su lugar en el Scrum Team.

Por lo tanto, una de las formas más importantes de prevenir problemas de asertividad es que el Product Owner trabaje con el Equipo Scrum diariamente. Esto lo ayudará a construir creencias realistas sobre el tiempo y la capacidad para implementar las ideas del Cliente.

Habilidades comerciales insuficientes

El siguiente error del que nos gustaría hablar es la falta de calificaciones comerciales adecuadas. Las fortalezas de estos Product Owners suelen ser calificaciones especializadas. Sus competencias están más relacionadas con el área del Equipo de Desarrollo que con el negocio. Entonces, hay una falta de conocimiento práctico y bien establecido sobre la competencia, sobre las reglas del mercado y el cliente final del producto creado por el Equipo Scrum.

No existe un remedio sencillo para ello, ya que puede darse en situaciones muy concretas. Seguramente, sin embargo, un buen curso de acción para un Product Owner es reconocerlo y seguir aprendiendo y ganando experiencia y competencias comerciales.

Desafíos que enfrenta el Product Owner con respecto al resto del Scrum Team

La capacidad de priorizar tareas, la asertividad del Product Owner y sus altas habilidades comerciales son los requisitos previos necesarios para crear un Product Backlog ejemplar, la base a largo plazo del Scrum Team. Si el Backlog no se describe de manera consistente y precisa, los problemas en la relación entre el Propietario del producto y el Cliente se extenderán a la relación entre el Propietario del producto y otro miembro del Equipo Scrum. Y a su vez, afectan directamente la efectividad del Scrum Team. ¿Qué otras trampas le esperan al Dueño de Producto en sus relaciones con los otros miembros del Equipo Scrum?

Para hacerlo más fácil, hemos presentado los problemas entre el Product Owner y Scrum Team en una tabla. A continuación puede encontrar una discusión detallada de cada problema y sugerencias de solución.

pobre carisma

Diariamente, el trabajo del propietario del producto es coordinar las pautas del cliente con la forma en que las implementa el equipo de desarrollo. Esto sin duda requiere tener la autoridad adecuada, habilidades para escuchar y carisma.

El problema de la autoridad insuficiente no puede resolverse de la noche a la mañana. Requiere trabajo a largo plazo en habilidades blandas. Y también ganando conocimiento sobre el alcance de las tareas y habilidades de otros miembros del equipo.

Habilidades especializadas insuficientes

Como escribimos en el artículo respondiendo a la pregunta ¿Quién es un Product Owner?, el rol de un Product Owner no es estrictamente técnico. Sin embargo, conocer los conceptos básicos de las habilidades especializadas de los miembros del equipo de desarrollo puede aumentar significativamente la autoridad de un propietario del producto. Las calificaciones insuficientes en el área de especialización del equipo no solo pueden generar problemas con el carisma y la autoridad del Product Owner. El error de no interesarse por la especialidad de los miembros del Equipo de Desarrollo y los fundamentos de sus competencias puede generar situaciones graciosas, pero también situaciones con nefastas consecuencias empresariales e interpersonales.

Por lo tanto, para que el equipo Scrum entregue productos de la mejor calidad, el propietario del producto debe tener un conocimiento profundo del producto. No debería ser difícil obtener la calificación adecuada considerando que el Product Owner es parte de un equipo de profesionales. Pueden proporcionar no solo explicaciones, sino también sugerencias sobre dónde obtener conocimientos sobre su campo.

Independencia

El propietario del producto debe poder tomar decisiones de forma independiente. Por supuesto, la cuestión clave es conocer las condiciones del Equipo Scrum y comunicarse constantemente con el Equipo de Desarrollo. Sin embargo, es el Product Owner quien es responsable de la efectividad de sus acciones. Por esta razón, los Product Owners necesitan construir su autoridad y asumir la responsabilidad de las decisiones que toman. Les corresponde a ellos la decisión final sobre la dirección del equipo, la priorización y la aceptación de las tareas.

Resumen

Hemos descubierto los errores más comunes del Product Owner. El papel de un Product Owner no es fácil. Por eso, al tomarlo, vale la pena prepararse para los problemas que otros han encontrado en su camino.

Los problemas de relación con el cliente generalmente se derivan de la falta de asertividad, la incapacidad para priorizar y las habilidades comerciales insuficientes.

Los errores de Product Owner que surgen durante el trabajo con el resto del Equipo Scrum resultan de la falta de independencia y carisma insuficiente de la persona que asumió el rol de Product Owner. Otra razón puede ser la falta de habilidades especializadas y falta de voluntad o falta de tiempo para ampliar el conocimiento.

Si te gusta nuestro contenido, únete a nuestra comunidad de abejas ocupadas en Facebook, Linkedin y Twitter.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos