Scope creep: por qué tu proyecto de software se infla y quién paga la cuenta
Una guía para el founder no técnico sobre qué es el scope creep, por qué ocurre en todo desarrollo tercerizado y cómo evitar que cada “solo una cosita más” reviente tu plazo y tu presupuesto.
Un founder de una fintech firmó un contrato de precio cerrado para su MVP. Tres meses de plazo, monto acordado, apretón de manos. En la segunda semana pidió una pantalla de reportes que “no estaba en el alcance, pero es rápida”. En la quinta, una integración con una pasarela de pagos. Al mes siguiente, un panel de administración “que todos tienen”. Cada pedido parecía pequeño por separado. Ninguno lo era. El lanzamiento se retrasó dos meses, el presupuesto casi se duplicó y la relación con la software house se deterioró. Nadie mintió. El alcance simplemente se fue de las manos.
Eso es scope creep, y la mayor parte de lo que se escribe al respecto lo trata como un problema de gestión de proyectos de quien dirige un equipo interno. Para un founder que compra software por fuera, el problema es otro y mucho más concreto.
El scope creep (o desviación del alcance) es el crecimiento gradual e incontrolado del alcance de un proyecto después de que ya empezó: funcionalidades, pantallas y pedidos que se van sumando sin que nadie revise plazo, costo o prioridad, hasta que el producto ya no se parece a lo acordado. No es el equipo externo siendo codicioso. No eres tú siendo indeciso. Es el resultado previsible de empezar a construir antes de cerrar el alcance y antes de que exista un proceso para cambiarlo.
Por qué todo proyecto se infla
El scope creep es la regla, no la excepción. La encuesta Pulse of the Profession del PMI mostró que más de la mitad de los proyectos lo sufre, una proporción que solo creció con los años: “52% de los proyectos sufrieron scope creep”, frente al 43% de cinco años antes. Si más de la mitad de los proyectos dirigidos por gerentes profesionales se infla, el tuyo, llevado por alguien que está aprendiendo a comprar software sobre la marcha, no es una anomalía. Es el caso base.
La razón es que el alcance de un software es más fácil de imaginar que de cerrar. Cuando describes el producto en una reunión, cada persona llena los espacios en blanco con una versión distinta del mismo sistema. Tú imaginas un registro simple; el desarrollador imagina un flujo con validación, recuperación de contraseña y niveles de permiso. Los dos creen que acordaron lo mismo. La diferencia solo aparece cuando el código ya se está escribiendo, y para entonces cada aclaración es, en la práctica, un pedido nuevo.
Súmale que aprendes sobre tu propio producto mientras se construye. La primera pantalla funcionando te da ideas que no tenías en el brief. Esas ideas son legítimas, a veces las mejores del proyecto. El problema nunca es tener la idea. El problema es inyectarla en medio del desarrollo como si fuera gratis.
Las tres puertas por las que entra el alcance
El scope creep no viene de un solo lado. Entra por tres puertas distintas, y cada una se cierra de un modo diferente.
La primera es la tuya. Es el “solo una cosita más” que pides porque parece trivial. Casi nunca lo es. Una pantalla de más suele significar un endpoint nuevo, un estado nuevo en la base de datos, un caso de error nuevo y una cosa más para testear. El costo que no ves es mayor que el que ves.
La segunda puerta es la de un alcance mal definido al principio. Cuando lo acordado fue vago (“una app de agendamiento”), todo lo que aparece después puede clasificarse honestamente como “siempre estuvo en el alcance” o “esto es nuevo”, según quién hable. Sin un documento que diga qué está dentro y, sobre todo, qué está fuera, cada conversación se vuelve una renegociación. Por eso un buen relevamiento de requisitos ahorra más dinero que cualquier descuento que vayas a conseguir en la propuesta.
La tercera puerta es la del socio. A veces la software house acepta cada pedido sin discutir, lo construye todo y te manda la cuenta ampliada al final. Otras veces usa un alcance flojo para cobrar un adicional en cada paso. Elegir con quién vas a construir es, en parte, elegir quién va a sostener el alcance contigo en lugar de surfear su deriva.
Quién paga depende del contrato
Acá está la parte que casi ningún artículo sobre scope creep le cuenta al founder: quién absorbe el costo del cambio lo decide la forma del contrato, antes de que exista cambio alguno.
En un contrato de precio cerrado, el riesgo del alcance es del proveedor, así que se protege. Cada pedido fuera de lo acordado se convierte en un adicional formal, con plazo y monto nuevos. No “ganas” la pantalla extra; renegocias el contrato a mitad de proyecto, desde la peor posición posible, con el desarrollo ya en marcha y el lanzamiento en el calendario. El precio cerrado no evita el scope creep. Solo convierte cada deriva en una negociación tensa.
En un contrato por tiempo y materiales, pagas por las horas, así que cada pedido nuevo simplemente consume más. Acá el scope creep no aparece como una pelea; aparece como una factura que crece y una fecha que se corre, mes tras mes, sin ningún momento dramático. Es más silencioso y, por eso, más peligroso para quien no está mirando de cerca.
Ninguna de las dos formas resuelve el scope creep. Las dos solo cambian dónde aparece el dolor: en el adicional o en la factura. Elegir la forma es elegir el tipo de dolor que prefieres administrar, y esa decisión importa tanto como el precio.
El proceso de cambio que defines antes del kickoff
La solución al scope creep no es congelar el alcance y no cambiar nada. El buen software cambia mientras se construye. La solución es hacer que el cambio sea visible y barato de decidir, en vez de invisible y caro de descubrir.
Acuerda, antes de la primera línea de código, tres cosas con el socio. Primero, qué significa “terminado” para la versión que están construyendo, escrito en un lugar que los dos firman. Segundo, cómo entra un pedido de cambio: por escrito, con una estimación de impacto en horas y plazo antes de que alguien empiece a programar. Tercero, quién decide el trade-off, que casi siempre eres tú, y con base en qué: qué empuja afuera o para después ese cambio.
Este proceso no es burocracia. Es lo que transforma “solo una cosita más” de un favor casual en una decisión explícita con precio. La pregunta deja de ser “¿se puede meter esto?” y pasa a ser “¿vale la pena atrasar el lanzamiento una semana, o sacar otra funcionalidad de la lista?”. Casi toda buena decisión de producto es un trade-off, y el scope creep es justamente lo que pasa cuando tomas esas decisiones sin darte cuenta de que las estás tomando.
Vale distinguir el scope creep de su primo del lado del producto, el feature creep: la acumulación de funcionalidades que deja el producto inflado incluso cuando el proyecto llega a tiempo. El scope creep revienta el cronograma; el feature creep arruina el producto. Los dos nacen del mismo reflejo de decir que sí a todo, y los dos se controlan con la misma disciplina de tratar cada agregado como una elección, no como un extra gratis.
Qué hacer cuando el alcance ya se está yendo
Si estás a mitad de desarrollo y sientes que ya se te fue de las manos, la salida no es apretar al proveedor ni fingir que los pedidos extra no salieron de ti. Es parar y reconstruir lo acordado. Lista todo lo que entró después del alcance original, separa lo esencial para lanzar de lo que puede esperar, y renegocia un nuevo “terminado” con plazo y costo honestos para esa lista recortada. Es incómodo, pero es más barato que seguir agregando a ciegas.
Y a la hora de tercerizar el próximo desarrollo, trata el proceso de cambio como parte del contrato, no como un detalle operativo. El founder de la fintech del comienzo de esta historia hizo exactamente eso en la segunda ronda: alcance cerrado por escrito, un único canal para pedir cambios y una regla de que nada entraba sin estimación antes. Pidió menos cosas en el camino, no porque se volviera más rígido, sino porque cada pedido por fin tenía un precio visible. El segundo proyecto entregó a tiempo. El alcance no se fue de las manos porque, esta vez, no había a dónde ir.
FAQ
¿Qué es el scope creep?
El scope creep es el crecimiento gradual e incontrolado del alcance de un proyecto después de que ya empezó: funcionalidades, pantallas y pedidos que se suman sin revisar plazo, costo o prioridad. En el desarrollo de software tercerizado, es la causa más común de proyectos que se atrasan y se pasan de presupuesto.
¿Qué significa “scope creep” en español?
La traducción más usada es “desviación del alcance” o “corrimiento del alcance”. En el mercado tecnológico, el término en inglés es el más común entre founders y equipos de producto, pero las tres expresiones describen lo mismo: el alcance creciendo sin control después del inicio del proyecto.
¿Cuál es la diferencia entre scope creep y feature creep?
El scope creep es el alcance del proyecto creciendo (más pantallas, más integraciones, más plazo). El feature creep es el producto acumulando funcionalidades hasta volverse confuso, incluso a tiempo. El scope creep revienta el cronograma; el feature creep arruina la experiencia. Los dos vienen del mismo hábito de decir que sí a todo.
¿El contrato de precio cerrado evita el scope creep?
No. Solo cambia quién paga. En el precio cerrado, cada cambio se vuelve un adicional renegociado a mitad de proyecto; por tiempo y materiales, se vuelve más horas en la factura. Ninguna forma de contrato evita el scope creep. Lo que lo evita es definir el alcance antes de empezar y acordar un proceso claro para cambiarlo.
¿Cómo evitar el scope creep en un proyecto tercerizado?
Cierra el alcance por escrito antes del kickoff (qué está dentro y, sobre todo, qué está fuera), acuerda un proceso de cambio donde todo pedido venga con una estimación de impacto antes de volverse código, y trata cada agregado como una decisión con precio, no como un favor. La mayor parte del scope creep se previene antes de la primera línea de código.