Las estimaciones de software tienen una reputación terrible. Y es merecida.
La mayoría de los proyectos de software se entregan tarde, sobre presupuesto, o con menos features de las prometidas. A veces, las tres cosas a la vez. Hay tantos chistes al respecto que se convirtieron en parte de la cultura de la industria.
Pero en Sintaxyz llevamos varios años entregando proyectos en tiempo y dentro del presupuesto. No siempre perfectamente —nadie lo hace perfectamente— pero con una tasa de error que consideramos aceptable y que mejora año a año.
Acá está el método que usamos.
Por qué fallan las estimaciones
Antes de hablar de soluciones, necesito hablar de las causas. Las estimaciones fallan por razones predecibles:
Optimismo sistemático: los humanos somos naturalmente optimistas cuando estimamos tiempo. Pensamos en el caso ideal, no en el caso probable. “Si todo sale bien, esto tarda dos semanas”. Y casi nunca todo sale bien.
Desconocimiento de los desconocidos: al principio de un proyecto, no sabés lo que no sabés. El sistema de pagos que parece simple tiene edge cases raros. La API de terceros que vas a integrar tiene una documentación pésima. Los requerimientos del cliente cambian cuando ven la primera demo.
Presión para comprometerse pronto: el cliente quiere un número antes de que tengamos suficiente información para darlo con confianza. El miedo a perder el proyecto hace que se den estimaciones optimistas sin suficiente análisis.
Falta de buffer sistemático: aunque el estimador sabe que algo puede salir mal, no siempre lo cuantifica y lo agrega al número final.
No separar la estimación de la negociación: “te lo hacemos en seis semanas” puede ser lo que el cliente quiere escuchar, no lo que la realidad permite.
El principio central: separar el descubrimiento del desarrollo
Lo más importante que cambiamos en nuestro proceso fue esto: no estimamos el desarrollo antes de hacer discovery.
Discovery es una fase corta —generalmente una semana para proyectos medianos— donde antes de comprometernos con un cronograma y un presupuesto, hacemos el análisis suficiente para entender qué estamos construyendo realmente.
Durante el discovery:
- Mapeamos los flujos principales de usuario.
- Identificamos las integraciones de terceros y evaluamos su complejidad real.
- Revisamos la arquitectura existente si hay sistema heredado.
- Definimos las decisiones técnicas clave.
- Identificamos los riesgos más importantes.
- Descomponemos el trabajo en unidades estimables.
Después del discovery, la estimación es mucho más confiable porque tenemos información real, no suposiciones.
El discovery tiene un costo. Generalmente lo cobramos por separado, o lo ofrecemos como parte de la propuesta inicial con la condición de que si el proyecto sigue adelante, se descuenta del total.
Para el cliente, el valor es claro: prefieren pagar una semana de análisis ahora que descubrir a las seis semanas que la estimación original era demasiado optimista.
La descomposición en tareas concretas
Después del discovery, estimamos a nivel de tarea, no de feature.
“Integrar con el sistema de pagos” no es una tarea estimable. “Implementar endpoint de creación de cargo con webhook de confirmación, incluyendo retry logic y logging” sí lo es.
Para cada tarea, el estimador responde tres preguntas:
- ¿Qué es lo mínimo que podría tardar esto si todo sale bien? (optimista)
- ¿Qué es lo más probable que tarde? (realista)
- ¿Qué es lo máximo que podría tardar si hay problemas? (pesimista)
Y aplicamos una fórmula simple conocida como PERT:
Estimación = (Optimista + 4×Realista + Pesimista) / 6
Esto da más peso al caso realista y menos a los extremos, pero obliga a pensar en los tres escenarios.
Después sumamos todas las tareas y aplicamos buffers por categoría:
- Features conocidas y bien entendidas: +20%
- Integraciones con sistemas de terceros: +40%
- Trabajo en código heredado: +50%
- Features con alta incertidumbre en requerimientos: +60%
Estos porcentajes vienen de años de retroalimentación de proyectos reales.
El rol de las iteraciones en la estimación
No estimamos proyectos completos cuando podemos evitarlo. Estimamos iteraciones de dos semanas.
Al principio de cada iteración, planificamos las tareas con suficiente detalle. Al final de cada iteración, tenemos algo funcional que mostrar y una oportunidad de ajustar el rumbo.
Esto cambia la naturaleza del riesgo. En lugar de descubrir a los tres meses que algo salió mal, lo descubrís a las dos semanas y podés corregir antes de que el error se amplifique.
También cambia la relación con el cliente. En lugar de “confíen en nosotros, en tres meses entregan”, es “en dos semanas tienen la primera demo, y desde ahí construimos juntos”.
Qué hacemos cuando aparece algo inesperado
Aparece. Siempre aparece algo.
El protocolo que seguimos:
- Identificamos el impacto tan pronto como lo detectamos. No esperamos al final de la iteración.
- Comunicamos de inmediato al cliente, con contexto claro: qué pasó, por qué, cuánto tiempo adicional implica, y cuáles son las opciones.
- Damos opciones concretas: ¿reducimos el alcance de esta iteración para absorber el imprevisito? ¿Agregamos tiempo a la iteración? ¿Ajustamos el cronograma global?
Lo que nunca hacemos es enterrar el problema y esperar que se resuelva solo. El problema no se resuelve solo. Y cuando el cliente lo descubre por las suyas, la confianza se daña mucho más que si lo comunicaron a tiempo.
La mala noticia entregada a tiempo siempre es mejor que la misma noticia entregada tarde.
Las métricas que seguimos
Después de cada proyecto, registramos:
- Estimación original vs tiempo real, por tipo de tarea.
- Dónde aparecieron los imprevistos más grandes.
- Qué tipos de trabajo tienden a ser más impredecibles.
Con el tiempo, esto construye un historial que hace las estimaciones siguientes más precisas. No es magia: es datos.
Lo que no hacemos
No damos estimaciones en la primera reunión. Si el cliente pide un número antes de que hayamos analizado el problema, damos un rango amplio con la aclaración explícita de que es una aproximación que requiere análisis adicional. Si el cliente no acepta eso, probablemente no es el cliente correcto para nosotros.
No aceptamos plazos que sabemos que son imposibles. Si el cliente dice “necesito esto en cuatro semanas” y nuestra estimación dice que son diez, lo decimos directamente. Podemos discutir qué puede hacerse en cuatro semanas, pero no prometemos lo que no podemos entregar.
No estimamos sin información. “Cuánto costaría construir algo similar a Airbnb” no es una pregunta que podamos responder sin análisis. La respuesta “depende” no es evasiva: es honesta.
El resultado
No somos perfectos. Hay proyectos donde nos equivocamos. Pero los errores son menores, se detectan antes, y se comunican bien.
La consecuencia práctica es que los clientes con los que trabajamos confían en nuestras estimaciones. No porque seamos infalibles, sino porque cuando algo cambia, lo sabemos primero que ellos y se lo decimos.
Eso, en una industria donde las sorpresas son la norma, es un diferencial real.
Si estás planificando un proyecto y querés revisar la estimación con alguien que ha pasado por este proceso muchas veces, hablemos.