Estimación de desarrollo de software: cómo leer el número
Tu desarrollador devolvió un número. Estas son las cuatro preguntas que lo convierten de nuevo en el rango que realmente es.
El correo tenía cuatro líneas. Un saludo, un gracias por la llamada, y luego el número: 12 semanas, 180.000 dólares. El founder nos lo reenvió con una pregunta encima. “¿Esto está bien?”
La estimación de desarrollo de software es la práctica de predecir cuánto tiempo y cuánto dinero costará construir un software. Lo que llega a tu bandeja de entrada, sin embargo, no es una predicción. Es un rango que alguien aplastó hasta convertirlo en un número único, porque un número único fue lo que pediste. Todo lo que sirve vive en el rango que tiraron a la basura.
El founder en cuestión, exdirector de operaciones de un hospital construyendo un producto de agendamiento para clínicas privadas, no sabía leer ese número. La mayoría de la gente con la que trabajamos tampoco, y no es un fallo de inteligencia. Es que toda guía escrita sobre estimación de desarrollo de software está escrita para quien produce la estimación. Busca el término y encontrarás nueve artículos enseñando a ingenieros a dimensionar una tarea y ninguno enseñando a un CEO qué preguntas vuelven honesto el número.
Este es el otro tipo de artículo.
Qué es realmente una estimación de software
Tres objetos distintos reciben el nombre de “estimación”, y confundirlos es donde muere la mayor parte del dinero.
Está el cálculo al vuelo, ofrecido en una llamada por alguien que conoce tu problema desde hace cuarenta minutos. Está el presupuesto, producido después de que un equipo leyó tus requisitos y discutió sobre ellos. Y está la promesa, el número que un proveedor tendrá que sostener y que, por lo tanto, defenderá en cada conversación que tengas durante los próximos seis meses.
Llegan en la misma tipografía. Significan cosas completamente distintas.
Debajo de los tres opera la misma maquinaria: alguien parte el trabajo en piezas, dimensiona cada pieza y suma. El dimensionamiento puede ir en días, en story points, en tallas de camiseta. La unidad te importa poco. Lo que importa es que cada una de esas piezas se dimensionó bajo incertidumbre, y la incertidumbre no sobrevivió a la suma.
Por qué la estimación de desarrollo de software siempre produce un rango, y por qué el rango queda escondido
Steve McConnell dedicó una carrera a medir cuánto se equivocan las estimaciones de software, y el resultado tiene nombre: el Cono de la Incertidumbre. Al principio de un proyecto, en el punto en que hay un concepto acordado pero ningún detalle decidido, las estimaciones hechas por estimadores expertos pueden errar por un factor de cuatro hacia arriba y un factor de cuatro hacia abajo. Son dieciséis veces de diferencia entre el extremo pesimista y el optimista. No porque el estimador sea malo. Porque el proyecto todavía no está decidido.
El cono se estrecha a medida que el proyecto avanza, y la mayor parte de ese estrechamiento ocurre en el primer 20% o 30% del calendario. Pero aquí está lo que los founders se equivocan sistemáticamente: no se estrecha porque el equipo se esfuerce más. Se estrecha porque se toman decisiones. La variabilidad de la estimación es reflejo directo de la variabilidad del proyecto. En palabras de McConnell, “no es posible ser más preciso; solo es posible tener más suerte.”
Lo cual produce la frase más útil de este texto:
No puedes negociar una estimación a la baja. Solo puedes decidir menos cosas sobre las que ella tenga que ser incierta.
Todo founder que alguna vez presionó un presupuesto ha sentido al proveedor “afilar el lápiz” y volver un 15% más barato. Entre una cosa y otra no se aprendió nada. No se tomó ninguna decisión. La incertidumbre no se fue a ninguna parte. Simplemente se reasignó, en silencio, del margen del proveedor a tu fecha de lanzamiento.
¿Cuáles son los cuatro tipos de estimación?
La mayoría de los artículos ordena las estimaciones por técnica: análoga, paramétrica, de tres puntos, bottom-up. Esa taxonomía es para quien estima. Esta es la tuya, ordenada por aquello a lo que el número realmente te compromete.
El cálculo al vuelo. Un orden de magnitud, no un número. Se ofrece desde la experiencia antes de que nadie haya leído nada. Su única función honesta es responder “¿tiene sentido siquiera esta conversación?”. Como carga el rango completo de dieciséis veces, es inservible para planificar y peligroso dentro de un board deck.
El presupuesto. Producido tras un discovery real, en el que alguien interrogó tus requisitos y encontró las partes en las que no habías pensado. Es contra este que planificas. Debería llegar como un rango. Si llegó como un punto, alguien redondeó por ti.
El compromiso. Aquello por lo que el equipo responderá de verdad. Solo es honesto una vez que se ha decidido lo suficiente como para estrechar el cono, lo que en la práctica significa después de que una parte del trabajo ya empezó.
El precio de contrato. Un número con consecuencias legales. Contiene una prima de riesgo, y esa prima la pagas se materialice el riesgo o no. Aquí la estimación deja de ser aritmética y se convierte en posición de negociación, y por eso el número de una declaración de trabajo nunca es el número de la primera llamada.
No son cuatro técnicas. Son cuatro niveles de promesa. Y el movimiento fatal, que vemos hacer a los founders constantemente, es tratar un cálculo al vuelo como si fuera un precio de contrato y luego sentirse traicionado cuando aparece la realidad.
Las cuatro preguntas que devuelven el rango
Cuando llega un número, tienes una ventana corta en la que hacer preguntas duras todavía es normal y todavía no es hostilidad. Úsala. Estas cuatro preguntas trabajan más que cualquier regateo.
1. “¿Cuál es el peor caso, y qué tiene que salir mal para llegar ahí?”
Los mejores estimadores ya llevan esa cuenta. Jacob Kaplan-Moss, cocreador de Django y autor de la guía práctica más clara sobre capturar la incertidumbre junto con el tiempo, sostiene que cualquier estimación que valga algo carga las dos cosas. “Diez a quince días” te dice algo que “diez días” esconde activamente.
Si tu proveedor no puede producir un peor caso, no lo ha pensado, y acabas de aprender gratis algo caro.
2. “¿De qué línea eres el que menos seguro estás?”
La varianza casi nunca se reparte de forma uniforme por un proyecto. Se concentra. Una tarea, normalmente la que nadie ha hecho antes, explica la mayor parte de la dispersión del plan entero. Encuentra esa tarea y habrás encontrado tu riesgo real, junto con el único lugar donde gastar dinero temprano tiene retorno de verdad.
En el agendador para clínicas nunca fue el calendario de citas. Fue la verificación de cobertura del seguro, una integración con un sistema cuya documentación era un PDF de 2016.
3. “¿Qué asumiste que yo tendría listo, y para cuándo?”
Enterrado en toda estimación hay un conjunto de supuestos sobre ti. Que aprobarás los diseños en dos días y no en dos semanas. Que conseguirás las credenciales de tu proveedor de pagos. Que decidirás el modelo de precio antes de que se construyan las pantallas de cobro. Que encontrarás una clínica real dispuesta a probar con pacientes reales.
En nuestra experiencia, la causa más común de una fecha incumplida no es la ingeniería. Es un founder que además lleva ventas, fundraising y contratación, y que ahora es el cuello de botella de once decisiones que nadie le dijo que eran suyas.
4. “¿Qué no está dentro de este número?”
Pregúntalo sin rodeos. La migración de los datos de la hoja de cálculo que todos siguen usando. Las herramientas de admin para el equipo de operaciones. La segunda ronda de revisiones de diseño. Las pruebas de carga. La revisión de la app store. Dos semanas de corrección de bugs después del lanzamiento, que no son opcionales y nunca aparecen en la estimación.
Todo lo que no se diga se convierte más tarde en una solicitud de cambio, a un precio que nadie negoció bajo presión competitiva.
¿Qué es la regla del 80/20 en el desarrollo de software?
La gente lo busca, así que respondamos y luego corrijámoslo.
La versión que los ingenieros se cuentan entre ellos es la de Tom Cargill, de Bell Labs, y es más graciosa y más cierta: el primer 90% del código se lleva el 90% del tiempo, y el 10% restante del código se lleva el otro 90% del tiempo.
Es un chiste sobre un fenómeno real. El software llega a parecer terminado mucho antes de estarlo. La demo de la sexta semana es preciosa. Se mueve, hace clic, hace que tu board se incline hacia adelante. Lo que no hace es manejar a dos recepcionistas compartiendo un mismo login y agendando dos pacientes en la misma cita de las 15h. Ni un pago con tarjeta rechazado. Ni un paciente que cancela dos veces y aun así recibe la factura. Ni los treinta estados tediosos que hay entre el “camino feliz” y la producción.
Esa distancia entre la demo y lo terminado es donde van a morir las estimaciones, y es la razón por la que un proveedor que te enseña algo impresionante en la semana seis y luego se queda callado no está necesariamente retrasado. Puede que simplemente haya llegado al trabajo de verdad.
Cómo estimar el costo de un software cuando eres tú quien paga
No lo pronosticas. Lo acotas. Tres movimientos, en orden de cuánto valen.
Compra una decisión, no un descuento. Si una línea concentra la mayor parte de la incertidumbre, paga por una investigación corta y con plazo cerrado de exactamente esa cosa antes de comprometerte con la obra completa. Dos semanas pagadas sobre la integración del seguro salen dramáticamente más baratas que la prima de riesgo que pagarías en un precio cerrado de doce semanas, y más baratas todavía que descubrir el problema en la semana nueve.
Presupuesta el peor caso, planifica con el caso esperado. Toma el rango en serio en ambas direcciones. Pon el número pesimista en el modelo que enseñas a tu board. Opera la empresa contra el esperado. Un founder que ya le contó el número optimista a sus inversores se ha quitado a sí mismo la capacidad de tomar buenas decisiones más adelante.
Entiende qué le hace el modelo de precio a la sala. El precio cerrado te compra certeza y la pagas dos veces: una en la prima de riesgo metida dentro del número, y otra en un socio que ahora gana dinero cada vez que te dice que no. Time and materials suele salir más barato en total y exige que prestes atención de verdad. Ninguno de los dos es correcto en abstracto. Hemos escrito aparte sobre qué es lo que mueve el precio de una aplicación, y la versión corta es que la variable grande nunca fue la tarifa por hora.
Cuando el número es más grande que el presupuesto
El primer instinto de casi todo founder es empujar el número. Es la palanca equivocada, y es la que con más probabilidad produce un proveedor que dice que sí y un proyecto que se pudre en silencio.
Empuja las decisiones. Cada hora de incertidumbre de la estimación está pegada a algo que nadie ha decidido todavía, y tú tienes permiso para decidirlo. Corta lo que no puedas defender. Aplaza la integración que sirve al 8% de los usuarios. Lanza la versión que funciona para una clínica en lugar de la que funciona para todas. Estrechar el alcance de proyecto es el único movimiento que hace el número más pequeño sin mover el dolor a un sitio donde no puedes verlo.
El agendador pasó de doce semanas a siete. No porque nadie afilara ningún lápiz, sino porque la integración de facturación con el seguro, la fuente de incertidumbre más gorda del plan, salió de la v1 y fue reemplazada por una exportación en CSV que una persona ejecutaba los viernes. Era feo. Salió a tiempo para el cliente ancla. La integración se construyó cuatro meses más tarde, bien hecha, por un equipo que para entonces ya sabía cómo eran los datos en realidad.
La pregunta que hay que hacer en su lugar
“¿Esto está bien?” no tiene respuesta, y los founders que la hacen suelen estar esperando que alguien los absuelva de una decisión que es genuinamente suya.
La versión que sí tiene respuesta es esta: ¿qué es lo que todavía no saben, y cuánto me va a costar averiguarlo? Una estimación que no puede responder eso no es una estimación. Es un deseo con decimales.
Preguntas frecuentes sobre estimación de desarrollo de software
¿Qué es la estimación en el desarrollo de software?
Es la práctica de predecir el esfuerzo, el tiempo y el costo necesarios para construir un software. El resultado es genuinamente un rango, porque el trabajo todavía no está del todo decidido. Cuando recibes un número único en lugar de un rango, alguien ha tomado por ti la decisión de qué extremo de ese rango mostrarte.
¿Qué tan precisas son las estimaciones de software?
Las tempranas se equivocan muchísimo, y esto está medido, no es anecdótico. En la fase de concepto, las estimaciones hechas por estimadores expertos cargan un error de aproximadamente cuatro veces en cada dirección. La precisión mejora a medida que se toman decisiones y el alcance deja de moverse, no a medida que el estimador se concentra más.
¿Cómo estimo el costo de un software siendo un founder no técnico?
No lo estimas. Lo acotas. Pide un caso esperado y un peor caso, presupuesta contra el peor caso, identifica la única línea que concentra más incertidumbre y paga por una investigación corta y con plazo cerrado solo de eso antes de comprometerte con la obra completa.
¿Qué debo preguntar cuando recibo una estimación de software?
Cuatro cosas: cuál es el peor caso y qué lo provoca, de qué línea el equipo está menos seguro, qué asume la estimación que tú vas a entregar y para cuándo, y qué se ha excluido deliberadamente del número.
¿Por qué los proyectos de software siempre se pasan de plazo?
Normalmente no porque la ingeniería fuera lenta. Porque el alcance siguió moviéndose, porque decisiones que le tocaban al founder llegaron tarde, o porque trabajo que todos asumían incluido (migración de datos, herramientas de admin, corrección de bugs post-lanzamiento) nunca estuvo dentro del número.