Un prezzo fisso per un prodotto nuovo è una scommessa: sapere prima ciò che si impara solo costruendo.

Un prezzo fisso richiede un perimetro funzionale completamente definito. Ma nei prodotti nuovi è proprio ciò che emerge solo durante lo sviluppo.

Per questo vendo tempo di sviluppo: una settimana, senza perimetro fissato in anticipo, senza prosecuzione automatica.

Una settimana di sviluppo non è un’unità di misura per un numero fisso di funzionalità. I prodotti software differiscono troppo per complessità, situazione di partenza e dipendenze tecniche perché ciò sia possibile.

Con compiti adatti, tuttavia, già in brevi cicli di sviluppo può nascere un sistema applicativo coerente: con un’interfaccia utente reale, una logica di dominio centrale, un modello dati, la visualizzazione e una struttura tecnica solida.

Nei sistemi desktop, in tempo reale o di visualizzazione complessi, una settimana può produrre uno spaccato verticale che non contiene ogni funzionalità futura, ma possiede abbastanza architettura e funzionalità reali per prendere decisioni di prodotto centrali.

Se le basi tecniche sono già ben comprese, la portata può spingersi molto più in là.

In presenza di rischi legati alla ricerca, all’integrazione o alle prestazioni, invece, il chiarimento di un singolo problema tecnico critico può avere il maggior valore economico.

La portata non è standardizzata. L’ambizione sì: quanta più realtà di prodotto affidabile possibile nel più breve tempo di sviluppo.