En muchos proyectos el problema no es técnico.
El problema es que cada persona habla un idioma distinto.
El desarrollador habla de endpoints, despliegues, dependencias y deuda técnica. Negocio habla de clientes, costes, fechas y resultados. Y en medio alguien asiente con la cabeza sin haber entendido nada.
Luego llegan los malentendidos.
Una pantalla que no era la esperada. Un proceso que no cubre la necesidad real. Una fecha que para unos era orientativa y para otros era un compromiso.
No falló el código. Falló la comunicación.
Hablar bien no es hablar complicado
A veces utilizamos tecnicismos porque son precisos. Eso está bien cuando hablamos con alguien que comparte el mismo contexto.
El problema aparece cuando convertimos esa precisión en una barrera.
Decir que “la API devuelve un 401 porque el token ha expirado” puede ser correcto. Pero quizá la persona de negocio solo necesita saber que el sistema no puede identificarse y que debemos renovar su credencial.
No estás rebajando el nivel de la conversación. Estás haciendo tu trabajo.
Si una explicación solo la entiende quien ya conoce la respuesta, no es una buena explicación.
Habla como si se lo contaras a tu abuela
No significa hablar de forma infantil. Significa eliminar todo lo que sobra.
Explica qué ocurre, por qué importa y qué decisión hay que tomar.
Antes de soltar una palabra técnica, pregúntate:
- ¿La otra persona necesita conocer este término?
- ¿Puedo explicarlo con un ejemplo real?
- ¿He dejado claro el impacto en tiempo, dinero o usuario?
- ¿Estoy explicando el problema o intentando demostrar que sé mucho?
- ¿La otra persona podría repetir lo que he dicho con sus propias palabras?
Una buena técnica es utilizar capas.
Primero das la versión sencilla. Después amplías solo si la otra persona lo necesita.
Por ejemplo: “Los pedidos no están llegando al almacén porque dos sistemas han dejado de comunicarse. Estamos revisando la credencial que utilizan para identificarse”.
Si te piden más detalle, entonces puedes hablar del endpoint, del token o del error HTTP.
Negocio también tiene que traducirse
La comunicación no es responsabilidad exclusiva del equipo técnico.
Pedir “una pantalla moderna”, “un proceso más ágil” o “algo parecido a lo que tiene la competencia” tampoco es explicar una necesidad.
Negocio debe aclarar qué problema quiere resolver, quién lo sufre y cómo sabremos que la solución funciona.
El técnico tiene que preguntar sin miedo. No para poner trabas, sino para evitar construir algo inútil.
Y negocio debe aceptar esas preguntas sin interpretarlas como resistencia.
Comprueba que os habéis entendido
No cierres una reunión con un simple “vale”.
Resume lo acordado.
Qué se va a hacer. Qué no se va a hacer. Quién toma cada decisión. Qué dependencias existen. Qué fecha se está manejando.
Una frase muy útil es: “Para asegurarme de que lo he entendido…”
Parece sencilla. Evita semanas de trabajo mal orientado.
El mejor profesional no es el que usa más palabras en inglés
Es el que consigue que perfiles muy distintos trabajen en la misma dirección.
Puede hablar con un desarrollador sin perder precisión. Puede hablar con dirección sin esconderse detrás de la tecnología. Y puede explicar un riesgo sin crear un drama innecesario.
No necesitas decir quick win cuando quieres decir mejora rápida. Ni deadline cuando quieres decir fecha límite. Ni scope cuando quieres decir alcance.
Utiliza la palabra que mejor ayude a entenderse. No la que suene más importante.
La comunicación no es un complemento del trabajo técnico.
Es lo que permite que el trabajo técnico sirva para algo.
Cuando técnicos y negocio se entienden, el proyecto avanza.
Cuando no se entienden, todo el mundo trabaja mucho y el resultado sigue siendo malo.
Habla claro. Pregunta. Resume. Confirma.
Y recuerda: si tu abuela no lo entiende, probablemente todavía no lo has explicado bien.
