Il ritardo non è un incidente. È una proprietà emergente del sistema.
Nei progetti meccatronici il ritardo non arriva per sorpresa.
Arriva perché il sistema è stato costruito per produrlo, ecco cosa intendo.
Non è un fallimento di esecuzione. È un risultato coerente con come il lavoro è stato progettato — o meglio, con ciò che non è stato progettato.
La domanda che vale la pena farsi non è “perché siamo in ritardo?”
La domanda è: perché persone competenti, strumenti evoluti e metodologie solide producono comunque ritardi sistemici?
Il falso colpevole: il project management
La risposta standard, quando un progetto scivola, è sempre la stessa.
Più pianificazione. Più controllo. Più strumenti, informazioni più dettagliate, revisioni prodotti più frequenti, passaggi a più alti livelli decisionali più rapidi.
Il risultato? Il ritardo rimane. Cambia forma, si sposta di qualche settimana, ma non scompare.
Il motivo è semplice e scomodo:
Il project management sta gestendo effetti, non cause.
Un sistema di gestione efficiente applicato a un sistema mal strutturato produce inefficienza ben gestita. Il PM diventa sempre più bravo a rincorrere ciò che sfugge — non a eliminare la fonte della fuga.
Il vero nodo: la cross competenza non progettata
Qui sta il cuore del problema, e vale la pena essere precisi.
Cross competenza non significa presenza di più discipline nello stesso team.
Questo è il malinteso più comune e più costoso.
Cross competenza significa progettazione delle interfacce tra discipline.
In un progetto meccatronico, meccanica, elettronica e software non sono moduli separati che si toccano in coda al progetto. Sono sistemi accoppiati: le scelte di uno vincolano gli altri in tempo reale, spesso in modo non lineare, sempre in modo bidirezionale.
Trattarli come moduli sequenziali è l’errore architetturale che produce il ritardo sistemico.
Dove si rompe il sistema: tre punti di frattura
1. Interfacce implicite
Nessuno le definisce esplicitamente perché “si capisce” cosa vuol dire che la meccanica e l’elettronica devono interfacciarsi.
In realtà, non si capisce. Ogni dominio ha le proprie assunzioni. Quelle assunzioni non vengono dette perché sembrano ovvie. E quando i sistemi si incontrano — tipicamente in fase di test, quando il costo di cambio è massimo — le assunzioni implicite diventano conflitti espliciti.
L’interfaccia non progettata emerge tardi. Sempre tardi.
2. Sequenzialità nascosta
“Prima la meccanica, poi l’elettronica, poi il software.”
È una logica apparentemente ragionevole. Il problema è che le dipendenze reali non sono sequenziali: sono circolari.
Il software ha bisogno di sapere come si comporterà il sistema fisico per scrivere la logica di controllo. La meccanica ha bisogno di sapere cosa dovrà gestire il software per dimensionare gli attuatori. L’elettronica sta nel mezzo, dipendente da entrambi.
La sequenzialità nasconde questa circolarità. La sequenzialità produce attese. Le attese producono ritardo.
3. Linguaggi non allineati
Ogni dominio ha il proprio vocabolario, le proprie metriche, i propri criteri di qualità.
Il meccanico ottimizza la robustezza strutturale. L’elettronico ottimizza il consumo energetico. Il software ottimizza la latenza. Ognuno è coerente con il proprio sistema di riferimento.
Nessuno ottimizza l’integrazione. Perché l’integrazione non appartiene a nessun dominio. Non è responsabilità di nessuno. E ciò che non appartiene a nessuno, nel progetto, non viene fatto.
La tesi, senza mediazioni
Se le interfacce non sono progettate, il project management diventa un sistema di gestione del caos.
Raccoglie le tensioni, le distribuisce nel tempo, le ammortizza con soluzioni di ripiego. Ma non le elimina.
Perché il PM non integra. Al massimo coordina ciò che è già integrabile.
Se l’integrabilità non è stata costruita a monte, nessun coordinamento a valle può rimediare. Si può solo inseguire.
Cosa significa progettare la cross competenza
Uscire dalla critica è necessario. La diagnosi serve solo se orienta un’azione diversa.
1. Spostare la domanda progettuale
La domanda corrente è: “chi fa cosa?”
La domanda che serve è: “cosa deve essere vero tra i domini perché il sistema funzioni?”
Non è un cambio cosmetico. È un cambio di oggetto del lavoro. Si passa dalla gestione delle attività alla progettazione delle condizioni di integrazione.
2. Rendere visibili le interfacce
Un’interfaccia non definita è una dipendenza nascosta. Per renderle visibili servono tre livelli:
- Segnali: quali informazioni passano tra sistemi, in quale formato, con quale frequenza, con quale tolleranza di errore.
- Vincoli fisici: tolleranze dimensionali, range di temperatura, tempi di risposta — tutto ciò che un dominio impone all’altro come condizione necessaria.
- Logiche di controllo: chi decide cosa, quando, e in base a quali input. Chi ha l’ultima parola su un trade-off che attraversa i confini di dominio.
Queste cose non emergono da sole in una riunione di allineamento. Devono essere estratte, rese esplicite e gestite come elementi concreti di progetto.
3. Anticipare l’integrazione
L’integrazione finale è una scommessa: si spera che i pezzi si incastrino perché ognuno ha lavorato bene nel proprio perimetro.
La scommessa perde quasi sempre.
L’alternativa è strutturare integrazioni progressive e cadenzate: momenti definiti nel progetto in cui i sistemi vengono fatti dialogare — non solo mostrati — per rivelare le incompatibilità quando costano ancora poco risolverle.
Questo non è verifica anticipata. È apprendimento strutturato sulle interfacce.
4. Una funzione che il progetto non ha: il governo delle interfacce
Non necessariamente una persona dedicata. Ma una funzione che qualcuno deve esercitare.
Il governo delle interfacce è chi:
- vede le dipendenze prima che diventino problemi
- rende esplicite le assunzioni che ogni dominio dà per scontate
- forza le decisioni incomplete a diventare esplicite, anche quando è scomodo
Nei progetti meccatronici questa funzione esiste raramente come ruolo consapevole. Viene esercitata — quando va bene — da qualcuno con sufficiente esperienza trasversale da vedere il sistema nel suo insieme. Quando non esiste, il progetto la sostituisce con il ritardo.
Il ribaltamento
Finché pensiamo che il problema sia pianificare meglio, continueremo a rincorrere i ritardi.
Quando iniziamo a progettare le interfacce tra competenze, il ritardo smette di essere la norma e torna a essere un’eccezione.
Non perché il progetto diventa più semplice. Ma perché la complessità smette di essere nascosta e diventa gestibile.
La differenza tra un progetto che scivola e uno che tiene non è nella qualità del piano di lavoro.
È nella qualità delle interfacce progettate.
Nei tuoi progetti, le interfacce sono progettate… o scoperte quando è troppo tardi?
Questo articolo è parte di una serie sulla progettazione dei sistemi di lavoro complessi in contesti meccatronici e product development.
Enrico Bonetto 