La conversación va siempre igual. Un gerente llega con un Excel o una descripción de tres líneas y dice: “necesito un sistema para esto, ¿cuánto me sale?”
Y yo tengo que hacer la pregunta que incomoda: ¿me estás describiendo el problema o la solución?
La diferencia importa más que el precio. Y confundirlas es, con diferencia, el error más caro que cometen las empresas al contratar desarrollo de software a medida en Chile.
Error número uno: pedir precio sin definir el problema
El Standish Group publica cada año el CHAOS Report, el estudio más largo sobre proyectos de software. El dato central no cambia mucho: alrededor del 66% de los proyectos falla o se sale del presupuesto. La causa más frecuente no es el proveedor malo ni la tecnología equivocada. Es el alcance sin definir.
En la práctica se ve así: el cliente llega con una idea, el proveedor cotiza lo que entendió, se firma el contrato y arranca el proyecto. La primera semana aparece algo “obvio” que ninguno de los dos escribió. La segunda semana, otro. Al mes hay una lista de funciones “que estaban implícitas” que nadie presupuestó.
Eso es scope creep. No es un accidente de mala fe: es la consecuencia natural de no haber definido el problema antes de diseñar la solución.
¿Cuánto cuesta? El sobrecosto promedio en proyectos que se rescatan está entre el 89% y el 200% del presupuesto inicial. Un proyecto que empezó en 400 UF puede terminar costando 700 u 800. Sin contar el tiempo interno del equipo del cliente ni la oportunidad de negocio perdida mientras el sistema no estaba listo.
La raíz es que los proveedores tienen incentivos para decir que sí. El que hace demasiadas preguntas antes de cotizar parece difícil. El que entrega un número rápido parece eficiente. Solo que ese número no cubre lo que el cliente asume que cubre.
El antídoto es simple: antes de cotizar, definir el problema. No el sistema. ¿Qué proceso de tu negocio está fallando? ¿Cuánto te cuesta ese fallo por mes? ¿Cómo se ve el éxito en seis meses? Las respuestas a esas tres preguntas valen más que cualquier lista de pantallas.
Error número dos: elegir por precio mínimo
El segundo error es consecuencia directa del primero. Si el problema no está bien definido, no puedes comparar propuestas: estás comparando lo que cada proveedor imaginó, no lo que tú necesitas.
En ese escenario, el criterio que termina ganando es el precio. Y el precio mínimo casi siempre gana por una razón simple: el proveedor barato cotizó menos porque prometió menos sin decírtelo.
Lo que pasa después es predecible. El proyecto arranca, aparecen los “fuera de alcance”, las horas extra se acumulan y el cliente termina pagando más del doble con menos control sobre el resultado. O peor: recibe el software prometido, que resulta que no resuelve el problema real.
No digo que lo caro sea necesariamente mejor. Digo que una propuesta que no desglosa el alcance por partidas —módulos, integraciones, entornos, pruebas, documentación, mantención— no te permite saber qué estás comprando. Y si no puedes saber qué estás comprando, el precio es el único criterio que queda, y es el peor.
La pregunta correcta no es “¿cuánto cuesta?” sino ¿qué incluye exactamente esta propuesta y qué no incluye?
Si el proveedor se incomoda con esa pregunta, ya tienes una respuesta.
Error número tres: firmar sin alcance escrito
El tercer error parece burocrático pero es el más fácil de evitar.
Contratar un desarrollo sin un documento de alcance firmado es un cheque en blanco. El cliente asume que todo lo que se mencionó en las reuniones está incluido. El proveedor asume que solo está incluido lo que cotizó. Cuando los supuestos divergen —y siempre lo hacen— la discusión es sobre interpretaciones, no sobre hechos.
Un buen documento de alcance no necesita ser extenso. Necesita responder cuatro cosas:
- Qué problema resuelve (en lenguaje de negocio, no técnico)
- Qué módulos o funciones están incluidas (lista explícita)
- Qué integraciones se desarrollarán (con qué sistemas existentes)
- Qué no incluye esta versión (igual de importante que lo que sí incluye)
Ese documento sirve de base para la propuesta, para el contrato y —sobre todo— para resolver sin discusiones cualquier “¿esto estaba incluido?” que aparezca durante el proyecto.
La sesión de scoping existe exactamente para construir ese documento. Es una reunión de trabajo donde mapeamos el problema real, los flujos, las integraciones y los criterios de éxito antes de cotizar. No es un costo extra: es lo que hace posible que la cotización sea precisa.
Las 5 preguntas que deberías hacer antes de firmar
Independientemente del proveedor que elijas, estas cinco preguntas te permiten evaluar si una propuesta está bien definida:
1. ¿Qué proceso específico de mi negocio resuelve este software? Si la respuesta es genérica —“optimizar operaciones”, “digitalizar procesos”— el alcance no está claro. La respuesta correcta nombra un flujo concreto y un resultado medible.
2. ¿Cómo sabemos que funcionó? ¿Qué se mide? Un proyecto sin KPIs no tiene criterio de éxito. Puedes recibir el software “terminado” y que no sirva para nada. Fuerza al proveedor a nombrar métricas antes de empezar.
3. ¿Qué integraciones con sistemas existentes están incluidas? Las integraciones son casi siempre el ítem más subestimado en una cotización. Una integración de sistemas que conecta con un ERP, un CRM o una pasarela de pago puede representar el 30% o más del costo total. Si no aparece en la propuesta, pregunta por qué.
4. ¿Qué explícitamente NO incluye esta propuesta? Esta pregunta incomoda a los proveedores que cotizaron de forma vaga. Un proveedor serio puede responderla de inmediato porque escribió el alcance con esa precisión. Si la respuesta es “buena pregunta, lo revisamos”, es una señal.
5. ¿Cómo manejamos los cambios de alcance durante el proyecto? Los cambios son inevitables. La pregunta no es si van a aparecer, sino si hay un proceso para manejarlos. Sprints semanales con demos y un proceso formal para incorporar cambios al alcance protegen tanto al cliente como al proveedor.
Si el proveedor no tiene respuestas claras a estas cinco preguntas, no es necesariamente deshonesto: es que el proyecto todavía no está listo para empezar.
El costo de equivocarse vs. el costo de hacer bien el scoping
Una sesión de scoping de dos horas puede parecer un paso extra cuando hay urgencia para arrancar. Entiendo esa urgencia: el proyecto lleva meses esperando y hay presión para moverse.
Pero el cálculo es simple. Si el scoping evita que un proyecto de 500 UF se salga en un 40% por scope creep, ahorraste 200 UF. Si el scoping muestra que el problema estaba mal planteado y reformula el alcance antes de construir lo que no se necesitaba, el ahorro puede ser el proyecto completo.
En proyectos que llegan con problema mal definido, usamos IA para acelerar el diagnóstico y la documentación del alcance: en un día mapeamos flujos, identificamos integraciones y generamos el documento base que antes tomaba una semana. La velocidad no reemplaza la claridad, pero reduce el costo de conseguirla. Es la misma lógica que aplicamos en el desarrollo de software: la IA absorbe las partes repetitivas para que el tiempo de ingeniería se concentre en el problema real.
El diagnóstico que hacemos antes de cotizar no es un paso de ventas. Es la diferencia entre cotizar lo que pediste y construir lo que necesitas.
Preguntas frecuentes
¿Qué es el scope creep y por qué multiplica el costo del software?
Scope creep es cuando el alcance del proyecto crece sin que el presupuesto o el plazo crezcan al mismo ritmo. Pasa cuando el problema no estaba bien definido antes de empezar: cada semana aparece algo “obvio” que nadie escribió y el proveedor cobra horas extra. En proyectos sin alcance cerrado, el costo real puede ser 2 a 3 veces el presupuesto inicial.
¿Cómo sé si una propuesta de software está bien definida?
Una propuesta seria describe el problema de negocio que resuelve, los módulos o funciones exactas incluidas, lo que explícitamente no incluye, las integraciones con sistemas existentes y cómo se miden los criterios de aceptación. Si solo lista pantallas o menciona tecnología sin definir el problema, falta la mitad.
¿Qué es una sesión de scoping y para qué sirve?
Es una reunión de trabajo —típicamente 1 a 2 horas— donde el equipo técnico y el cliente mapean el problema real, los flujos de negocio, las integraciones y los criterios de éxito antes de cotizar. El resultado es un alcance escrito que sirve de base para la propuesta y el contrato. Evita el error más común: cotizar sin entender el problema.
¿Cuánto cuesta equivocarse al contratar software?
Según el Standish Group CHAOS Report, dos tercios de los proyectos de software fallan o se salen del presupuesto. El sobrecosto promedio en proyectos que se rescatan está entre el 89% y el 200% del presupuesto original. Eso sin contar el tiempo interno del equipo del cliente, los plazos perdidos ni la oportunidad de negocio que no llegó.
¿Cuáles son las señales de alerta de un proveedor de software?
Cinco señales: cotiza sin hacer preguntas, no desglosa el alcance por partidas, promete plazo y precio fijo sin un levantamiento previo, no tiene ejemplos de proyectos terminados en producción y no habla del proceso post-entrega. Una buena señal: dice “no” a algo que pediste porque no tiene sentido para el problema que describiste.
¿Tienes un proyecto en mente? Agenda una sesión de scoping sin costo. Salís con el alcance por escrito, un rango de inversión realista y claridad sobre qué conviene hacer primero.