¿Ajuste o cambio de alcance? Cómo decidir antes de ejecutar una petición del cliente

El cliente pide cambiar un texto de la página de contacto antes de publicar su web. Poco después, solicita que esa misma página incluya un formulario conectado a su sistema de gestión. Ambas peticiones llegan por correo y parecen fáciles de atender, pero no tienen el mismo efecto sobre el proyecto. Si el equipo empieza a trabajar sin distinguirlas, puede comprometer una fecha, duplicar tareas o crear expectativas que nadie aprobó.

La gestión de cambios de alcance en proyectos no consiste en responder «eso no estaba incluido» a cada solicitud. Consiste en comparar lo pedido con el acuerdo vigente, entender sus consecuencias y tomar una decisión compartida antes de ejecutar. Esto protege la relación con el cliente tanto como el presupuesto y la planificación del proveedor.

La referencia es el acuerdo, no el tamaño aparente de la petición

Un ajuste adapta la ejecución de algo ya acordado sin alterar sustancialmente el resultado, las responsabilidades ni las condiciones de entrega. Corregir un texto facilitado para una página prevista, dentro del proceso de revisión pactado, puede ser un ajuste. Una corrección de un error respecto a los criterios de aceptación acordados tampoco debería etiquetarse como nueva funcionalidad.

Un cambio de alcance modifica lo que se va a entregar o las condiciones necesarias para hacerlo: añade un resultado, amplía un flujo, introduce una integración, exige nuevas aprobaciones o altera plazos y recursos. El formulario conectado a otro sistema puede requerir definir datos, permisos, pruebas y una persona responsable de la aplicación receptora. Aunque el botón visible ocupe poco espacio, el trabajo real no se mide por su apariencia.

La referencia debe ser accesible: propuesta aprobada, entregables, exclusiones, supuestos, hitos y criterios de aceptación. Si el acuerdo es ambiguo, no conviene convertir automáticamente la ambigüedad en un cargo adicional ni asumir en silencio todo el trabajo. Primero hay que aclarar qué entendían ambas partes y registrar la interpretación acordada.

Preguntas para clasificar una solicitud

Antes de estimar o prometer una fecha, quien recibe la petición puede plantear estas preguntas:

• ¿Qué resultado busca el cliente? Una petición de solución concreta puede ocultar un problema que ya se puede resolver dentro del alcance. Preguntar por el objetivo evita construir más de lo necesario.
• ¿Estaba contemplado el resultado, no solo el componente? Que el proyecto incluya un formulario no implica que incluya una integración o un nuevo proceso de aprobación.
• ¿Cambia algún criterio de aceptación? Si el trabajo deja de considerarse terminado bajo condiciones distintas, hace falta revisar la decisión de entrega.
• ¿Qué ocurre con dependencias y responsables? Datos adicionales, acceso a sistemas, revisión de otro departamento o pruebas nuevas pueden cambiar la secuencia del proyecto.
• ¿Cuál es el impacto combinado? Una petición pequeña puede ser asumible por sí sola, pero varias acumuladas pueden desplazar tareas acordadas. Hay que mirar el conjunto, no cada correo aisladamente.

No hace falta una fórmula universal ni fijar un umbral arbitrario de horas. Una clasificación útil distingue entre corrección de lo acordado, ajuste dentro del margen de revisión, aclaración pendiente y cambio que requiere una decisión sobre alcance, plazo o coste. El resultado de cada categoría debe ser comprensible para quien solicita el trabajo y para quien lo ejecuta.

Decidir sin detener innecesariamente el proyecto

Un proceso ligero empieza con una única entrada para las peticiones, aunque lleguen por reunión, mensajería o correo. Se registra quién solicita qué, el objetivo, la fecha en que se necesita y cualquier documento relacionado. La persona responsable del proyecto confirma que la petición se ha recibido; no confirma todavía que se hará.

Después, el equipo técnico o de entrega analiza opciones y dependencias. La persona responsable del proyecto propone la clasificación y explica sus motivos. Del lado del cliente debe haber alguien con autoridad para aceptar prioridades y consecuencias comerciales; no basta con que cualquier participante de una reunión diga «adelante». Si la solicitud afecta a especialistas u otros equipos, se les consulta antes de cerrar el compromiso.

Para un cambio de alcance, una respuesta útil presenta opciones: añadirlo y revisar condiciones, sustituir una tarea prevista por la nueva necesidad, dejarlo para una fase posterior o no realizarlo. Cada opción debería indicar qué se entregará, qué queda fuera, qué decisiones o materiales debe aportar el cliente y qué efectos previsibles tiene sobre el calendario y los recursos. Un ajuste también merece una confirmación breve si modifica una prioridad o consume una ronda de revisión pactada.

La regla operativa es sencilla: no convertir una petición en trabajo aprobado por el mero hecho de haberla recibido. Si aparece una incidencia que exige una acción inmediata para contener un problema, puede autorizarse esa acción limitada por separado; la solución definitiva sigue necesitando una decisión explícita.

Dejar una decisión que el equipo pueda ejecutar

La documentación no tiene que ser extensa. Una ficha o registro compartido puede incluir la solicitud original, la referencia al alcance vigente, la clasificación, el análisis de impacto, las opciones, el responsable de aprobar, la decisión y la versión actualizada del plan. Conviene conservar también las solicitudes descartadas o aplazadas: explican por qué un entregable no incluye algo que se discutió.

Imaginemos que un cliente pide añadir una pregunta a un formulario ya previsto. Si cabe en los datos y revisiones acordados, puede tratarse como ajuste y confirmarse por escrito. Si la nueva respuesta debe activar una ruta de aprobación, generar documentos y enviarse a otra herramienta, hay un cambio de proceso que merece evaluación. La diferencia está en el trabajo y las obligaciones que aparecen detrás de la pregunta, no en el número de campos.

Un formulario estructurado y un tablero compartido suelen bastar para recibir, asignar y seguir solicitudes. Una automatización basada en reglas puede avisar al responsable y actualizar estados cuando se aprueba una decisión. La IA puede ayudar a resumir mensajes largos o detectar preguntas pendientes, pero no debería decidir por sí sola qué se pactó ni aprobar compromisos comerciales: esas conclusiones necesitan revisión humana.

Para empezar, revisa un proyecto activo y elige un solo tipo de petición que hoy llega por varios canales. Define la referencia de alcance, quién clasifica, quién aprueba y qué constancia escrita precede a la ejecución. Después observa dónde se acumulan esperas, aclaraciones y trabajos repetidos; esos datos permiten simplificar el proceso sin perder control.

Si quieres ordenar esa decisión en un proyecto concreto, Cibercoding puede ayudarte a revisar el flujo de solicitudes y detectar qué conviene aclarar, documentar o automatizar.