Product Backlog: Conjunto de requisitos demoninados historias descritos
en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo
mismo, por retorno de inversión considerando su beneficio y coste. Los
requisitos y prioridades se revisan y ajustan durante el curso del proyecto a
intervalos regulares.
Sprint Planning: Reunión durante la cual el Product Owner presenta las
historias del backlog por orden de prioridad. El equipo determina la cantidad
de historias que puede comprometerse a completar en ese sprint, para en
una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.
Sprint: Iteración de duración prefijada durante la cual el equipo trabaja
para convertir las historias del Product Backlog a las que se ha
comprometido, en una nueva versión del software totalmente operativo.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo
las historias del sprint.
Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que
el equipo se sincroniza para trabajar de forma coordinada. Cada miembro
comenta que hizo el día anterior, que hará hoy y si hay impedimentos.
Demo y retrospectiva: Reunión que se celebra al final del sprint y en la
que el equipo presenta las historias conseguidas mediante una
demonstración del producto. Posteriormente, en la retrospectiva, el equipo
analiza qué se hizo bien, qué procesos serían mejorables y discute acerca
de cómo perfeccionarlos.
Azure board
El trabajo del PO “tradicional” se centra entonces en hacer bien el producto
relevado o demandado ayudando al equipo a entregar el mayor valor posible en cada
iteración. Sin embargo, por diversas razones las transformaciones digitales presentan
desafíos que no pueden superarse trabajando de esa manera, entre ellas:
1. Los productos a desarrollar tienen un alto contenido de discovery:
pretenden dar respuesta a problemas inéditos para los cuales no hay
soluciones efectivas conocidas.
2. Requieren descubrir y diseñar en forma colaborativa, emergente,
iterativa e incremental un producto que sea de valor para el negocio, de
alta usabilidad (UX) y técnicamente factible.
3. Existen dependencias entre diferentes áreas de la organización que se
convierten en impedimentos duros o provocan retrasos.
4. Los stakeholders impactados por el producto suelen tener amplios
desacuerdos en sus intereses y presentar contradicciones al momento
de plantear sus necesidades.
5. Existen otros roles dentro de las empresas que se solapan con el rol
de PO: Product Manager, CEO, Director, Marketing y Ventas, con visiones
del negocio no siempre holísticas o sistémicas.
6. En los niveles directivos se presentan sesgos cognitivos sobre la
dirección del producto a desarrollar, con imposición de visiones no
validadas y micro-management.
7. El contexto organizacional puede dificultar la colaboración y la co-
creación entre stakeholders claves y el equipo de desarrollo.
HABILIDADES ESTRATÉGICAS
Un PO con un enfoque más centrado en la estrategia de
negocio/producto y el valor entregado a los stakeholders que
en la táctica de desarrollo del mismo.
Un PO más consciente de que puede estar enfrentándose
a contextos complejos o de problemas desconocidos y
soluciones desconocidas, para los cuales lo más sensato es
trabajar en ciclos de aprendizaje y validación de hipótesis
haciendo experimentos basados en prototipos.
Conocimiento del ciclo de vida de productos, tipos de
modelos de negocio, sus riesgos y su impacto en desarrollo de
productos.
No sólo usar métricas de proceso sino además métricas
cuantitativas y cualitativas de negocio para medir el
impacto real y poder validar la estrategia usada.
¿Considerar que Scrum aborda adecuadamente el
proceso de Product Discovery?
Design Thinking, Lean Startup, Lean UX y Service Design son metodologías ágiles mucho
más adecuadas para el Product Discovery que Scrum. Scrum define al Product Owner como
el único guardián del Product Backlog: la única persona que sabe lo que es más valioso en
un momento dado. Scrum no explica cómo el Product Owner obtiene esta información.
¿Cómo se puede aprender sobre nuevas ideas y
requisitos?
Para responder a esta pregunta, el candidato debe describir su proceso ideal de Product
Discovery, desde la idea pasando por la hipótesis y la experimentación hasta la validación
(preferiblemente).
¿Cómo sería el proceso para manejar las ideas de
productos de los Stakeholders y de la organización
en general?
Por lo general, es una buena idea tener un proceso que involucre activamente a los
Stakeholders y a los miembros de la organización en el Product Discovery. A la gente le
gusta tener un propósito y ser parte de algo más grande que ellos. Brindar a todos en la
organización la oportunidad de contribuir, sin importar el rango, facilita el trabajo como
Product Owner. Tal proceso no requiere tecnología sofisticada: una simple hoja de cálculo
o formulario compartido es suficiente para comenzar.
Inicialmente, una plantilla para sugerir nuevos Features del producto podría consistir en
preguntas que aborden el Por qué, el Cómo, el Qué y el Para quién. Podría
abordar la naturaleza táctica o estratégica de la sugerencia, un posible periodo de tiempo o
una estimación del rendimiento esperado de la inversión.
Lo más importante es que el diseño de un proceso para manejar las ideas de productos debe
mantenerse ágil: el proceso debe comenzar con una solución simple y luego mejorarse una
vez que se hayan analizado el feedback inicial de los Stakeholders sobre el proceso.
¿En qué etapa se involucraría al Equipo Scrum en el
proceso de Product
¿Qué hace un Dueño de Producto?
1.
1. Primero, dependiendo de la organización, se encargará de
centralizar los requerimientos (pedidos) de la organización o de
un área específica de la organización. El maneja un listado de
requerimientos en donde se encuentran los pedidos realizados
desde aquellos hechos por la gerencia hasta los hechos por el
practicante (pre-aprobados por su jefatura correspondiente).
1.
1. Luego, se encarga de evaluar si los requerimientos realmente van
a generar valor al negocio, es decir, si con el tiempo existirá un
retorno de inversión monetario, si tendrá algún beneficio para la
empresa o si son compromisos u obligaciones necesarias de
hacerse por ley.
Para este punto, él se reunirá una o las veces necesarias con las
jefaturas y con los que considere correspondiente para entender
el qué, el porqué y el cuándo necesitan el requerimiento y si
realmente es necesario hacerse (evaluará la factibilidad de cada
uno).
1.
1. Siendo él quien recopila está información, el Dueño de Producto
conoce los detalles de cada requerimiento y con esto crea las
Historias de Usuario o Especificaciones de Requerimiento en
lenguaje textual, como él entiende el pedido en un Listado de
Requerimientos o Product Backlog en forma priorizada, lo que da
más valor al negocio al inicio.
1.
1. Se reúne con el equipo de Desarrollo para mostrarle la lista y que
le indiquen (el Equipo de Desarrollo) en cuanto tiempo estarán
listos los primeros requerimientos e informar a los Stakeholder los
acuerdos tomados.
1.
1. Él y solo él es quien administra y controla su listado de
requerimientos (Product Backlog).
