«¿Cuánto sale?» es la primera pregunta de todo proyecto de software y la más difícil de contestar bien. Un número redondo en la primera reunión tranquiliza, pero casi siempre es una apuesta: o está inflado para cubrir lo que nadie sabe todavía, o se queda corto y la diferencia aparece después, en forma de recortes, demoras o discusiones. Esta guía explica cómo se estima un proyecto de software de verdad, qué riesgos hay que mirar y por qué un presupuesto cerrado suele fallar justo cuando más importa.
Por qué es tan difícil estimar software
Construir software no es como construir una casa con planos terminados. Al empezar, buena parte de lo que hay que hacer todavía no está decidido: cómo se calcula un precio especial, qué pasa con un pedido que se anula a medias, qué datos devuelve el sistema de facturación con el que hay que conectarse. Cada una de esas respuestas cambia el trabajo.
En ingeniería de software esto tiene nombre: el cono de la incertidumbre, descripto por Barry Boehm y popularizado por Steve McConnell. Al principio de un proyecto, una estimación puede errarle hasta cuatro veces para arriba o para abajo; el margen se achica a medida que se toman decisiones y se construye. No es falta de experiencia de quien estima: es que la información todavía no existe.
Qué se estima (y qué suele quedar afuera)
Las pantallas son la parte visible, pero rara vez la más cara. Una estimación seria mira todo esto:
- Funcionalidades: qué tiene que poder hacer cada tipo de usuario.
- Reglas de negocio: cálculos, excepciones, aprobaciones. Suelen ser lo que más horas lleva.
- Integraciones: facturación, bancos, e-commerce, el sistema que ya tenés. Dependen de terceros y son el riesgo número uno.
- Datos: qué hay que migrar de planillas o sistemas viejos y en qué estado está.
- Lo que no se ve: pruebas, seguridad, permisos, servidores, puesta en marcha, capacitación y documentación.
Un presupuesto que sólo lista pantallas está dejando afuera, como mínimo, la mitad del trabajo.
Cómo se estima: cinco pasos
1. Un relevamiento corto, antes del número
Antes de estimar hay que entender el proceso: quién usa el sistema, qué hace hoy, con qué planillas, qué se conecta con qué y qué es imprescindible desde el primer día. Unas pocas reuniones con las personas que hacen el trabajo ahorran semanas de supuestos equivocados.
2. Partir el proyecto en piezas chicas
«Un sistema de pedidos» no se puede estimar; «alta de clientes», «carga de pedidos» o «cálculo de precios» sí. Cuanto más chica la pieza, menos se le erra. Las piezas que no se pueden achicar porque todavía no se entienden son una señal: ahí está el riesgo.
3. Estimar con rangos, no con un número
Cada pieza lleva tres valores: el mínimo si todo sale bien, el probable y el máximo si aparecen los problemas que ya se sospechan. Una técnica clásica para combinarlos es la estimación de tres puntos de PERT: (mínimo + 4 × probable + máximo) / 6. Lo importante no es la fórmula, sino que el rango muestra dónde está la duda: una pieza de 32 a 96 horas pide más atención que una de 16 a 32.
4. Escribir los supuestos y los riesgos
Toda estimación descansa en supuestos: «hasta tres listas de precios», «el sistema de facturación tiene una API documentada», «los datos iniciales vienen en Excel». Escribirlos convierte una discusión futura en una conversación simple: si un supuesto cambia, la estimación de esa pieza cambia, y los dos lados lo saben desde el principio.
5. Empezar por una etapa chica y volver a estimar
La mejor forma de achicar el cono de la incertidumbre es construir. Una primera etapa acotada, con lo imprescindible, pone el sistema en manos de usuarios reales y da datos concretos: cuánto se tardó de verdad, qué apareció que nadie había previsto. Con eso, la estimación del resto es mucho más precisa.
En el caso de las órdenes de trabajo para técnicos de climatización, la app arrancó con una sola familia de equipos y seis técnicos; el resto de los equipos y de las personas entró por etapas. En el caso de la planilla de tráfico convertida en sistema, el proyecto se organizó en seis meses de trabajo con entregas parciales, no en una sola entrega final.
Por qué fallan los presupuestos cerrados
Un precio cerrado parece la opción más segura para quien contrata: se sabe cuánto se paga y el riesgo queda del lado del proveedor. En la práctica pasa otra cosa:
- Se paga la incertidumbre por adelantado. Quien cotiza cerrado tiene que cubrirse del peor caso, así que el número incluye un colchón que se paga aunque nada salga mal.
- El alcance se congela cuando menos se sabe. Lo que se firma al principio es la versión del sistema con menos información de todo el proyecto.
- Cada cambio es una negociación. Cualquier mejora que aparece al usar el sistema pasa a ser «fuera de alcance», y el proyecto se llena de discusiones en lugar de avances.
- Si el colchón no alcanza, se recorta calidad. Las pruebas, la documentación y la prolijidad del código son lo primero que se sacrifica, y eso se paga después en mantenimiento.
Un precio cerrado sí funciona cuando el alcance es chico, conocido y difícil de cambiar: una integración puntual, un módulo bien definido, una migración de datos con origen y destino claros.
Alternativas que funcionan
- Precio por etapas. Se cierra el precio de la primera etapa, que es la que mejor se conoce, y cada etapa siguiente se estima con lo aprendido.
- Horas contratadas con tablero a la vista. Se acuerda una bolsa de horas por etapa y el cliente ve en todo momento cuántas se consumieron y en qué.
- Cambios de alcance estimados antes de hacerse. Cada pedido nuevo se registra, se estima su impacto en horas y en fechas, y se aprueba o se rechaza antes de empezar. Nada se suma en silencio.
Con este esquema, el presupuesto deja de ser una apuesta de una sola vez y pasa a ser una herramienta de gestión: se sabe cuánto se gastó, cuánto falta y qué decisiones movieron el número.
Cómo leer un presupuesto de software
Antes de comparar números entre proveedores, conviene revisar que cada presupuesto tenga esto:
- Un desglose por funcionalidad, no un único total.
- Los supuestos escritos y lo que no incluye.
- Pruebas, puesta en marcha y capacitación como ítems propios.
- Cómo se manejan los cambios de alcance.
- Qué pasa después de la entrega: garantía, soporte y mantenimiento.
Un presupuesto mucho más barato que el resto rara vez es una ganga: casi siempre está dejando algo afuera. Si todavía estás decidiendo si te conviene desarrollar o contratar un producto existente, mirá software a medida vs SaaS.
Qué llevar a la primera reunión
- Cómo se hace hoy el proceso, con las planillas o sistemas que se usan.
- Quiénes van a usar el sistema y cuántos son.
- Con qué otros sistemas tiene que conectarse.
- Qué es imprescindible para el primer día y qué puede esperar.
- Si hay una fecha límite, el motivo (una temporada, un vencimiento legal, un contrato).
- Un presupuesto de referencia, aunque sea un rango: ayuda a proponer una primera etapa que entre.
Errores comunes
- Pedir un número antes de explicar el proceso. El número que se obtiene es un promedio de supuestos.
- Elegir sólo por precio. Se termina comparando presupuestos que no cubren lo mismo.
- Querer todo en la primera versión. Alarga el proyecto y posterga el momento en que el sistema empieza a servir.
- No dejar escritos los supuestos. Después nadie recuerda qué estaba incluido.
- Tratar la estimación como una promesa. Es la mejor predicción con lo que se sabe hoy; tiene que actualizarse cuando se sabe más.
Cómo te ayudamos desde Intway
Trabajamos por etapas: un relevamiento corto, una estimación por funcionalidad con rangos y supuestos escritos, y una primera etapa acotada que pone el sistema a funcionar rápido. En los proyectos por horas, ves las horas consumidas y cada cambio de alcance se estima y se aprueba antes de hacerse. Mirá cómo encaramos un software a medida para pymes, un ERP a medida o la ampliación de tu equipo de desarrollo.