Stima dei costi di un prototipo
Come valutare un prototipo: si tratta di un prodotto finalizzato all’apprendimento, non all’uso. Come evitare che il codice provvisorio si trasformi nel codice di produzione che nessuno aveva previsto.
La storia il cui risultato è «ora sappiamo cosa realizzare», non «l’abbiamo realizzato».
Un prototipo è concepito per l’apprendimento, non per l’uso. Lo scopo è rispondere a una domanda — questa interazione risulta adeguata, questo approccio è scalabile, questa API reggerà? — con sufficiente rapidità da consentire di cambiare direzione prima di impegnarsi definitivamente. I team che stimano i prototipi nello stesso modo in cui stimano le funzionalità ottengono un dato che finanzia un tipo di lavoro non adeguato.
L’altra modalità di fallimento è l’opposto: si realizza un prototipo di dimensioni ridotte, si rilascia qualcosa che “funziona a malapena”, e poi si passa alla produzione perché la tempistica è andata avanti. Il prototipo che diventa il prodotto è il codice più costoso dell’intero codice sorgente, poiché nessuno ha previsto le parti che mancano.
Ciò che viene detto nella stanza
Ingegnere: «Posso mettere insieme qualcosa in un paio di giorni.»
Introduzione: “Qual è la domanda a cui stiamo cercando di rispondere?”
PM: «Questo materiale è destinato ai clienti o è solo per uso interno?»
Introduzione: «Se la risposta è sì, lo buttiamo via e lo ricostruiamo?»
Ingegnere: «Non lo buttiamo mai via.»
Domande che vale la pena porsi prima di votare
- A quale domanda risponde il prototipo e come potremo sapere di aver ottenuto una risposta?
- Solo per uso interno o anche davanti ai clienti?
- “Da buttare” per impostazione predefinita — e il team è determinato a seguire questa linea?
- Qual è il periodo di tempo previsto e cosa succede al termine di esso?
- Se funziona, qual è il percorso da seguire per passare dal prototipo al codice di produzione?
Il motto dell’ingegnere «non lo buttiamo mai via» rappresenta il vero rischio: si deve prevedere nel budget il prototipo come soluzione e definire la fase di produzione come un progetto a sé stante, in modo che l’idea di «buttarlo via» non venga promossa automaticamente.
Definite le dimensioni di un prototipo in base alla soluzione, non al prodotto finale — e pianificate la ricostruzione prima che sia il calendario a farlo per voi.
Proprio come la stima di un picco di ricerca, il risultato atteso è la conoscenza; trattateli allo stesso modo. Si vedano gli errori comuni nel Planning Poker relativi all’inserimento di elementi di indagine nella storia, nonché gli altri esempi pratici di stima.