Dependency Mapping
Dependency Mapping es una sesión de equipo de una hora que enumera todos los sistemas y equipos que toca un proyecto, los riesgos que generan esas dependencias y cómo se va a gestionar cada riesgo. Después establece puntos de control periódicos con los responsables implicados. La versión descrita aquí sigue el Atlassian Team Playbook y produce una hoja de trabajo en tres partes: sistemas afectados, riesgos y mitigaciones, y ciclos de retroalimentación.
Guion de facilitación
- 1
Preparar el terreno: explicar las tres secciones de la hoja de trabajo y el objetivo de la sesión.
5 min - 2
Sistemas afectados: enumerar los sistemas aguas arriba y aguas abajo con su responsable, tipo de impacto y descripción.
20 min - 3
Lluvia de ideas de riesgos en silencio, un riesgo por nota.
5 min - 4
Compartir y discutir los riesgos; registrar para cada uno el nivel de impacto, la mitigación y el responsable.
15 min - 5
Plan de gestión: partes interesadas, ritmo de revisión y acciones para cada dependencia. Acordar quién comparte el mapa y cuándo se revisa de nuevo.
15 min
Consejos
Entender «sistema» en sentido amplio: otros equipos, proveedores, procesos de aprobación y datos compartidos cuentan tanto como el software.
Preguntar expresamente por los efectos aguas abajo, porque los equipos enumeran lo que necesitan de otros con mucha más facilidad que lo que van a romperles a otros.
Dar a cada dependencia una persona con nombre como responsable; el nombre de un equipo no es alguien a quien se pueda llamar.
Respetar los tiempos asignados y dejar el diseño detallado de las mitigaciones para el responsable, después de la sesión.
Errores comunes
Enumerar solo las dependencias aguas arriba. El equipo protege su propia entrega y pasa por alto a los equipos a los que está a punto de trastocar, que se enteran después en producción.
Nombrar como responsable a un equipo en lugar de a una persona. Cuando la dependencia se retrasa no hay nadie concreto a quien contactar y el punto de control nunca ocurre.
Calificar todos los riesgos como altos. La hoja de trabajo deja de ayudar a decidir dónde poner la atención.
Mapear sin que los responsables de las dependencias lleguen a ver el resultado. Los supuestos del equipo sobre otros equipos quedan sin verificar y a menudo son erróneos.
Tratar el mapa como un artefacto del inicio del proyecto. Las dependencias cambian a medida que el proyecto avanza, y un mapa sin revisar oculta las nuevas.
Variaciones
En remoto: completar una hoja de trabajo digital compartida mientras una persona comparte pantalla, y usar notas ocultas para la ronda de riesgos en silencio. Programas grandes: que cada línea de trabajo mapee primero sus propias dependencias y después unir las hojas y buscar los sistemas que aparecen más de una vez. Versión visual: dibujar el proyecto en el centro de una pizarra, con los sistemas aguas arriba a la izquierda y los de aguas abajo a la derecha, antes de pasar el contenido a la tabla. Documentación ampliada: añadir columnas más allá de la plantilla cuando las partes interesadas necesiten más contexto para entender una entrada.
Casos de uso
Cuándo usarlo
Empieza un proyecto que necesita trabajo, datos o aprobación de equipos ajenos al propio
Un cambio va a alterar un sistema sobre el que construyen otros equipos y todavía no se les ha avisado
Proyectos anteriores se retrasaron por el calendario de otro equipo o por una sorpresa de un proveedor
Varios equipos planifican el mismo periodo y necesitan ver dónde choca su trabajo
Un proyecto ha cambiado de alcance y sus supuestos originales sobre otros equipos quizá ya no se sostengan
Cuándo no usarlo
El proyecto queda por completo dentro de un equipo, sin sistemas externos. Un Premortem cubre mejor sus riesgos
Hace falta entender el interés y la influencia de las personas y no los vínculos técnicos o de entrega. Usar un Mapa de Interesados
La pregunta es quién hace cada tarea. Una Matriz RACI lo responde directamente
El proyecto está en una fase tan temprana que el alcance no está definido. Redactar primero un Project Poster o una carta de proyecto para que haya algo a partir de lo cual mapear dependencias
Nadie va a hacerse cargo del seguimiento. Un mapa sin puntos de control queda desactualizado en pocas semanas y da una falsa tranquilidad
Métodos relacionados
Preguntas frecuentes
¿Qué es Dependency Mapping?▾
Dependency Mapping es una sesión de equipo que identifica los sistemas y equipos de los que depende un proyecto o a los que afecta, los riesgos que generan esos vínculos y cómo se van a gestionar. En la versión del Atlassian Team Playbook lleva alrededor de una hora y produce una hoja de trabajo con tres secciones: sistemas afectados, riesgos y mitigaciones, y ciclos de retroalimentación.
¿Cuál es la diferencia entre dependencias aguas arriba y aguas abajo?▾
Las dependencias aguas arriba (upstream) son cosas que el proyecto necesita de otros, como una API, un conjunto de datos o una aprobación. Las dependencias aguas abajo (downstream) son los sistemas y equipos que se verán afectados por lo que el proyecto cambie. Un mapa útil cubre ambas direcciones.
¿Cuánto dura Dependency Mapping y quién debería asistir?▾
La dinámica está fijada en 60 minutos para 2 a 12 personas. Conviene incluir a miembros del equipo que conozcan en detalle los vínculos técnicos y organizativos, y enviar la hoja de trabajo con antelación para que la sesión empiece con ideas sobre la mesa. Los responsables de las dependencias en otros equipos revisan el resultado después.
¿En qué se diferencia Dependency Mapping de un premortem?▾
Un premortem imagina que el proyecto ha fracasado y recoge todas las causas posibles, internas o externas. Dependency Mapping mira solo los vínculos con otros sistemas y equipos, los registra de forma sistemática y añade un ritmo de revisión con sus responsables. Los dos encajan bien juntos al inicio de un proyecto.
¿Con qué frecuencia debe actualizarse el mapa de dependencias?▾
El ritmo se fija por dependencia durante la sesión: semanal para las volátiles y de alto impacto, mensual o trimestral para las estables. Además, conviene revisar el mapa completo cada vez que cambie el alcance o se sume un equipo nuevo.
Planifica tu próximo taller con IA
Workshop Weaver te ayuda a combinar métodos como Dependency Mapping en una agenda completa y cronometrada en minutos.
Probar gratisMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Atlassian Team Playbook.