Il Project Management adattivo per lo sviluppo di prodotti hardware

Lo sviluppo dei prodotti hardware richiede due approcci fra loro integrati:

1. Lo sviluppo di soluzioni alternative
2. La progettazione concorrente

Per i prodotti #hardware è opportuno progettare e a volte sviluppare più soluzioni, fra loro alternative, per una medesima funzionalità.

Ciascuna soluzione viene comparata con quelle alternative sulla base di una molteplicità di punti di vista fra i quali ad esempio, la funzionalità/usabilità, l’impatto ambientale, il costo e la costruibilità.

Questa modalità si chiama progettazione concorrente o concurrent engineering dove diversi reparti lavorano simultaneamente a diversi aspetti e/o fasi dello sviluppo del prodotto.

Project management adattivo

La pianificazione è adattativa perché procede per piccoli passi con incrementi e modifiche del prodotto, adattando quelli successivi in funzione di quanto emerge.

Il team agile è auto-organizzato e quindi è attore della pianificazione dei propri lavori.

Il project management adattivo è quindi uno strumento nelle mani del team e per questo deve essere di facile gestione.

La pianificazione dei lavori non è infatti il compito principale dei membri del team di sviluppo. L’approccio agile adattivo presenta il limite di avere una prospettiva temporale limitata, determinata dal numero ridotto di iterazioni o passi che si possono pianificare.

👉Quindi la pianificazione agile va opportunamente integrata per avere una prospettiva temporale che copra tutto il tempo di sviluppo, che normalmente è di molti mesi e molto spesso di 1 o più anni.

In altre parole occorre

1. poter scomporre il piano di lungo termine in passi di medio termine o  release di sviluppo. Ciascuna release contiene i deliverable di alto livello, o macro argomenti,  che verranno sviluppati.
2. definire in maniera dettagliata il backlog con i macro argomenti, le relative storie  e i passi o iterazioni, della release in sviluppo. All’interno di ciascuno dei piccoli passi o iterazioni le kanban board sono importanti per tracciare il flusso di lavoro.
3. definire in maniera più grezza quali sono i macro argomenti da consegnare nelle release successive.
4. Il piano delle release è inoltre associato ad una serie di milestone che sono tipicamente quelle di fine release, alle quali si aggiungono altre significative all’interno di una o più release.

La modalità agile va pertanto integrata con un piano delle milestone tipico dell’approccio classico a cascata o waterfall.

La pianificazione è quindi multilivello

L’agile che si concentra sui deliverable e quindi sul valore consegnato è molto vicina all’Earned Value proprio del project management classico.

Lo sviluppo dei prodotti fisici richiede molte competenze con impiego delle stesse non omogeneo. Alcune competenze richiedono un impiego a tempo pieno mentre altre richiedono un impiego a tempo parziale.

📢 Ritornerò in un prossimo articolo con una descrizione dettagliata delle macro funzionalità di un efficace ed efficiente sistema di gestione adattiva dei progetti di sviluppo di prodotti hardware.