Cómo estimar tiempos de un proyecto sin fallar siempre

El sesgo de planificación (planning fallacy), documentado por Daniel Kahneman y Amos Tversky, describe algo muy específico: cuando estimamos nuestro propio trabajo, imaginamos el camino sin obstáculos — sin la reunión que se alarga, sin el bug inesperado, sin la dependencia externa que se atrasa. Cuando estimamos el trabajo de otra persona o un proyecto ajeno, en cambio, somos mucho más realistas porque no tenemos el mismo optimismo sobre nuestra propia ejecución.

Esto explica por qué "estimá con cuidado" no funciona como consejo: el problema no es falta de cuidado, es un sesgo estructural. Lo que sí funciona es cambiar el método de estimación para que no dependa de imaginar el escenario ideal. Las tres técnicas siguientes hacen exactamente eso.

La forma más simple y subestimada: buscar una tarea parecida que ya se hizo antes y usar su tiempo real (no el estimado) como base. "La última migración de base de datos parecida tomó 3 semanas" es un dato mucho más confiable que cualquier cálculo teórico, porque ya incluye los obstáculos reales que aparecieron la vez anterior.

Cómo aplicarla: antes de estimar una tarea nueva, preguntá "¿hicimos algo parecido antes? ¿cuánto tardó realmente?" Si la respuesta es "sí, pero esta vez va a ser más rápido porque ya aprendimos" — desconfiá: esa frase es exactamente el sesgo de planificación hablando.

PERT (Program Evaluation and Review Technique) pide tres números en vez de uno: tiempo optimista (todo sale perfecto), tiempo pesimista (varias cosas salen mal) y tiempo más probable (el escenario típico). La fórmula pondera el escenario más probable:

Estimación = (Optimista + 4 × Más probable + Pesimista) / 6

Ejemplo: escribir el contenido de una página web. Optimista: 2 días. Más probable: 4 días. Pesimista: 8 días (el cliente pide dos rondas de cambios). Estimación PERT: (2 + 4×4 + 8) / 6 = 4,3 días. El beneficio no es el número exacto — es que forzar el escenario pesimista hace visible un riesgo (las rondas de cambios) que una estimación de un solo número habría ignorado.

Nacida en equipos Scrum, pero útil en cualquier equipo: cada persona estima en privado (con cartas de una baraja tipo Fibonacci: 1, 2, 3, 5, 8, 13…) y todos revelan al mismo tiempo. Si hay consenso, listo. Si hay una diferencia grande — alguien dice 2 y otra persona dice 13 — esa diferencia es información valiosa: casi siempre significa que una de las dos personas sabe algo que la otra no (un riesgo oculto, o una simplificación posible).

Por qué funciona mejor que preguntarle a una sola persona: evita que la estimación quede anclada al número que dice primero la persona con más jerarquía o más confianza — un sesgo social además del cognitivo. No hace falta cartas físicas: cualquier ronda donde todos escriben su número antes de verlo el de los demás logra el mismo efecto.

Después de estimar con cualquiera de las tres técnicas, agregá un búfer explícito — no "por las dudas metamos un día más" escondido en cada tarea, sino un bloque de tiempo visible al final del proyecto (10-20% del total suele alcanzar) que absorbe los imprevistos que ya sabés que van a pasar aunque no sepas cuáles. Es la diferencia entre negar la incertidumbre y planificarla.

Esto conecta directo con la fase de planificación del proyecto completo — ver las 5 fases de un proyecto — y con quién tiene que aprobar ese búfer antes de comprometer una fecha con el cliente, que suele ser una decisión para la matriz RACI del proyecto.