luismori.

Engineering Workflow

Decision Making Engineering Strategy Product Management

Cómo resolver problemas ambiguos: explorar alternativas, identificar incógnitas y tomar decisiones

Una guía práctica para ingenieros y PMs que enfrentan problemas complejos, con muchas respuestas posibles, riesgos ocultos y sin un camino claramente mejor.

17 min de lectura

Algunos problemas no llegan como tickets bien definidos.

Llegan como una niebla:

  • el resultado de negocio importa, pero el camino no está claro
  • ingeniería ve varias arquitecturas posibles
  • producto ve varios segmentos de clientes o flujos de trabajo
  • los líderes quieren una respuesta contundente antes de que el equipo tenga suficiente evidencia
  • todos tienen opiniones, pero nadie puede demostrar qué opción funcionará

Este artículo trata sobre esas situaciones.

Al June 22, 2026, revisé fuentes sobre Cynefin, Wardley Mapping, mapeo de supuestos, spikes, premortems, ciclos OODA, decisiones de puerta de una vía frente a puertas de dos vías y Architecture Decision Records. Cada práctica individual está respaldada por fuentes. El modelo operativo combinado que presento a continuación es mi síntesis para equipos de producto e ingeniería que necesitan avanzar cuando el problema tiene muchas soluciones posibles o cuando el equipo todavía no sabe cómo es realmente el espacio de soluciones.

TL;DR

  • Los problemas ambiguos no se resuelven fingiendo que son claros. Se resuelven clasificando la incertidumbre y eligiendo el ciclo de aprendizaje adecuado.
  • Empieza por preguntar: ¿Es claro, complicado, complejo o caótico? Los problemas claros necesitan guías de acción. Los complicados necesitan análisis de expertos. Los complejos necesitan experimentos. Los caóticos necesitan medidas inmediatas para estabilizar la situación.
  • Registra las incógnitas como supuestos, no como preocupaciones vagas. Pregunta: ¿Qué debe ser cierto para que este plan funcione?
  • Explora alternativas de forma deliberada, pero no indefinidamente. Usa pruebas de bajo costo, spikes, prototipos, entrevistas y premortems para reducir primero la incertidumbre más costosa.
  • Trata las decisiones reversibles de manera distinta a las irreversibles. Avanza rápido con las puertas de dos vías. Tómate más tiempo con las puertas de una vía.
  • El ciclo para avanzar es: definir el problema -> mapear incógnitas -> generar opciones -> probar riesgos -> decidir -> registrar -> revisar.
  • Un buen registro de decisión debe incluir el contexto, las opciones consideradas, el nivel de confianza, las consecuencias y la señal que llevaría a revisarla.

Qué aprenderás aquí

  • Cómo reconocer cuándo un problema es ambiguo y no solo complicado
  • Cómo pueden los ingenieros y PMs registrar incógnitas sin convertir la planificación en teatro
  • Cómo elegir entre investigación, spikes, prototipos, experimentos y ejecución directa
  • Cómo evitar la parálisis por análisis cuando hay demasiadas alternativas
  • Cómo documentar decisiones para que los equipos futuros entiendan los compromisos
  • Cómo usar un registro pequeño de supuestos en código o documentos para mantener visible la incertidumbre

El problema central

La mayoría de los equipos se sienten cómodos con la incertidumbre de ejecución:

We know what to build.
We are not sure how long it will take.

Los problemas ambiguos son diferentes:

We are not fully sure what problem we are solving.
We are not fully sure which constraints matter.
We are not fully sure which solution family is best.
We are not fully sure what we do not know yet.

Esa última línea es la peligrosa.

Las incógnitas conocidas son manejables. Puedes anotarlas, asignar responsables y ponerlas a prueba. Las incógnitas desconocidas son diferentes. Solo aparecen cuando empiezas a interactuar con la realidad: una entrevista con un usuario, un prototipo, una prueba de integración, un ensayo de migración, un incidente en producción o una llamada de ventas fallida.

El objetivo no es eliminar la incertidumbre. El objetivo es convertir la incertidumbre invisible en trabajo de aprendizaje visible.

Primero, clasifica la situación

Cynefin es útil aquí porque nos recuerda que no todos los problemas necesitan el mismo proceso. The Cynefin Company describe el framework como una forma de ayudar a los líderes a tomar decisiones en contexto, distinguiendo entre distintos dominios y adaptando las acciones a la realidad.

Para el trabajo práctico de software, me gusta esta versión simplificada:

Clear
  Known problem, known solution.
  Use a checklist or existing playbook.

Complicated
  Several valid answers may exist.
  Bring experts together, compare trade-offs, map dependencies.

Complex
  Patterns are still emerging.
  Run safe-to-fail experiments and learn by probing.

Chaotic
  No stable pattern and immediate risk.
  Act to contain damage first, then analyze.

Esta clasificación importa porque los equipos suelen actuar de forma equivocada:

  • Investigan demasiado el trabajo claro y pierden velocidad.
  • Tratan el trabajo complicado como si la opinión de una sola persona fuera suficiente.
  • Tratan el trabajo complejo como si una reunión de planificación pudiera revelar la respuesta.
  • Intentan mapear el caos mientras el sistema está en llamas.

En caso de duda, usa este criterio de decisión:

Is the system actively burning?
  yes -> stabilize first
  no
    |
    v
Is there a proven playbook?
  yes -> execute the playbook
  no
    |
    v
Can experts reason to a good answer?
  yes -> analyze alternatives
  no
    |
    v
Run experiments to discover the shape of the problem

Mapea las incógnitas antes de evaluar las soluciones

Cuando un equipo salta directamente a las soluciones, cada opción suena mejor en boca de quien más la defiende.

Antes de comparar alternativas, anota qué tendría que ser cierto para que cada opción tenga éxito.

Por ejemplo, imagina que un equipo debe elegir cómo agregar logs de auditoría para clientes empresariales:

  • Opción A: escribir directamente en Postgres
  • Opción B: publicar eventos en Kafka
  • Opción C: usar un pipeline de eventos administrado
  • Opción D: empezar con Postgres y extraerlo más adelante

En lugar de debatir preferencias, pregunta:

What must be true for Option A to work?
  - audit volume stays within Postgres write capacity
  - reporting queries do not harm transactional paths
  - retention requirements remain simple

What must be true for Option B to work?
  - the team can operate Kafka safely
  - downstream consumers can tolerate eventual consistency
  - debugging event delivery will be manageable

What must be true for Option C to work?
  - vendor retention and compliance controls match customer needs
  - pricing is acceptable at projected volume
  - export and migration paths are credible

What must be true for Option D to work?
  - future extraction boundaries are designed now
  - product can accept a smaller first release
  - the migration path is not blocked by schema choices

Ahora la conversación cambia. Ya no preguntas: «¿Qué opción nos gusta?». Preguntas: «¿Qué supuestos son los más importantes y los menos comprobados?».

Esa es la esencia del mapeo de supuestos. El Design Sprint Kit de Google presenta los supuestos que requieren un salto de fe como supuestos importantes que, si resultan falsos, pueden hacer fracasar una iniciativa. Lo útil es ubicar los supuestos según su importancia y la evidencia disponible, y luego enfocar los experimentos próximos en el cuadrante de lo importante y desconocido.

                    high importance
                          ^
                          |
     important + known    |    important + unknown
     build into plan      |    test first
                          |
low evidence <------------+------------> high evidence
                          |
     unimportant +        |    unimportant + known
     unknown              |    ignore for now
     park for later       |
                          v
                    low importance

El mapa es útil, pero la conversación lo es aún más. Si producto cree que un supuesto es conocido e ingeniería cree que es desconocido, resolver ese desacuerdo es parte del trabajo.

Explora alternativas sin perderte

Explorar alternativas solo aporta valor cuando cambia la decisión.

Un ciclo práctico de exploración se ve así:

1. Frame the decision
2. Generate credible options
3. List assumptions behind each option
4. Rank assumptions by cost-if-wrong and evidence
5. Test the riskiest assumptions
6. Make the smallest responsible decision
7. Record what would change your mind

Ese ciclo te protege de dos trampas comunes.

La primera es la convergencia prematura. El equipo elige la primera solución plausible porque parece una forma decidida de actuar. Es rápido, pero solo porque traslada el riesgo al futuro.

La segunda es la divergencia infinita. El equipo sigue descubriendo opciones, pero nunca toma una decisión. Parece riguroso, pero a menudo esconde miedo a asumir la responsabilidad.

Una buena exploración tiene una regla para detenerse:

Stop exploring when:
  - the riskiest assumption has enough evidence
  - the remaining uncertainty is acceptable
  - the next test costs more than the expected learning
  - the decision is reversible enough to try

Ese último punto es importante.

La distinción de Jeff Bezos entre puertas de una vía y puertas de dos vías es útil porque separa las decisiones que requieren una deliberación cuidadosa de las que deben tomarse rápidamente. La carta de Amazon a sus accionistas de 2015 describe las decisiones de Tipo 1 como trascendentales e irreversibles, y las de Tipo 2 como modificables y reversibles. Un error organizacional común es aplicar un proceso pesado de Tipo 1 a demasiadas decisiones de Tipo 2.

En términos de ingeniería:

Two-way door:
  - feature flag choice
  - first dashboard layout
  - internal naming convention
  - prototype implementation
  - vendor trial with low migration cost

One-way door:
  - irreversible data deletion policy
  - long-term customer contract constraint
  - architecture that locks in compliance posture
  - public API guarantee
  - migration that is hard to roll back

Avanza rápido cuando puedas volver atrás. Tómate más tiempo cuando la puerta se cierre detrás de ti.

Elige la herramienta de aprendizaje adecuada

No todas las incógnitas necesitan el mismo tipo de investigación.

Usa investigación cuando la incertidumbre se refiera a usuarios, mercado, políticas o prácticas existentes:

  • entrevistas con clientes
  • revisión de tickets de soporte
  • análisis de competidores
  • consultas sobre cumplimiento normativo
  • entrevistas con partes interesadas internas

Usa un spike cuando la incertidumbre sea técnica y concreta. Extreme Programming popularizó las soluciones de tipo spike como pequeños programas que exploran posibles soluciones. James Shore describe los spikes como experimentos pequeños y aislados que ayudan a tomar decisiones y que a menudo se descartan una vez encontrada la respuesta.

Las buenas preguntas para un spike son específicas:

Can we stream 10,000 audit events per second through this path?
Can this auth provider support tenant-specific SAML metadata?
Can our current ORM express the query shape without raw SQL?
Can we replay failed events idempotently?

Las malas preguntas para un spike son vagas:

Investigate event-driven architecture.
Research scalability.
Try the new vendor.
Explore options.

Usa un prototipo cuando la incertidumbre se refiera a la interacción, el flujo de trabajo o la comprensión del usuario:

  • interfaz en la que se puede hacer clic
  • prueba de puerta falsa
  • flujo de tipo concierge
  • backend operado manualmente detrás de una interfaz real

Usa un premortem cuando el equipo esté adquiriendo demasiada confianza. El premortem de proyectos de Gary Klein pide al equipo imaginar que el proyecto ya fracasó y trabajar hacia atrás para identificar causas plausibles. Su valor no está en el pesimismo, sino en crear un espacio seguro para decir aquello que preocupa a todos en silencio.

Usa entrega incremental cuando sea probable que haya incógnitas desconocidas. No puedes anticipar todas las sorpresas en un plan, pero sí puedes diseñar el trabajo para que la realidad te dé señales antes.

Una plantilla práctica para registrar decisiones

Los Architecture Decision Records son un buen patrón ligero para registrar decisiones. El formato original de ADR de Michael Nygard mantiene los registros breves y enfocados en el contexto, la decisión, el estado y las consecuencias. Martin Fowler también destaca que los ADR deben registrar alternativas que se hayan considerado seriamente, compromisos, nivel de confianza y criterios para una reevaluación.

Para decisiones ambiguas de producto e ingeniería, ampliaría un poco la plantilla:

# Decision: [short title]

## Status
Proposed | Accepted | Superseded

## Context
What problem are we solving?
What constraints matter?
What is known today?

## Options Considered
- Option A: ...
- Option B: ...
- Option C: ...

## Assumptions
- [high risk] ...
- [medium risk] ...
- [low risk] ...

## Evidence
What did we learn from research, spikes, prototypes, or production data?

## Decision
What are we choosing now?

## Confidence
High | Medium | Low

## Consequences
What gets easier?
What gets harder?
What risks remain?

## Revisit Trigger
What signal would cause us to reopen this decision?

El criterio que lleva a revisar la decisión es la parte que suele subestimarse.

Sin él, los equipos reabren decisiones porque alguien nuevo tiene una opinión contundente. Con él, las reabren porque el contexto cambió.

Ejemplos:

Revisit if monthly audit-event volume exceeds 500 million.
Revisit if enterprise customers require seven-year searchable retention.
Revisit if event replay becomes part of the public support contract.
Revisit if debugging delivery failures takes more than one engineer-day per month.

Ese tipo de criterio convierte la incertidumbre en un contrato observable.

Ejemplo de código: un registro pequeño de supuestos

No necesitas una plataforma para empezar. Un archivo estructurado sencillo o un script pequeño pueden hacer visibles los supuestos.

Aquí tienes un ejemplo con estilo TypeScript:

type EvidenceLevel = "none" | "weak" | "medium" | "strong";
type DecisionImpact = "low" | "medium" | "high";

type Assumption = {
  id: string;
  statement: string;
  owner: string;
  evidence: EvidenceLevel;
  impactIfWrong: DecisionImpact;
  nextTest: string;
};

const evidenceScore: Record<EvidenceLevel, number> = {
  none: 0,
  weak: 1,
  medium: 2,
  strong: 3,
};

const impactScore: Record<DecisionImpact, number> = {
  low: 1,
  medium: 2,
  high: 3,
};

function riskScore(assumption: Assumption): number {
  const uncertainty = 3 - evidenceScore[assumption.evidence];
  return uncertainty * impactScore[assumption.impactIfWrong];
}

function prioritizeAssumptions(assumptions: Assumption[]): Assumption[] {
  return [...assumptions].sort((a, b) => riskScore(b) - riskScore(a));
}

const auditLogAssumptions: Assumption[] = [
  {
    id: "A1",
    statement: "Postgres can absorb first-year audit writes without harming core transactions.",
    owner: "platform",
    evidence: "weak",
    impactIfWrong: "high",
    nextTest: "Run a write-load spike with realistic tenant distribution.",
  },
  {
    id: "A2",
    statement: "Enterprise customers can accept daily export instead of live search in v1.",
    owner: "product",
    evidence: "none",
    impactIfWrong: "high",
    nextTest: "Interview five target customers before implementation starts.",
  },
];

console.log(prioritizeAssumptions(auditLogAssumptions));

Esto es deliberadamente sencillo.

Lo importante no es el código. Lo importante es el comportamiento que fomenta:

  • cada supuesto tiene un responsable
  • la evidencia es explícita
  • la incertidumbre de alto impacto pasa a primer plano
  • cada supuesto riesgoso tiene una próxima prueba

Puedes usar la misma estructura en Markdown, YAML, Linear, Jira, Notion, GitHub Issues o una carpeta de ADR. El formato importa menos que el hábito.

El ritual del equipo

Aquí tienes una versión sencilla de 60 minutos para un equipo multidisciplinario:

0-10 min: frame the decision
  - What outcome are we trying to create?
  - What decision must be made now?
  - What can wait?

10-20 min: generate options
  - Include boring options
  - Include build vs buy
  - Include "do less now" and "do nothing yet"

20-35 min: expose assumptions
  - What must be true for each option to work?
  - What would make this option fail?
  - What are we quietly assuming?

35-45 min: rank risk
  - High impact and low evidence goes first
  - Low impact unknowns go to the parking lot

45-55 min: choose learning actions
  - spike
  - interview
  - prototype
  - premortem
  - small release

55-60 min: assign owners and stopping rules
  - Who tests what?
  - By when?
  - What result changes the decision?

Esta reunión no debería terminar con «investigar más» como tarea vaga. Debería terminar con pruebas concretas y criterios de decisión.

Un ejemplo práctico

Supongamos que el equipo necesita decidir cómo lanzar un asistente de soporte con IA.

La primera versión del problema podría sonar así:

Build an AI assistant for customer support.

Eso es demasiado amplio. Reformúlalo:

Reduce support response time for billing questions without increasing incorrect refunds or policy violations.

Ahora clasifica la incertidumbre:

  • Claro: soporte ya tiene políticas de facturación y límites para reembolsos.
  • Complicado: la integración con Zendesk, Stripe y los datos internos de clientes necesita una revisión de expertos.
  • Complejo: la confianza de los clientes y el comportamiento del modelo ante tickets ambiguos necesitan experimentos.
  • Caótico: por ahora no es caótico, a menos que el sistema ya esté perjudicando a clientes reales.

Genera opciones:

A. AI drafts replies, human approves every response.
B. AI classifies tickets and routes them to the right queue.
C. AI fully handles low-risk billing questions.
D. AI only retrieves policy snippets for human agents.

Expón los supuestos:

A assumes reviewers can approve drafts faster than writing from scratch.
B assumes routing accuracy is enough to reduce queue time.
C assumes low-risk billing questions are easy to detect reliably.
D assumes better context retrieval is the real bottleneck.

Pon a prueba los supuestos más riesgosos:

Interview support agents:
  Is writing the reply the bottleneck, or is finding account context the bottleneck?

Run a trace review:
  How many billing tickets are truly low-risk?

Prototype draft approval:
  Do agents accept drafts, edit them heavily, or ignore them?

Premortem:
  It is three months later and the assistant was rolled back. What happened?

Luego decide:

Decision:
  Start with AI-assisted policy retrieval and draft suggestions for billing tickets.

Confidence:
  Medium.

Why:
  Support interviews show context lookup is the largest bottleneck.
  Full automation still has weak evidence around refund safety.

Revisit:
  Reconsider partial automation if draft acceptance exceeds 70 percent
  and policy-violation review stays below the current human baseline for 30 days.

No es una decisión perfecta. Es una decisión con memoria.

Cómo resolver estos casos con éxito

Resolver con éxito problemas ambiguos no significa acertar a la primera.

Significa diseñar el camino para que el equipo aprenda más rápido de lo que crece el riesgo.

La estrategia práctica:

  1. Identifica el tipo de problema. No uses una guía para problemas claros en trabajo complejo.
  2. Separa las opciones de los supuestos. Las opciones son elecciones. Los supuestos son las condiciones que hacen que esas elecciones tengan éxito o fracasen.
  3. Prioriza las incógnitas más inquietantes. Pon a prueba los supuestos importantes y desconocidos antes que los fáciles y poco importantes.
  4. Usa la prueba creíble de menor costo. Un spike, una entrevista, un prototipo o un premortem deben responder una pregunta relevante para la decisión.
  5. Prefiere avanzar de forma reversible. Convierte las puertas de una vía en puertas de dos vías cuando sea posible.
  6. Registra la decisión por escrito. Incluye alternativas, evidencia, nivel de confianza, consecuencias y criterios para revisarla.
  7. Sigue aprendiendo después del lanzamiento. Las incógnitas desconocidas suelen aparecer después del contacto con usuarios reales, datos reales u operaciones reales.

Vacíos y secciones que valdría la pena agregar más adelante

Este artículo es una guía práctica, no un manual operativo completo. Los vacíos más importantes que ampliaría en una próxima entrega son:

  • Guiones de facilitación para llevar a cabo la sesión de mapeo de supuestos de 60 minutos con un equipo grande
  • Matrices de evaluación de decisiones para ponderar costo, reversibilidad, alineación estratégica, carga operativa y valor para el usuario
  • Flujos de investigación asistidos por agentes de IA para generar listas de opciones y mantener separadas las afirmaciones respaldadas por fuentes de las inferencias
  • Casos de estudio que muestren cómo un equipo cambió de rumbo después de un spike, un premortem o una entrevista con un cliente
  • Plantillas para ADR, registros de supuestos, notas de premortem y fichas de experimentos

La mejora más útil sería un paquete descargable para tomar decisiones: una plantilla en Markdown para la decisión, un mapa de supuestos, una ficha de spike y un ADR.

Fuentes