domingo, marzo 29, 2020

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.
  • Vista 1 - Descubrimiento (Discovery):
    • En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
      • expertos del negocio
      • arquitectos de software y arquitectos empresariales
      • Expertos en UX / UI
      • clientes
      • posibles suarios
      • expertos en Seguridad y Riesgos
      • expertos en Procesos
      • gerentes de Producto (Product Managers
      • otros PO e interesados claves
    • Para definir:
      • el producto,
      • la visión del producto
      • la lista ordenada del producto (Product Backlog)
      • el producto minimo viable (Minimum Viable Product - MVP
      • las versiones, 
      • los prototípos,
      • los indicadores,
      • los esquemas de ROI
      • las hipótesis, etc.
    • Para esto se vale de:
      • visitas a clientes y usuarios
      • conocer donde va a ser usado el producto (gemba walks)
      • investigaciones de mercado
      • análisis de la compentencia (benchmarks)
      • estrategias de construcción del producto
      • dependencia de otros productos o soluciones, etc.
  • Vista 2 - Desarrollo (Development): 
    • En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
  • Vista 3 - Producción (Production): 
    • En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.
De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:
  • Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • problemas de rendimiento y funcionamiento
      • estadisticas de desempeño
      • problemas de seguridad
      • deuda técnica identificada y que debe ser priorizada
  • Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
    • El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
      • funcionalidades innecesarias
      • funcionalidades a adicionar
      • estrategias de implementación
      • deuda técnica identificada a ser priorizada
      • incidentes y bugs a ser priorizados
      • retos técnicos
      • estimaciones
      • nuevas dependencias técnicas
      • nuevas dependencias funcionales con otros productos o equipos de trabajo
  • Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • valor o ROI generado vs. el esperado
      • datos que se obtienen de la validación de hipótesis
    • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • estadisticas de desempeño
      • problemas de seguridad identificados
      • problemas de experiencia de usuario identificados
      • deuda técnica identificada y que debe ser priorizada
      • estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
  2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
  3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.


5 comentarios:

  1. Wow Jorge señor, buen artículo, qué introspección profunda como un enfoque para ser un buen propietario del producto y un ciclo de PO en las diferentes vistas

    ResponderBorrar
  2. Wow Jorge señor, buen artículo, qué introspección profunda como un enfoque para ser un buen propietario del producto y un ciclo de PO en las diferentes vistas

    ResponderBorrar
  3. Gracias Jorge, una visión 360 de ese gran ROL.

    ResponderBorrar