Los cambios son normales en un proyecto de software. El problema aparece cuando una petición modifica el resultado acordado sin dejar visible qué cambia, por qué, qué impacto tiene y quién lo aprueba.
Gestionar alcance no consiste en impedir el aprendizaje ni en justificar cualquier coste adicional. Consiste en mantener una referencia común, clasificar la solicitud y decidir de forma trazable si se corrige, incorpora, intercambia, aplaza o rechaza.
Mantén una referencia antes de hablar de cambios
Solo puedes identificar un cambio si existe una versión de referencia. Debe permitir localizar:
- problema y resultado esperado;
- usuarios y flujos incluidos;
- entregables y exclusiones;
- supuestos y dependencias;
- criterios de aceptación;
- decisiones todavía abiertas.
La guía para definir alcance y criterios de aceptación explica cómo crear esa base. C08 comienza cuando una petición posterior puede alterarla.
No congeles el documento para siempre. Guarda versiones y registra qué referencia está vigente para que una conversación nueva no borre la decisión anterior.
Clasifica la petición antes de estimarla
Una misma frase —“esto debería hacer otra cosa”— puede describir situaciones distintas:
| Tipo | Pregunta de control | Tratamiento inicial |
|---|---|---|
| Defecto | ¿Incumple un criterio o comportamiento ya acordado? | reproducir, corregir y volver a probar |
| Aclaración | ¿Precisa una ambigüedad sin cambiar el resultado? | documentar la interpretación |
| Requisito nuevo | ¿Añade usuario, flujo, dato, regla o resultado? | evaluar como cambio de alcance |
| Cambio de restricción | ¿Ha cambiado una API, norma, proveedor o dependencia? | medir impacto y alternativas |
| Mejora | ¿Aumenta utilidad sin ser necesaria para aceptar lo acordado? | priorizar frente a otros trabajos |
La clasificación no decide automáticamente quién asume el trabajo o el coste. Eso depende de la referencia y de los acuerdos aplicables. Si hay una disputa contractual, hace falta revisar el texto concreto; este artículo no sustituye asesoría jurídica.
Registra la necesidad, no solo la solución propuesta
Una solicitud útil contiene:
- problema o evidencia que la origina;
- persona o proceso afectado;
- resultado que debería cambiar;
- urgencia y consecuencia de no actuar;
- referencia afectada;
- alternativa o workaround existente;
- solicitante y persona con autoridad para decidir.
“Añadir un botón” no explica el trabajo. Quizá el problema se resuelve con una regla, una vista o un cambio operativo. Mantener la necesidad separada de la solución permite comparar alternativas.
Evalúa el impacto completo
Antes de aprobar, revisa qué cambia en:
- flujo, usuarios y permisos;
- datos, migración e integraciones;
- diseño y desarrollo;
- pruebas y criterios de aceptación;
- documentación y formación;
- operación, soporte y mantenimiento;
- otras entregas o decisiones.
Microsoft recomienda establecer una línea base y un proceso que indique cómo se comunica, evalúa y decide una solicitud de cambio (Microsoft Support, observada el 29/08/2026). La guía pertenece a Microsoft Project; aporta un mecanismo general, no umbrales universales de coste o calendario.
Si todavía faltan datos, registra un rango de opciones o una investigación necesaria. No conviertas una primera impresión en precio o plazo comprometido.
Decide entre cinco salidas
Una decisión no se limita a “sí” o “no”:
- Corregir: lo pedido ya formaba parte de lo aceptado.
- Incorporar: se añade con impacto y referencia actualizados.
- Intercambiar: entra una necesidad y sale o se reduce otra para conservar una restricción.
- Aplazar: se conserva en backlog con condición de revisión.
- Rechazar: no contribuye al objetivo o su coste/riesgo no se justifica.
La gestión de cambios de AGESIC describe evaluar impacto y someter la modificación a aprobación dentro de un proceso de alcance (AGESIC, observada el 29/08/2026). Su contexto es un modelo de calidad para organismos uruguayos; no establece el órgano ni la formalidad que necesita cada empresa española.
Usa un registro breve y auditable
| Campo | Registro |
|---|---|
| ID y fecha | referencia estable |
| Motivo | problema y evidencia |
| Tipo | defecto, aclaración, requisito, restricción o mejora |
| Impacto | alcance, datos, integración, prueba, operación |
| Opciones | incorporar, intercambiar, aplazar, rechazar |
| Decisión | resultado y responsable |
| Versión | documentos y criterios actualizados |
| Evidencia | demostración, prueba o documento |
Azure DevOps recomienda conservar trazabilidad entre requisito, criterios de aceptación, discusiones y cambios de los elementos de trabajo (Microsoft Learn, observada el 29/08/2026). La herramienta es opcional: una tabla versionada puede bastar si el equipo la mantiene.
Aplica proporcionalidad sin dejar cambios invisibles
No todas las decisiones necesitan una reunión o un comité. Una aclaración sin impacto puede registrarse y resolverse por la persona responsable. Un cambio que afecta varios flujos, datos, aceptación o terceros necesita análisis y aprobación más explícitos.
La proporcionalidad no significa saltarse el registro. Los cambios pequeños acumulados pueden alterar la entrega aunque ninguno parezca material por separado. Revisa periódicamente el conjunto y no solo cada solicitud aislada.
Conecta cambio y aceptación
Cuando un cambio se aprueba, actualiza:
- alcance y versión de referencia;
- criterio de aceptación afectado;
- casos de prueba;
- dependencias y responsables;
- documentación y decisión de entrega.
La guía para probar y aceptar un software antes de la entrega debe evaluar la versión vigente, no una expectativa anterior ni una petición todavía no aprobada.
Checklist antes de aprobar una solicitud
- Existe una referencia previa identificable.
- La petición está clasificada.
- El problema se separó de la solución propuesta.
- Se revisaron flujo, datos, integración, prueba y operación.
- Las opciones y compensaciones son visibles.
- Una persona con autoridad tomó la decisión.
- La nueva versión y sus criterios quedaron actualizados.
- Se comunicó qué se hará y qué no.
Un buen control de cambios no promete evitar desviaciones. Permite decidirlas con información suficiente y conservar una historia que pueda revisarse después.