¿Qué es una solicitud de cambio (change request)?
Una solicitud de cambio es una petición formal para modificar el alcance acordado de un proyecto en curso. Se describe, se evalúa en cuanto a esfuerzo, costes, plazo y riesgo, y solo se implementa tras la aprobación del cliente, de modo que el alcance y el presupuesto se mantengan trazables.

Solicitud de cambio: definición y finalidad
Una solicitud de cambio (en alemán, Änderungsantrag) surge cuando, durante un proyecto, se comprueba que se desea algo distinto o más de lo acordado: una función adicional, un flujo modificado o un sistema más que debe conectarse. Hace visibles los cambios, en lugar de dejar que se cuelen de pasada en la ejecución.
Sirve para mantener bajo control el alcance, los costes y los plazos. Sin un procedimiento claro aparece el llamado «scope creep»: el alcance crece poco a poco, el presupuesto y el calendario se desvían y, al final, ambas partes discuten sobre lo que realmente se había acordado. En los proyectos a precio cerrado, este riesgo es especialmente alto.
Cómo funciona el procedimiento
El proceso suele ser sencillo: se describe la petición, con su motivo y urgencia. El contratista evalúa el esfuerzo, los costes, el plazo y las repercusiones en otras funciones. El cliente decide si aprueba, aplaza o rechaza. Solo entonces comienza la ejecución y se documenta el nuevo estado.
No todo cambio es una solicitud de cambio: un error en el que el software se aparta de lo acordado es un defecto y se corrige, no se vuelve a cobrar. En los proyectos ágiles, la priorización en el backlog sustituye en parte al procedimiento: las nuevas peticiones entran en el backlog y, a cambio, otras pasan a un segundo plano o se eliminan.
- Descripción del cambio solicitado con su motivo
- Efectos en el alcance funcional y en otras áreas
- Estimación del esfuerzo en horas o días, con los costes
- Efectos en el plazo y en la aceptación
- Decisión con fecha y nombre de quien la aprueba
Ejemplo práctico: un configurador para una carpintería
Una carpintería encarga a precio cerrado un configurador online de muebles. A mitad del proyecto, el gerente se da cuenta de que los pedidos deberían pasar directamente al software de contabilidad. Eso no figuraba en la especificación funcional, y la interfaz no es un detalle menor.
El desarrollador registra la petición como solicitud de cambio, estima dos días de esfuerzo adicional y advierte de que la puesta en marcha se retrasa una semana. La carpintería aprueba el cambio. Ambas partes saben qué se acordó adicionalmente y la aceptación transcurre sin discusión.
Errores habituales e implantación
Los errores típicos son las promesas verbales, los cambios que se incorporan «un momento» sin indicar las consecuencias para el plazo y las pruebas, y la falta de un responsable del lado del cliente que los apruebe. Resulta útil describir el procedimiento ya en la oferta: quién presenta los cambios, con qué rapidez se evalúan y qué tarifas se aplican.
Nano Concepts incorpora el proceso de cambios a la oferta, evalúa las peticiones con transparencia y deja por escrito las aprobaciones, para que el alcance, el precio y el plazo sean trazables en todo momento. Así queda espacio para nuevas ideas sin que el proyecto se descontrole. Los clientes conservan el control de los costes y los contratistas evitan trabajo adicional sin retribución.
Preguntas frecuentes sobre Solicitud de cambio (change request)
En principio, el cliente, cuando la petición excede el alcance acordado. El esfuerzo se estima y se aprueba de antemano. Los errores en los que el software no funciona como se acordó son, en cambio, defectos y los corrige el contratista.
La corrección de un error subsana una desviación de lo acordado: el software no hace lo prometido. Una solicitud de cambio modifica lo acordado en sí, porque se desea algo nuevo o distinto. En el primer caso hay un defecto; en el segundo, un encargo adicional.
El scope creep es el crecimiento gradual del alcance del proyecto por muchos pequeños deseos adicionales que no se evalúan ni se aprueban. Sus consecuencias son presupuestos superados, plazos retrasados y disputas. Un proceso de cambios claro lo evita.
No. Los ajustes menores dentro del alcance acordado, como textos o detalles de la ejecución, forman parte del desarrollo normal del proyecto. Un procedimiento compensa en cuanto el esfuerzo, los costes o los plazos se ven afectados de forma apreciable. El umbral debe fijarse en la oferta.
Servicios que encajan

Software a medida
Software según sus procesos en lugar de estándar con concesiones: para sustituir Excel, herramientas internas y aplicaciones especializadas.
Más información
Desarrollo de software
Software desde el requisito hasta la operación: web, móvil e interfaces con un único proveedor.
Más información
Consultoría tecnológica
Elección de software, arquitectura, revisión de código y hoja de ruta de digitalización, con independencia y orientación práctica.
Más información
Mantenimiento de software
Corrección de errores, actualizaciones de seguridad, adaptaciones y evolución de su software a medida, con un contrato de mantenimiento claro.
Más informaciónTérminos relacionados
Relevante para estos sectores
Artículos relacionados de la revista

Scrum en proyectos de software: roles, proceso y velocity
Scrum hace visible el progreso, siempre que el Product Owner pueda decidir, la Definition of Done se aplique y la velocity sirva como herramienta interna de planificación. Una guía para quienes encargan software a medida.
Seguir leyendo
Documento de requisitos de software (Lastenheft): estructura, ejemplo y checklist
Un buen documento de requisitos hace comparables los presupuestos y posibles los precios cerrados. Cómo se estructura, cómo formular requisitos verificables y cómo saber si el suyo está completo.
Seguir leyendo
Microservicios o monolito: guía de decisión para equipos y productos
Los microservicios se consideran modernos, pero para muchos productos un monolito modular es la mejor opción. Cómo valorar con realismo equipos, versiones, consistencia de datos y costes de operación.
Seguir leyendo