Un approccio che si è dimostrato estremamente utile in questo contesto è il “metodo agile”
Quando si sviluppa un prodotto fisico o hardware è molto comune, anzi consigliato, vagliare ipotesi alternative.
Pensiamo in questo senso a cose vicine a noi, come la realizzazione di un cucina su misura.
Anche partendo da moduli esistenti questa attività richiede l’elaborazione e la valutazione di soluzioni alternative.
Ciascuna soluzione presenta vantaggi e svantaggi, costi differenti e, spesso, diversi tempi di approvvigionamento o di costruzione.
Questo approccio può essere descritto con lo schema evolutivo delle tazze alternative.
In questo schema ci sono 3 alternative di disegno di una tazza.
Poiché non sappiamo quale verrà preferita dal cliente gli vengono presentate in prima istanza o iterazione:
- soluzioni di tazze tondeggianti
- soluzioni di tazze coniche
- soluzioni di tazze con piedistallo
Come avviene nella vita reale si procede ad una prima selezione dopo la quale si continua lo sviluppo delle soluzioni approvate.
Si procede così alla seconda iterazione che produrrà una ulteriore selezione.
Ciascuna soluzione viene valutata dal punto di vista delle funzionalità tenendo conto delle prospettive del Design for X, come ho descritto nel mio precedente articolo.
Questo approccio permette di essere efficaci e di proporre quindi un prodotto che soddisfa maggiormente il cliente.
Costituisce inoltre un modo per contenere i rischi.
Di fronte ad un eventuale ripensamento del cliente non si torna all’inizio ma solamente ad uno dei passi precedenti.
Come facciamo a sapere quante iterazioni occorreranno? … Non lo sappiamo.
Come facciamo a pianificare questo sviluppo di soluzioni alternative?
Sicuramente non possiamo impiegare una pianificazione a cascate rappresentata da un diagramma di Gantt.
Eppure questo approccio, che viene chiamato Sviluppo per Set di Soluzioni Concorrenti o Set Based Concurrent Engineering, mi venivano proposte ben prima che scoprissi l’agilità.
Non sono mai riuscito fino a quel momento a fare una pianificazione reale delle attività da svolgere.
E se usassimo invece il classico approccio adattivo Agile?
L’approccio Agile gestisce in modo iterativo la modifica quanto sviluppato, e gestisce in modo incrementale l’aggiunta di nuovi elementi del prodotto (progettuali o fisici).
In questo modo è possibile gestire in modo efficace un processo complesso come quello dello sviluppo di soluzioni alternative concorrenti.
La soluzione è vincente perché concentra il team a presentare soluzioni, sviluppate “quanto basta” perché il team possa farne una valutazione insieme agli stakeholder e al cliente.
Durante le iterazioni successive si sviluppano ulteriormente le soluzioni approvate fino a convergere verso una soluzione concordata.
Con i miei team di sviluppo prodotti e con quelli delle aziende che seguo, in tutti i prodotti che abbiamo sviluppato abbiamo applicato continuamente questo approccio.L’approccio Agile ha finalmente dato, a me e ai miei team, la possibilità di gestire lo sviluppo di soluzioni alternative tenendo conto delle molteplici prospettive del Design for X.
