Solicitud de cambio: cómo cambiar un software a mitad de proyecto

La forma controlada en que un founder no técnico cambia lo que se está construyendo, antes de que el cambio se convierta en scope creep o en una factura sorpresa.

Daniel dirige una fintech pequeña en Madrid. Seis semanas después de empezar a construir su panel de crédito, vio cómo una demo de ventas se torcía porque la app mostraba los importes en euros pero no las fechas en que el dinero se movía de verdad. Arreglo evidente. Soltó una línea en el Slack del proyecto: “Oye, ¿podemos mostrar también la fecha de liquidación junto a cada importe? Debería ser rápido.” Le devolvieron dos pulgares arriba. Siguió con lo suyo.

Tres semanas después, la factura llegó 1.100 € por encima de lo previsto, el lanzamiento se retrasó nueve días y Daniel no tenía ni idea de por qué. La fecha de liquidación “rápida” significaba traer un campo que el sistema nunca había guardado, lo que exigía cambiar la base de datos, lo que exigía volver a probar cada pantalla que tocaba una transacción. Nada de eso era visible desde donde él estaba. Aprobó un cuadro pequeño y pagó por uno grande.

La cosa que habría salvado a Daniel no tiene glamour y casi nunca se le explica a quien más la necesita. Se llama solicitud de cambio.

Qué es, en realidad, una solicitud de cambio

Una solicitud de cambio es un registro corto y escrito de una modificación en lo que un equipo de software está construyendo, planteada después de que el trabajo ya empezó, que dice qué cambia, por qué y cuánto cuesta en dinero y en tiempo antes de que alguien toque el código. Es la puerta por la que todo cambio a mitad de proyecto debería pasar.

Esa es la idea entera. Acordaste construir A. Ahora quieres A-más, o A-pero-distinto. La solicitud de cambio es cómo esa nueva decisión recibe nombre, precio y aprobación a propósito, en lugar de absorberse en silencio y descubrirse más tarde.

Casi todo lo que se lee sobre solicitudes de cambio en internet está escrito para departamentos de TI corporativos que gestionan cambios en sistemas ya en producción, o para jefes de proyecto que viven dentro de una herramienta como Jira o monday. Ese encuadre es real, pero no es el tuyo. No estás aprobando un parche de servidor. Eres un founder que encargó un build, no lee el código y necesita una forma de dirigir el proyecto sin volar a ciegas. El mismo artefacto, con riesgos completamente distintos.

Solicitud de cambio vs scope creep: el mismo cambio, controlado o no

Aquí está la distinción que importa más que cualquier definición. Una solicitud de cambio y el scope creep muchas veces son exactamente el mismo cambio. La única diferencia es si pasó por una puerta que controlas o por una grieta que no viste.

La fecha de liquidación de Daniel era una solicitud de cambio que nunca se escribió. Como se quedó en un mensaje de Slack, nadie se detuvo a ponerle precio, nadie señaló el trabajo en la base de datos, y el coste apareció como una línea misteriosa en la factura en lugar de un número que él aprobó por adelantado. Eso es scope creep. No porque alguien fuera deshonesto, sino porque el cambio no tenía puerta de entrada, así que entró por la pared.

Repite el mismo momento con una solicitud de cambio y se ve distinto. Daniel pide la fecha de liquidación. El equipo responde: “Ese campo hoy no se guarda, así que esto es alrededor de día y medio de trabajo más las pruebas, unos 1.200 €, y mueve el hito dos días. ¿Lo hacemos?” Ahora Daniel decide. Quizá la demo lo vale y dice que sí con los ojos abiertos. Quizá dice “aparcado hasta después del lanzamiento”. En cualquier caso, fue él quien eligió, y no hay sorpresa en la factura.

La solicitud de cambio no impide el cambio. Convierte el cambio en una decisión en lugar de en un accidente. Ese es el valor entero, y vale más para un founder no técnico que para casi cualquier otra persona en la sala, porque eres el único que no puede ver el coste venir por su cuenta.

Qué entra en una solicitud de cambio

Una buena solicitud de cambio es corta. Si pasa de una página, el cambio es lo bastante grande como para ser un miniproyecto propio y hay que dimensionarlo como tal. Para un cambio corriente quieres cinco cosas, y deberías poder leer las cinco aunque no leas código.

Qué cambia, en lenguaje claro. Una o dos frases que entienda una persona normal. “Mostrar la fecha de liquidación junto a cada importe de transacción en el panel.” No “modificar el serializador de transacciones.” Si no puedes seguir la descripción, eso es una señal, no un detalle que saltarse.

Por qué. La razón de negocio, con tus palabras. “Ventas no cierra demos sin esto.” Importa porque es lo que vas a sopesar contra el coste. Un cambio con razón débil y precio real es el “no” más fácil que darás en tu vida.

El coste en dinero y en tiempo. La estimación honesta del equipo sobre el esfuerzo y sobre lo que le hace al calendario. Un cambio barato en euros puede salir caro en días si bloquea otro trabajo. Quieres los dos números.

Qué toca. Una línea sobre el efecto dominó. ¿Esto cambia una pantalla, o llega a datos de los que dependen otras pantallas? Aquí se esconden las sorpresas de “cambio pequeño, coste grande”, y un buen socio te lo dirá antes de que preguntes.

Tu decisión. Aprobado, rechazado o aparcado, con fecha y tu nombre. Una solicitud de cambio sin decisión registrada es solo una conversación, y las conversaciones no se sostienen cuando los recuerdos discrepan dos meses después.

Eso es todo. No hace falta software. Un documento compartido con una lista corrida de estas resuelve un build que no sea enorme. La disciplina vive en el hábito, no en la herramienta.

Los cuatro tipos de cambio que vas a enfrentar de verdad

La gestión de cambios corporativa separa las solicitudes en categorías como “estándar”, “normal” y “de emergencia”. Útil para un equipo de operaciones de TI. No es el corte que ayuda a un founder a decidir. Los cuatro tipos que vas a encontrar en la práctica son estos.

La aclaración. No estás cambiando el plan de verdad; estás descubriendo que el plan era vago. El alcance de proyecto original decía “el usuario puede exportar sus datos” y ahora aprendes que “exportar” podía ser un CSV, un PDF o una API entera. Esto no debería costar más si la vaguedad estaba en la especificación, y un socio justo lo tratará como rellenar un hueco, no como un cambio de pago. Fíjate en cómo un equipo maneja estos casos. Dice mucho.

La adición. Trabajo genuinamente nuevo que nadie planeó. Una pantalla nueva, una integración nueva, una regla nueva. Esta es una solicitud de cambio de verdad con precio de verdad, y es el tipo más honesto. Quisiste más, más cuesta más, todos entienden el trato.

La reversión. Estás deshaciendo o redirigiendo algo ya construido. Estas son las que los founders más subestiman, porque arrancar trabajo terminado y reconstruirlo suele ser más caro de lo que habría sido hacerlo bien a la primera. Una reversión puede costar más que la función original. Saberlo de antemano cambia con cuánto cuidado fijas las decisiones antes de que empiece el trabajo.

El “ya que estás ahí”. El peligroso. “Ya que estás tocando el panel, ¿puedes también…?” Estos parecen gratis porque el equipo ya está en el barrio. A veces de verdad son baratos. A menudo son un segundo cambio con el abrigo del primero, y tres de ellos apilados son cómo un retraso de dos semanas se convierte en uno de dos meses. Haz que cada uno sea su propia línea, aunque parezca pequeño.

Quién plantea una, y por qué deberías ser tú

En la versión corporativa de esto, cualquiera puede abrir una solicitud de cambio y un comité de cambios la revisa. En tu build, la pregunta es más simple y la respuesta es, casi siempre, tú.

Los cambios surgen de dos direcciones. Algunos vienen de ti, porque el mercado se movió, un cliente lo pidió o una demo expuso un hueco. Algunos vienen del equipo, porque chocaron con algo que el plan no anticipó. Ambos son legítimos. Lo que quieres es un acuerdo permanente de que ninguno de los dos lados actúa sobre un cambio de cualquier tamaño sin que primero se convierta en una solicitud escrita. El desarrollador no añade en silencio lo que mencionaste de pasada. Tú no esperas un trabajo que nunca aprobaste.

La razón de que pase por ti no es control por el control. Es que eres la única persona capaz de sopesar un cambio frente a lo que el equipo no ve: el runway, el calendario de la ronda, el cliente que intentas no perder, la fecha de lanzamiento que le prometiste al consejo. Un desarrollador que optimiza por un código limpio y un founder que optimiza por una Serie A tomarán decisiones distintas sobre el mismo cambio, y la del founder es la que debe ganar. Una solicitud de cambio es lo que pone esa decisión en tus manos en lugar de en un hilo de Slack que nadie vuelve a leer.

Este es también el test más claro de si trabajas con un socio tecnológico o con una caja negra. Un socio plantea solicitudes de cambio sin que se lo pidas, las pone a precio con honestidad y a veces te disuade de una. Una caja negra absorbe tus comentarios sueltos, te los cobra después y lo llama “lo que pediste”.

Cómo se pone precio a una solicitud de cambio, y la trampa del “es solo una cosita”

La frase más cara en software es “es solo una cosita”. No porque los equipos mientan sobre ello, sino porque “cosita” describe el cuadro que tienes en la cabeza, y el cuadro es la parte más barata.

Un cambio que describes en una frase puede exigir tocar los datos de debajo, la lógica que los procesa, cada pantalla que los muestra y las pruebas que demuestran que nada se rompió. La fecha de liquidación de Daniel era una frase y cuatro capas de trabajo. La parte visible, el número en la pantalla, era quizá una hora. La parte invisible era todo lo que tenía que moverse para que esa hora fuera segura.

Cuando una solicitud de cambio vuelve más cara de lo que esperabas, el movimiento correcto no es suponer que te están inflando la cuenta. Es hacer una pregunta: “¿Qué hace que esto sea más de lo que parece?” Un buen socio responde en términos de negocio que puedes seguir. “La fecha no se guarda en ningún sitio, así que tenemos que empezar a capturarla, rellenar los registros antiguos y revisar cada vista de transacciones.” Un mal socio dice “es complejo” y no aprendes nada. La calidad de esa respuesta vale más que el propio presupuesto.

También quieres el precio del cambio atado a cómo ya pagas. Si estás en un contrato a precio cerrado, las solicitudes de cambio son donde vive la negociación de verdad, así que la definición de qué cuenta como terminado en el alcance original importa enormemente. Si estás en time and materials, cada cambio ya está medido, y la solicitud va sobre todo de que tú mantengas el total visible para ti mismo. En cualquier caso, la solicitud es el momento en que el coste abstracto de “más” se convierte en un número real que aceptas o rechazas. Para un retrato más completo de por qué esos números se mueven como se mueven, nuestro análisis de cuánto cuesta una aplicación recorre el mismo terreno desde el lado del presupuesto.

El hábito de la solicitud de cambio que mantiene un build honesto

Nada de esto requiere un diagrama de procesos ni una suscripción a una herramienta. Requiere un hábito, pactado en voz alta al principio del proyecto: ningún cambio de cualquier tamaño ocurre sin una solicitud escrita y una decisión registrada.

Dilo en la primera reunión. “Si cualquiera de los dos quiere cambiar algo una vez que empecemos, va al registro de cambios primero, recibe precio y plazo, y yo lo apruebo antes de que empiece ningún trabajo. Incluido lo pequeño.” Un socio serio se sentirá aliviado de que lo hayas dicho, porque eso lo protege tanto como a ti. El equipo que se resiste te está diciendo algo.

Toda la tradición ágil se construye sobre la premisa de que los requisitos van a cambiar, de que eso es normal e incluso sano. El Manifiesto Ágil se cuida de dar la bienvenida a los requisitos cambiantes incluso al final del desarrollo. Pero “dar la bienvenida al cambio” y “absorber el cambio de forma invisible” no son la misma instrucción. Das la bienvenida al cambio dándole una puerta de entrada, una etiqueta de precio y tu firma. Te quemas con el cambio cuando no tiene ninguna de las tres.

Daniel dirige sus builds de otra manera ahora. Cada cambio, incluso los que parecen demasiado pequeños para molestarse, va a un documento compartido con un número y un sí o un no al lado. Sus facturas dejaron de sorprenderlo. No porque sus proyectos dejaran de cambiar, sino porque dejó de enterarse de los cambios después de haberlos pagado. La solicitud de cambio no lo frenó. Solo movió el momento de la decisión a antes de gastar el dinero, donde debía estar todo el tiempo.

Preguntas frecuentes

¿Qué es una solicitud de cambio?
Una solicitud de cambio es un registro corto y escrito de una modificación en lo que un equipo de software está construyendo, planteada después de que el trabajo empezó, que dice qué cambia, por qué y cuánto costará en dinero y en tiempo antes de tocar el código. Convierte un cambio a mitad de proyecto en una decisión que apruebas a propósito, en lugar de un coste que descubres más tarde.

¿Qué entra en una solicitud de cambio?
Cinco cosas: una descripción en lenguaje claro de qué cambia, la razón de negocio, el coste en dinero y en tiempo, una nota sobre qué otras partes del sistema toca y una decisión registrada (aprobada, rechazada o aparcada) con fecha y nombre. Si pasa de una página, el cambio es lo bastante grande como para dimensionarlo como un proyecto propio.

¿Cuáles son los cuatro tipos de solicitud de cambio?
Para un founder, el corte útil es por lo que el cambio hace: una aclaración (el plan era vago y estás rellenando un hueco, normalmente sin coste extra), una adición (trabajo genuinamente nuevo con precio real), una reversión (deshacer trabajo terminado, a menudo más caro que el original) y el “ya que estás ahí” (parece gratis, a menudo no lo es). La TI corporativa usa las categorías estándar, normal y de emergencia, que importan menos cuando encargas un build.

¿Quién puede iniciar una solicitud de cambio?
Cualquiera de los dos lados puede plantearla, tú o el equipo de desarrollo, y ambos son legítimos. El acuerdo a fijar al principio es que ningún lado actúa sobre un cambio de cualquier tamaño sin escribirlo y obtener tu aprobación primero, porque eres la única persona capaz de sopesar un cambio frente al runway, el calendario y el cliente que intentas conservar.

¿En qué se diferencia una solicitud de cambio del scope creep?
A menudo son el mismo cambio. La diferencia es el control. Una solicitud de cambio pasa por una puerta que gestionas, con precio y tu aprobación. El scope creep es el mismo cambio colándose por una grieta, sin precio y sin aprobación, hasta que aparece en la factura. La solicitud es lo que convierte el creep en una elección.