¿Qué es el scope creep y cómo evitarlo en un proyecto de software?

El scope creep es la expansión progresiva del alcance de un proyecto de software más allá de lo acordado originalmente, sin ajustar el tiempo, el costo o los recursos disponibles. Pasa cuando se suman requisitos nuevos —una función más, un ajuste "chico"— sin pasar por un proceso formal de aprobación, y cada suma individual parece demasiado pequeña como para justificar renegociar el plan completo.

No es lo mismo que un cambio de alcance bien gestionado: la diferencia no está en si el alcance cambia —casi siempre cambia, en cualquier proyecto real—, sino en si ese cambio queda documentado, se evalúa su impacto en tiempo y recursos, y se aprueba por ambas partes antes de ejecutarse. El scope creep es exactamente el cambio que entra sin pasar por ese paso.

¿Por qué aparece el scope creep incluso en proyectos bien planeados?

La causa más común no suele ser un pedido puntual fuera de lugar a mitad de proyecto —es que el alcance nunca quedó del todo cerrado desde el arranque. El Pulse of the Profession 2018 del Project Management Institute (PMI), una encuesta a 5.402 organizaciones, encontró que las tres causas más citadas de proyectos que no cumplen su objetivo son un cambio en las prioridades del negocio (39%), un cambio en los objetivos del proyecto (37%) y una recolección incorrecta de requisitos al inicio (35%). Ninguna de las tres es un capricho de último momento: son fallas de definición temprana que dejan la puerta abierta para que el alcance se estire sin que nadie lo registre como una decisión.

¿Cuánto cuesta el scope creep en la práctica?

Según ese mismo relevamiento de PMI, el 52% de los proyectos completados en los 12 meses previos había tenido scope creep —un salto marcado frente al 43% que la misma encuesta había medido cinco años antes. No es un problema marginal ni exclusivo de proyectos mal gestionados: según esos datos, es el escenario más común, no la excepción.

¿Alcanza con documentar el alcance al principio para evitarlo?

Documentar el alcance al arrancar ayuda, pero no alcanza solo. Los pedidos nuevos casi nunca llegan como una propuesta formal de cambio —llegan como un comentario suelto en una llamada, un "che, ya que estás, ¿le sumamos esto?"—, y sin un proceso explícito para evaluarlos, cada uno entra por goteo sin que nadie mida el efecto acumulado. Lo que sí funciona, de forma consistente, combina tres elementos: un documento de alcance que dice tan claro qué queda afuera como qué queda adentro, un proceso de control de cambios donde cada pedido se evalúa antes de aceptarse —no después—, y una autoridad clara que aprueba o rechaza cada cambio en vez de dejarlo colar por consenso tácito.

¿Qué cambia con un criterio de aceptación firmado por milestone?

En Zenit, cada milestone arranca con un criterio de aceptación firmado por la empresa y el squad antes de que se escriba la primera línea de código: qué incluye ese hito, qué queda afuera, y qué evidencia demuestra que está terminado. Ese acuerdo cumple, en la práctica, el rol del control de cambios que la mayoría de los proyectos improvisa sobre la marcha —si algo nuevo aparece a mitad de un milestone, no se suma por goteo: se convierte en una decisión explícita sobre si entra en el milestone actual, con su costo y plazo ajustados, o en el siguiente.

Ese mecanismo ataca el síntoma —los pedidos que se cuelan sin evaluación—, pero la causa de fondo, según los datos de PMI citados arriba, suele estar antes: en requisitos que nunca quedaron del todo claros. Kaizen entra justo ahí, en el discovery previo al match: en vez de partir de un formulario que cada empresa completa como puede, escucha las reuniones del equipo y arma un brief con alcance, milestones y decisiones ya documentadas antes de que el squad arranque a trabajar —el mismo tipo de definición temprana que, según PMI, es lo que más reduce el riesgo de que el alcance se estire sin control.

El objetivo no es que el alcance nunca cambie —casi todo proyecto de software real aprende algo sobre la marcha, y hacer como que eso no va a pasar es la forma más rápida de terminar renegociando todo de nuevo—, sino que cada cambio sea una decisión visible, evaluada, y no una acumulación silenciosa que nadie decidió a propósito.