- OnceDev
Seis pautas para decir no a un stakeholder
Creado por: Mike Cohn Traducido por: rick@oncedev.com
Aprender a decir no a las partes interesadas es una habilidad que todo Product Owner necesita dominar.
https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder
Decir que no puede ser muy difícil. A la mayoría de nosotros nos gusta complacer a los demás. Pero cuando decimos que no, decepcionamos al solicitante.
Pero decir no a las partes interesadas es una parte importante del trabajo del Product Owner. El Product Owner tiene la tarea de optimizar el valor entregado por un producto, no de decir sí a todas las solicitudes de los clientes.
Por cada vez que el Product Owner responde "sí" a la solicitud de características de algún participante, el Product Owner tendrá que responder "no" a alguna solicitud futura del cliente. El tiempo del equipo es limitado y un "sí" hoy requerirá un "no" en algún momento posterior.
Esto significa que aprender a decir no a las partes interesadas es una habilidad que cada Product Owner necesita dominar. Quiero compartir seis pautas sobre cómo puedes hacerlo de manera cortés pero firme.
1. Sé claro con las partes interesadas: ¿Esto es un no? ¿O es un no, por ahora?
Cuando los Product Owner necesitan decirles a las partes interesadas que no están priorizando una solicitud de una característica en particular, deben tener claro qué significa su "no".
Si estás diciendo que nunca harás que el equipo trabaje en esta función, no dejes la puerta abierta para alentar a los interesados a que vuelvan a preguntar más tarde. Es una pérdida de tiempo y es frustrante para tí tener que decir continuamente que no cuando sabes que nunca vas a trabajar en esa función.
Si, por otro lado, le estás diciendo al cliente que no, por ahora, que más adelante podrías trabajar en esa función, sé claro sobre eso también. Podrías, por ejemplo, decir:
"Lo siento, no podemos trabajar en eso ahora. Créeme, desearía que pudiéramos. Pero ya nos hemos comprometido a entregar [nombra cualquier característica que sea] para agosto. Necesito mantener al equipo enfocado en eso o nos arriesgamos a perder ese compromiso. Pero si me recuerdas esto en agosto, prometo considerar hacerlo después de eso."
Nota que en esta respuesta de ejemplo, no sugerí prometer que lo harías más tarde, solo que lo considerarías.
Además, ten en cuenta que le devuelves la carga a la parte interesada o al cliente. Haz que reinicien la solicitud o que te recuerden cuándo es el momento adecuado. Haz esto para asegurarte de que la característica sigue siendo importante para ellos. Si la parte interesada no está dispuesta a hacer algo tan pequeño como recordarte de una solicitud de función, me preguntaría si la función alguna vez fue importante o urgente.
Lo más importante es que no dejes que los interesados se van pensando que deberían preguntar nuevamente en un mes si tu respuesta fue realmente que nunca lo harías.
2. Expresar aprecio y empatía por los clientes.
Cuando se presenta una solicitud de función, los Product Owner siempre deben agradecer a la parte interesada e indicar que comprenden por qué la función es importante para esa parte interesada.
Alguien se tomó el tiempo para preguntarle algo a tu equipo. Eso significa que están interesados en tu producto. Dile al cliente que aprecias que se tomen el tiempo de preguntar. Algo como esto es todo lo que necesitas decir:
Gracias. Le agradezco que haya pensado en cómo se podría mejorar nuestro producto.
Más allá de apreciar, los Product Owner también deben mostrar empatía por la situación de los interesados. Estás a punto de decir no a una solicitud que probablemente sea muy importante para ellos. La característica puede, al menos en la mente de las partes interesadas, estar obligada a cumplir los objetivos asignados por su jefe, e incluso podría afectarlos financieramente.
Antes de transmitir tu empatía, asegúrate de entender por qué la característica es importante para el cliente. Y si no entiendes, asegúrate de hacerlo antes de rechazar la solicitud de función.
Puedes expresar tu empatía por su situación con una declaración como:
"Puedo ver por qué esta característica es importante para usted para lograr [lo que sea]."
Asegúrate de ser sincero sobre esto. No creo que yo sea único en estar frustrado por la empatía falsa.
3. Ofrece solo una razón para decir no
Al decir no, es mejor que los Product Owner proporcionen una razón convincente en lugar de una lista de razones. Cuando se les ofrece una lista de razones, las personas tienden a elegir la razón más débil y argumentan en contra de ella.
Imagínate que soy tu cliente y te pido que haga que tu equipo deje de lado su trabajo actual en favor de una característica que quiero. Y tú me dices:
"Lo siento pero no puedo hacer eso. Ya hemos planeado este Sprint. Necesitaría que el equipo tenga otra reunión de planificación, y eso no les gustará. Y estoy seguro de que en lo que estamos trabajando actualmente es de mayor prioridad."
¿Qué parte de tu argumento crees que voy a atacar? ¿La necesidad de hacer otra reunión de planificación o que el trabajo actual es de mayor prioridad?
Iré por el argumento de que el equipo necesitaría hacer otra reunión de planificación y no le gustará. Podría ofrecerme hacer que la reunión sea menos desagradable al hacerlo durante el almuerzo y yo les compraré la pizza.
Incluso si todavía no te gusta mi plan, ahora he cambiado la conversación: estamos discutiendo si llevar a cabo una reunión en lugar de sobre los méritos de la función. Ese es un argumento más difícil de ganar.
Y es la base equivocada para tomar la decisión.
Sé firme y ofrece la razón más convincente para decir no. Si la parte interesada te convence exitosamente de que cambies de opinión argumentando ese punto, puede valer la pena considerar si tus razones secundarias para decir no son suficientes. Si no es así, es posible que debas decir sí a la función.
4. Transmite que cada uno tiene el mismo objetivo
Si el Product Owner y la parte interesada que solicita algo, comparten el mismo objetivo general; el Product Owner debería mencionarlo al enviar noticias no deseadas.
El Product Owner y las partes interesadas a menudo tienen diferentes objetivos. Y, sí, a veces, están en conflicto. Pero, por lo general, existe un objetivo superior a nivel del producto que se comparte y al que puedes hacer referencia.
Esto es particularmente fácil si ambos son parte de la misma compañía. En ese caso, di algo como:
· Por mucho que me gustaría que el equipo trabaje en eso para usted, debemos mantenernos enfocados en [un objetivo mayor y compartido].
· Como estoy seguro de que recuerda, a todos nos han dado el objetivo de [objetivo mayor y compartido].
Recordarle al cliente que comparte un objetivo común lo ayuda a comprender por qué debes decir que no, incluso si todavía no está totalmente de acuerdo con la respuesta.
5. Explica las consecuencias de decirle sí a las partes interesadas
Al rechazar una solicitud de un actor interesado, los Product Owner deben explicar las consecuencias de decir sí.
Esto puede ayudar al interesado a ver por qué te sientes obligado a decir que no. Podrías, por ejemplo, decir:
· Si, por el contrario, trabajamos en su función, no podremos cumplir con el plazo general.
· El equipo ya está trabajando horas extra. No puedo agregar esto a su carga de trabajo sin eliminar otra cosa que ya hemos comprometido con otra persona.
Explicar las consecuencias ayuda a las partes interesadas a comprender y, con suerte, empatizar con las razones por las que estás diciendo que no.
6. Ofrécele al cliente una alternativa
En lugar de decir directamente no a un cliente, el Product Owner puede ofrecer una alternativa.
Podrías ofrecer algo como:
· No podemos hacer todo lo que nos ha pedido, pero ¿Qué tal si hiciéramos este subconjunto?
· No puedo hacer que el equipo trabaje en esto ahora mismo, pero ¿Qué tal si empezamos en tres semanas?
Ten cuidado: solo ofrece una alternativa si lo vas a hacer en serio.
Decir que no no tiene que ser difícil
Los Product Owner a menudo temen decir que no y decepcionar a las partes interesadas o al cliente. Pero decir que no no tiene que ser tan difícil.
Descubrí que ser claro, proporcionar una razón en lugar de muchas, ser comprensivo y agradecido, nos demuestra que compartimos el mismo objetivo final. Explicando las consecuencias de decir sí y ofreciendo una alternativa hace que decir no sea mucho más fácil.
Cuando se hace bien, decir que no puede mejorar, en lugar de dañar, la relación del Product Owner con la parte interesada.
¿Qué piensas tú?
¿Cómo les dices a los interesados que no? ¿Has encontrado ciertas técnicas útiles o dañinas? Por favor comparte tus pensamientos en los comentarios abajo.