Sei miti dello sviluppo del prodotto

Artwork: Ricky Allman, Undertable, 2011, acrilico su tela, 72″ x 48″

La maggior parte dei responsabili dello sviluppo del prodotto lottano sempre per portare a termine i progetti in tempo e nel budget. Non hanno mai abbastanza risorse per portare a termine il lavoro, e i loro capi esigono programmi e risultati prevedibili. Così i manager spingono i loro team ad essere più parsimoniosi, a scrivere piani più dettagliati e a minimizzare le variazioni di programma e gli sprechi. Ma questo approccio, che può funzionare bene nel trasformare le fabbriche sottoperformanti, può effettivamente danneggiare gli sforzi di sviluppo del prodotto.

Anche se molte aziende trattano lo sviluppo del prodotto come se fosse simile alla produzione, i due sono profondamente diversi. Nel mondo della produzione di oggetti fisici, i compiti sono ripetitivi, le attività sono ragionevolmente prevedibili, e gli oggetti creati possono essere in un solo posto alla volta. Nello sviluppo del prodotto molti compiti sono unici, i requisiti del progetto cambiano costantemente e l’output – grazie, in parte, all’uso diffuso della progettazione avanzata assistita dal computer e della simulazione e all’incorporazione del software nei prodotti fisici – sono informazioni, che possono risiedere in più posti allo stesso tempo.

Il mancato apprezzamento di queste differenze critiche ha dato origine a diversi errori che minano la pianificazione, l’esecuzione e la valutazione dei progetti di sviluppo del prodotto. Insieme, abbiamo passato più di 50 anni a studiare e consigliare le aziende sugli sforzi di sviluppo del prodotto, e abbiamo incontrato queste idee sbagliate – così come altre che sorgono per motivi diversi – in una vasta gamma di settori, tra cui semiconduttori, auto, elettronica di consumo, dispositivi medici, software e servizi finanziari. In questo articolo li esporremo e offriremo modi per superare i problemi che creano.

Fallacia 1: Un alto utilizzo delle risorse migliorerà le prestazioni.

In entrambe le nostre ricerche e il nostro lavoro di consulenza, abbiamo visto che la stragrande maggioranza delle aziende si sforza di utilizzare completamente le proprie risorse di sviluppo prodotto. (Uno di noi, Donald, attraverso indagini condotte nei corsi per dirigenti al California Institute of Technology, ha scoperto che il manager medio dello sviluppo prodotto mantiene l’utilizzo della capacità sopra il 98%). La logica sembra ovvia: i progetti richiedono più tempo quando le persone non lavorano al 100% del tempo – e quindi, un’organizzazione di sviluppo occupata sarà più veloce e più efficiente di una che non è altrettanto brava a utilizzare le sue persone.

Ma in pratica questa logica non regge. Abbiamo visto che la velocità, l’efficienza e la qualità dell’output dei progetti diminuiscono inevitabilmente quando i manager riempiono completamente i piatti dei loro dipendenti addetti allo sviluppo del prodotto, indipendentemente da quanto siano abili quei manager. Un alto utilizzo ha seri effetti collaterali negativi, che i manager sottovalutano per tre motivi:

Non tengono pienamente conto della variabilità intrinseca del lavoro di sviluppo.

Molti aspetti dello sviluppo del prodotto sono imprevedibili: quando arriveranno i progetti, quali compiti individuali richiederanno, e quanto tempo impiegheranno i lavoratori che non hanno mai affrontato tali compiti prima per farli. Le aziende, tuttavia, sono più familiari con processi ripetitivi come la produzione e l’elaborazione delle transazioni, dove il lavoro non cambia molto e le sorprese sono poche e lontane tra loro. Tali processi si comportano in modo ordinato quando l’utilizzo delle risorse aumenta. Aggiungi il 5% di lavoro in più, e ci vorrà il 5% di tempo in più per completarlo.

I processi ad alta variabilità si comportano in modo molto diverso. Quando l’utilizzo aumenta, i ritardi si allungano drammaticamente. Aggiungete il 5% in più di lavoro, e per completarlo potrebbe volerci il 100% in più. Ma poche persone capiscono questo effetto. Nella nostra esperienza con centinaia di team di sviluppo prodotto, abbiamo scoperto che la maggior parte erano significativamente sovraccarichi. Per completare tutti i progetti in tempo e nel budget, alcune organizzazioni con cui abbiamo lavorato avrebbero avuto bisogno di almeno il 50% di risorse in più di quelle che avevano.

È vero che una certa variabilità è il risultato di una mancanza di disciplina, e che alcune attività di sviluppo prodotto (come la progettazione di componenti per un prototipo di aereo o l’esecuzione di test clinici) includono un lavoro più ripetitivo. Ma anche se parte del lavoro è prevedibile, quando è combinato con altro lavoro imprevedibile, si vedranno problemi di code.

Non capiscono come le code influenzino la performance economica.

L’alto utilizzo delle risorse crea inevitabilmente code di progetti. Quando il lavoro parzialmente completato rimane inattivo, in attesa che la capacità diventi disponibile, la durata del progetto complessivo cresce. Le code ritardano anche il feedback, inducendo gli sviluppatori a seguire più a lungo percorsi improduttivi. Rendono difficile alle aziende di adattarsi alle esigenze del mercato in evoluzione e di rilevare i punti deboli del loro prodotto prima che sia troppo tardi. Ironicamente, questi problemi sono proprio quelli che i manager pensano che un alto utilizzo permetterà ai loro team di evitare.

Anche quando i manager sanno che stanno creando delle code, raramente si rendono conto del costo economico. Anche se questo costo può essere quantificato, abbiamo scoperto che la stragrande maggioranza delle aziende non lo calcola. I manager devono soppesare i costi delle code contro i costi della capacità sottoutilizzata per trovare il giusto equilibrio.

Nello sviluppo del prodotto, l’inventario work-in-process è prevalentemente invisibile.

Le code di produzione consistono in cose fisiche, e quando l’inventario in una fabbrica raddoppia, è ovvio. Questo non è il caso dello sviluppo del prodotto, dove l’inventario consiste in gran parte di informazioni, come la documentazione del progetto, le procedure e i risultati dei test e le istruzioni per costruire i prototipi. Quando l’inventario raddoppia in un processo di ingegneria, non ci sono segni fisici. Inoltre, poiché gli standard contabili richiedono che la maggior parte delle scorte R&D siano riportate a valore zero, i rendiconti finanziari non danno alcuna indicazione di gravi eccessi di inventario nello sviluppo dei prodotti.

È molto difficile combattere un problema che non si può vedere o misurare. Consideriamo la situazione di una grande azienda farmaceutica. Diversi anni fa il suo nuovo capo della scoperta dei farmaci ha affrontato un dilemma manageriale. Come altri dirigenti che gestiscono grandi organizzazioni di R&D, stava cercando di trovare modi per rendere i suoi scienziati più innovativi. Voleva che sperimentassero di più con nuovi composti chimici che potessero generare nuovi farmaci promettenti e, allo stesso tempo, che eliminassero il più presto possibile i candidati non promettenti. Gli esperimenti con gli organismi viventi, tuttavia, erano responsabilità della sperimentazione animale, un dipartimento che non era sotto il suo controllo ed era gestito come un centro di costo. Veniva valutato in base all’efficienza con cui utilizzava le risorse di sperimentazione, il che naturalmente portava ad un alto utilizzo. Di conseguenza, gli scienziati nella scoperta dei farmaci dovevano aspettare da tre a quattro mesi per i risultati di test che richiedevano poco più di una settimana per essere eseguiti. L’organizzazione “ben gestita” dei test ostacolava il progresso dell’unità di scoperta.

La soluzione ovvia a questi problemi è di fornire un buffer di capacità nei processi che sono altamente variabili. Alcune aziende lo hanno capito da tempo. Per decenni, 3M ha programmato gli sviluppatori di prodotti all’85% della loro capacità. E Google è famosa per il suo “20% di tempo” (che permette agli ingegneri di lavorare un giorno alla settimana su qualsiasi cosa vogliano – una pratica che significa capacità extra disponibile se un progetto è in ritardo). Tuttavia, nella nostra esperienza questo tipo di soluzione è piuttosto difficile da implementare. Come discuteremo, poche organizzazioni possono resistere alla tentazione di usare fino all’ultimo pezzo di capacità disponibile. I manager iniziano di riflesso a lavorare di più ogni volta che vedono del tempo libero.

Ma ci sono altre soluzioni possibili:

Cambiare i sistemi di gestione-controllo.

Per l’azienda farmaceutica, questo potrebbe comportare l’adozione di misure per allineare gli obiettivi dell’unità di test sugli animali con quelli dell’unità di scoperta. L’azienda potrebbe, per esempio, premiare la sperimentazione animale per le risposte tempestive (misurando il tempo dalla richiesta al completamento del test) piuttosto che l’utilizzo delle risorse.

Aumentare selettivamente la capacità.

Aggiungere risorse extra alle aree in cui i tassi di utilizzo sono del 70% o superiori può ridurre significativamente i tempi di attesa. Se l’azienda farmaceutica facesse questo nei test sugli animali, otterrebbe un feedback sui nuovi composti chimici molto più velocemente. Nelle impostazioni in cui i test sono condotti con la modellazione e la simulazione al computer, l’aumento della capacità è spesso relativamente poco costoso, dal momento che comporta solo l’acquisto di attrezzature informatiche aggiuntive e licenze software.

Limitare il numero di progetti attivi.

Se l’azienda farmaceutica non potesse aumentare la capacità dei test sugli animali, potrebbe comunque abbassare il tasso di utilizzo riducendo il numero di progetti attivi che esplorano nuovi composti chimici. La disciplina di porre un limite rigido a ciò che va in una pipeline di sviluppo del prodotto spesso si traduce in una maggiore attenzione e in priorità più chiare.

Rendere l’inventario del work-in-process più facile da vedere.

Un metodo è quello di utilizzare schede di controllo visivo. Queste possono assumere un certo numero di forme, ma la chiave è avere un qualche tipo di token fisico, come una nota Post-it, che rappresenti il lavoro di sviluppo (vedi l’esposizione “Tipica scheda di controllo del lavoro in corso”). Una scheda di controllo dovrebbe mostrare tutto il lavoro attivo e mostrare in quale stato si trova ogni parte del progetto. Dovrebbe essere al centro del processo di gestione del team. I team possono tenere riunioni giornaliere di 15 minuti intorno a queste lavagne per coordinare gli sforzi e mantenere il lavoro in movimento.

Fallacia 2: Elaborare il lavoro in grandi lotti migliora l’economia del processo di sviluppo.

Una seconda causa di code nello sviluppo del prodotto è la dimensione dei lotti. Diciamo che un nuovo prodotto è composto da 200 componenti. Potreste scegliere di progettare e costruire tutte e 200 le parti prima di testarle. Se invece si progettassero e costruissero solo 20 componenti prima di iniziare i test, la dimensione del lotto sarebbe inferiore del 90%. Questo avrebbe un effetto profondo sul tempo di coda, perché la coda media in un processo è direttamente proporzionale alla dimensione del lotto.

La riduzione delle dimensioni dei lotti è un principio critico della produzione snella. I piccoli lotti permettono ai produttori di ridurre il lavoro nel processo e accelerare il feedback, il che, a sua volta, migliora i tempi di ciclo, la qualità e l’efficienza. I piccoli lotti hanno un’utilità ancora maggiore nello sviluppo dei prodotti, ma pochi sviluppatori si rendono conto della potenza di questo metodo. Di nuovo, poiché le informazioni che stanno producendo sono per lo più invisibili per loro, lo sono anche le dimensioni dei lotti. In secondo luogo, gli sviluppatori sembrano avere un pregiudizio inerente all’uso di grandi lotti, forse perché credono erroneamente che grandi lotti producano economie di scala.

In un processo ben gestito, la dimensione del lotto bilancerà i costi di transazione e di mantenimento (vedere la mostra “Come determinare la dimensione ottimale del lotto”). È simile all’acquisto di uova al supermercato. Se compri una fornitura di 12 mesi in un solo viaggio, il tuo costo di transazione è basso, ma la maggior parte delle uova si rovinerà, aumentando il tuo costo di mantenimento. Se compri una fornitura di un giorno alla volta, il deterioramento sarà basso, ma i tuoi costi di transazione saranno alti. Intuitivamente, si cerca di trovare un equilibrio tra le due cose.

Le aziende che capiscono come funziona hanno sfruttato i progressi dell’IT per ridurre le dimensioni dei lotti, spesso con risultati sorprendenti. Alcune aziende di software che erano solite testare grandi lotti di codice ogni 90 giorni, ora testano lotti molto più piccoli più volte al giorno. Un produttore di periferiche per computer che ha usato un approccio simile con il suo gruppo software ha ridotto il tempo del ciclo di test del software del 95% (da 48 mesi a 2,5 mesi), ha migliorato l’efficienza del 220% e ha diminuito i difetti del 33%. I risparmi sui costi sono stati il doppio di quanto l’azienda si aspettava. Anche se questi risultati sono stati eccezionali, abbiamo scoperto che la riduzione della dimensione dei lotti migliora significativamente la maggior parte dei progetti di sviluppo. Allo stesso modo, gli strumenti computerizzati di modellazione e simulazione hanno abbassato drasticamente la dimensione ottimale dei lotti di sperimentazione e test nelle aziende che sviluppano prodotti fisici.

Fallacia 3: Il nostro piano di sviluppo è ottimo; dobbiamo solo attenerci ad esso.

In tutto il nostro lavoro di consulenza e ricerca, non ci siamo mai imbattuti in un singolo progetto di sviluppo prodotto i cui requisiti siano rimasti stabili durante il processo di design. Eppure molte organizzazioni ripongono una fiducia smodata nei loro piani. Attribuiscono qualsiasi deviazione alla cattiva gestione ed esecuzione e, per minimizzarle, tracciano attentamente ogni passo rispetto agli obiettivi intermedi e alle pietre miliari. Questo modo di pensare va bene per attività altamente ripetitive in processi di produzione consolidati. Ma può portare a scarsi risultati nell’innovazione di prodotto, dove ogni giorno si generano nuove intuizioni e le condizioni cambiano costantemente.

Un classico studio di problem solving tecnico fatto da Thomas Allen del MIT evidenzia la natura fluida del lavoro di sviluppo. Ha scoperto che gli ingegneri che stavano sviluppando un sottosistema aerospaziale concepivano e valutavano un certo numero di alternative di progettazione prima di selezionare quella che ritenevano essere la migliore. Lungo la strada le loro preferenze cambiavano spesso, mentre provavano e raffinavano le soluzioni tecniche concorrenti. Questo è tipico nei progetti di innovazione: I test e la sperimentazione rivelano cosa funziona e cosa no, e le ipotesi iniziali sui costi e sul valore possono essere smentite.

Definire i bisogni dei clienti può anche essere difficile all’inizio di un progetto di sviluppo del prodotto. Se ci si pensa, questo non è sorprendente: Non è facile per i clienti specificare accuratamente i loro bisogni per soluzioni che non esistono ancora. Infatti, la familiarità con gli attributi dei prodotti esistenti può interferire con la capacità di un individuo di esprimere il suo bisogno di un nuovo prodotto. Le preferenze dei clienti possono anche cambiare bruscamente durante il corso di un progetto di sviluppo, quando i concorrenti introducono nuove offerte ed emergono nuove tendenze.

Per tutte queste ragioni, attenersi al piano originale – non importa quanto eccellente sia la sua concezione e quanto abile la sua esecuzione – può essere una ricetta per il disastro. Questo non significa che non crediamo nella pianificazione. Lo sviluppo del prodotto è un insieme di attività complesse che richiedono un’attenta coordinazione e l’attenzione al più piccolo dettaglio. Tuttavia, il piano dovrebbe essere trattato come un’ipotesi iniziale che viene costantemente rivista man mano che le prove si sviluppano, i presupposti economici cambiano e l’opportunità viene rivalutata. (Vedere “The Value Captor’s Process,” di Rita Gunther McGrath e Thomas Keil, HBR maggio 2007.)

Fallacia 4: Prima si inizia il progetto, prima sarà finito.

Come abbiamo discusso prima, i tempi morti sono un anatema per i manager. Essi tendono a sfruttare ogni tempo morto iniziando un nuovo progetto. Anche se il compito non può essere completato perché le persone devono tornare ad un altro progetto, i manager ragionano sul fatto che qualsiasi cosa fatta sul nuovo progetto è lavoro che non dovrà essere fatto più tardi. Questo modo di pensare porta le aziende ad iniziare più progetti di quelli che possono perseguire vigorosamente, diluendo le risorse.

Questa diluizione è pericolosa. Se un’azienda si imbarca in un progetto prima di avere le risorse per andare avanti, inciamperà lentamente nel processo di sviluppo. Questo è problematico perché il lavoro di sviluppo del prodotto è altamente deperibile: Le ipotesi sulle tecnologie e sul mercato possono diventare rapidamente obsolete. Più lento è il progresso di un progetto, maggiore è la probabilità che debba essere riorientato. Infatti, un ramo dell’esercito ha scoperto che i suoi superamenti dei costi e dei tempi erano esponenzialmente proporzionali (alla quarta potenza) alla durata di un progetto. In altre parole, quando il programma originale di un progetto raddoppiava, il costo e lo sforamento del programma aumentavano di un fattore 16.

L’importanza di ridurre la quantità di lavoro in corso è evidente quando guardiamo una delle formule classiche della teoria delle code: La legge di Little. Essa afferma semplicemente che, in media, il tempo di ciclo è proporzionale alla dimensione della coda divisa per la velocità di elaborazione. Così, se 20 persone sono davanti a voi in fila da Starbucks e il barista serve cinque persone al minuto, sarete serviti in quattro minuti. È possibile ridurre il tempo di ciclo aumentando la velocità di elaborazione o riducendo il numero di lavori in corso. Nella maggior parte dei contesti quest’ultima è l’unica scelta pratica.


Per alcuni sviluppatori di prodotti la soluzione è stata quella di controllare rigorosamente la velocità di inizio lavoro. Lo fanno corrispondere al ritmo con cui il lavoro viene effettivamente completato; gestiscono attentamente il numero di progetti in corso; si assicurano che una volta che un progetto viene lanciato, sia adeguatamente seguito fino al suo completamento; e resistono alla tentazione di rubare risorse da un progetto in corso per spremerne di nuove.

Fallacia 5: Più caratteristiche mettiamo in un prodotto, più piacerà ai clienti.

I team di sviluppo prodotto sembrano credere che aggiungere caratteristiche crei valore per i clienti e sottrarle distrugga valore. Questo atteggiamento spiega perché i prodotti sono così complicati: I telecomandi sembrano impossibili da usare, i computer richiedono ore per essere impostati, le automobili hanno così tanti interruttori e manopole che assomigliano alle cabine di pilotaggio degli aerei, e persino l’umile tostapane ora è dotato di un manuale e di display LCD.

Le aziende che sfidano la convinzione che più è meglio creano prodotti che sono eleganti nella loro semplicità. Bang & Olufsen, il produttore danese di prodotti audio, televisori e telefoni, capisce che i clienti non vogliono necessariamente armeggiare con l’equalizzatore, il bilanciamento e altri controlli per trovare la combinazione ottimale di impostazioni per ascoltare la musica. I suoi altoparlanti di fascia alta fanno automaticamente le regolazioni necessarie per riprodurre una canzone con la massima fedeltà possibile all’originale. Tutto ciò che rimane da selezionare per gli utenti è il volume.

Per fare in modo che le aziende acquistino e implementino il principio che meno può essere più è difficile perché richiede uno sforzo extra in due aree dello sviluppo del prodotto:

Definire il problema.

Articolare il problema che gli sviluppatori cercheranno di risolvere è la parte più sottovalutata del processo di innovazione. Troppe aziende vi dedicano troppo poco tempo. Ma questa fase è importante perché è dove i team sviluppano una chiara comprensione di quali sono i loro obiettivi e generano ipotesi che possono essere testate e raffinate attraverso esperimenti. La qualità di una dichiarazione del problema fa la differenza nella capacità di un team di concentrarsi sulle poche caratteristiche che contano davvero.

Quando Walt Disney stava progettando Disneyland, non si affrettò ad aggiungere più caratteristiche (giostre, tipi di cibo, quantità di parcheggio) di quelle che avevano gli altri parchi di divertimento. Piuttosto, cominciò a porsi una domanda molto più grande: Come poteva Disneyland fornire ai visitatori un’esperienza magica? Certamente, la risposta non è arrivata da un giorno all’altro; ha richiesto una ricerca minuziosa e dettagliata, una sperimentazione costante e una profonda comprensione di cosa significasse “magico” per Disney e i suoi clienti. IDEO e altre aziende hanno fasi dedicate in cui si immergono completamente nel contesto in cui il prodotto o servizio previsto sarà utilizzato. I loro sviluppatori leggono tutto ciò che è interessante sui mercati, osservano e intervistano i futuri utenti, ricercano le offerte che saranno in concorrenza con il nuovo prodotto e sintetizzano tutto ciò che hanno imparato in immagini, modelli e diagrammi. Il risultato sono intuizioni profonde sui clienti che vengono testate, migliorate o abbandonate durante il processo di sviluppo iterativo.

Determinare cosa nascondere o omettere.

I team sono spesso tentati di mettersi in mostra producendo soluzioni tecniche brillanti che stupiscono i loro colleghi e il management. Ma spesso i clienti preferiscono un prodotto che funzioni semplicemente senza sforzo. Dal punto di vista del cliente, le migliori soluzioni risolvono un problema nel modo più semplice e nascondono il lavoro di cui gli sviluppatori sono così orgogliosi.

Un’azienda che ha capito questo è Apple. È nota per molte cose – prodotti innovativi, design elegante e marketing intelligente – ma forse la sua più grande forza è la sua capacità di arrivare al cuore di un problema. (Vedere “The Real Leadership Lessons of Steve Jobs”, di Walter Isaacson, nel nostro numero di aprile). Come il defunto Steve Jobs ha spiegato una volta, “Quando inizi a guardare un problema e sembra davvero semplice, non capisci davvero la complessità del problema. E le tue soluzioni sono troppo semplificate. Poi entri nel problema e vedi che è davvero complicato. E te ne esci con tutte queste soluzioni contorte….È qui che la maggior parte delle persone si ferma”. Non Apple. Continua a lavorare. “La persona veramente grande continuerà ad andare avanti”, ha detto Jobs, “e troverà… il principio chiave alla base del problema e troverà una soluzione bella ed elegante che funziona.”

Determinare quali caratteristiche omettere è importante tanto quanto – e forse più importante che – capire quali includere. Sfortunatamente, molte aziende, nel tentativo di essere innovative, inseriscono ogni possibile campanello e fischio senza considerare pienamente fattori importanti come il valore per i clienti e la facilità d’uso. Quando queste aziende omettono alcune funzionalità pianificate, è tipicamente perché hanno bisogno di tagliare i costi o perché sono rimasti indietro rispetto al programma o perché il team ha fallito in qualche altro modo.

Invece, i manager dovrebbero concentrarsi sul capire se l’eliminazione di qualsiasi caratteristica proposta potrebbe migliorare un particolare prodotto e permettere al team di concentrarsi su cose che veramente aumentano l’esperienza complessiva del cliente. Questo può essere determinato trattando ogni presunto requisito come un’ipotesi e testandolo in piccoli e rapidi esperimenti con i potenziali clienti.

I team di sviluppo spesso assumono che i loro prodotti sono finiti quando non si possono aggiungere altre caratteristiche. Forse la loro logica dovrebbe essere il contrario: I prodotti si avvicinano alla perfezione quando non si possono più eliminare altre caratteristiche. Come disse una volta Leonardo da Vinci, “La semplicità è l’ultima sofisticazione.”

Fallacia 6: Avremo più successo se ci riusciamo la prima volta.

Molti progetti di sviluppo prodotto non riescono a raggiungere i loro obiettivi di budget, scadenze e prestazioni tecniche. Indubbiamente, una cattiva pianificazione, processi rigidi e una leadership debole giocano un ruolo. Ma un’altra causa spesso trascurata è la richiesta dei manager che i loro team “facciano bene la prima volta”. Richiedere il successo al primo passaggio orienta i team verso le soluzioni meno rischiose, anche se i clienti non le considerano un gran miglioramento rispetto a ciò che è già disponibile. Peggio ancora, i team sono poco incentivati a perseguire soluzioni innovative ai problemi dei clienti.

Per evitare di commettere errori, i team seguono un processo lineare in cui ogni fase (specificare, progettare, costruire, testare, scalare, lanciare) è attentamente monitorata in “porte” di revisione. Il lavoro sulla fase successiva non può iniziare finché il progetto non passa attraverso il cancello. Man mano che il progetto si muove lungo la linea, vengono presi impegni significativi e il costo per rispondere a nuove intuizioni aumenta di ordini di grandezza. I test di successo nelle ultime fasi sono celebrati, e le sorprese, non importa quanto siano preziose, sono considerate battute d’arresto. Sfortunatamente, un flusso di processo così lineare può causare il superamento del progetto perché il feedback dei test viene ritardato, i team si aggrappano alle cattive idee più a lungo di quanto dovrebbero, e i problemi non vengono scoperti finché non è costoso risolverli.

Una tolleranza per “sbagliare la prima volta” può essere la strategia migliore finché le persone iterano rapidamente e frequentemente e imparano rapidamente dai loro fallimenti. I progressi nelle tecnologie di simulazione e di prototipazione rapida hanno reso questo modo di operare molto più facile e meno costoso.

Considerate cosa abbiamo trovato in uno studio su 391 team che hanno progettato circuiti integrati personalizzati. I team che hanno seguito un approccio iterativo e condotto test precoci e frequenti hanno commesso più errori lungo il percorso. Ma poiché hanno usato tecnologie di prototipazione a basso costo, hanno superato (in termini di tempo e sforzo richiesto) le squadre che hanno cercato di ottenere il loro design giusto la prima volta. I team che hanno affrontato alti costi di prototipazione hanno investito più sforzi nelle specifiche, nello sviluppo e nella verifica. E poiché hanno fatto le loro iterazioni più tardi nel processo – e ne hanno fatte molte di meno – hanno ritardato la scoperta di problemi critici.

Sperimentare molte idee diverse è cruciale per i progetti di innovazione. Quando le persone sperimentano rapidamente e frequentemente, molti nuovi concetti falliranno, naturalmente. Ma questi fallimenti precoci possono essere desiderabili perché permettono ai team di eliminare rapidamente le opzioni scadenti e concentrarsi su alternative più promettenti. Un crash test che dimostra che il design di un’auto non è sicuro, un candidato farmaco che si dimostra tossico, o un’interfaccia utente software che confonde i clienti possono essere tutti risultati desiderabili – a condizione che si verifichino all’inizio di un processo, quando sono state impegnate poche risorse, i progetti sono ancora molto flessibili, e si possono provare altre soluzioni.

Un esempio classico dei vantaggi dell’approccio “fallisci presto, fallisci spesso” è la sorprendente vittoria di Team New Zealand nella Coppa America del 1995. Per testare le idee per migliorare il design della chiglia, il team ha usato due barche quasi identiche: una barca che è stata modificata nel corso del progetto e una barca “di controllo” che non lo era. Su base giornaliera, il team simulava ipotesi su una stazione grafica locale, applicava quelle che sembravano promettenti alla barca, la faceva gareggiare contro il controllo e analizzava i risultati. Al contrario, il suo concorrente, il Team Dennis Conner, che aveva accesso a computer più potenti (supercomputer alla Boeing), eseguiva grandi lotti di simulazioni ogni poche settimane e poi testava le possibili soluzioni su una barca. Il risultato: Team New Zealand ha completato molti più cicli di apprendimento, ha eliminato più rapidamente le idee poco promettenti e ha finito per battere la barca di Team Dennis Conner, Young America.

Quello che speriamo sia ormai chiaro è che gli esperimenti che risultano in fallimenti non sono necessariamente esperimenti falliti. Generano nuove informazioni che un innovatore non era in grado di prevedere. Più veloce è il ciclo di sperimentazione, più feedback possono essere raccolti e incorporati in nuovi cicli di esperimenti con idee nuove e potenzialmente rischiose. In un tale ambiente i dipendenti tendono a perseverare quando i tempi si fanno difficili, si impegnano in lavori più impegnativi e superano i loro colleghi avversi al rischio.

Ma creare questo tipo di ambiente non è facile – un argomento che Amy C. Edmondson della Harvard Business School ha esplorato in “Strategie per imparare dal fallimento” (HBR aprile 2011). Il fallimento può portare all’imbarazzo ed esporre le lacune nella conoscenza, il che può minare l’autostima degli individui e la loro posizione in un’organizzazione. Dopo tutto, quanto spesso i manager vengono promossi e i team premiati per l’esposizione precoce di fallimenti che portano un progetto ad essere ucciso – anche se la riassegnazione precoce di risorse preziose va a beneficio dell’azienda? Questo è particolarmente vero nelle organizzazioni che hanno costruito una “tolleranza zero per il fallimento” o un ambiente “senza errori” (Six Sigma).

Questo articolo appare anche in:

Thomas Alva Edison aveva capito tutto questo. Ha organizzato i suoi famosi laboratori intorno al concetto di sperimentazione rapida, collocando le officine meccaniche per la costruzione di modelli vicino alle stanze in cui venivano condotti gli esperimenti, in modo che i macchinisti potessero collaborare strettamente con i ricercatori. I laboratori avevano biblioteche che contenevano un gran numero di volumi in modo che le informazioni potessero essere trovate rapidamente; magazzini vicini con ampie quantità di forniture e una forza lavoro diversificata di artigiani, scienziati e ingegneri. Edison voleva essere sicuro che quando lui o i suoi uomini avevano un’idea, questa potesse essere immediatamente trasformata in un modello o prototipo funzionante. “La vera misura del successo è il numero di esperimenti che possono essere ammassati in 24 ore”, disse.

I progressi nella tecnologia dell’informazione, come la progettazione assistita dal computer, la modellazione e la simulazione, hanno già permesso alle aziende di fare grandi passi avanti nello sviluppo di prodotti migliori in meno tempo e ad un costo inferiore. Molte aziende, tuttavia, non hanno sfruttato il pieno potenziale di questi strumenti, perché il loro pensiero di gestione non si è evoluto velocemente come la tecnologia: Si avvicinano ancora al lavoro altamente variabile dello sviluppo del prodotto, che genera informazioni, come se fosse un lavoro di produzione. Con il continuo progresso dell’IT, l’opportunità di migliorare il processo di sviluppo del prodotto diventerà ancora più grande. Ma lo saranno anche i rischi per le aziende che non riescono a riconoscere che lo sviluppo del prodotto è profondamente diverso dalla produzione.