POs: ¿Quieren algunos consejos de Scrum Masters y equipos sobre cómo ser efectivo? Has venido al lugar correcto.
He trabajado y hablado con innumerables Scrum Masters y equipos de desarrollo a lo largo de los años. Me han hablado de buenos Product Owners o POs y malos POs. Saben que un buen Product Owner puede convertir un buen producto en un gran producto, y un mal Product Owner puede hundir un proyecto más rápido que cualquier mala decisión tecnológica.
Los POs exitosos generalmente no tienen mejores currículos que sus contrapartes menos efectivas. Lo que sí tienen es una habilidad especial para saber qué necesitan las personas (ya sean esas personas sus partes interesadas, clientes o equipos) y asegurarse de que lo tengan (o puedan entender por qué no). ¿Qué hay detrás de esa habilidad?
He encontrado seis cosas que los Product Owners efectivos deben brindar a las diversas personas a las que sirven: disponibilidad, visión, colaboración, altas expectativas, prioridades y flexibilidad, y narración de historias.
#1. Los buenos Product Owners están disponibles
Los equipos de Scrum a menudo se encuentran bajo una enorme presión para entregar más, más rápido. Pero eso es imposible sin el tiempo y el apoyo del PO para responder preguntas y aclarar expectativas.
Comience con la mentalidad de que, tanto como cualquier desarrollador, usted es parte del equipo. Siéntate con el equipo si estás en una oficina; si eres remoto, participa en los canales de Slack o Discord del equipo. Asistir a los scrums diarios . Ir a planificación de sprints , revisiones y retrospectivas .
Recuerde que su función en el equipo es ser la autoridad en lo que los usuarios quieren y, lo que es más importante, en lo que valoran . Demuestre que comprende el producto y cómo se utilizará, no solo escribiendo historias de usuarios , sino conociendo el producto a medida que evoluciona y se desarrolla. Eso incluye poder demostrar la nueva funcionalidad en las revisiones de sprint.
#2. Los Product Owners efectivos pintan una visión
Los mejores POs tienen una visión convincente de su producto. Esto no necesita ser una visión al estilo de Steve Jobs de una industria completamente nueva. Pero los equipos necesitan saber por qué se crea un producto.
Los POs como usted son responsables de asegurarse de que el producto tenga una visión que pueda articular. Si no puede articularlo, no empiece a construirlo.
Los miembros del equipo se motivan cuando les proporciona lo que Larson y LaFasto llaman “una meta clara y estimulante”. Según estos expertos, la falta de un objetivo claro y elevado es la razón más frecuente por la que los equipos fracasan.
El mejor ejemplo de un objetivo claro y elevado fue el llamado del presidente Kennedy para llevar a un hombre a la luna antes de fines de la década de 1960.
- Estaba claro: Todo el mundo sabría si el objetivo se había cumplido o no.
- Fue edificante: podemos imaginar fácilmente la emoción de estar en un equipo de tanta importancia histórica.
El objetivo del producto debe ser igual de claro. Por supuesto, el objetivo no tiene que ser tan elevado como poner a un hombre en la luna, pero debe ser algo que queramos lograr, ya sea porque el objetivo en sí es significativo o por el desafío que será lograrlo.
Ejemplos de objetivos de productos claros y elevados
Los siguientes son ejemplos de objetivos de productos claros y elevados:
- Gane un premio al “Producto del año” de la revista que cubre nuestra industria.
- Reduzca la duración de las llamadas en nuestros centros de llamadas en tres minutos por llamada.
- Cree un producto tan simple de usar que el tiempo de capacitación se reduzca de tres días a medio día.
La visión del producto puede (y debe) cambiar con el tiempo. Incluso Jeff Bezos de Amazon no podría haber anticipado todo en lo que se ha convertido Amazon. Si lo hubiera hecho, ciertamente no le habría dado a Amazon su eslogan inicial de “la librería más grande de la Tierra”.
#3. Los POs exitosos colaboran con todas las partes interesadas
Los POs son excelentes para comprender que los usuarios y los clientes son partes interesadas en el éxito de un producto o proyecto. También son buenos para reconocer a las partes interesadas del negocio dentro de una organización.
Sin embargo, demasiados Product Owners no reconocen la importancia de otro grupo de partes interesadas: ¡los miembros del equipo de desarrollo! El equipo tiene un interés personal en el éxito del producto y debe ser incluido junto con las partes interesadas de la empresa, el usuario y el cliente.
Eso significa considerar las opiniones de los desarrolladores sobre las prioridades.
Y significa confiar también en sus consejos sobre las características y necesidades del producto.
Cuando los miembros del equipo piden poder hacer algo, quieren que el PO confíe en que lo están haciendo por el bien del producto.
Por ejemplo, suponga que los miembros del equipo quieren limpiar un código antiguo. Usted, como PO, puede hacer preguntas como:
- ¿Qué pasaría si nunca limpiamos ese código?
- ¿Qué pasaría si lo aplazamos por dos sprints?
Es posible que las respuestas a estas preguntas lleven a la decisión de no realizar la limpieza del código. Pero es más probable que las respuestas lo ayuden a evaluar si es mejor hacer la limpieza del código ahora o en unas pocas semanas.
#4. Los mejores Product Owners establecen altas expectativas
Tener altas expectativas de su equipo. Los desarrolladores prosperan al resolver problemas desafiantes, cosas como ‘hacer que esto funcione diez veces más rápido’ o ‘hacer eso en una cuarta parte de la memoria’, cuando se les da la libertad y el tiempo para buscar soluciones creativas.
Tener el tiempo para hacer un buen trabajo es clave para el éxito. No me puedo imaginar parado sobre el hombro de Van Gogh diciendo: “Pinta más rápido. Es lo suficientemente bueno.” Sin embargo, los equipos escuchan esto casi a diario.
Habrá momentos en que los productos se envíen con imperfecciones conocidas. Habrá momentos en que un equipo necesite apresurar una función para hacer una versión “suficientemente buena” por ahora. Y, créanme, el equipo de desarrollo lo entiende.
Pero esos momentos deben equilibrarse con momentos en los que los miembros del equipo puedan hacer un trabajo de calidad.
Cuando las personas crean algo más allá de cierta velocidad , toman atajos que vuelven para atormentarlos (y a usted). Muy pocos productos valen la pena hacer a alta velocidad, y todos los productos apresurados terminan costando mucho más en las próximas versiones.
Dado que desea entregar lo más rápido posible, con alta calidad, es aconsejable programar a tiempo para aprender y mejorar. Las habilidades técnicas se vuelven obsoletas rápidamente. Se desarrollan nuevas tecnologías. Las tecnologías antiguas se mejoran, mejoran o muestran que se pueden usar de nuevas maneras.
Los miembros del equipo saben todo esto. Es por eso que quieren tiempo para mejorar sus habilidades existentes y aprender otras nuevas. Muchos miembros del equipo también disfrutan el desafío y la emoción que conlleva el aprendizaje.
Es una situación en la que todos ganan: los miembros del equipo hacen el trabajo duro de aprender algo y usted, como Product Owner, se beneficia de lo que han aprendido.
#5. ¿Qué hace a un buen Product Owner en Agile? Prioridades y Flexibilidad
Hace un par de años, estaba hablando con un colega y le comenté que una práctica en particular “sería buena para proyectos con limitaciones de tiempo”. Me desafiaron: “Muéstrame un proyecto que no tenga limitaciones de tiempo”. Me reí y dije: “Tienes razón. No hay tal cosa.”
Esencialmente, todos los proyectos tienen limitaciones de tiempo hasta cierto punto, por lo que los POs deben priorizar la funcionalidad que desean crear. Si dice: “Todo es la máxima prioridad”, entonces cuando el proyecto se agote, puede esperar un conjunto aleatorio de funcionalidades, porque el equipo no habrá sabido cuál era realmente la pieza más importante para terminar primero.
Eso no significa que las prioridades estén grabadas en piedra. Los POs pueden (y probablemente deberían) cambiar de opinión a medida que cambia el mercado y aprenden más sobre el producto que se está desarrollando.
Por ejemplo, suponga que el equipo está a la mitad de product backlog y se presenta la oportunidad de vender el producto a medio terminar a un conjunto inicialmente pequeño de clientes. Eso podría valer la pena considerarlo.
Alternativamente, suponga que un competidor feroz anuncia alguna característica nueva de gran éxito. Agregar esa característica a su propio producto puede convertirse en una prioridad más alta que gran parte del trabajo restante.
La indecisión y los cambios aleatorios son molestos, pero los cambios basados en nuevos conocimientos son una interrupción importante. De hecho, si el equipo ha establecido un proceso de desarrollo para satisfacer las altas expectativas de los POs, la capacidad del equipo para responder al cambio puede convertirse en una ventaja competitiva para la organización.
#6. Los POS son buenos narradores
Los equipos necesitan escuchar acerca de las funciones en fragmentos que sean lo suficientemente grandes para entender pero lo suficientemente pequeños para estimar. Las historias de usuario satisfacen perfectamente esta necesidad.
Pero las historias de usuario no pueden estar solas. Cada historia de usuario es un marcador de posición para una conversación: un recordatorio para que el POs y los desarrolladores hablen sobre una función. La historia del usuario puede ser la parte más visible de una historia, pero la parte más importante son las conversaciones que tienen lugar para refinar la historia y comunicar el comportamiento deseado del software.
Las historias de los usuarios deben estar vinculadas a los objetivos de los usuarios y conducir a lograr el objetivo claro y elevado del producto. Un buen dueño de producto no solo recitará una lista de historias; podrán relacionar esas historias tanto con los flujos de trabajo como con el conocimiento de cómo los usuarios interactuarán con el sistema .
Cómo ser un PO exitoso
La gran propiedad del producto es difícil. Debe dedicar tiempo a mirar hacia los clientes, usuarios, competidores, tendencias en su industria y más. Pero también debe dedicar tiempo a mirar hacia adentro del equipo, trabajar con ellos y responder sus preguntas.
Ninguna de las seis cosas que he descrito requiere habilidades especiales, capacitación o conocimiento del dominio. Cualquiera puede hacerlos. Pero la importancia de estos atributos puede ser una de las cosas más importantes que debe comprender un PO exitoso.
Esté disponible, priorice y vuelva a priorizar el trabajo, cuente historias de usuarios, articule un objetivo claro y elevado, establezca altas expectativas y colabore. Serás recompensado con resultados superiores.
Refencia:
https://www.mountaingoatsoftware.com/blog/six-things-your-team-wants-from-you-as-their-product-owner