7 min read
“¿Cuánto te toma esa tarea?” “Como tres días.”
Terminó tomando dos semanas.
Si esta escena te suena familiar, no estás solo — y probablemente no es porque seas mal estimando.
Estimar software mal no es un defecto de carácter, es casi una constante universal de la profesión.
¿Por qué siempre nos equivocamos?
El fenómeno tiene nombre: la falacia de planificación (planning fallacy), documentada por los psicólogos Daniel Kahneman y Amos Tversky.
Tendemos sistemáticamente a subestimar el tiempo que algo va a tomar, incluso cuando ya tenemos experiencia previa mostrándonos que nuestras estimaciones anteriores fueron optimistas.
En software específicamente, hay razones adicionales:
- Solo vemos el camino feliz: cuando estimamos, imaginamos el código funcionando a la primera. La realidad incluye bugs inesperados, dependencias que no funcionan como documentan, y “ah, pero esto también hay que cambiarlo”.
- Confundimos “sé cómo hacerlo” con “sé cuánto toma”: entender la solución conceptualmente no es lo mismo que haber medido cuánto tiempo lleva implementarla en la práctica.
- El trabajo invisible no se estima: code review, testing, documentación, deploys, reuniones de coordinación — rara vez entran en el número que decimos en voz alta.
- Presión social hacia el optimismo: decir “esto puede tomar el doble de lo que parece” se siente como estar poniendo excusas de antemano, así que redondeamos hacia abajo sin darnos cuenta.
Técnicas que mejoran la estimación
1. Desglosar hasta que duela un poco
Una tarea de “implementar el checkout” es imposible de estimar con precisión.
Desglosada en “validar el carrito”, “integrar con el gateway de pagos”, “manejar el caso de pago rechazado”, “enviar confirmación por correo” — cada pieza individual es mucho más fácil de estimar, y la suma termina siendo más precisa que el número redondo original.
2. Estimar en rangos, no en números exactos
“Tres días” suena a compromiso firme.
“Entre dos y cinco días, con mayor probabilidad cerca de tres” comunica la incertidumbre real que existe.
Herramientas como los rangos optimista/probable/pesimista (estimación PERT) capturan esto formalmente.
3. Planning Poker para calibrar en equipo
Cada persona estima en privado (con cartas numeradas, generalmente en secuencia de Fibonacci: 1, 2, 3, 5, 8, 13), y todos revelan al mismo tiempo.
Si hay mucha dispersión, la conversación que sigue — “¿por qué vos pensás que es un 13 y yo pensé que era un 3?” — suele revelar supuestos ocultos que nadie había verbalizado.
El valor de Planning Poker no está en el número final, está en esa conversación.
4. Medir la precisión histórica del equipo
Si tu equipo constantemente estima 5 días y termina tomando 8, ese factor de corrección (1.6x) es información valiosa y medible.
No se trata de ser “mejor” estimando en abstracto — se trata de calibrar contra tu propio historial real.
5. Separar estimación de compromiso
Una estimación es una predicción con incertidumbre. Un compromiso es una promesa.
Cuando el negocio pide una estimación pero la trata como un compromiso inamovible, se genera presión para redondear hacia abajo — exactamente el patrón que perpetúa el problema.
Esta distinción, dicho sea de paso, conecta directamente con el post de cómo decir “no” a tu jefe o cliente: comunicar el rango real con datos, en lugar de un número optimista para complacer, es la misma habilidad aplicada a estimaciones.
El factor IA: más rápido, pero no infalible
Es imposible hablar de estimaciones en 2026 sin mencionar el impacto de las herramientas de inteligencia artificial.
Asistentes de código como Claude Code, Copilot o Cursor genuinamente reducen el tiempo de muchas tareas: generar boilerplate, escribir tests, hacer refactors mecánicos, o incluso implementar una funcionalidad completa a partir de una buena especificación puede tomar una fracción del tiempo que tomaba hace pocos años.
Pero acá hay una trampa real, y vale la pena nombrarla con claridad: la IA acelera la escritura del código, no necesariamente el trabajo completo de construir software.
El factor humano sigue siendo indispensable para varios componentes que una estimación optimista basada solo en “la IA lo escribe rápido” tiende a pasar por alto:
- Entender el problema de negocio real: la IA puede generar código a partir de una especificación, pero definir qué especificación es la correcta — qué edge cases importan, qué comportamiento espera realmente el usuario — sigue siendo trabajo humano.
- Revisar y validar el resultado: código generado rápido igual necesita code review, testing exhaustivo y validación contra el dominio real. Ese tiempo no desaparece — a veces incluso crece, porque revisar código ajeno (o generado) requiere un esfuerzo cognitivo distinto a escribirlo.
- Integración con el sistema existente: la parte más lenta de la mayoría de las tareas rara vez es “escribir la lógica nueva” — es entender cómo encaja con quince servicios, configuraciones y comportamientos heredados que ya existen. La IA ayuda, pero no reemplaza ese conocimiento contextual.
- Decisiones de arquitectura y trade-offs: elegir entre dos enfoques válidos, evaluar el costo a largo plazo de una decisión técnica, o simplemente saber cuándo NO seguir la sugerencia de la IA porque no encaja con el contexto del equipo — eso sigue siendo, y probablemente seguirá siendo por mucho tiempo, criterio humano.
La recomendación práctica: si tu equipo empezó a estimar más bajo “porque ahora usamos IA”, validá esa reducción contra datos reales de tu propio equipo, igual que harías con cualquier otro factor de corrección.
La IA cambia la forma de la curva de esfuerzo — probablemente aplana la parte de “escribir código” — pero no elimina la incertidumbre del resto del trabajo.
Tratarla como una bala de plata en las estimaciones es la versión 2026 del mismo optimismo que ya nos afecta desde antes de que existiera.
¿Cómo comunicar incertidumbre sin sonar evasivo?
Hay una diferencia entre “no sé” (que suena a falta de preparación) y “esto tiene una incertidumbre específica, y acá está la razón” (que suena a criterio profesional). Algunas frases que funcionan:
- “Puedo estimar la parte que conocemos con confianza — 3 días. La parte que depende de la API externa tiene más incertidumbre porque no controlamos su documentación; le pondría un rango de 2 a 5 días.”
- “Esta estimación asume que el diseño no cambia. Si hay ajustes de producto a mitad de camino, el número se mueve.”
- “Nunca implementamos algo así antes en este sistema. Prefiero darte un número después de un spike (investigación acotada) de un día, en lugar de adivinar ahora.”
Conclusión
Nadie estima perfecto, y probablemente nadie lo hará nunca — la incertidumbre es inherente a construir algo que no existía antes.
Lo que sí está a nuestro alcance es estimar con más honestidad: desglosar, comunicar rangos, calibrar contra datos reales, y — cada vez más relevante — usar las herramientas de IA disponibles sin dejar que su velocidad nos haga olvidar todo el trabajo humano que sigue rodeando al código.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Daniel Kahneman — Pensar rápido, pensar despacio
Software Estimation: Demystifying the Black Art — Steve McConnell