Estimar proyectos de software sin mentirle al cliente

Las estimaciones no fallan por optimismo, fallan por presentarse como una sola fecha. Cómo estimamos por rangos y fases.

Toda empresa de desarrollo tiene una historia de un proyecto que se estimó en tres meses y tomó nueve. La nuestra también. Lo que cambió no fue que aprendiéramos a adivinar mejor, sino que dejamos de presentar las estimaciones como si fueran predicciones.

Una fecha única es una mentira estadística

Cuando alguien dice "esto toma seis semanas", en realidad quiere decir "si todo sale bien, seis semanas; si hay complicaciones normales, entre ocho y diez". La segunda frase es honesta y la primera es la que se pone en el contrato.

Nosotros entregamos siempre tres números: el escenario optimista, el probable y el pesimista, con la lista de supuestos de cada uno. El cliente decide con qué número planea.

Estima fases, no proyectos

La precisión de una estimación cae en picada después de la sexta semana. Por eso cotizamos con detalle solo la fase siguiente y con rango amplio el resto del proyecto. Al terminar cada fase, la siguiente se re-estima con información real.

• Fase 1 (diagnóstico): precio cerrado, siempre. Es corta y bien acotada.
• Fase 2 (primer bloque funcional): precio cerrado, estimado con el conocimiento del diagnóstico.
• Fases posteriores: rango, refinado al cierre de cada fase anterior.

El cliente no odia la incertidumbre. Odia enterarse de la incertidumbre en el mes cinco.

Registra los supuestos por escrito

La mayoría de los desfases no vienen del desarrollo, vienen de dependencias: el acceso al sistema legado que tardó seis semanas, la definición de negocio que nadie podía autorizar, el proveedor externo que no respondía.

Anota cada supuesto en la propuesta con su responsable y su fecha límite. Cuando uno se incumple, la conversación sobre el desfase es un dato, no una discusión.