# Las Estimaciones son Mentira
Table of Contents
Vamos a partir con una verdad incómoda que pocos se atreven a decir en una reunión de directorio: Las estimaciones de software son, fundamentalmente, una mentira.
No es una mentira malintencionada. Es una mentira necesaria. El negocio necesita proyectar flujos de caja, campañas de marketing y compromisos con clientes. No pueden operar con un “estará listo cuando esté listo”.
El problema es que el desarrollo de software no es una ingeniería exacta, es descubrimiento constante. Pero como líderes, no podemos quedarnos en la queja. Mi enfoque no es buscar la estimación perfecta, sino diseñar una estrategia de ejecución que haga irrelevante el error de cálculo.
La Trampa del Desarrollo Lineal
En el modelo tradicional, o incluso en equipos Ágiles mal dirigidos y obsesionados con el diseño visual, se tiende a desarrollar el software de manera lineal, tal como lo percibe el usuario.
El instinto dice: “Primero hagamos el Login, luego el Home, luego el Perfil…”.
Esto es un error estructural. El orden de navegación del usuario no tiene nada que ver con el orden de riesgo técnico.
Si pasas las primeras dos semanas perfeccionando un Login (que es un problema más que resuelto) y dejas el motor de procesamiento de reglas de negocio para el final, estás escondiendo la basura bajo la alfombra. Cuando llegues a la parte difícil, ya no tendrás tiempo de maniobra.
1. Ejecución: Front-Loading y Paralelismo
Para hackear la incertidumbre, mi playbook de inicio de proyecto se basa en dos pilares agresivos:
Atacar el Incendio (Front-Loading)
Yo opero al revés que el flujo de usuario. Busco lo que me da miedo el día uno.
Mi inicio de desarrollo siempre es excesivamente robusto en lo técnico. Si hay una integración con un legacy bancario que me quita el sueño, esa es la tarea #1. Si hay una duda sobre el rendimiento de la base de datos, hacemos la prueba de concepto la primera semana.
Paralelismo Extremo
Aquí rompo con la idea de ir “cerrando tickets” secuencialmente. En el arranque, necesito dispersar la fog of war lo más rápido posible.
Lanzo a cada miembro del equipo a una punta distinta del mapa. No quiero a dos devs haciendo pair programming en un botón. Quiero a uno levantando la infraestructura, a otro conectando la API crítica, y a otro maquetando la vista más compleja.
- Detección Temprana: Al tener ojos en todo el sistema, detectamos bloqueos ocultos en días, no en semanas.
- Integración Acelerada: En muy poco tiempo, el software deja de ser una idea abstracta y empieza a tomar forma real y testeable.
2. Arquitectura: La Trampa de la Sobre-Ingeniería
Aquí viene la advertencia vital: Front-loading de riesgo NO es lo mismo que sobre-ingeniería.
He visto equipos paralizarse intentando crear la Arquitectura Perfecta™ para un producto que ni siquiera tiene usuarios. Pasan semanas diseñando una arquitectura de microservicios orientada a eventos, con capas de abstracción genéricas para soportar “futuros casos de uso”.
Eso no es ser robusto, es ser ingenuo.
En etapas tempranas, el feedback del usuario va a destruir tus suposiciones. Si construiste una catedral de cristal, te va a doler mucho romperla cuando el cliente te diga que en realidad quería una cabaña de madera.
Principio YAGNI (You Ain’t Gonna Need It)
Mi regla de oro para evitar la grasa innecesaria:
- Resuelve el problema actual, no el de mañana. ¿Necesitamos soportar múltiples proveedores de pago hoy? No. Entonces no diseñes una
AbstractPaymentFactorycompleja. Integra Stripe y avanza. - Código borrable > Código extensible. En la fase inicial, prefiero código simple y desacoplado que sea fácil de borrar y reescribir, a código complejo lleno de patrones de diseño que es difícil de modificar.
3. Negociación: La Ecuación del Líder
Una vez que atacamos el riesgo técnico (Front-Loading) y evitamos la complejidad innecesaria (Anti-Sobre-Ingeniería), tenemos el control del proyecto. Ahora podemos negociar con datos reales.
Si entendemos que la capacidad de producción de una Célula madura es constante, la matemática es simple:
Si el negocio viene y dice: “Weon Iván, necesitamos salir dos semanas antes por competencia”, el tiempo baja y mi Capacidad es constante, la única variable que se mueve es el Alcance.
Negociar “On The Spot”
La diferencia entre un gestor y un Director de Tecnología es la capacidad de negociar en tiempo real, sin decir “déjame ver y te aviso la próxima semana”.
Como tengo el mapa mental del proyecto, puedo decir con autoridad:
“Ok, salimos dos semanas antes. Pero el módulo de reportes avanzados no va en la v1. Saldremos con exportación a CSV básica. ¿Les sirve para operar? ¿Sí? Listo, le damos.”
Cierre: Deuda Técnica como Estrategia
Al final del día, gestionar un proyecto innovador es gestionar deuda.
Cuando estamos validando hipótesis, la “Calidad Académica” es negociable. A veces, tomar un atajo sucio (hardcodear una variable, duplicar una función) es la decisión estratégica correcta para llegar al mercado antes y validar si alguien quiere usar lo que construimos.
- Pedimos un préstamo de velocidad (atajo consciente).
- Validamos la hipótesis (lanzamos).
- Pagamos la deuda (refactorizamos si hay éxito).
Si gestionas el riesgo al principio, evitas la sobre-ingeniería y negocias el alcance con agresividad, las fechas dejan de ser una guillotina y se convierten en una simple variable más de tu estrategia de victoria.
