¿Qué es la incertidumbre?

La incertidumbre es la imposibilidad de saber con seguridad qué va a ocurrir. En el desarrollo de software aparece en casi todo: qué necesita realmente el usuario, cuánto va a costar construir una funcionalidad, cómo se comportará el sistema en producción o qué hará la competencia. No es un fallo de planificación, sino una característica del propio trabajo creativo: si construyes algo nuevo, por definición no tienes datos previos exactos sobre ello.

Conviene distinguir incertidumbre de riesgo. El riesgo es un suceso concreto que puede pasar y cuyo impacto puedes valorar (por ejemplo, "que el proveedor del pago falle"). La incertidumbre es más amplia y difusa: abarca lo que ni siquiera sabes que desconoces. Por eso no se elimina con un buen plan, sino que se reduce poco a poco a medida que aprendes.

La mayoría de los problemas de un proyecto no vienen de hacer mal lo conocido, sino de tratar lo incierto como si fuera seguro. Cuando un equipo se compromete a un alcance cerrado y a una fecha fija al inicio, está prometiendo certeza sobre algo que aún no entiende. El resultado habitual son estimaciones que se desvían, requisitos que cambian a mitad de camino y producto que nadie usa.

Reconocer la incertidumbre cambia la forma de trabajar. En lugar de intentar acertar a la primera con un plan perfecto, el objetivo pasa a ser aprender rápido y barato. Cada decisión se trata como una hipótesis que hay que validar, no como una verdad que ejecutar sin más.

Los marcos ágiles como Scrum no prometen eliminar la incertidumbre: la asumen y la reducen de forma gradual mediante el empirismo, es decir, tomando decisiones a partir de lo observado y no de suposiciones. El mecanismo se apoya en tres pilares prácticos:

• Iteraciones cortas. Dividir el trabajo en sprints acota el horizonte de predicción. Es mucho más fácil estimar dos semanas que seis meses, porque lo que ves de cerca lo conoces mejor.
• Entregas frecuentes. Cada incremento que llega a manos reales genera información nueva. Hacer deploy pronto y a menudo convierte suposiciones en hechos: o la funcionalidad se usa, o no.
• Feedback y reordenación. Con el feedback recogido se reordena el backlog, de modo que el equipo siempre trabaja en lo más valioso conocido en ese momento, no en lo que parecía importante hace meses.

Otras prácticas refuerzan lo mismo. Un MVP reduce la incertidumbre de mercado validando una idea con el mínimo esfuerzo. Y limitar el trabajo en curso con un WIP limit acelera el aprendizaje, porque terminar antes una cosa te da respuestas antes que tener muchas a medias.

El cono de la incertidumbre es la forma habitual de visualizar este fenómeno. Representa cómo el margen de error de una estimación es enorme al principio de un proyecto y se va estrechando con el tiempo, a medida que se toman decisiones, se construye producto y se recoge información.

La consecuencia práctica es clara: al arrancar, una estimación de coste o plazo puede desviarse muchísimo en cualquier dirección, así que tiene más sentido dar un rango amplio que un número exacto. Conforme avanzan los sprints, el cono se cierra y las estimaciones se vuelven progresivamente más fiables. Por eso en Agile se reestima de forma continua en lugar de fijar una única cifra al comienzo y defenderla contra la evidencia.

• Confundir un plan detallado con certeza. Un documento de cien páginas no reduce la incertidumbre; solo la disfraza. Lo que la reduce es construir, entregar y medir.
• Estimar lo incierto como si fuera conocido. Dar una fecha exacta para algo que nunca se ha hecho transmite una falsa seguridad que tarde o temprano se rompe.
• Esperar a tenerlo todo claro antes de empezar. La información que falta suele aparecer solo al construir. Posponer la primera entrega retrasa también el aprendizaje.
• No actualizar el plan con lo aprendido. Si recoges feedback pero sigues ejecutando el backlog original sin reordenarlo, desperdicias justo lo que reduce la incertidumbre.
• Cargar de trabajo en paralelo. Muchas tareas abiertas a la vez retrasan las respuestas; cerrar antes da datos antes.

La incertidumbre es el motivo de fondo de buena parte del andamiaje ágil. Para profundizar, mira empirismo (la base de cómo se decide con evidencia), el cono de la incertidumbre (cómo evoluciona con el tiempo), sprint y backlog (dónde se gestiona iteración a iteración) y riesgos (su pariente más concreto y acotado).