Características de un gran Product Owner

Extracto traducido al castello del whitepaper “Characteristics of a Great Scrum Team” escrito por Barry Overeem.

Product Owner

El Product Owner es responsable de maximizar el valor del producto y el trabajo del equipo de desarrollo. Es un rol de una sola persona que lleva la perspectiva del cliente del producto a un equipo Scrum.

El Product Owner es responsable de:

  • Desarrollar y mantener una visión de producto y estrategia de mercado;
  • Gestión de productos;
  • Ordenar y gestionar el Product Backlog;
  • Involucrar a los Stakeholders y usuarios finales en el refinamiento del Product Backlog y en la gestión del Backlog;
  • Alineación con otros Product Owners cuando sea necesario desde la perspectiva general del producto, la empresa o el cliente.

UN GRAN PRODUCT OWNER …

  • Abraza, comparte y socializa la visión del producto. Un gran Product Owner representa la voz de los clientes y crea una visión del producto junto con los Stakeholders. Cada decisión se toma considerando la visión del producto. Esto asegura el desarrollo sostenible del producto, proporciona claridad para el equipo de desarrollo y aumenta drásticamente las posibilidades de éxito del producto.
  • Supera las expectativas del cliente. Un gran Product Owner realmente entiende las intenciones y los objetivos del cliente con el producto y es capaz de superar sus expectativas. La satisfacción del cliente es el objetivo final!
  • Está empoderado. Un gran Product Owner está empoderado para tomar decisiones relacionadas con el producto. Seguramente crear respaldo para sus decisiones puede llevar algún tiempo, pero tomar decisiones importantes con rapidez es una condición principal para el ritmo sostenible del equipo de desarrollo.
  • Ordena el Product Backlog. Un gran Product Owner entiende que se debe ordenar el Product Backlog. La prioridad, el riesgo, el valor, las oportunidades de aprendizaje y las dependencias se toman en cuenta y se equilibran entre sí. Por ejemplo, cuando se construye una casa, el techo puede tener la mayor prioridad considerando la posibilidad de lluvia. Pero aún es necesario realizar los cimientos y las paredes antes y, por lo tanto, ordenarlos por encima de la construcción del techo.
  • Prefiere la comunicación cara a cara. Un gran Product Owner entiende que la mejor manera de transmitir información es la comunicación cara a cara. Las historias de los usuarios se explican en una conversación personal. Si se utiliza una herramienta para la gestión del Backlog, su función es apoyar el diálogo. La herramienta nunca reemplaza una buena conversación pasada de moda.
  • Conoce técnicas de modelado. Un gran Product Owner tiene una mochila llena de valiosas técnicas de modelado. Él sabe cuándo aplicar un modelo específico. Algunos ejemplos son Business Model Generation, Lean Startup o Impact Mapping. Sobre la base de estos modelos, sabe cómo impulsar el éxito del producto.
  • Comparte experiencias. Un gran Product Owner comparte experiencias con sus compañeros. Esto podría realizarse tanto dentro como cuera de la organización: los seminarios y conferencias son una excelente manera de compartir experiencias y recopilar conocimientos. Además, escribir las lecciones aprendidas puede ser valioso para otros Product Owners.
  • Tiene un User Story Mapping. Un gran Product Owner debe dominar el concepto de User Story Mapping. Es una técnica que le permite agregar una segunda dimensión a su Backlog. La visualización le permite ver el panorama general del Product Backlog. Jeff Patton escribió un excelente material sobre el concepto de Story Mapping.
  • Se encuentra centrado en la funcionalidad. Un gran Product Owner se centra los aspectos funcionales y no-funcionales del producto. Las horas o incluso los puntos de la historia son menos importantes. El objetivo del Product Owner es maximizar el valor para el cliente. Es la funcionalidad la que tiene valor; por lo tanto, este es el enfoque principal para el Product Owner.
  • Está bien informado. Un gran Product Owner tiene conocimiento profundo en lo (no-)funcional del producto y entiende su composición técnica. Para productos grandes, puede ser difícil comprender todos los detalles, y escalar la función de Product Owner puede ser una opción. Sin embargo, el Product Owner siempre debe conocer las piezas más grandes del rompecabezas y, por lo tanto, tomar decisiones conscientes y sólidas.
  • Entiende el dominio del negocio. Un gran Product Owner entiende el dominio y el entorno del que forma parte. Un producto siempre debe construirse teniendo en cuenta su contexto. Esto incluye comprender la organización que paga por el desarrollo, pero también conocer las últimas condiciones del mercado. El envío de un producto increíble después de que se cierre la ventana de oportunidad es bastante inútil.
  • Actúa en diferentes niveles. Un gran Product Owner sabe cómo actuar en diferentes niveles. La forma más común de definir estos niveles es estratégica, táctica y operativa. El Product Owner debe saber cómo explicar la estrategia del producto a nivel ejecutivo, generar apoyo en la gerencia media y motivar al equipo de desarrollo con sus desafíos diarios.
  • Conoce los 5 niveles de planificación ágil. Dentro de Agile, la planificación se realiza de forma continua. Cada producto necesita una visión (nivel 1) que proporcionará información para el Roadmap del producto (nivel 2). El Roadmap es un plan estratégico a largo plazo de cómo la empresa quisiera ver la evolución del producto. De acuerdo con el Roadmap, las condiciones del mercado y el estado del producto, el Product Owner puede planificar los Releases (nivel 3). Durante el Sprint Planning (nivel 4), el equipo planifica y acuerda que Itemas del Product Backlog estan seguros de poder completar durante el Sprint y los ayuda a lograr el objetivo de Sprint. El Daily Scrum (nivel 5) se utiliza para inspeccionar y adaptar el progreso del equipo hacia el cumplimiento del objetivo Sprint.
  • Está siempre disponible. Un gran Product Owner está disponible para los Stakeholders, los clientes, el equipo de desarrollo y el Scrum Master. Las preguntas importantes se responden rápidamente y la información valiosa se proporciona a tiempo. El Product Owner garantiza que su disponibilidad nunca bloquea el progreso del equipo de desarrollo.
  • Es capaz de decir ‘no’. Un gran Product Owner sabe cómo y cuándo decir no. Esta es probablemente la característica más obvia pero más difícil de dominar. Decir sí a una nueva idea o Feature es fácil, es solo otro Itém para el Product Backlog. Sin embargo, una buena gestión del Product Backlog comprende la creación de un Product Backlog manejable con Itéms que probablemente se completarán. Agregar Itéms al Backlog sabiendo que nada les sucederá solo crea ‘desperdicio’ y falsas expectativas.
  • Actúa como un “Mini-CEO”. Un gran Product Owner es básicamente un mini-CEO de su producto. Tiene buen ojo para las oportunidades, se enfoca en el valor comercial y el retorno de la inversión y actúa proactivamente ante posibles riesgos y amenazas. Tiene en cuenta todo lo relacionado con el crecimiento de su producto (tamaño, calidad, cuota de mercado).
  • Conoce los diferentes tipos de Itéms válidos del Product Backlog. Un gran Product Owner puede aclarar el hecho de que el Product Backlog consiste en más que solo nuevas Features. Por ejemplo, también deben tenerse en cuenta: innovación técnica, errores, defectos, requisitos no funcionales y experimentos.
  • Se toma en serio el refinamiento de Backlog. Un gran Product Owner pasa el tiempo suficiente para refinar el Product Backlog. El refinamiento de Backlog es el acto de agregar detalles, estimaciones y orden a los Itéms en el Product Backlog. El resultado debe ser un Product Backlog suficientemente granular y bien comprendido por todo el equipo. En promedio, el Equipo de Desarrollo no gasta más del 10% de la capacidad del Equipo de Desarrollo en actividades de refinamiento. La forma en que se hace no está prescrita y depende del equipo. El Product Owner puede involucrar a los Stakeholders y al equipo de desarrollo en el refinamiento del Backlog. Involucra a los Stakeholders porque les da la oportunidad de explicar sus deseos y necesidades. Involucra al equipo de desarrollo porque pueden aclarar preguntas o implicaciones funcionales y técnicas. Esto asegurará un entendimiento común y aumentará considerablemente la calidad del Product Backlog. Como consecuencia, también aumentará la oportunidad de construir el producto correcto con la calidad deseada.

Leave a Reply

Your email address will not be published. Required fields are marked *