Il visibility gap in R&D: perche i progetti hardware slittano e il management lo scopre per ultimo

Definizione: il visibility gap in R&D e il tempo che passa tra il momento in cui un problema tecnico nasce dentro un team di ingegneria e il momento in cui il management lo viene a sapere in una forma su cui puo decidere. Nei progetti hardware, firmware ed embedded questo intervallo dura tipicamente da due a sei settimane — ed e li che si accumula gran parte del costo di un progetto in ritardo.

Questo articolo e pensato per CTO, VP Engineering e R&D Director di aziende con 30-200 ingegneri, dove il budget R&D e una voce importante ma la visibilita in tempo reale sui progetti pre-produzione semplicemente non esiste.

Una scena che ogni CTO riconosce

Riunione del lunedi. Il CEO chiede al CTO come va il progetto del nuovo controller.

La risposta onesta e una catena di condizionali: il firmware e stabile, ma c'e un guasto intermittente quando la funzione X si combina con la Y, e il test di durata non e partito perche il banco e condiviso con un altro progetto, quindi la consegna e "tre settimane, forse quattro — dipende."

Il CEO sente una cosa sola: non lo sappiamo. Il cliente sente una cosa sola: non riescono a impegnarsi su una data. E gli ingegneri, tre piani sotto, sapevano dello spike di consumo gia da dieci giorni. Lo avevano detto alla macchinetta del caffe. Non e mai arrivato a qualcuno che potesse decidere.

Questo e il visibility gap. Non mancanza di informazione — l'informazione esiste — ma un fallimento di traduzione tra la realta ingegneristica e le decisioni di management.

Perche i progetti R&D sono davvero in ritardo

Dopo 14 anni tra sviluppo firmware, progettazione di banchi prova, logistica robotizzata e gestione di portafogli di progetti di innovazione in parallelo, ho visto lo stesso schema in ogni organizzazione, indipendentemente da dimensione e settore:

1. I problemi nascono presto e in silenzio. Un campione di molla cede a fatica a 347 cicli invece di 1.000. Un chipset nuovo mostra deriva di tensione sotto zero. La prenotazione del laboratorio di certificazione slitta. Nessuno di questi eventi e un segreto: gli ingegneri li conoscono il giorno stesso in cui accadono.
2. La conoscenza resta locale. L'informazione vive in un thread Slack, nello screenshot di un oscilloscopio, in una conversazione in corridoio. E reale, ma e destrutturata e non risale la catena.
3. Il reporting di stato filtra via il rischio. Alla domanda "come va?", i team rispondono "on track" — che di solito significa "non e ancora fallito". L'ottimismo vago e la lingua di default delle riunioni di stato.
4. La scoperta avviene a ridosso della deadline. Il management apprende del problema quando non puo piu essere assorbito: lo slittamento e ormai visibile, le opzioni di mitigazione sono scadute e l'unica decisione rimasta e come scusarsi con il cliente.

Il ritardo in se raramente e la parte costosa. La parte costosa e scoprirlo tardi. Un problema di materiale trovato al giorno 12 costa una telefonata al fornitore e un sovrapprezzo per la consegna urgente. Lo stesso problema trovato al giorno 30 costa una riprogettazione, una consegna mancata, una penale contrattuale e un cliente che da quel momento gonfia di margine ogni vostra data futura.

Perche Jira, i Gantt e gli standup non chiudono il gap

La maggior parte delle organizzazioni risponde con piu tracking: ticket piu granulari, Gantt piu dettagliati, riunioni di stato piu frequenti. Raramente funziona, per una ragione strutturale:

Gli strumenti di project management tracciano i task. Il visibility gap vive nei rischi.

Un task puo essere al 90% mentre il progetto e gia morto, perche nel 10% restante c'e l'unica cosa che nessuno ha validato: il materiale mai testato, il laboratorio mai prenotato, il comportamento termico mai misurato. Al contrario, un progetto puo sembrare indietro sui task ed essere perfettamente sano, perche tutto cio che era davvero incerto e gia stato validato.

Il completamento dei task misura l'attivita. La validazione dei rischi misura la verita. I progetti hardware ed embedded slittano sulla seconda.

C'e anche una ragione umana: il tracking dettagliato scarica lavoro amministrativo sugli ingegneri, che rispondono razionalmente alimentando il sistema con l'aggiornamento minimo indispensabile. Lo strumento si riempie di dati che descrivono il movimento, non la realta.

Cosa significa davvero "pronto" nell'R&D hardware

La domanda a piu alta leva che un leader tecnico possa fare al proprio team non e "quando sara finito?". E:

"Quali sono le cinque cose che devono essere vere perche questo prodotto possa essere consegnato — e quali di queste non conosciamo ancora?"

In un tipico progetto elettromeccanico le risposte somigliano a queste: la molla deve superare 1.000 cicli di attuazione; il controller deve rispondere sotto i 100 ms nel 99% dei casi; l'assieme deve restare stabile da -20 a +60 gradi; l'unita deve passare la certificazione di sicurezza; la distinta base deve restare sotto il costo obiettivo.

Ognuna di queste e un criterio di successo con un target misurabile, un metodo di validazione, un responsabile e una data. E ognuna porta con se un rischio con nome e cognome: un lotto fornitore mai provato, un chipset mai testato a bassa temperatura, un laboratorio con sei settimane di coda.

Quando criteri e rischi sono espliciti, lo stato del progetto smette di essere un'opinione. "Siamo on track?" diventa una domanda fattuale: quanti criteri sono validati, quanti in corso, e la velocita di validazione e compatibile con la deadline?

Un framework pratico: visibilita guidata dai rischi

Il cuore di questo approccio si puo implementare con la sola disciplina, prima di qualunque strumento:

1. Definire "pronto" il primo giorno. Due ore con gli ingegneri senior. Output: 5 criteri di successo, ciascuno con target quantitativo e metodo di validazione.
2. Dare un nome alle incognite. Per ogni criterio, scrivere la cosa piu grossa che il team non ha mai testato o misurato. Questi rischi nominati diventano la spina dorsale di ogni conversazione di stato.
3. Fare domande quantitative ogni giorno. Non "come va il test di durata?" ma "quanti cicli completati, a quale velocita giornaliera, e quella velocita raggiunge il target prima della deadline?". Due minuti al giorno per ingegnere bastano.
4. Trattare il silenzio come un dato. Un criterio senza aggiornamenti da 72 ore non e neutro: o e bloccato o e dimenticato, ed entrambi i casi meritano una domanda.
5. Trasformare le scoperte in decisioni con un prezzo. Ogni rischio rilevato deve arrivare a chi decide nella forma: evidenza, impatto quantificato, opzioni con costi, decisione richiesta. "La molla ha ceduto a 347 cicli; senza intervento lo slittamento e di tre settimane e circa 50.000 euro; un lotto di grado superiore con consegna urgente costa 5.000 euro; decidere oggi." Quella frase e cio che la visibilita significa davvero.

Dove l'AI cambia l'economia del problema e nei passi da 3 a 5: i modelli linguistici oggi sono abbastanza buoni da generare domande giornaliere consapevoli del contesto, estrarre metriche dalle risposte destrutturate degli ingegneri, collegare le osservazioni nel tempo e far emergere i gap di velocita e le anomalie che un PM umano trova solo passando ore a rincorrere le persone. Il giudizio resta umano. La rincorsa no.

Domande frequenti

Cos'e il visibility gap in R&D?
E il ritardo tra il momento in cui un problema tecnico compare dentro un team di ingegneria e il momento in cui il management lo apprende in forma azionabile. Nello sviluppo hardware ed embedded copre comunemente da due a sei settimane.

Perche i progetti hardware slittano in modo piu imprevedibile di quelli software?
Perche la validazione fisica ha cicli di feedback lunghi e seriali: banchi di durata, camere climatiche, laboratori di certificazione e lead time dei fornitori non si parallelizzano gratis, e un singolo campione fallito puo invalidare settimane di piano.

Strumenti di project management migliori risolvono il problema?
Non da soli. I task tracker misurano l'attivita; gli slittamenti nascono nei rischi non validati. Chiudere il gap richiede modellare cio che non si sa, non solo cio che e assegnato.

Qual e il primo passo piu rapido?
Fare l'esercizio delle due ore: definire le cinque condizioni di "pronto" e l'incognita piu grande dietro ciascuna. La maggior parte dei team scopre il proprio vero percorso critico in quella riunione — e raramente e dove dice il Gantt.

Vinicio Lupo si occupa di AI Process Intelligence per team tecnici, R&D e PMO: trasformare il caos ingegneristico non misurabile in sistemi chiari, misurabili e automatizzabili. Se i tuoi progetti continuano a sorprenderti due settimane prima della deadline, il problema probabilmente non e il tuo team — e la tua visibilita.