Una persona senior está a cargo y la mesa es lo suficientemente pequeña para tomar decisiones. Esto es lo que pasa cada día, lo que tendrás en las manos el día diez y cómo sigue mejorando después.
Respondemos por escrito tres preguntas con las personas que pueden decir que sí: quién lo usa, qué datos podemos tocar y qué cuenta como buen resultado. Cuando se salta este paso, los proyectos tardan seis meses.
El producto completo llega después. Primero hacemos que un flujo de trabajo funcione de principio a fin sobre tus sistemas reales, y aunque todavía se vea sin pulir, tiene que ser real.
Con usuarios reales y datos reales salen errores reales, y cada uno nos enseña algo que ningún taller nos enseñaría. Aquí es donde de verdad se diseña el producto.
Hacemos una demostración con todo funcionando, pulimos lo que a la gente le encantó y decidimos juntos el siguiente paso: seguir, cambiar el rumbo o parar. Cualquiera de las tres está bien, porque decides con algo real en las manos.
Corre en tus sistemas, toca datos reales y la usa tu gente.
Cabe en una página: qué entra, qué queda fuera y qué aprendimos.
Es fijo y cubre el camino hasta producción.
Es el día del lanzamiento, y planeamos hacia atrás desde ahí.
Puedes seguir, cambiar el rumbo o parar, y la decisión es tuya, con algo real en las manos.
Quedan por escrito antes de empezar a reforzar. Si el alcance cambia, primero lo hablamos, así que no hay facturas sorpresa.
Alguien senior de Dash y alguien senior de tu empresa están en cada llamada.
Cada versión pasa por el conjunto completo de pruebas, y si los números bajan, la función espera.
El código, los prompts y los datos quedan en un repositorio tuyo desde el primer día.
Con los diez días ya tienes algo real. Después del lanzamiento, lo que construimos sigue aprendiendo de la forma en que la gente lo usa, así que se adapta y mejora con el tiempo, y dentro de seis meses es mejor que el día en que lo recibiste.
