Un lanzamiento puede parecer bien encaminado en las listas de tareas de cada equipo y, aun así, ser imposible de completar. Ingeniería espera los textos aprobados; marketing, una demostración que funcione; y soporte no sabe qué comportamiento mostrará esa demostración. Cada equipo ve su propio trabajo, pero nadie ve las entregas entre equipos.
Un taller de mapeo de dependencias reúne esas entregas en un mismo tablero. El resultado es un acuerdo sobre qué necesita un equipo de otro, cuándo lo necesita y qué ocurrirá si no está disponible.
Qué debe mostrar un mapa de dependencias
Existe una dependencia cuando el trabajo no puede avanzar según lo previsto sin una aportación, decisión, capacidad o recurso procedente de otra parte. Que un diseñador necesite afirmaciones aprobadas sobre el producto es una dependencia. Que dos diseñadores asistan a la misma reunión no lo es necesariamente.
La dinámica de mapeo de dependencias de Atlassian tiene en cuenta los sistemas afectados, los riesgos, los responsables y la coordinación continuada. En un lanzamiento entre varios equipos, convierte esa visión amplia en acuerdos explícitos de entrega. Incluye tanto las aportaciones previas que necesita tu equipo como el trabajo posterior que depende de sus resultados.
Un cronograma indica cuándo están programadas las actividades. Una matriz RACI aclara la participación y la responsabilidad sobre las decisiones. El mapa de dependencias responde a otra pregunta: ¿qué debe estar disponible para que este trabajo pueda avanzar? Puede que necesites las tres herramientas, pero no deberían repetir la misma información.
Prepara un taller centrado en un resultado
Delimita el alcance con un objetivo como «lanzar la nueva experiencia de incorporación de clientes», en lugar de «mapear toda la empresa». En la parte superior del tablero, escribe la fecha prevista de lanzamiento y qué queda expresamente fuera del alcance. Si la fecha es provisional, indícalo. De lo contrario, los participantes podrían ajustar el trabajo a un compromiso que nadie ha asumido realmente.
Invita a quienes puedan confirmar las entregas: una persona de cada equipo que entrega o recibe trabajo, además de quien pueda resolver los conflictos de alcance y calendario. Pídeles que aporten restricciones reales, como colas de revisión, ausencias previstas, acceso a entornos y plazos de proveedores. Una reunión formada solo por coordinadores de proyecto puede producir un mapa atractivo de promesas sin confirmar.
Antes de la sesión, dibuja un carril horizontal por equipo y sitúa el resultado final a la derecha. Reserva una zona para preguntas pendientes, de modo que una discusión sobre una fecha no detenga todo el ejercicio.
Construye el mapa desde el resultado hacia atrás
Empieza por el equipo receptor. Pregunta: «¿Qué necesitas tener para completar este trabajo?». Continúa hacia los pasos anteriores hasta que el siguiente requisito esté bajo el control de ese equipo o fuera de los límites del taller. Trabajar hacia atrás facilita detectar requisitos previos que faltan, más que intentar recordar todas las tareas en una lluvia de ideas.
Redacta tarjetas de entregables con verbos y objetos concretos: «aprobar las afirmaciones de la guía de incorporación», «publicar el endpoint de pruebas» o «confirmar la vía de escalado». Conecta la tarjeta que aporta el entregable con la que lo necesita. Añade una etiqueta breve a cada flecha: «texto aprobado», «credenciales de prueba» o «política validada». Explica el sentido de las flechas en una pequeña leyenda y úsalo de forma coherente.
No todas las flechas significan lo mismo. Distingue los requisitos imprescindibles del trabajo que puede comenzar con una aportación provisional. Una captura preliminar puede permitir que alguien empiece a redactar una guía, aunque las capturas definitivas sean necesarias para publicarla. Mostrar esa diferencia abre opciones sin fingir que la dependencia ha desaparecido.
Ejemplo práctico: lanzar una prueba de autoservicio
Imagina un equipo de software que prepara una prueba de autoservicio. Producto define la oferta; Ingeniería implementa el acceso; Marketing publica la página de registro; y Soporte se prepara para responder a los clientes. El primer mapa muestra un bloqueo circular: Marketing quiere capturas de la prueba ya terminada, mientras que Ingeniería necesita el texto definitivo de la página para cerrar las reglas de la prueba.
El equipo separa la decisión sobre la oferta de los recursos visuales. Producto puede aprobar primero las reglas; Marketing puede preparar la página con elementos provisionales; e Ingeniería puede proporcionar un entorno de pruebas antes del lanzamiento en producción. El mapa pasa a mostrar entregas más pequeñas y verificables.
| Entrega | Equipo que entrega → equipo receptor | Condición de aceptación | Si se retrasa |
|---|---|---|---|
| Reglas de la prueba | Producto → Ingeniería y Marketing | Duración, restricciones de acceso y comportamiento al finalizar la prueba aprobados | Elevar la decisión de alcance antes de continuar la implementación |
| Entorno de pruebas | Ingeniería → Marketing y Soporte | Una cuenta de prueba identificada puede completar el registro y la cancelación | Continuar con los borradores de texto; aplazar las capturas definitivas y la formación |
| Explicación para los clientes | Marketing → Soporte | El texto publicado coincide con las reglas implementadas | Utilizar internamente el borrador revisado; no distribuir textos obsoletos |
| Vía de escalado | Soporte → responsable del lanzamiento | Contacto y cobertura acordados para el día del lanzamiento | Reducir el alcance del despliegue o aplazar la decisión de lanzamiento |
Las fechas de estas entregas deben acordarlas quienes realizan y reciben el trabajo. Dibujar un plazo más temprano no crea capacidad adicional.
Convierte las flechas importantes en acuerdos
Para cada entrega que pueda afectar al resultado, registra quién se responsabiliza de proporcionarla, quién la recibe, la fecha en que se necesita, la fecha prevista de entrega y la condición de aceptación. Mantén las dos fechas separadas. La diferencia entre ambas deja al descubierto un conflicto que una única «fecha límite» podría ocultar.
Pide al responsable receptor que explique con sus propias palabras qué considerará utilizable. «API lista» puede significar una especificación publicada para una persona y acceso estable a producción para otra. Un acuerdo más útil sería: «El endpoint de pruebas devuelve los datos de ejemplo acordados y el equipo de integración puede autenticarse».
Si las fechas entran en conflicto, considera una entrega más pequeña, una simulación, un cambio de secuencia o una reducción de alcance antes de limitarte a aumentar la presión. Registra las decisiones importantes y sus implicaciones en un registro de decisiones (en inglés). El tablero puede enlazar esa decisión sin convertirse en una segunda transcripción de la reunión.
Identifica las dependencias que requieren atención
Busca un único equipo que abastece a muchos otros, una cadena larga sin margen de tiempo, una entrega que nadie acepta o una dependencia externa cuya fecha solo se supone. Revisa también los ciclos: a veces reflejan colaboración iterativa, pero otras veces indican que ninguna de las partes sabe quién debe actuar primero.
No etiquetes todas las dependencias como críticas. Escribe la consecuencia junto a la flecha problemática: «La formación no puede empezar», «Hay que repetir la revisión de seguridad» o «El lanzamiento puede continuar sin este informe». Estas frases aportan más que un muro de tarjetas rojas. Un mapa por sí solo no calcula la ruta crítica del proyecto; para eso hacen falta duraciones y reglas de programación.
Mantén la utilidad del mapa después de la reunión
En Boardmix, organiza el ejemplo de la prueba en cuatro carriles: Producto, Ingeniería, Marketing y Soporte. Representa los entregables con formas y las entregas entre equipos con conectores etiquetados. Conecta las reglas aprobadas de la prueba con el entorno de pruebas y el texto de la página de registro. Después, conecta el entorno con las capturas y el ensayo de Soporte. Junto a cada flecha importante, añade el responsable que entrega, el que recibe y la condición de aceptación. Abre Boardmix para crear el mapa y enlaza las tareas que el equipo ya gestiona.
Revisa el mapa cuando cambie una aportación, se mueva una fecha de entrega o un receptor rechace lo recibido, no solo durante las reuniones periódicas de seguimiento. Pregunta a los receptores afectados cómo cambia su trabajo. Actualiza el plan del proyecto (en inglés) si la respuesta modifica la secuencia o el alcance. Una flecha completada debe significar que el receptor dispone de lo que necesita, no simplemente que alguien le ha enviado algo.
