Casi ningún proyecto fracasa por un solo cambio grande. Fracasan por treinta cambios pequeños, cada uno razonable por separado, ninguno de los cuales se presupuestó.
Aclaración o cambio
La distinción importa y normalmente se puede determinar.
Una aclaración resuelve una ambigüedad en algo ya acordado. La especificación indica que los usuarios pueden restablecer su contraseña; el cliente confirma que el enlace de restablecimiento debe caducar después de una hora. Eso siempre se iba a implementar; se concretó un detalle.
Un cambio añade, elimina o modifica el alcance acordado. La especificación indica que los usuarios restablecen su contraseña por correo electrónico; ahora el cliente también quiere SMS. Eso es trabajo nuevo.
La zona gris aparece cuando la especificación no dice nada al respecto. Si la especificación no indicaba durante cuánto tiempo era válido el enlace, alguien tenía que decidirlo, y decidirlo es una aclaración. Si la especificación no mencionaba SMS en absoluto, añadirlo es un cambio. Una regla útil: si un desarrollador razonable que leyera la especificación lo habría creado de todos modos, es una aclaración.
Por qué los cambios pequeños cuestan más de lo que su tamaño sugiere
Un cambio que lleva dos horas de programación rara vez cuesta dos horas. También implica:
- Debatir y especificar el propio cambio.
- Efectos sobre lo que ya se ha creado — aparece un campo nuevo en un formulario, en la validación, en la base de datos, en los informes y en las exportaciones.
- Volver a probar todo aquello que afecta o toca el cambio.
- Actualizar la documentación y cualquier diseño ya aprobado.
- El coste de la interrupción, que es real y rara vez se presupuesta.
Por eso un cambio solicitado durante el diseño cuesta una fracción de lo que cuesta el mismo cambio solicitado después de las pruebas de aceptación. El multiplicador entre esos dos momentos es grande — suele citarse un orden de magnitud, y la dirección del efecto no se discute aunque sí pueda discutirse la cifra exacta.
Explicárselo pronto al cliente facilita mucho las conversaciones posteriores, porque entiende que se le pide reflexionar detenidamente durante la fase de diseño por una razón.
Un proceso de cambios lo bastante sencillo como para utilizarlo de verdad
Para un proyecto pequeño, cuatro pasos:
- La solicitud se documenta. Un párrafo, en un único lugar visible para ambas partes. Los cambios verbales son la raíz de la mayoría de las disputas.
- El desarrollador prepara una estimación — esfuerzo, coste y efecto sobre la fecha de entrega. El efecto sobre la fecha importa tanto como el coste y a menudo se olvida.
- El cliente aprueba o rechaza por escrito. Rechazar es un resultado legítimo y debería resultar sencillo.
- Los cambios aprobados se añaden al calendario y a la factura, y la fecha de entrega se modifica formalmente si ha cambiado.
El paso que más se omite es el tercero, y omitirlo es lo que genera la discusión al final: se realizó un trabajo que nadie aceptó formalmente pagar.
Cómo gestionar los cambios pequeños
Gestionar una solicitud de cambio formal para un ajuste de quince minutos cuesta más en proceso que en trabajo, y hacerlo hace que el proyecto parezca conflictivo. Dos enfoques viables:
Una asignación para cambios. Incluir en el contrato un número establecido de horas para pequeños ajustes, con seguimiento e informes. Cuando se agote, los cambios posteriores se presupuestan. Es transparente y elimina la fricción de las solicitudes realmente menores.
Agruparlos. Recopilar los cambios pequeños y presupuestarlos juntos en momentos definidos. Hay menos interrupciones y el cliente ve el coste acumulado — lo que a menudo hace que establezca prioridades.
Cambios ante los que el cliente debería oponerse
No todas las solicitudes de cambio se originan en el cliente. Si un desarrollador plantea un cambio porque algo de la especificación acordada resulta ser más difícil de lo esperado, por lo general eso no es un cambio — es un error de estimación, y el riesgo de estimación normalmente recae en quien preparó la estimación.
La excepción se da cuando la especificación era realmente ambigua y la interpretación del cliente es la más costosa. Eso sí es un cambio, y por eso el esfuerzo de especificación inicial se amortiza.
Conservar el registro
Una única lista, visible para ambas partes, que contenga cada cambio con su estado, coste y efecto sobre la fecha. Al final del proyecto, esa lista explica exactamente por qué la factura final difiere del presupuesto original — y un proyecto capaz de explicar la diferencia rara vez termina en una disputa.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVPs de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles operativos y gestión del backend.
- Integración de API de IA cuando tu producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicita una revisión del alcance y un presupuesto del proyecto cuando estés listo para planificar la primera versión.