Los tipos de ambigüedad en gestión de proyectos se refieren a las distintas formas en que la falta de claridad, la multiplicidad de interpretaciones o la información incompleta se manifiestan a lo largo del ciclo de vida de un proyecto. No se trata de un simple error de comunicación, sino de una condición inherente al trabajo con sistemas humanos y técnicos donde los requisitos, los objetivos, las dependencias y el entorno pueden admitir más de una lectura válida. Esta realidad afecta tanto a proyectos predictivos como adaptativos y condiciona las decisiones de planificación, ejecución y control.
En la práctica profesional, reconocer los diferentes tipos de ambigüedad permite a los directores de proyecto y a los equipos elegir estrategias de tratamiento más afinadas. Donde un principiante ve solamente incertidumbre difusa, un profesional experimentado identifica si la ambigüedad proviene de las expectativas del cliente, de la tecnología empleada, de la estructura organizacional o de la propia naturaleza innovadora del producto. Al descomponer el problema, se pasa de una sensación de desorden a un mapa de intervenciones posibles. El presente artículo define el concepto, explora sus categorías principales y analiza su lugar en los marcos de referencia actuales.
Tabla resumen: Tipos de ambigüedad
| Concepto | Resumen |
|---|---|
| Ambigüedad | La ambigüedad en la gestión de proyectos no solo deriva de información incompleta o interpretaciones múltiples, sino que constituye una condición sistémica inherente a la interacción entre sistemas humanos y técnicos, presente incluso cuando los datos parecen claros. |
| Aversión | Daniel Ellsberg demostró en las décadas de 1960 y 1970 que las personas optan sistemáticamente por riesgos conocidos frente a situaciones con información ambigua, incluso si estas últimas ofrecen mejores resultados potenciales; este sesgo cognitivo se conoce como aversión a la ambigüedad. |
| PMBOK | El Project Management Institute integra la gestión de la ambigüedad de forma transversal en las áreas de alcance, riesgos y partes interesadas, destacando que los supuestos no validados y los requisitos imprecisos constituyen fuentes persistentes de desviaciones y conflictos. |
| Métodos ágiles | Los enfoques ágiles asumen la ambigüedad como un elemento natural del desarrollo y la reducen de manera iterativa mediante historias de usuario detalladas, criterios de aceptación explícitos (definición de terminado) y ciclos cortos de retroalimentación empírica. |
| Expectativas | Cuando un patrocinador modifica su visión sobre una funcionalidad, a menudo está descubriendo sus necesidades reales al observar los avances concretos; el director de proyecto debe alinear las expectativas de forma continua y no solo al inicio, transformando esa evolución en un proceso guiado. |
| Priorización | Técnicas como MoSCoW, WSJF y el modelo Kano contribuyen a disminuir la ambigüedad al ordenar entregables según valor y urgencia, pero su verdadero impacto reside en documentar de manera transparente lo que se excluye o posterga, previniendo así la expansión descontrolada del alcance. |
| Roles | La ambigüedad en los roles se mitiga al delimitar con precisión las funciones del Scrum Master, el Product Owner y el equipo de desarrollo; sin embargo, las adopciones parciales o híbridas de Agile provocan solapamientos confusos entre jerarquías funcionales y responsabilidades de producto. |
| Gestión | Gestionar la ambigüedad no consiste en eliminarla por completo al inicio, sino en aceptarla como una variable de trabajo y disiparla progresivamente cuando se cuenta con información suficiente, evitando decisiones prematuras que solidifiquen supuestos erróneos. |
¿Qué es la ambigüedad en la gestión de proyectos?
Una definición de ambigüedad en proyectos parte de la idea de que un mismo hecho, documento o situación puede ser interpretado de maneras distintas y razonables por diferentes actores. A diferencia del riesgo, que supone conocer los posibles eventos y asignarles probabilidades, la ambigüedad aparece cuando ni siquiera se sabe qué preguntas hacer. El Project Management Institute, en el estándar PMBOK, no dedica un capítulo exclusivo a la ambigüedad, pero la aborda de forma transversal en las áreas de gestión del alcance, de los riesgos y de los interesados, al señalar que los supuestos no verificados y los requisitos mal formulados son fuentes constantes de problemas.
En el vocabulario de PRINCE2, la ambigüedad se gestiona mediante el principio de “gestionar por excepción” y la definición de tolerancias. Cuando un aspecto del proyecto queda deliberadamente abierto, se establecen límites dentro de los cuales el equipo puede decidir sin escalar; más allá de esos límites, la ambigüedad debe resolverse con la dirección del proyecto. Los métodos ágiles, por su parte, no intentan eliminar la ambigüedad de antemano, sino que la aceptan como parte del proceso, con mecanismos como las historias de usuario, las definiciones de hecho y la retroalimentación frecuente para ir reduciéndola iterativamente. De hecho, en Scrum se habla de “refinamiento del backlog”, que es en esencia un proceso continuo de clarificación.
Una manera sencilla de entenderlo es imaginar que se encarga la construcción de una casa. Si el cliente dice “quiero una cocina moderna y luminosa”, hay ambigüedad: “moderna” puede significar minimalista para el arquitecto y tecnológica para el cliente. Mientras que una incertidumbre sería “no sabemos si lloverá durante la obra”, la ambigüedad está en la definición misma de lo que se espera. Gestionarla no consiste en eliminarla por completo al inicio —algo imposible en proyectos complejos—, sino en saber convivir con ella y reducirla progresivamente en el momento adecuado.
Claves para entender la ambigüedad
- Definición de ambigüedad
- La ambigüedad aparece en los proyectos cuando un mismo hecho, documento o situación permite interpretaciones razonables y divergentes entre los actores involucrados.
- Diferencia frente al riesgo
- A diferencia del riesgo, que parte de conocer los posibles eventos y estimar su probabilidad, la ambigüedad surge cuando el equipo desconoce incluso las preguntas que debe plantear.
- Tratamiento en los estándares
- El PMBOK aborda la ambigüedad de manera transversal en las áreas de alcance, riesgos e interesados, mientras que PRINCE2 la gestiona mediante la gestión por excepción y los márgenes de tolerancia.
- Enfoque ágil e iterativo
- Los enfoques ágiles integran la ambigüedad como parte inherente del desarrollo y la atenúan gradualmente mediante historias de usuario bien definidas, definiciones de hecho explícitas y retroalimentación iterativa.
Orígenes y contexto interdisciplinario
El concepto de ambigüedad tiene raíces en la filosofía del lenguaje, la psicología cognitiva y la teoría de la decisión. En los años sesenta y setenta, académicos como Daniel Ellsberg demostraron que las personas prefieren situaciones de riesgo conocido antes que aquellas donde la información es ambigua, un fenómeno conocido como “aversión a la ambigüedad”. En el ámbito militar, la niebla de la guerra descrita por Clausewitz es una forma de ambigüedad situacional. La ingeniería de sistemas también contribuyó al trasladar la noción de que los problemas perversos o wicked problems contienen ambigüedad en los objetivos y en las soluciones posibles.
En la gestión de proyectos, estas influencias confluyen para reconocer que la ambigüedad en la gestión de proyectos no es un defecto del plan, sino una característica del entorno. Los proyectos con alta innovación o con múltiples partes interesadas heredan la ambigüedad de los contextos sociales y técnicos en los que nacen. Por eso, las técnicas para tratarla no son exclusivas de una disciplina: provienen de la facilitación grupal, el pensamiento sistémico, el diseño de experimentos y la inteligencia emocional. Saber leer la ambigüedad es también saber leer la organización que rodea al proyecto.
Aterrizando esto al día a día de un equipo, implica que cuando un patrocinador cambia de opinión sobre una funcionalidad, no siempre hay mala fe ni falta de visión; muchas veces el propio patrocinador está descubriendo qué quiere a medida que ve avances. La ambigüedad no es un enemigo a batir, sino un dato sobre la madurez del entendimiento colectivo.
Tipos de ambigüedad en proyectos
Los tipos de ambigüedad en gestión de proyectos se suelen clasificar según su origen, aunque en la realidad se solapan constantemente. Distinguirlos permite al director de proyecto focalizar las técnicas de clarificación y comunicación de manera más precisa. A continuación se detallan las categorías más relevantes que aparecen en la literatura y en la experiencia profesional.
Ambigüedad de requisitos
Es la forma más extendida y la que todo analista de negocio conoce. Surge cuando las necesidades del cliente o del usuario no están expresadas con suficiente precisión, contienen contradicciones o simplemente no han sido exploradas. En lugar de especificaciones cerradas, se reciben peticiones genéricas del tipo “el sistema debe ser fácil de usar”. Esta ambigüedad se combate con prototipado, historias de usuario progresivamente refinadas, design thinking y revisiones frecuentes. La clave está en no precipitarse a documentar requisitos detallados antes de que exista un entendimiento compartido, porque se genera una falsa sensación de certeza.
Ambigüedad técnica
Aparece cuando la solución constructiva o tecnológica no está definida. El equipo sabe qué quiere lograr, pero no cómo hacerlo. Esto es típico en proyectos de investigación y desarrollo, adopción de nuevas plataformas o integración de sistemas heredados. La ambigüedad técnica se reduce mediante pruebas de concepto, spikes técnicos, prototipos arquitectónicos y experimentos controlados. En contextos predictivos, se intenta resolverla durante la planificación; en entornos adaptativos, se reserva capacidad en cada iteración para ir explorando las zonas grises.
Ambigüedad de alcance
Se refiere a la indeterminación sobre los límites del proyecto: qué queda dentro y qué fuera. Puede originarse por una visión estratégica poco madura, contratos ambiguos o expectativas divergentes entre las áreas de negocio. A menudo, la línea entre “imprescindible” y “deseable” se difumina. Las técnicas de priorización (MoSCoW, WSJF, Kano) ayudan a reducir esta ambigüedad, pero el director de proyecto debe gestionar activamente las expectativas de los interesados y documentar de forma transparente aquello que conscientemente se deja fuera, para evitar la expansión incontrolada del alcance.
Ambigüedad estratégica
Es propia de programas y portafolios, donde los objetivos de alto nivel pueden ser deliberadamente ambiguos porque responden a cambios políticos, regulatorios o de mercado. Un proyecto que herede una meta como “mejorar la experiencia del cliente” sin métricas concretas vive en la ambigüedad estratégica. El PMBOK, en su guía de gestión de programas, insiste en la alineación continua con la estrategia organizacional precisamente para ir acotando este tipo de ambigüedad a medida que el programa avanza. No se trata de un fallo, sino de una característica de la capa de decisión donde la certidumbre es imposible al inicio.
Ambigüedad organizacional
Surge cuando no están claros los roles, las responsabilidades o la autoridad para tomar decisiones. En estructuras matriciales fuertes, o cuando varios patrocinadores tienen visiones contrapuestas, el equipo recibe señales contradictorias. Esta ambigüedad afecta directamente a la velocidad y a la moral. La remediación pasa por cartas de proyecto que definan con nitidez la gobernanza, matrices RACI bien construidas y una comunicación ascendente que exponga los conflictos latentes.
Ambigüedad de rol y de equipo
Se produce cuando las personas dentro del proyecto no saben exactamente qué se espera de ellas, bien por descripciones de puesto genéricas o por la dinámica de equipos auto-organizados que aún no han madurado. En la práctica ágil, la ambigüedad de roles se mitiga con la clarificación de las responsabilidades del Scrum Master, Product Owner y Developers, pero en organizaciones que adoptan Agile de forma parcial, los equipos a menudo heredan una mezcla confusa de mandos funcionales y responsabilidades de producto.
Ambigüedad legal y contractual
Los contratos, las declaraciones de trabajo y los acuerdos de nivel de servicio pueden contener cláusulas interpretables. Una frase como “el proveedor realizará las pruebas necesarias para garantizar la calidad” es ambigua si no se especifica qué estándares se aplican y quién define “necesarias”. Este tipo de ambigüedad constituye un riesgo legal y suele requerir la participación de asesores jurídicos y expertos en adquisiciones para acotarla antes de la firma. Una vez iniciado el proyecto, el director debe gestionar las expectativas contractuales con sumo cuidado para evitar disputas que paralicen la ejecución.
Todas estas categorías comparten un rasgo: no pueden resolverse con más análisis del mismo tipo que las generó. La ambigüedad de requisitos no se arregla con una especificación de cien páginas si el problema está en la divergencia de visiones entre los usuarios; hace falta conversación. Y la ambigüedad técnica no desaparece con más planificación si lo que falta es conocimiento empírico.
Ideas clave sobre ambigüedad
- Clasificación según su origen
- Distinguir las ambigüedades según su origen, aun cuando tienden a solaparse, orienta al director de proyecto en la selección de técnicas de clarificación y comunicación específicas para cada situación.
- Ambigüedad de necesidades
- Esta ambigüedad surge cuando las necesidades del cliente se expresan de forma vaga o contradictoria. Se mitiga eficazmente con prototipado iterativo, refinamiento de historias de usuario y design thinking, antes de formalizar la documentación de requisitos.
- Ambigüedad técnica
- Se mitiga mediante pruebas de concepto, prototipos arquitectónicos y experimentos controlados. En proyectos predictivos, se resuelve durante la fase de planificación; en entornos adaptativos, se explora y reduce progresivamente a lo largo de las iteraciones.
- Ambigüedad de alcance
- Las técnicas de priorización como MoSCoW, WSJF o Kano ayudan a gestionarla, pero exigen documentar explícitamente lo que queda fuera del alcance y moderar las expectativas para prevenir la expansión descontrolada del alcance.
La ambigüedad en los marcos de gestión de proyectos
Los principales marcos de trabajo abordan la ambigüedad en el PMBOK, PRINCE2 y las metodologías ágiles con enfoques complementarios. No existe un único proceso que la gestione; cada marco distribuye la responsabilidad entre varias áreas de conocimiento y fases del ciclo de vida.
Perspectiva del PMBOK
La Guía del PMBOK (7.ª edición) se aleja de los procesos prescriptivos y adopta un modelo basado en principios y dominios de desempeño. El dominio de Incertidumbre trata explícitamente la ambigüedad como una de sus facetas, junto con la volatilidad y la complejidad. El director de proyecto debe planificar la gestión del alcance identificando supuestos y restricciones, y mantener un registro de riesgos que incluya riesgos de ambigüedad. Además, el proceso de identificar a los interesados y analizar sus expectativas es una herramienta para revelar áreas donde diferentes lecturas pueden coexistir. Los documentos como el acta de constitución del proyecto y el enunciado del alcance establecen el punto de partida, pero el PMBOK reconoce que la elaboración progresiva —ir detallando sobre la marcha— es la respuesta natural ante la ambigüedad.
Enfoque de PRINCE2
PRINCE2, con su énfasis en la justificación comercial continua y la gestión por fases, maneja la ambigüedad manteniendo períodos de planificación cortos. Al final de cada fase, el equipo revisa el plan de la siguiente y puede incorporar la información que ha ido emergiendo. Las tolerancias a nivel de fase, etapa y proyecto actúan como amortiguadores que evitan que pequeñas desviaciones por malentendidos se conviertan en crisis. El rol del Project Board juega un papel crucial, ya que es el foro donde se exponen las interpretaciones divergentes de la dirección, el usuario y el proveedor, forzando la resolución de la ambigüedad de alto nivel.
La ambigüedad en los métodos ágiles
En lugar de considerarla una anomalía, los métodos ágiles incorporan la ambigüedad como un elemento central de su filosofía. La planificación adaptativa, las entregas frecuentes y los ciclos de inspección y adapt
Perspectiva BVOP
BVOPM, como metodología orientada al valor, aborda la ambigüedad principalmente desde la gestión de riesgos del producto y el tratamiento de los cambios de alcance. Propone separar la gestión de riesgos del proyecto de la gestión de riesgos del producto, utilizando unidades cuantificadas de “tamaño de pérdida” y filtros dinámicos para priorizar aquellos riesgos donde la ambigüedad puede generar mayor impacto. Además, su escala de cinco niveles de alcance —de Definitivo a Imposible— reconoce explícitamente que no todos los elementos del alcance tienen el mismo grado de certeza, categorizando la ambigüedad como parte normal del desarrollo. Los cambios de alcance no se interpretan como fallos de planificación, sino como retroalimentación del usuario, lo que reduce la presión por fingir certidumbre en las etapas tempranas.
Aplicación práctica y uso en proyectos reales
En el día a día, el director de proyecto maneja la ambigüedad sin siempre etiquetarla como tal. Gestionar la ambigüedad en proyectos se traduce en acciones concretas como organizar talleres de requisitos con prototipos de baja fidelidad, mantener listas de supuestos que se revisan semanalmente o reservar tiempo en cada sprint para spikes de investigación. Muchas veces, la diferencia entre un proyecto atascado y uno que avanza es la habilidad del líder para formular preguntas que expongan las interpretaciones ocultas, en lugar de limitarse a documentar la ambigüedad como un riesgo genérico.
Un caso común es el proyecto de transformación digital donde el patrocinador declara que “hay que modernizar la plataforma”, pero los equipos de negocio tienen visiones incompatibles sobre el resultado final. En lugar de redactar un documento de alcance prematuro, el director de proyecto puede impulsar un inception con todos los interesados, generar un lienzo de producto y acordar métricas de éxito medibles, aunque sean provisionales. A medida que el proyecto construye incrementos, la ambigüedad va dejando paso a decisiones basadas en evidencia. No se trata de improvisar, sino de invertir en claridad justo a tiempo: suficiente para la siguiente decisión, sin paralizar el trabajo esperando certidumbre total.
En programas, los directores de programa utilizan hojas de ruta con distintos horizontes: alta precisión para los próximos tres meses, progresivamente menos detalle hacia los siguientes trimestres. Esta práctica, alineada con la elaboración progresiva del PMBOK, es una respuesta directa a la ambigüedad estratégica y de alcance. La comunicación honesta sobre lo que no se sabe es tan importante como la comunicación sobre los hitos confirmados.
Resumen práctico: gestión de la ambigüedad
- Técnicas concretas contra la ambigüedad
- El director de proyecto materializa la gestión de la ambigüedad en acciones tangibles: talleres de requisitos con prototipos de baja fidelidad, listas de supuestos revisadas semanalmente y spikes de investigación integrados en cada sprint.
- Preguntas que exponen interpretaciones
- Formular preguntas que saquen a la luz interpretaciones ocultas diferencia un proyecto que avanza de uno que se estanca, mucho más que registrar la ambigüedad como un riesgo genérico.
- Inception para alinear interesados
- Ante visiones vagas del patrocinador, como «modernizar la plataforma», un inception con lienzo de producto y métricas de éxito provisionales alinea a todos los implicados antes de redactar el alcance.
- Claridad justo a tiempo
- La elaboración progresiva apoyada en hojas de ruta con precisión decreciente, combinada con la honestidad sobre lo que aún se desconoce, permite avanzar sin exigir una certidumbre total.
Desafíos, trampas y conceptos erróneos comunes
Uno de los errores más frecuentes es equiparar ambigüedad con incertidumbre y aplicar técnicas de gestión de riesgos estándar sin adaptar el enfoque. Mientras que la incertidumbre puede modelarse con distribuciones de probabilidad, la ambigüedad requiere conversación, exploración y alineamiento. Otro error habitual es intentar resolver toda ambigüedad en la fase de planificación, produciendo documentos mastodónticos que nadie lee y que, además, generan una ilusión de control. La práctica sensata consiste en identificar los puntos de mayor impacto y posponer aquellos detalles que el proyecto puede ir afinando más adelante sin consecuencias graves.
También se subestima la ambigüedad organizacional. Los directores de proyecto novatos suelen asumir que, porque existe un organigrama, las responsabilidades están claras. En la realidad, las decisiones se toman en pasillos y las líneas de autoridad se solapan. Ignorar esta ambigüedad conduce a bloqueos constantes. Otra trampa es la cultura de “el cliente siempre sabe lo que quiere”. Salvo en proyectos muy repetitivos, el cliente tiene una dirección pero no un mapa detallado; pretender lo contrario fuerza definiciones prematuras que generan rechupetes de alcance más adelante.
Una confusión adicional proviene de considerar la ambigüedad como una debilidad que hay que ocultar ante la alta dirección. Los profesionales maduros entienden que hacer explícitas las zonas grises, junto con un plan para ir acotándolas, demuestra control y no incompetencia. Al fin y al cabo, los patrocinadores prefieren saber que hay un mapa de exploración antes que recibir sorpresas en la fase de entrega.
Relaciones con otros conceptos de gestión de proyectos
La ambigüedad se relaciona estrechamente con la complejidad, la volatilidad y el riesgo, pero no son sinónimos. Un proyecto puede ser muy complejo —muchas piezas interdependientes— sin apenas ambigüedad si las especificaciones son precisas; una planta de ingeniería ya diseñada al detalle es compleja pero clara. A la inversa, un proyecto de desarrollo de una app sencilla puede tener una complejidad técnica baja, pero una ambigüedad de requisitos altísima si los usuarios no articulan bien sus necesidades. Ambigüedad y gestión de riesgos se solapan en los llamados riesgos de ambigüedad, donde el evento incierto es precisamente que una interpretación errónea cause un fallo. En el PMBOK, la identificación de riesgos incluye el análisis de supuestos, una herramienta que aborda directamente la ambigüedad al cuestionar qué creencias no verificadas sostienen el plan.
Asimismo, la ambigüedad está vinculada con la gestión de los interesados y con la comunicación. Una matriz de comunicaciones que no contemple los distintos lenguajes de negocio, técnico y operativo es caldo de cultivo para malentendidos. La técnica de elaboración progresiva del alcance y la planificación gradual son, en esencia, respuestas a la ambigüedad. Y en la gestión del cronograma, la creación de reservas de contingencia para trabajo impreciso —conocido como buffer en la Cadena Crítica— es una manera de absorber el impacto de aquello que no se pudo detallar.
En entornos ágiles, los conceptos de “definición de preparado” y “definición de terminado” funcionan como vallas que limitan la ambigüedad: un ítem del backlog no entra en un sprint si su nivel de ambigüedad supera un umbral, y no se considera terminado hasta que se cumplen criterios de aceptación que eliminan la ambigüedad interpretativa sobre el resultado.
Claves de la ambigüedad en proyectos
- Ambigüedad y complejidad no se equivalen
- Un proyecto de alta complejidad puede resultar nítido si sus especificaciones son precisas, mientras que una aplicación sencilla suele padecer una ambigüedad extrema en los requisitos.
- Riesgos de ambigüedad y análisis de supuestos
- La ambigüedad se funde con la gestión de riesgos cuando el suceso incierto es una interpretación errónea que desencadena un fallo, y el análisis de supuestos del PMBOK cuestiona las premisas no verificadas que sostienen el plan.
- Comunicación e interesados como fuente
- Si la matriz de comunicaciones no integra los lenguajes de negocio, técnico y operativo, se genera un caldo de cultivo para interpretaciones divergentes que alimentan la ambigüedad.
- Planificación gradual y reservas de contingencia
- Tanto la elaboración progresiva del alcance como la planificación gradual constituyen respuestas deliberadas frente a la ambigüedad, y los amortiguadores de la Cadena Crítica absorben el impacto del trabajo que no pudo detallarse por la incertidumbre.
- Definiciones de preparado y terminado en ágil
- En entornos ágiles, la definición de preparado impide que un elemento ambiguo ingrese al sprint, y la definición de terminado impone criterios de aceptación que despejan toda ambigüedad sobre el resultado alcanzado.
Evolución y pensamiento actual
Durante décadas, la gestión de proyectos trató la ambigüedad como un defecto del proceso de levantamiento de información. La evolución del concepto de ambigüedad refleja un cambio de paradigma: de la ingeniería determinista, que busca especificaciones completas desde el primer día, a enfoques que reconocen que en entornos complejos el conocimiento emerge. El modelo Cynefin, ampliamente usado en agilismo, sitúa los problemas ambiguos en el dominio complejo, donde la respuesta adecuada es sondear, percibir y responder, no analizar en exceso. Autores como Peter Taylor y Nader Rad han popularizado la idea de que el director de proyecto moderno necesita tolerancia a la ambigüedad como competencia central, junto con la comunicación empática y el pensamiento sistémico.
Actualmente se debate si los marcos predictivos son incompatibles con la gestión de la ambigüedad. El consenso emergente es que no es cuestión del marco, sino de cómo se aplica. Un proyecto en construcción puede predecirse con alta certidumbre porque la ambigüedad del diseño se resuelve en la fase de ingeniería, antes de mover tierras. En cambio, un proyecto de software o de cambio cultural necesita ciclos cortos de retroalimentación. Los enfoques híbridos intentan combinar ambas velocidades: planificación predictiva para lo conocido, iteración para lo ambiguo.
La tendencia en la formación de directores de proyecto es incluir ejercicios de clarificación, manejo de conversaciones difíciles y diseño de experimentos. Se entiende que, más que una técnica, gestionar la ambigüedad es una actitud: la capacidad de mantener el rumbo sin un mapa completo, confiando en que la brújula de la retroalimentación y el diálogo irá revelando el paisaje.
