01 / CONTEXTO
No todas las conversaciones hacen el mismo trabajo
Una reunión puede parecer larga porque hay demasiadas opiniones. A veces el problema es más sencillo: nadie ha dicho qué tipo de conversación están teniendo. Un equipo puede estar intentando entender un problema, elegir entre opciones, repartir una entrega o revisar un resultado. Cada una necesita una salida diferente.
Cuando se mezclan, ocurre algo reconocible. Alguien ofrece una idea mientras otra persona pide responsables. Una tercera discute datos que todavía faltan. Al final se acuerda «seguir hablando» o se reparte una tarea que no responde la pregunta inicial. La conversación crea movimiento, pero no coordinación.
Yo empezaría por nombrar el trabajo de esa reunión. Si queremos explorar, la salida puede ser una hipótesis y la evidencia que falta. Si queremos decidir, la salida es una elección y su motivo. Si queremos coordinar, necesitamos compromisos y dependencias. Si queremos revisar, necesitamos comparar un resultado con lo que esperábamos. Esta distinción evita pedirle a una sola conversación que haga cuatro trabajos a la vez.
02 / MECANISMO
Cerrar con una salida verificable
Scrum utiliza transparencia, inspección y adaptación para que el trabajo pueda revisarse [1]. La guía de GOV.UK añade que una decisión debe estar en el nivel de autoridad adecuado y apoyarse en evidencia proporcional [2]. No necesito usar Scrum ni copiar una reunión institucional para quedarme con una idea práctica: al cerrar, el equipo debe poder explicar qué cambia.
Para eso dejaría siete cosas visibles: la pregunta concreta; la evidencia disponible y la que falta; la decisión o hipótesis; la acción siguiente; quién responde por ella; cuándo se revisa; y qué señal haría cambiar el rumbo. Si falta autoridad, tiempo o un recurso, no lo escondería detrás de una tarea. El cierre puede ser «necesitamos que otra persona decida» o «no hay evidencia suficiente; haremos esta comprobación». Nombrar el bloqueo evita que alguien cargue con una responsabilidad que no tiene.
03 / EJEMPLO
Una oferta que todavía no conviene cambiar
Ejemplo hipotético: un equipo lleva una hora debatiendo si debe cambiar su oferta. Una persona piensa que el precio es demasiado alto; otra cree que el problema está en el mensaje; una tercera dice que no conocen bien al cliente. En lugar de votar una solución, nombran la conversación: están explorando una hipótesis sobre por qué la gente no renueva.
Reúnen la evidencia disponible. Tienen dos correos de clientes que mencionan presupuesto, pero ninguna conversación reciente. Deciden no modificar la oferta todavía. Acordan entrevistar a cinco clientes que no renovaron; una persona prepara preguntas sobre la situación anterior, alternativa actual y criterio de decisión; otra revisa los datos de uso. Se dan 48 horas y fijan una señal: compararán la explicación del precio con las dificultades de uso antes de elegir qué cambiar; ambas podrían estar influyendo.
Dos días después descubren que cuatro personas entendieron una parte distinta del servicio. La decisión cambia: antes de tocar precio, probarán una explicación nueva en dos propuestas. La primera reunión no ha resuelto todo, pero ha dejado una prueba que puede contradecir la intuición inicial. Eso es avanzar.
04 / APLICACIÓN
Evitar que la acción oculte el bloqueo
Al abrir una reunión, escribiría una frase: «Hoy necesitamos entender», «hoy necesitamos elegir», «hoy necesitamos repartir» o «hoy necesitamos revisar». Si la conversación cambia de tipo, lo diría. Al terminar, comprobaría que una persona que no estuvo pueda responder qué se decidió, por qué y qué ocurrirá después.
Si aparecen demasiados temas, no intentaría resolverlos con una lista interminable. Separaría lo que necesita otra reunión, lo que requiere una decisión de alguien con autoridad y lo que puede convertirse en una prueba pequeña. La acción individual puede desbloquear aprendizaje, pero no arregla por sí misma un objetivo incompatible, una regla injusta o falta de capacidad. La bitácora sobre sistemas ayuda a mirar esas condiciones.
05 / LÍMITES
No toda lentitud es falta de compromiso
La reflexión que recogí sobre actuar en lo pequeño nació en un contexto concreto y no prueba que el ejemplo de una persona vaya a arrastrar a un equipo. Una conversación lenta puede estar revelando cuidado necesario, desacuerdo legítimo o información insuficiente. Buscar una salida no significa imponer velocidad.
Si la reunión no puede resolver una condición, debe dejar claro quién puede hacerlo y qué información necesita. De lo contrario, el bloqueo volverá a aparecer en la siguiente conversación.
06 / APRENDIZAJES
Qué me llevaría
- Nombraría si estamos explorando, decidiendo, coordinando o revisando.
- Cerraría con pregunta, evidencia, responsable, señal y revisión.
- Escribiría el bloqueo que requiere otra autoridad o recurso.
- Usaría una prueba para aprender antes de defender una intuición.
07 / PREGUNTAS DETONANTES
Para continuar
- ¿Qué trabajo necesita hacer esta conversación?
- ¿Qué evidencia nos falta para decidir con honestidad?
- ¿Quién puede cambiar realmente lo que está bloqueado?
- ¿Qué señal hará que revisemos el acuerdo?
08 / REFERENCIAS
Cómo se ha elaborado esta bitácora
Parto de una reflexión situada que anoté tras una mentoría y la contrasto con Scrum Guides y GOV.UK. El caso de la oferta es hipotético.
Fuentes
- The Scrum Guide ↗︎
Guía oficial; transparencia, inspección y adaptación.
- Governance principles for agile service delivery ↗︎
Página completa; autoridad, evidencia y riesgo en servicios públicos.
Datos de la entrada
- Autor
- Iván Carrillo
- Revisión
- 2026-09-22
- Idioma
- Español
- Apoyo de elaboración
- Inteligencia artificial para investigación, redacción y montaje; basada en mis notas personales.