Así es el calendario real de diez días para llegar a una versión que ya funciona.

Nos preguntan cómo llegamos en diez días a una versión que ya funciona, y la respuesta honesta tiene poco que ver con la velocidad. Diez días es lo que tarda un proyecto cuando una sola persona senior está a cargo de todo y en la mesa hay tan poca gente que se puede decidir ahí mismo.

Este es el calendario que de verdad seguimos, y casi no ha cambiado en un año porque la forma del problema tampoco cambia mucho.

Los días 1 y 2 son para accesos y decisiones

Hacemos tres preguntas y las respondemos por escrito con las personas que pueden decir que sí. ¿Quién va a usar esto? ¿Qué datos podemos tocar y dónde están? ¿Qué cuenta como buen resultado el día diez?

Es la parte aburrida y también la razón por la que la mayoría de los proyectos tardan seis meses, porque nadie hizo estas preguntas hasta la cuarta semana, cuando las respuestas ya resultaban incómodas. Nosotros las hacemos primero y no empezamos a construir hasta tenerlas. Lo único que no negociamos es el acceso a un sistema real, aunque sea solo de lectura, porque un piloto sin acceso es una presentación de diapositivas.

Los días 3 a 5 son para que una cosa funcione de principio a fin

El producto entero viene después. En estos tres días hacemos que un solo flujo de trabajo funcione completo, sobre infraestructura real y con datos reales. Si el producto es un agente de reservas, el día cinco ya funciona un tipo de reserva, desde el mensaje hasta la confirmación, de verdad. Puede verse sin pulir, pero tiene que ser real.

Aquí la tentación es ampliar: tres flujos donde había uno, un panel que nadie pidió, una página de configuración. Nos mantenemos firmes, porque todo lo que agreguemos ahora es algo que los usuarios reales no van a poder romper el día seis.

Los días 6 a 8 traen usuarios reales, datos reales y errores reales

Lo usan unas cuantas personas del propio cliente y se rompe de maneras que ningún taller habría previsto. La búsqueda en documentos se cae con un formato que nadie había mencionado. Un usuario escribe mezclando árabe e inglés y el agente se confunde, y alguien intenta reservar un horario que no existe.

Aquí es donde de verdad se diseña el producto, porque cada error es una decisión que de otro modo habríamos tomado adivinando. Los corregimos el mismo día y a la mañana siguiente los mismos usuarios vuelven a probar.

Los días 9 y 10 son para mostrarlo, reforzarlo y decidir

Se lo mostramos funcionando a las personas que no estuvieron en la sala y lo grabamos para que también lo vea quien no pudo llegar a esa reunión. Reforzamos las partes que a la gente le encantaron y quitamos las que nadie tocó.

Después decidimos juntos si seguimos, cambiamos de rumbo o paramos, y cualquiera de las tres es una buena salida. Lo que importa es que tú decides con algo real en las manos, sin tener que imaginártelo a partir de una propuesta.

Diez días alcanzan, sin trucos, cuando una persona senior está a cargo de todo y el grupo es tan pequeño que puede decidir.

Esto es lo que tienes en las manos el día diez

Una versión que ya funciona en tus sistemas, un alcance de una página, un precio fijo y una fecha de lanzamiento para el camino a producción, la grabación de la demo y una decisión que te toca tomar a ti.

A partir de ahí cambian las reglas y pasan a ser las que hacen que un producto dure: alcance fijo, fecha fija, una persona a cargo de cada lado y pruebas antes de cada entrega. Todo el proceso está en una sola página.