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’utilizzo. L’obiettivo è rispondere a una domanda (questa interazione risulta naturale? 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 consegna 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 sala
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 da 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?
- È previsto di default che venga scartato, e il team è determinato a procedere in tal senso?
- Qual è il periodo di tempo previsto e cosa accade al termine dello stesso?
- 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 bilancio 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 per default.
Definite le dimensioni di un prototipo in funzione della soluzione, non del 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’insinuarsi dell’attività di indagine nella storia, nonché gli altri esempi pratici di stima.