La pregunta que más se repite en una primera reunión no es cuánto cuesta. Es cuándo lo veo. Detrás de esa pregunta suele haber una mala experiencia: un proveedor que desapareció tres meses y volvió con algo que no era lo que se había pedido.
Nosotros trabajamos al revés. Dividimos el proyecto en sprints, y al final de cada uno enseñamos funcionando lo que se ha construido. No una presentación ni un porcentaje de avance: el software, en marcha, con el cliente delante.
1. El sprint se ajusta a su necesidad
No hay una duración fija. Un proyecto con una fecha límite de por medio pide ciclos más cortos y revisiones más frecuentes. Uno de recorrido largo, donde lo importante es construir bien la base, admite tramos más amplios. La duración se acuerda al principio en función de la urgencia y del tipo de trabajo, y se puede ajustar si las circunstancias cambian.
El calendario se adapta al proyecto, no el proyecto al calendario.
2. Al final de cada sprint hay algo que se puede usar
Cada ciclo termina con trabajo terminado, no con trabajo empezado. Puede ser una pantalla completa, una integración que ya mueve datos reales o un flujo que se puede recorrer de principio a fin. Lo que se enseña funciona, aunque el proyecto entero esté a medias.
Eso cambia la conversación. En lugar de discutir sobre un documento, se discute sobre algo que se ve y se toca, que es donde salen las observaciones que de verdad importan.
3. La revisión es del cliente, no nuestra
La demo no es un trámite para dar por bueno lo hecho. Es el momento en el que quien conoce el negocio dice si aquello encaja con cómo se trabaja de verdad en su empresa. Casi siempre aparece algo: un caso que no habíamos contemplado, un dato que hacía falta en otra pantalla, un paso del proceso que en la práctica se hace de otra manera.
Ese es exactamente el objetivo. Cuanto antes aparezca, más barato es resolverlo.
4. Corregir pronto cuesta poco
Un desvío detectado en la primera revisión se arregla en horas. El mismo desvío detectado al final del proyecto puede obligar a rehacer parte de lo construido encima. La diferencia de coste entre los dos momentos es enorme, y no la paga el proveedor: la paga el proyecto, en tiempo y en dinero.
Por eso las revisiones frecuentes no son una cortesía comercial. Son la forma más barata de construir.
5. El cliente decide qué va primero
Antes de cada sprint se acuerda qué entra. Si a mitad de proyecto cambia una prioridad, porque llega una inspección, una campaña o un cliente grande, se replanifica lo siguiente sin tirar nada de lo anterior. Lo ya entregado sigue funcionando.
Esa capacidad de reordenar sin romper es la ventaja real de trabajar por tramos.
6. Se ve el avance, no se cuenta
Al terminar el proyecto no hay ninguna sorpresa, porque el cliente ha visto cada paso. Sabe qué se ha hecho, en qué orden y por qué. Y tiene, desde la primera entrega, algo que ya le sirve.
Qué le pedimos al cliente
El modelo funciona con una condición: alguien de la empresa tiene que estar en las revisiones. No hace falta que sea técnico, al contrario. Tiene que ser quien conoce el proceso y puede decidir. Una hora bien aprovechada al final de cada sprint ahorra semanas de trabajo mal orientado.
Es el único compromiso que pedimos, y es el que hace que todo lo demás tenga sentido.
