Es posible que en tu recorrido profesional te encuentres en una situación en la que tienes dos equipos con puntos de vista diferentes sobre el mismo problema, y necesites ponerlos de acuerdo. No es una tarea fácil y suele requerir mucha paciencia y energía. Aquí tengo una receta para aproximarte a esta tarea
Suele ocurrir que los dos equipos están observando el mismo objeto, proyecto, situación, cliente o similar. Sin embargo cuando hablan entre si, parece que son cosas completamente diferentes: ninguno de los dos equipos reconoce nada de lo que habla el otro. Se suelen escuchar frases como: «No comprendo como no veis esto» o «Pero olvídate de eso y mira esto otro»
Esta técnica te vale para cuando formas parte de uno de los equipos o cuando eres un elemento externo.
La idea es olvidarse de todo lo que dice cada equipo e ir a lo más básico que realmente tienen que ver los dos equipos
Por ejemplo, si estamos hablando de por qué un cliente está descontento, puede que el equipo de operaciones hable de la disponibilidad de los servidores, y el equipo de desarrollo hable de la cantidad de bugs. En este caso, lo más básico que tienen que ver los dos es que el cliente tiene que estar contento, así que podemos decir una frase como esta: «Ok. Lo que está claro para todos es que el cliente está descontento y tenemos que arreglarlo. ¿Es correcto? ¿Lo veis así?». Y es necesario que todos y cada uno de los miembros de los equipos se pongan de acuerdo en ello, lo verbalicen en voz alta, que todo el mundo lo oiga.
El hecho de que todo el mundo lo diga y lo oiga de los demás, consigue que los participantes de repente recuerden que todos estamos en el mismo barco, y que tenemos que conseguir ese objetivo entre todos.
Es necesario tener consenso este momento. Si no lo tenemos, necesitaremos dar un paso más atrás, y buscar un objetivo común más básico todavía. En este caso podríamos llegar a algo tan básico como. «De acuerdo, tú piensas que el cliente está contento, pero sí que estamos de acuerdo todos en que nuestro jefe piensa que está descontento, porque ha recibido un mail y así nos lo ha dicho. ¿Es así? ¿Estamos de acuerdo en esto?»
Una vez tenemos ese mínimo consenso, tenemos que empezar a construir la visión de cada equipo, investigar, preguntar y verbalizar cómo cada equipo llega desde ese punto de vista básico hasta su preocupación principal tan diferente entre equipos.
Siguiendo con el ejemplo anterior, por ejemplo el equipo de desarrollo podría decir algo similar a «el cliente está descontento porque aparecen bugs que ya estaban corregidos» y el equipo de soporte podría decir «el cliente está descontento porque los servidores se han caído varias veces la última semana». Eventualmente podríamos llegar a una par de lineas de actuación: una en la que se revisa cómo se gestiona el código fuente, y otra en que se investigue si los bugs han causado la caída de los servidores.
