Por qué tu Proyecto de Software Siempre Tarda Más de lo que te Dijeron
La respuesta honesta que ninguna agencia te da: por qué las estimaciones de software siempre fallan y qué puedes hacer al respecto.
Por qué tu Proyecto de Software Siempre Tarda Más de lo que te Dijeron
Un founder me escribió hace unas semanas con una pregunta que escucho todo el tiempo: "Me prometieron 3 meses y vamos en el quinto. ¿Esto es normal?" La respuesta corta es sí. La respuesta honesta es que probablemente nadie te explicó por qué.
Los proyectos de software siempre tardan más. No porque los devs sean flojos ni porque las agencias sean deshonestas (bueno, a veces sí), sino porque estimar software es fundamentalmente difícil. Y aquí está lo que nadie te dice en el pitch inicial.
La estimación original fue un número de ventas, no un plan real
Cuando una agencia te dice "3 meses", ese número salió de algún lado, pero rara vez fue de una descomposición técnica detallada. Fue de "¿cuánto puede aguantar este cliente esperando?" o "¿cuánto necesitamos para ganar este contrato?"
El problema no es la mala fe, aunque existe. Es que en la fase de ventas, nadie conoce bien tu proyecto todavía. Los requerimientos están vagos, los edge cases no están definidos, y las integraciones con tus sistemas actuales son un misterio. Todo eso se convierte en trabajo real después de que firmas.
La primera señal de que una estimación fue seria: te hicieron preguntas incómodas antes de dártela. Si en la primera llamada ya tenías número, desconfía.
Los requerimientos que "ya estaban claros" nunca lo estaban
Hay una frase que escucho en cada proyecto retrasado: "pero eso lo habíamos pedido desde el principio." Y casi siempre es verdad desde la perspectiva del cliente. Y casi siempre también es verdad que estaba implícito, no especificado.
"Quiero que el usuario pueda hacer login" parece simple. Pero implica: ¿con email y contraseña? ¿Con Google? ¿Con magic links? ¿Qué pasa si olvidan la contraseña? ¿Cuántas sesiones simultáneas? ¿Se cierra la sesión automáticamente?
Eso es solo el login. Multiplica esa complejidad por cada feature de tu producto y empiezas a entender por qué el scope crece.
Los buenos equipos de desarrollo tienen un proceso para extraer estos detalles antes de escribir código. Los no tan buenos descubren los edge cases en producción.
El costo invisible de las dependencias externas
Tu app necesita conectarse a Stripe. A un proveedor de facturas electrónicas. A la API de tu logística. A ese sistema legacy que nadie quiere tocar pero que tiene toda la data.
Cada integración externa es una caja negra con sus propias sorpresas: documentación desactualizada, rate limits no documentados, comportamientos distintos entre sandbox y producción. En algunos proyectos, las integraciones son el 40% del trabajo técnico, pero en el estimado inicial ocuparon el 10%.
Si tienes integraciones en tu proyecto, el riesgo de retraso aumenta considerablemente. No es excusa, es física.
Los cambios en el camino cuestan más de lo que crees
"Solo agrégame esta funcionalidad pequeña." Esa frase ha retrasado proyectos enteros.
En software, cambiar algo a mitad del desarrollo no es como agregar un párrafo a un documento. Puede significar replantear la base de datos, modificar la arquitectura de la API, reescribir pantallas ya terminadas. El costo de un cambio crece exponencialmente entre más tarde lo pides.
Esto no significa que no puedas cambiar de opinión, los mejores proyectos iteran. Significa que cada cambio tiene un costo real en tiempo y debe ser conversado abiertamente.
Entonces, ¿qué puedes hacer tú como founder?
Primero, exige un desglose real. Antes de firmar cualquier cosa, pide ver cómo llegaron a ese número. Si el equipo no puede mostrarte una descomposición por módulos con supuestos explícitos, el número es inventado.
Segundo, documenta los requerimientos antes de empezar. No necesitas un documento de 80 páginas, pero sí necesitas especificar los flujos principales con criterios concretos de "terminado". Un buen equipo te ayuda a hacer esto.
Tercero, protege el scope. Cada vez que llegue una solicitud de cambio, evalúa el impacto en tiempo y costo. No es rigidez, es respeto al plan original. Si el cambio vale la pena, págalo. Si no vale la pena, no lo hagas.
Cuarto, habla seguido con el equipo. Proyectos que tienen comunicación semanal real (no solo actualizaciones de Jira) detectan problemas dos semanas antes que los proyectos donde solo hablas con el PM cada mes.
En DevAces tratamos de tener estas conversaciones incómodas desde el primer día, porque un retraso que se anticipa en semana 2 es mil veces menos doloroso que uno que aparece en semana 10. Si estás evaluando opciones para tu próximo proyecto, cuéntanos qué necesitas y te decimos honestamente qué esperar.
Los proyectos de software tardan más porque son complejos. Pero la mayoría de esos retrasos son predecibles, y con el equipo correcto, manejables.