Entregar en semanas, no en trimestres

Casi todos los clientes nuevos preguntan cuánto va a tomar la primera versión. La respuesta honesta solía ser un trimestre, a veces dos, y casi todo ese tiempo se iba en cosas que no tenían nada que ver con si el software de verdad funcionaba. Ahora lo bajamos a semanas, y vale la pena explicar qué cambió en realidad, porque no es solo que tecleamos más rápido.

Un alcance chico, a propósito

La palanca más grande no es el modelo. Es reducir la primera versión a lo más pequeño que de verdad pruebe la pregunta real: si la gente va a usar esto, si el flujo de trabajo aguanta, si el número que queremos mover en realidad se mueve. Todo lo que no sostiene esa pregunta espera a la versión dos. Esto siempre fue buena práctica. Ahora es más fácil seguirla porque construir la versión chica ya no se siente como desperdiciar un esfuerzo grande.

Dónde el modelo recupera tiempo

Dentro de ese alcance chico, el modelo redacta rápido: las pantallas de gestión de datos, el primer intento de una integración con una API, el código repetitivo de autenticación y formularios que todo proyecto necesita y a nadie le gusta escribir. Nada de eso es donde pasa el pensamiento de verdad, así que acelerarlo no nos cuesta nada. Recupera días que antes gastábamos en configuración, y esos días los usamos en las una o dos decisiones que de verdad definen si el proyecto funciona.

Lo que no se acelera

Hablar con la gente que va a usar el producto no se acelera, y no dejamos que se acelere. Un prototipo en la segunda semana igual necesita que alguien real reaccione, y esa reacción sigue tomando lo que tenga que tomar para que una persona forme una opinión honesta. Probar los casos límite feos tampoco se acelera. Si acaso hacemos más de eso, porque el tiempo que recupera el modelo va directo a pruebas en vez de perderse en más funciones.

Qué debería esperar un cliente de verdad

Una primera versión funcional en semanas, no un producto terminado. Algo real, suficiente para reaccionar, suficiente chico como para poder reconstruir las partes equivocadas sin perder meses. Preferimos entregar algo pequeño y honesto sobre lo que es, que algo amplio que finge estar terminado. La versión amplia siempre termina teniendo dos decisiones equivocadas metidas adentro, y para cuando se notan, ya son caras de deshacer.

Semanas en vez de trimestres no es un truco de velocidad. Es lo que pasa cuando las partes aburridas de construir software dejan de comerse la mayor parte del tiempo, y las partes que sí necesitan una decisión real reciben el tiempo que siempre debieron tener.