Comencemos con esa conversación tipo entre un Stakeholder y un Product Owner, esa relación yo vengo a pedir y quiero que todo esté cuanto antes. Estas conversaciones son siempre delicadas, y sobre todo dependen mucho de la relación que el Product Owner tenga con sus Stakeholders. En muchos artículos, videos, libros, se menciona que la mejor herramienta para priorizar es saber decir «no». Este monosílabo no es santo de devoción de nadie, a ninguno nos gusta que nos nieguen una petición, por lo que creo que debemos saber cómo decir no, cómo negarnos con sentido, y por ello creo que decir «no» debe ir siempre seguido de un «por qué», para terminar con un «entonces» que ofrezca una solución o alternativa.
Imaginemos el siguiente diálogo:
– Stakeholder: Se nos ha ocurrido que podríamos hacer esto la web, ¿qué te parece?
– Product Owner: ¡Ah qué buena idea!, tiene muy buena pinta
– Stakeholder: El caso es que nos gustaría que estuviera cuanto antes
– Product Owner: Bueno, primero tendríamos que ver si esto tiene más valor respecto lo que hay priorizado
– Stakeholder: Ya… pero es que lo quiero ASAP, ¿le podrías echar un ojo ahora y me dices para cuando estaría?
¿Os suena? ¿habéis tenido alguna conversación similar?.
Si queremos que nuestro Product Backlog contenga lo que realmente aporta valor a un producto, saber priorizar es fundamental, y para ello hay que descartar ideas, y ordenar adecuadamente las que son aceptadas.
Las consecuencias de contestar «si» a todo por sistema es una mentira que se paga caro. En el lado del Stakeholder generas una falsa expectativa que finalmente se convierte en una decepción y mengua las relaciones de confianza, vital entre estos roles. En el caso tuyo personal y de todo equipo, se genera un sensación de estrés e insatisfacción, porque todo equipo siente que nunca llega a lo que se espera de ellos.
Es curioso que cuando uno dice que «si» a algo no necesita una explicación, automáticamente la sensación de felicidad inunda tu interior. En el caso de escuchar un «no» la sensación inicial que se proyecta es de rechazo, por ello explicar el «por qué» es importante para presentar las razones y comprender que hay un motivo justificado.
En una conversación como hemos visto antes, se podría mostrar el Product Backlog a nuestro Stakeholder, explicarle lo que tenemos en marcha así como las prioridades a corto plazo, para que con sus propios ojos vea que quizá hay algo más importante para el producto y por tanto, para el beneficio del cliente y empresa. De esta manera, el Stakeholder y Product Owner comparten la misma visión y pueden negociar partiendo del mismo escenario.
Tras explicar por qué no es posible «echarle un ojo ahora y decir cuanto llevaría», la petición tiene dos salidas, o bien se queda fuera del Product Backlog porque no tiene valor ninguno, o bien dentro del mismo entre otras ideas y proyectos teniendo en cuenta el valor que aporta al producto. Si nos damos cuenta esto es realmente un «si» a la petición, lo que ha cambiado es que en vez de hacerlo ASAP se hará cuando llegue su momento adecuado. Tener un Product Backlog bien gestionado permite que esta conversación sea productiva, cree un consenso entre ambos roles y finalmente tomemos la decisión más acertada.
El Product Owner consigue que todos los proyectos se entreguen cuanto antes, dentro de su prioridad
Tan importante es saber decir «no», como educar a las personas a escucharlo, por lo que en nuestro diálogo, debemos diferenciar muy bien el tipo de negación que estamos usando: «no» rotundo o «no» en este momento.
Un Stakeholder siempre va a pedir más de lo que tú le puedes dar, y es tu trabajo como Product Owner facilitar una conversación que acabe en la mejor decisión para el producto, el cliente y por tanto la empresa.
Vanesa Tejada 