No estimamos el alcance: lo recortamos para llegar a la fecha

Todo fundador ha oído responder a “¿cuánto va a tardar?” con un número. Y casi todos han visto ese número duplicarse. No es deshonestidad. Es que el número se calculó de la forma equivocada.

El 24 de enero de 2026, el ingeniero de software Sean Goedecke publicó un texto que resume lo que practico desde hace años. La primera frase de su tesis es seca: “No es posible estimar con precisión el trabajo de software.” En How I estimate work, explica por qué y qué hace en su lugar.

Por qué estimar alcance no funciona

El argumento de Goedecke es simple. La mayor parte del trabajo de software es desconocida hasta que alguien empieza a hacerlo. No sabes cuánto lleva una integración con un sistema que nunca abriste, ni cuánto cuesta un flujo que nadie probó con usuarios reales. El trabajo conocido es fácil de estimar. El desconocido domina el total.

También observa que, dentro de las empresas, la estimación rara vez nace del ingeniero. Quien la pide ya tiene una fecha en mente. La estimación se vuelve negociación.

Qué hacer en su lugar: partir de la fecha

En lugar de preguntar “¿cuánto tarda este proyecto?”, Goedecke pregunta “¿qué enfoques caben en este plazo?”. En sus palabras, el trabajo es descubrir “el conjunto de enfoques de software que encaja con esa estimación”.

Su proceso tiene cuatro pasos:

1. Entender el contexto antes del código. Cuánta presión hay, qué tan esencial es el proyecto, qué plazo se espera.
2. Ir al código ya con la fecha. Y preguntar qué es posible dentro de ella.
3. Mirar las incógnitas. Cuántas áreas desconocidas obliga a tocar cada enfoque, y qué riesgo tiene cada una.
4. Presentar opciones, no un número. Cada camino con su riesgo y su compensación. Quien decide, elige.

Si ningún enfoque cabe, dice, quizá sea el requisito lo que tiene que cambiar.

Cómo se vuelve método en el Studio

Para un fundador, el razonamiento de Goedecke tiene una traducción directa. Tienes una fecha que importa: una ronda, una feria, una temporada, el fin de la caja. El producto tiene que estar en línea en esa fecha. Entonces la pregunta correcta no es “¿cuánto tarda mi producto completo?”. Es “¿cuál es el mejor producto que cabe hasta entonces?”.

No estimamos alcance. Lo recortamos para cumplir la fecha. En la práctica:

• La fecha va primero. Queda por escrito en el contrato.
• El diagnóstico mapea las incógnitas. Integraciones, datos heredados, reglas de negocio que nadie documentó. Ahí está el riesgo.
• El alcance se diseña para la fecha. Cada funcionalidad entra o sale por una razón. Lo que sale va a una lista para la siguiente versión, por escrito.
• El precio se cierra tras el diagnóstico. Solo se puede cerrar el precio cuando alcance y fecha están atados.

Caso 1: AI Vou Eu, en línea en 4 semanas

AI Vou Eu es un SaaS de turismo con IA.

Con la fecha fijada, el trabajo fue elegir el flujo central que tenía que funcionar en el lanzamiento y quitar el resto del camino. El producto salió en línea en 4 semanas.

Caso 2: LCX, un solo sistema en 29 días

LCX es una empresa de turismo que opera en más de 10 países de Sudamérica. Tenía un sistema por país. El encargo era unirlo todo en un solo sistema.

Un proyecto así, estimado de la forma tradicional, se convertiría en un cronograma de meses, con cada país pidiendo sus excepciones. Partiendo de la fecha, la pregunta pasó a ser “¿qué tiene que ser común a todos los países el primer día?”. El sistema único salió en línea en 29 días.

Lo que este método te exige

Recortar alcance para cumplir la fecha no es magia. Exige tres cosas al fundador:

1. Una fecha real. No “lo antes posible”. Una fecha con motivo.
2. Disposición a decir que no. A funcionalidades buenas que no son esenciales ahora.
3. Confianza en la siguiente versión. Lo que sale del lanzamiento no muere. Vuelve con datos de uso real para decidir si vale la pena.

A cambio, obtienes algo que ninguna estimación da: un producto en línea en la fecha en que importa.

Qué cambia esto para ti

La próxima vez que alguien responda “¿cuánto tarda?” con un número, pregúntale: “¿qué recortas si tienes que entregar en la mitad del tiempo?”. Si la respuesta es “nada”, ese número es un tiro al aire. Si llega una lista clara de opciones y riesgos, estás hablando con alguien que entiende de dónde viene el retraso.

Y si tienes una fecha y un producto que debe estar en línea ese día, nuestro servicio de desarrollo de sistemas a medida y SaaS empieza justamente por esa conversación.