- Es imposible estimar con precisión la duración de un proyecto de software, y la mayoría del trabajo está dominado por “desconocidos” impredecibles
- En lugar de ser una herramienta para ingenieros, las estimaciones se usan como una herramienta política de la gerencia, para decidir prioridades del proyecto y asignación de presupuesto
- En la práctica, la estimación define el trabajo; los equipos trabajan encontrando un enfoque técnico posible dentro del plazo dado
- Para estimar de forma efectiva, los ingenieros deben centrarse en entender el contexto político, evaluar riesgos desconocidos y presentar múltiples escenarios de ejecución
- Este enfoque prioriza la confianza y la colaboración realista por encima de la precisión, y resalta la capacidad de ingeniería de entender la estructura de toma de decisiones dentro de la organización
La ficción de las estimaciones de software
- En la industria existe la “ficción cortés” de que un equipo experimentado puede predecir cronogramas con precisión si se esfuerza lo suficiente
- En la práctica, la mayoría de los ingenieros reconoce que predecir con exactitud es imposible
- Algunos equipos estiman usando tallas de camiseta, pero eso al final se convierte a tiempo y se entrega a la capa gerencial
- A veces también se usan heurísticas poco realistas como “duplica la estimación inicial y agrégale 20%”
Por qué es imposible estimar
- Las tareas pequeñas y claras sí pueden predecirse, pero la mayoría de los proyectos se realiza sobre sistemas inciertos y complejos
- Ejemplo: cambiar el texto de un enlace puede estimarse en 45 minutos, pero un cambio grande en un sistema no
- La mayor parte de la programación es una actividad de investigación exploratoria, y no se puede saber de antemano todo el trabajo necesario solo con planificación
- El antiguo enfoque de diseño arquitectónico centralizado fracasó, y las decisiones deben tomarlas los desarrolladores que trabajan con el código real
- Como resultado, solo 10% del trabajo es conocido, mientras que el otro 90% no puede estimarse por estar en territorio desconocido
La estimación es una herramienta de la gerencia, no de ingeniería
- Las estimaciones no tienen relación con mejorar la productividad del equipo, y muchos equipos eficientes trabajan sin ellas
- La gerencia intenta ajustar las estimaciones al resultado que quiere: si el plazo es largo, presiona para acortarlo; si es corto, pide agregar buffer
- Solo los proyectos técnicamente imposibles llegan, de forma excepcional, a producir un juicio realista
- En las áreas que generan poco interés dentro de la organización, a veces los procedimientos formales simplemente se mantienen
- Por eso, las estimaciones funcionan como un medio político para que personas no ingenieras seleccionen o cancelen proyectos
La estimación define el trabajo
- A diferencia de la percepción general, no se define primero el trabajo, sino la estimación, y a partir de ahí se decide el enfoque técnico
- Ejemplo: el enfoque para implementar una función de “hablar con PDF” en 6 meses es completamente distinto del enfoque para hacerlo en un día
- La restricción de tiempo determina la profundidad y la calidad del diseño del código, y los ingenieros eligen la solución posible dentro del plazo dado
Cómo se estima en la práctica
- Primero, hay que entender el contexto político para captar la importancia del proyecto y el plazo esperado
- Después, se exploran enfoques posibles con base en un plazo que ya está definido
- Cuantos más desconocidos (unknowns) haya, mayor será la estimación y más habrá que reducir el alcance del enfoque
- Al final, en vez de dar un plazo exacto, se presentan evaluaciones de riesgo y varios escenarios de ejecución
- Ejemplo: resolver todo directamente, rodear parte del problema o pedir apoyo a otro equipo
- El rol del ingeniero no es “¿cuánto tardará?”, sino “¿qué método es posible dentro del plazo dado?”
Objeciones y respuestas
- Algunos ingenieros evitan estimar en condiciones inciertas, pero eso hace que una persona no técnica termine estimando en su lugar
- Una actitud de confrontación constante con la gerencia, en vez de colaboración, es improductiva y debilita la confianza
- Los equipos que no sienten presión quizá simplemente estén en un área fuera del foco de la organización
Conclusión
- En la práctica, los gerentes se acercan al equipo con un plazo que ya tienen en mente, y el equipo busca una solución técnica posible dentro de ese marco
- La estimación es una herramienta de negociación entre directivos, y solo los proyectos imposibles sirven excepcionalmente para transmitir la realidad
- Una buena estimación debe incluir no una cifra precisa, sino riesgos y opciones
- La estimación exacta del trabajo de software es imposible, y una estimación exitosa depende de reconocer y gestionar los riesgos desconocidos
2 comentarios
> Primero entender el contexto político para comprender la importancia del proyecto y el cronograma esperado
> Después explorar enfoques posibles tomando como base el plazo ya fijado
Oh, vaya
Opiniones de Hacker News
Comparto mi tabla de referencia para estimar proyectos, medio en broma. Para proyectos internos (por ejemplo, migrar de proveedor, sin impacto para usuarios), calculo el tiempo que sea defendible ante mi jefe. Para proyectos con impacto en usuarios (por ejemplo, agregar una función nueva), se sigue mientras el ROI siga siendo positivo. Para proyectos que requieren colaboración con socios externos, el equipo comercial fija la fecha de entrega y el equipo de ingeniería ajusta un poco la definición del MVP para encajar en ese calendario.
Me sorprendía que nadie hablara de planning poker o story points. No es perfecto, pero es un método bastante bueno. Todo trabajo debería terminarse dentro del sprint, y si es muy grande, hay que dividirlo. Todo el equipo debe ponerse de acuerdo con los puntos, y en ese proceso aparece el verdadero valor de la discusión. Después de unos meses, la velocidad del equipo se estabiliza y se puede predecir con una precisión de más o menos ±10%. No es magia, pero ayuda a entregar valor de forma constante y a volver a evaluar la relación costo-beneficio en cada sprint.
Yo hago estimaciones basadas en intervalos de confianza, preguntando en unidades de “2 horas, 2 días, 2 semanas, 2 meses, 2 años”. Si el rango es demasiado amplio, lo divido más; y si no se puede, evalúo si vale la pena gastar tiempo en reunir más información. Si no, se cancela el proyecto.
Una vez estimé en un sprint una migración sencilla de contraseñas de texto plano a hash, y en realidad tomó 6 meses. Descubrimos porque un cliente mostró en video que escribía la contraseña sin distinguir mayúsculas y minúsculas. Además, eliminaron una imagen de PHP y eso también provocó fallas de compilación. Estimar siempre es una aventura divertida.
Me llama la atención que muchos ingenieros y gerentes no estimen usando métricas de proyectos anteriores. Si revisas los datos de throughput del equipo, puedes calcular una duración aproximada y un intervalo de confianza (por ejemplo, 90%, 70%, 50%). Así también le das a la gente externa una idea probabilística del contexto.
Yo veo la estimación como un proceso de negociación. Presento tres opciones como si fueran versiones de auto: Economy, Mid-tier y Luxury. El negocio siempre quiere la funcionalidad de la opción 3 con el presupuesto de la 1, así que al final ajusto según la situación. Tener preparado el plan #1 permite cambiar rápido en caso de crisis, y durante la negociación ayuda a visualizar el costo de tomar atajos. Gracias a eso he evitado varias veces decisiones irracionales de PMs o ejecutivos en modo pánico.
Trabajo con sistemas distribuidos de gran escala al nivel FAANG, y ahí estimar con precisión es casi imposible. Hay demasiados unknown-unknowns, y hasta hacer un prototipo requiere enormes volúmenes de datos y tiempo. Por eso, más que estimar, me enfoco en gestionar la incertidumbre.
El método más confiable es compararlo con proyectos similares. Algo como “esto es 20% más complejo que el proyecto X, así que tardará 20% más”. Claro, para eso hay que registrar de forma constante los datos reales de duración de proyectos anteriores.
Al principio iba a discutir contra la idea de que “estimar es imposible”, pero terminé dándome cuenta de que el rol dentro de la organización importa más. Aunque el equipo vea que, según la capacidad y la estimación, no se puede, la fecha no cambia. Al final se termina ajustando con recorte de alcance o compromisos de calidad. Por eso quizá es más correcto decir que “estimar no sirve de mucho”.
Siento que la clave de una estimación es la ambigüedad. Hay tareas que se ven pequeñas, como un ajuste fino de UI, pero en realidad son trabajo donde se aprende mientras se hace. En cambio, un cambio grande puede terminarse rápido si está bien definido. En la era de los LLM, más que el tamaño del cambio, lo que determinará el tiempo requerido será el grado de incertidumbre.