Cuando dos equipos se esperan mutuamente: una historia de dependencias
Una agencia pública de tamaño medio implantaba un nuevo portal de permisos. Dos grupos llevaban el trabajo: un equipo interno de aplicaciones que construía el front-end y un equipo de datos que levantaba la base de datos de expedientes por detrás. Sobre el papel el plan era impecable. En la práctica, los dos equipos trabajaban en plantas distintas, en husos horarios distintos tras el cambio a remoto y con dos gestores de proyecto diferentes. Los nombres y las fechas se han cambiado, pero la forma de esto le resultará familiar.
Cómo se frenó
El equipo de aplicaciones suponía que el de datos entregaría una API terminada para finales de marzo. El equipo de datos suponía que el de aplicaciones enviaría primero los requisitos de campos definitivos. Ninguna de esas suposiciones estaba escrita en un lugar que ambos equipos pudieran ver. Durante tres semanas, cada parte se creía bloqueada por la otra y trabajaba en silencio en tareas de menor prioridad. La primera vez que alguien dijo la palabra «bloqueado» en voz alta fue en un comité de dirección, cuando el patrocinador preguntó por qué se había retrasado la demo. Para entonces, dos sprints se habían perdido.
Aquí no hubo incompetencia. Ambos equipos estaban ocupados y eran capaces. El fallo fue que la dependencia entre ellos vivía solo en la cabeza de las personas, y en un entorno remoto e híbrido, la conversación de pasillo que solía atrapar esto nunca ocurrió.
Qué la habría sacado a la luz antes
Una dependencia es una promesa: un equipo se compromete a entregar algo que otro necesita, en una fecha y en una forma definida. La solución es hacer esa promesa explícita, visible y con dueño. Unos pocos hábitos hacen casi todo el trabajo:
Nombrar la dependencia como un compromiso de dos partes. Escribe quién necesita qué, de quién, en qué forma y para cuándo, y haz que ambas partes lo confirmen, no solo el equipo receptor.
Darle un único responsable. Cada dependencia entre equipos necesita una persona nombrada que responda por la entrega, del lado proveedor. «El equipo de datos» no es una persona.
Ponerla en una sola vista compartida. Un simple registro de dependencias o un tablero compartido vale más que dos gestores separados. Si una dependencia no es visible para ambos equipos en el mismo lugar, en realidad no existe.
Revisarla con una cadencia corta. Una sincronización semanal de 15 minutos entre los dos responsables, centrada solo en las entregas próximas y las fechas cambiadas, detecta el deslizamiento cuando aún hay tiempo de reaccionar.
La lección más profunda
Las dependencias entre equipos son donde los proyectos mueren en silencio, porque ningún equipo es dueño del hueco entre ellos. El riesgo es mayor justo cuando la gente está dispersa y la coordinación informal se ha adelgazado. No necesitas una gobernanza pesada para gestionar esto: necesitas una lista compartida y honesta de quién espera qué de quién, revisada con la frecuencia suficiente para que una fecha que se desliza se note en días, no en la demo.
Haz que «estoy bloqueado» sea algo normal de decir pronto, no una confesión de fracaso.
Sigue las fechas a las que se compromete el equipo proveedor, no las que el equipo receptor espera.
Cuando una fecha se mueva, síguela hacia adelante: ¿el trabajo de quién se acaba de retrasar por ello?
Si tu entrega se atasca una y otra vez en las costuras entre equipos, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a hacer visibles esas dependencias y mantenerlas en movimiento.