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 prototipo, destinato a essere scartato, 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 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 allo 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 trasferisce quel prodotto in 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 non sono presenti.
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 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?
- È considerato “usa e getta” per impostazione predefinita, e il team è determinato a seguire questa linea?
- Qual è il periodo di tempo previsto e cosa accade 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 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 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 quando si stima un picco di attività 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 di stime efficaci.