Estimación: técnicas, PERT y el cono de incertidumbre

Cuánto va a costar y cuánto va a tardar, dicho con honestidad: qué es una estimación, cómo se hace, por qué siempre es un rango y por qué no es una promesa.

1. Qué es (y qué no es) una estimación

Una estimación es una predicción de cuánto esfuerzo, tiempo o dinero hará falta, hecha con la información que tenemos ahora y, por tanto, con incertidumbre. Steve McConnell, en el libro de referencia sobre el tema, separa tres cosas que en las empresas se mezclan constantemente:Ampliación. McConnell, S. (2006). Software Estimation: Demystifying the Black Art, cap. 1. Ver también Construx · The Cone of Uncertainty.

La frase de las diapositivas "una estimación no es una promesa" va justo de esto. El fallo típico: el JP da una estimación ("unas 16 semanas, si todo va bien"), el cliente la oye como compromiso ("16 semanas") y el proyecto "llega tarde" a una fecha que nadie prometió de verdad. El trabajo de gestión es comparar la estimación con el objetivo y, si no encajan, negociar (alcance, recursos, fecha) antes de comprometerse. Es otra vez el equilibrio explícito de restricciones de la lección 1.

Y una regla que se deriva: la estimación no se negocia; el plan sí. Si el cliente dice "16 semanas es mucho, ponme 12", bajar la cifra no hace que el trabajo sea más pequeño: sólo hace la estimación falsa. Lo negociable es qué se hace (alcance), con quién (recursos) o cuándo (fecha).

Qué se estima, y en qué orden

La cadena clásica, que verás también en la lección de costes (Tema 2, diap. 50: "Trabajo → esfuerzo → recursos → coste"):

• Tamaño: cuánto hay que construir (nº de funcionalidades, puntos de función, story points, paquetes de la EDT).
• Esfuerzo: cuánto trabajo cuesta, en persona-horas o persona-días (lección 9: esfuerzo ≠ duración).
• Duración: cuánto calendario, según cuántas personas, su dedicación y las dependencias (camino crítico).
• Coste: esfuerzo × coste por hora + infraestructura, licencias, etc. (lección 14).

Cada paso añade su propia incertidumbre: si el tamaño está mal, todo lo de detrás está mal.

2. Técnicas de estimación

No hay una técnica "correcta": se elige según la fase del proyecto y los datos disponibles. Lo profesional es combinar al menos dos y, si discrepan mucho, investigar por qué.Ampliación. SWEBOK v4, KA Software Engineering Management, "Effort, Schedule, and Cost Estimation"; PMBOK 6, proceso "Estimar la duración de las actividades" (juicio experto, análoga, paramétrica, tres valores, ascendente).

Juicio experto

Una o varias personas con experiencia en ese tipo de trabajo dan su estimación. Es la técnica más usada del mundo y la más expuesta a sesgos. Se mejora mucho con estructura:

• Delphi / Wideband Delphi: varios expertos estiman por separado y de forma anónima, se comparan resultados, se discuten las diferencias (¿qué sabe el que dijo 3 semanas que no sabe el que dijo 10?) y se repite hasta converger. Evita que el más veterano o el más ruidoso arrastre al resto (anclaje).
• Planning poker: la versión ágil de Wideband Delphi. Cada miembro elige una carta a la vez y se revelan juntas; los extremos explican su razonamiento.

Estimación por analogía (análoga)

Se parte de un proyecto pasado parecido y se ajusta por las diferencias: "La app de horarios de Metro Norte nos llevó 1.800 h; TusBus es parecida pero añade tiempo real, así que +30 %: unas 2.300 h". Es rápida y barata, útil al principio, cuando hay poca información. Su calidad depende de que el proyecto de referencia sea realmente comparable y de tener datos históricos fiables (otra razón para registrar lecciones aprendidas al cerrar, lección 11).

Estimación paramétrica

Usa una relación estadística entre una variable medible y el esfuerzo: "en nuestros proyectos, cada pantalla cuesta de media 40 h; TusBus tiene 25 pantallas → 1.000 h". En software, los modelos clásicos son COCOMO (Boehm: esfuerzo en función del tamaño en líneas de código, con factores de ajuste) y los puntos de función (miden el tamaño funcional desde los requisitos, independiente del lenguaje).Ampliación. Boehm, B. (1981). Software Engineering Economics; COCOMO II (2000). Puntos de función: IFPUG, norma ISO/IEC 20926. Es tan buena como los datos con que se calibró el parámetro.

Estimación ascendente (bottom-up)

Se estima cada paquete de trabajo de la EDT (lección 9) y se suma hacia arriba. Es la más precisa y la más cara, y sólo es posible cuando ya existe una EDT detallada, es decir, más tarde. Tiene dos trampas: olvidar trabajo que no está en la EDT (por eso la regla del 100 %) y sumar estimaciones "optimistas" de cada parte, que acumulan el error en el mismo sentido.

Estimación relativa (ágil)

En lugar de horas, se estima el tamaño relativo de cada historia en story points, comparándolas entre sí ("esta es el doble que aquella"), normalmente con una escala tipo Fibonacci (1, 2, 3, 5, 8, 13…) cuyos saltos crecientes reflejan que lo grande es más incierto. La duración sale de la velocidad observada del equipo (puntos completados por sprint). Las diapositivas lo contraponen a "horas, recursos, actividades" del enfoque predictivo.Tema 2, diap. 54. Cohn, M. (2005). Agile Estimating and Planning. Ventaja: las personas comparan mejor que miden en absoluto, y la velocidad se calibra con datos reales del propio equipo. Cuidado: los puntos no son comparables entre equipos, y usarlos para medir productividad individual los corrompe.

3. Estimación de tres puntos y PERT

Dar un único número esconde la incertidumbre. La estimación de tres puntos pide tres valores para cada actividad:Ampliación. PERT (Program Evaluation and Review Technique) nació en 1958 en la Marina de EE. UU. para el programa del misil Polaris. Ver Three-point estimation.

• O · optimista: si todo sale bien (no "si ocurre un milagro").
• M · más probable: lo que pasaría normalmente.
• P · pesimista: si salen mal las cosas razonables que pueden salir mal (no "si cae un meteorito").

PERT da más peso al valor más probable. La distribución del esfuerzo en software suele ser asimétrica hacia la derecha: hay poco margen para ir mucho más rápido de lo normal y mucho para ir más lento (un bloqueo, un bug raro, una dependencia externa). Por eso, si P está mucho más lejos de M que O, la media PERT queda por encima del valor más probable, y eso es correcto.

Ejemplo con TusBus

El equipo estima la actividad D (Backend) en semanas: O = 4, M = 6, P = 11.

Cómo se lee: 6,5 semanas no es "lo que tardará"; es el centro de un rango. Aproximando a una normal, hay ~68 % de probabilidad de caer entre E ± 1σ (5,3-7,7) y ~95 % entre E ± 2σ (4,2-8,8). Si el cliente quiere un 95 % de confianza, el compromiso no puede ser 6,5: está más cerca de 9.

Para un camino entero

Para una secuencia de actividades (p. ej., el camino crítico), las medias se suman y las varianzas (σ²) se suman; la σ del camino es la raíz de esa suma (suponiendo actividades independientes). Por eso la σ total crece más despacio que la suma de σ: los errores de unas actividades compensan en parte los de otras.

Matiz importante: la suposición de independencia es optimista. En software, si una cosa sale mal (el proveedor de GPS no cumple) suele arrastrar a varias. Por eso la simulación Monte Carlo (lección 13) es más realista para riesgo global.

4. El cono de incertidumbre

"Cuanto más lejano es el trabajo, mayor incertidumbre" (diap. 61) tiene una forma conocida. Barry Boehm la midió en los años 80 y McConnell la popularizó como cono de incertidumbre: el error de una estimación es enorme al principio y se estrecha a medida que se toman decisiones.Ampliación. Boehm (1981); McConnell (2006), cap. 4. Construx · The Cone of Uncertainty.

Tres lecturas para un gestor:

1. Una estimación temprana es necesariamente un rango amplio. Si en la RFP de TusBus te piden "una cifra", lo honesto es dar un rango y explicar qué decisiones lo estrecharán. Un "18 semanas" el primer día es falsa precisión.
2. El cono no se estrecha solo con el paso del tiempo, sino con las decisiones que eliminan variabilidad (cerrar requisitos, elegir arquitectura, hacer un prototipo de la integración GPS). Un proyecto que no decide sigue en la boca ancha del cono aunque pasen meses.
3. El cono es el mejor caso. Representa lo que consiguen estimadores expertos; con malas prácticas el error es mayor, nunca menor.

Esto conecta con todo lo anterior: justifica la planificación gradual (rolling wave, lección 9), los ciclos de vida iterativos (lección 7: cada iteración aporta información real) y reducir la incertidumbre cuanto antes (lección 3), sobre todo la que más impacto tiene.

5. Por qué las estimaciones salen cortas

La desviación casi siempre va en el mismo sentido: nos quedamos cortos. Causas conocidas:

• Sesgo optimista / falacia de la planificación: tendemos a imaginar el caso en que todo sale bien, aunque sepamos que en proyectos pasados no fue así.Kahneman, D. y Tversky, A. (1979), "planning fallacy". Ver Planning fallacy. Remedio: la vista externa: mirar cuánto tardaron de verdad proyectos parecidos (analogía con datos) en vez de imaginar el nuestro.
• Trabajo olvidado: se estima programar, pero no las reuniones, la integración, las pruebas, el despliegue, la documentación, las vacaciones. La EDT con regla del 100 % es el antídoto.
• Anclaje: si alguien dice "esto son dos semanas, ¿no?" antes de estimar, todas las estimaciones se acercan a dos semanas. Por eso se estima por separado (Delphi, planning poker).
• Presión: se ajusta la estimación a lo que el cliente quiere oír (confundir estimación con objetivo).
• Ley de Parkinson: "el trabajo se expande hasta llenar el tiempo disponible". Si das holgura a cada tarea, se consume; por eso la reserva se gestiona a nivel de proyecto, no repartida en cada tarea (lección 13).
• Síndrome del estudiante: empezar tarde porque "hay tiempo", y quemar el margen al principio.
• Ley de Hofstadter, medio en broma: "siempre tarda más de lo que esperas, incluso teniendo en cuenta la ley de Hofstadter".

6. Buenas prácticas

1. Estima en rangos (o con tres puntos) y di el nivel de confianza.
2. Documenta los supuestos de la estimación ("suponiendo que el ayuntamiento da acceso a la API de GPS en la semana 3"). Si el supuesto cae, la estimación se revisa (lección 3: supuestos = riesgos latentes).
3. Estima quien hace el trabajo, o al menos participa. Una estimación impuesta no compromete a nadie.
4. Usa datos históricos: registra estimado frente a real en cada proyecto.
5. Re-estima cuando cambia la información; el plan se actualiza (diap. 61).
6. Separa estimación y reserva: la estimación es la mejor predicción; la incertidumbre se cubre con reservas explícitas, no inflando cada tarea a escondidas ("estimación ≠ presupuesto ≠ coste real": las reservas son lo que va de una a otro, lecciones 13 y 14).

Práctica

Repaso espaciado · lecciones 4, 7, 9

Para profundizar

Resúmenes imprimibles: Fórmulas · Glosario.