Articoli

team agile

L’organizzazione di un team Agile per la Progettazione Concorrente

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:

      1. Progettazione per il Montaggio

      1. Progettazione per il Post-Vendita

      1. Progettazione per gli Acquisti.

      1. Progettazione per la Costruzione

      1. Progettazione per il Costo

      1. Progettazione per l’Affidabilità 

      1. Progettazione per l’Ambiente e il relativo Impatto

      1. Progettazione per il Riciclaggio

      1. Progettazione per la Comunanza o Standardizzazione 

      1. Progettazione per lo Smontaggio

      1. 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.

    team agile

    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:

        1. Un Team Permanente o Core Team, composto da persone impegnate a tempo pieno nel progetto 

        1. 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.

        Lascia un commento

        Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

        Iscriviti alla newsletter
        e rimani aggiornato sulle novita’

        Altri approfondimenti sullo sviluppo prodotto Agile che ti potrebbero interessare

        Discovery & Construction

        Product Discovery & Product Construction

        Vi parlo dello sviluppo di prodotti innovativi, ispirandomi al libro “Prodotti da amare” di Marty Kagan. Vi è una grande differenza tra le aziende leader e le altre nel processo di creazione dei prodotti. Il concetto chiave è il “product discovery”: esplorare e testare le idee prima di investire pesantemente. Questo si integra con il “product delivery” o “construction”. L’autore del libro sottolinea l’importanza dei prototipi, che nell’HW io preferisco chiamare “pretotipi”, e di strumenti come Lean Canvas e Story Mapping. C’è troppa attenzione allo Scrum, quando invece è importante creare funzionalità realmente utili. Il libro è consigliato a chi vuole innovare veramente.

        Leggi Tutto »

        I pretotipi ovvero gli antesignani del prodotto

        I pretotipi sono dimostratori rapidi ed economici per testare idee chiave prima di creare prototipi completi. Parlo di un progetto di palettizzazione automatica dove abbiamo realizzato un pretotipo del componente più critico che era il vassoio in soli 15 giorni. Abbiamo risparmiato alcuni mesi e importanti investimenti. Questo pretotipo ha permesso di validare i materiali migliori con i quali costruire il vassoio definitivo.

        Leggi Tutto »

        Cos’è la Fabbrica Agile – Intervista StoryTime

        In questa intervista con Antonio Panareo di Story Time abbiamo parlato della fabbrica dell’innovazione in modalità agile che ho istituito durante la mia ultima esperienza aziendale. Istituire questa fabbrica agile è stata un’autentica scommessa e parlo dell’esperienza vissuta con i miei team.

        Leggi Tutto »