Quanto difficile è sviluppare un prodotto che soddisfi le esigenze dei clienti e/o utilizzatori e che, nel contempo, sia industrialmente costruibile, abbia un basso impatto ambientale ed altro ancora?
E’ molto difficile, e ancora di più difficile è farlo in tempi brevi e senza importanti rifacimenti del prodotto stesso.
Una volta validato il prodotto si apportano infatti al prodotto le modifiche necessarie per renderlo industrialmente producibile e manutenibile.
Questa fase è costosa e allunga i tempi specialmente per prodotti molto innovativi.
Lo sviluppo di nuovi prodotti è da sempre condizionato da una molteplicità di aspetti che considerano la prospettiva del cliente e la prospettiva dell’azienda.
In particolare sono almeno 11 questi aspetti:
-
-
Progettazione per il Montaggio
-
-
-
Progettazione per il Post-Vendita
-
-
-
Progettazione per gli Acquisti.
-
-
-
Progettazione per la Costruzione
-
-
-
Progettazione per il Costo
-
-
-
Progettazione per l’Affidabilità
-
-
-
Progettazione per l’Ambiente e il relativo Impatto
-
-
-
Progettazione per il Riciclaggio
-
-
-
Progettazione per la Comunanza o Standardizzazione
-
-
-
Progettazione per lo Smontaggio
-
-
-
Progettazione per la Sicurezza
-
L’approccio che tiene in conto queste 11 prospettive viene chiamato Design for X.
La Progettazione Concorrente o Concurrent Engineering, di cui il Design for X è uno degli strumenti, è la modalità raccomandata da anni per di sviluppare nuovi prodotti.
In tanti anni di sviluppo di prodotti con metodi tradizionali a cascata non sono mai riuscito, con i miei team, a tenere pienamente conto di tutti questi aspetti.
La pratica delle riunioni di riesame di progetto (Design Review) è una modalità che ho impiegato per coinvolgere le persone direttamente interessate ad uno o più aspetti del Design for X.
Il successo è stato solo parziale.
Solamente con l’adozione dell’approccio Agile, grazie al fatto che il team è cross-funzionale, è stato possibile realizzare Design for X e il Concurrent Engineering
Di fatto le riunioni di sprint review si sono sostituite ai design review.
Come ho descritto nel mio articolo “Chi paga la velocità dello sviluppo agile dei prodotti?…il Costo del Ritardo” , l’approccio Agile ha come obiettivo una sostanziale sovrapposizione e integrazione delle diverse fasi di sviluppo.
Se pensiamo alle 11 prospettive del Design for X è facile avere team con più di 15 persone.
Un team ottimale dovrebbe limitarsi a non più di 9 persone per funzionare al meglio.
E’ insensato coinvolgere sempre, così tante persone, in tutti gli eventi di sviluppo prodotto.
E’ un grande spreco di risorse e di tempo, che produce la sindrome di rifiuto delle riunioni.
Per questo è opportuno scomporre il Team di Progetto in 2 team integrati fra loro:
-
- Un Team Permanente o Core Team, composto da persone impegnate a tempo pieno nel progetto
-
- Un Team a Tempo Parziale o Shell Team, composto da persone impegnate con precise regole di ingaggio all’interno del progetto progetto.
Per la mia esperienza le funzioni dello Shell Team, impegnate a tempo parziale, sono tipicamente:
-
-
Preventivisti e consutivatori dei costi
-
-
-
Tecnici per il calcolo e la simulazione
-
-
-
Industrializzatori e/o esperti di tempi e metodi
-
-
-
Acquisitori
-
-
-
Tecnologi di processo
-
-
-
Collaudatori / Validatori / Sperimentatori
-
-
-
Persone del Marketing
-
In tal modo le persone dello Shell Team potranno essere coinvolte anche in più progetti.
Questo diventa una grande opportunità per il trasferimento continuo di conoscenza fra i diversi team di sviluppo di prodotti diversi.
Ho visto in questi anni una crescita integrata e reciproca delle competenze dei “progettisti” e degli “industrializzatori”, che apprendono come la sfida stia nel rendere costruibili componenti non necessariamente semplici e banali.