Maturità dell’Informazione nel Design: Capire Quando un’Idea è Pronta per Decollare

Ciao a tutti! Oggi voglio addentrarmi in un argomento che mi affascina e che ritengo fondamentale nel mondo del design e dello sviluppo, specialmente quando si parla di progetti su larga scala: la maturità dell’informazione. Quante volte ci siamo trovati a lavorare con dati, specifiche o bozze ancora “acerbe”? Informazioni che devono passare tra colleghi, reparti, fornitori, spesso in uno stato non definitivo. Ecco, capire *quanto* è matura un’informazione è cruciale per un sacco di decisioni.

Pensateci: quanto impegno dedicare a un compito se le informazioni di partenza sono vaghe? Quando possiamo sovrapporre le fasi di un progetto basandoci su dati preliminari? Che margine di cambiamento dobbiamo prevedere per quelle informazioni che sappiamo non essere ancora definitive? Avere una bussola per orientarsi nella maturità dell’informazione potrebbe persino aiutarci a interpretare meglio i dati archiviati dei progetti passati e imparare da essi.

Il punto è che, finora, non c’è mai stato un consenso chiaro su cosa significhi davvero “maturità dell’informazione” in questo contesto. Ognuno sembra avere la sua interpretazione. Per questo, ho pensato fosse utile provare a mettere un po’ d’ordine, creando una sorta di mappa, una tassonomia che definisca e distingua i vari aspetti di questa maturità. Spero che questo possa chiarire come l’informazione possa “maturare” lungo diverse dimensioni durante il processo di design e sviluppo e magari stimolare nuove ricerche su come gestire al meglio le informazioni preliminari nei grandi progetti.

Perché la Maturità dell’Informazione è Così Importante?

Partiamo da un presupposto: il flusso corretto delle informazioni è vitale per le performance di un processo di design e sviluppo. Molte delle informazioni scambiate sono preliminari, specialmente in contesti come l’ingegneria concorrente (concurrent engineering), dove rilasciare informazioni in anticipo permette di sovrapporre attività e facilitare la comunicazione tra discipline diverse fin dalle prime fasi.

Tuttavia, affidarsi troppo a informazioni preliminari può portare a decisioni sbagliate e a dover rifare il lavoro (il temuto rework!). Per usare queste informazioni in modo appropriato, dobbiamo farci domande come:

• Quanto è completa questa informazione?
• È coerente con il resto?
• Quanto è accurata?
• Quali ipotesi sono state fatte per generarla? Con quali modelli?
• Quanto è stata validata?

La mia idea è che una migliore comprensione della maturità delle informazioni preliminari possa portare un valore enorme nella gestione dei flussi informativi, nel processo decisionale e nella gestione della concorrenza nei progetti complessi.

Vediamo alcuni esempi pratici:

• Gestione dei processi in concurrent engineering: Capire la maturità aiuta a bilanciare i benefici del rilascio anticipato di informazioni (più velocità) con i rischi (più rework, decisioni sub-ottimali).
• Comunicazione e negoziazione nel design: Associare metadati sulla maturità alle informazioni preliminari può stimolare il dialogo, rendendo visibile il ragionamento dietro a certe scelte. Permette agli stakeholder di dare input prima, senza sentirsi vincolati a decisioni premature.
• Supporto alle decisioni: Aiuta ad applicare metodi che tengano conto delle incertezze specifiche, magari progettando con flessibilità o allocando margini adeguati per assorbire potenziali cambiamenti. È fondamentale assicurarsi che le informazioni critiche siano abbastanza mature, specialmente quando si accelera lo sviluppo di prodotti complessi e critici per la sicurezza. Se l’informazione non è matura, si possono avviare attività di validazione mirate.
• Supporto individuale: Aiuta le persone a valutare se il proprio lavoro è pronto per essere passato ad altri, considerando le esigenze specifiche di chi lo riceverà. Delle checklist sulla maturità potrebbero aiutare i meno esperti a non tralasciare nulla o a evitare un eccessivo perfezionismo inutile.
• Valore dei dati ingegneristici: In un’era di digital engineering, data-driven design e design engineering 4.0, capire la maturità delle informazioni preliminari è cruciale per sfruttarle al meglio.

Definire la Maturità: Un Concetto Sfuggente

Nel tempo, sono state proposte diverse definizioni di maturità dell’informazione nel design. Alcune la legano alla completezza per il rilascio, altre al consenso e alla stabilità dei dati, altre ancora allo stato evolutivo verso un valore finale, o alla qualità percepita rispetto a uno scopo.

Tutte queste definizioni suggeriscono che la maturità sia uno stato evolutivo, un “grado di qualcosa” (completezza, consenso, stabilità, correttezza, qualità, sviluppo…). Alcune sottolineano la soggettività, altre meno.

Considerando queste premesse, propongo questa definizione: La maturità dell’informazione preliminare è il suo grado di sviluppo rispetto alle aspettative di sufficienza per specifici contesti e consumatori.

Spieghiamo i termini:

• Informazione preliminare: Si applica a informazioni non ancora finalizzate.
• Grado di sviluppo: La maturità si capisce nel contesto del suo processo di maturazione (cioè, il processo di design e sviluppo).
• Rispetto alle aspettative: La maturità è relativa ai punti di arrivo attesi soggettivamente dagli stakeholder (e questi punti possono cambiare!).
• Sufficienza per specifici contesti: Un’informazione può essere matura per uno scopo (es. pianificare un prototipo) ma non per un altro (es. avviare la produzione).
• Sufficienza per specifici consumatori: L’abilità di interpretare l’informazione dipende dalla conoscenza e dalla situazione di chi la riceve. Ciò che è maturo per uno, può non esserlo per un altro.

Maturità vs. Qualità, Incertezza, Conoscenza, Fiducia

È facile confondere la maturità con altri concetti vicini. Vediamo le differenze:

* Qualità dell’Informazione: La qualità è il “grado in cui un insieme di caratteristiche intrinseche soddisfa i requisiti”. Si parla spesso di dimensioni come accuratezza, completezza, consistenza, tempestività. La differenza chiave? La qualità non considera esplicitamente il grado di sviluppo, mentre la maturità si focalizza proprio sull’informazione preliminare nel suo processo evolutivo.
* Incertezza: La maturità è strettamente legata all’incertezza. L’incertezza è definita come “qualsiasi deviazione dall’ideale irraggiungibile di conoscenza completamente deterministica”. Nel design, l’incertezza è ovunque e può derivare da mancanza di conoscenza (epistemica) o da variazioni intrinseche (aleatoria). Man mano che un design matura, molte incertezze (soprattutto quelle epistemiche) si risolvono. Possiamo dire che l’aumento della maturità spesso comporta la riduzione o la caratterizzazione delle incertezze fino a un livello accettabile per chi userà l’informazione.
* Conoscenza (e Ignoranza): L’informazione immatura è spesso associata a una conoscenza limitata. Usando le categorie degli “unknowns” (noti noti, noti ignoti, ignoti noti, ignoti ignoti), un aumento della conoscenza rilevante può portare a una maggiore percezione di maturità. Ma attenzione: a volte, approfondendo un problema, scopriamo nuovi “ignoti noti” e ci rendiamo conto che il design è meno maturo di quanto pensassimo! La relazione non è sempre lineare.
* Fiducia (Trust) e Confidenza (Confidence): La maturità è legata anche alla fiducia nell’informazione e nelle sue fonti. La fiducia implica accettare l’incertezza e un rischio se la fiducia è mal riposta. La confidenza è più la convinzione soggettiva del produttore dell’informazione (“quanto credo nel mio lavoro?”). La fiducia è più la convinzione del ricevente (“quanto credo a questa informazione ricevuta?”). Entrambe influenzano la percezione di maturità e sono soggette a bias psicologici.

In sintesi, maturità, qualità, conoscenza, fiducia e incertezza sono concetti sfaccettati e interconnessi. La maturità si distingue per il suo focus sul grado di sviluppo dell’informazione preliminare all’interno del suo processo.

Una Tassonomia per Mettere Ordine: I 18 Aspetti della Maturità

Dato che non esisteva un framework condiviso, ho cercato di costruirne uno basandomi sulla letteratura di diversi campi (design, management, information systems, filosofia, costruzioni). L’obiettivo era creare una tassonomia, una struttura gerarchica, che fosse:

• Comprensiva: Integrando i concetti esistenti.
• Di Qualità: Interpretabile, con concetti distinti (crispness), conservativa (usando termini esistenti se possibile), parsimoniosa (non troppi concetti) e generale (applicabile a vari contesti).
• Utile: Potenzialmente informativa per la ricerca orientata alla pratica.

Il risultato è una tassonomia con 18 aspetti distinti, organizzati in tre categorie principali: Contenuto, Contesto e Provenienza. Vediamoli nel dettaglio.

Categoria 1: Contenuto (La sostanza dell’informazione)

Questa categoria riguarda la maturità dell’informazione in sé. Si divide in Completezza e Chiarezza.

Sottocategoria: Completezza

• Copertura (Coverage): Riguarda quanto “ampiamente” l’informazione copre ciò che ci si aspetta. È come chiedere: “Ci sono tutte le parti previste?”. Non si applica a tutto (es. un singolo numero), ma ha senso per un documento (capitoli scritti/pianificati), un modello CAD (parti modellate/pianificate) o un dato statistico (numero di campioni usati/attesi). Richiede un’aspettativa sullo stato finale.
• Profondità (Depth): Quanto è dettagliata o concettualmente ricca l’informazione rispetto all’atteso? Un capitolo può essere solo una scaletta o un testo completo. Un modello CAD può essere uno scheletro o includere finiture e tolleranze. Nel BIM si parla di “Level of Detail” o “Level of Geometry”.
• Prontezza (Readiness): Il grado di avanzamento percepito o formale dell’informazione verso il livello di maturità richiesto. Può essere informale (“bozza”, “definitivo”) o seguire stadi definiti (es. “in approvazione”, “rilasciato”, o i LOD nel BIM, che indicano l’adeguatezza per certe fasi del processo come progettazione, installazione, verifica).

Sottocategoria: Chiarezza

• Nomenclatura (Nomenclature): L’aderenza a norme, standard, convenzioni (unità di misura, simboli, definizioni). Una nomenclatura immatura può portare a fraintendimenti o all’impossibilità di usare l’informazione.
• Concisión (Conciseness): Quanto l’informazione è condensata e priva di ridondanze inutili, rispetto alle esigenze del ricevente. Un documento prolisso o un disegno con troppe viste non sono concisi. A differenza di copertura e profondità, aumentare la concisione spesso significa rimuovere qualcosa.
• Nitidezza (Crispness): Quanto è precisa, specifica, definita l’informazione. È l’opposto di vaghezza, imprecisione, ambiguità (nel senso di molteplici interpretazioni possibili, es. “caldo” può essere temperatura o piccantezza). Un linguaggio nitido riduce i fraintendimenti. A volte, però, un’informazione volutamente non nitida (es. un range di valori) può essere utile in fasi preliminari.

Categoria 2: Contesto (Come l’informazione si inserisce e cambia)

Questa categoria guarda a come l’informazione si integra con ciò che la circonda e con se stessa, e come ci si aspetta che cambi nel tempo. Si divide in Consistenza e Dinamismo.

Sottocategoria: Consistenza

• Compatibilità (Compatibility): Quanto l’informazione “si incastra” bene con altre informazioni e situazioni (es. un sottosistema rispetta le interfacce definite? Il design soddisfa i requisiti?). Incompatibilità possono nascere da trasformazioni di dati, semplificazioni, alta concorrenza, mancanza di visione d’insieme, o dalla creazione di versioni multiple della stessa informazione.
• Coerenza (Coherence): La consistenza interna dell’informazione. Ci sono contraddizioni all’interno della stessa rappresentazione? (es. costi diversi per la stessa voce in pagine diverse di un report; interferenze tra parti in un CAD). L’incoerenza è tipica prima della convergenza finale o se le modifiche non vengono propagate ovunque.
• Comprensibilità (Understandability): Quanto adeguatamente si può cogliere il significato dell’informazione. È diverso dalla nitidezza: un’informazione può essere non nitida ma comprensibile (es. “vive vicino a Milano”), mentre un’altra può essere incomprensibile per la sua struttura ambigua (es. “lui intorno incontra Milano”). Dipende dal contesto d’uso e dalla conoscenza del ricevente. Si applica più a informazioni complesse (documenti, modelli) che a singoli parametri.

Sottocategoria: Dinamismo

• Convergenza (Convergedness): L’ampiezza e la significatività attese dei potenziali cambiamenti futuri. Un’informazione poco convergente ha un ampio range di possibili valori finali. È legata all’eliminazione dei margini di progetto non necessari.
• Stabilità (Stability): La frequenza o rapidità di cambiamento attesa. Quanto è probabile che l’informazione non cambi più da qui alla fine del processo? L’instabilità è un aspetto chiave dell’incertezza legata al contesto.
• Comprensione dello Stato Futuro (Comprehendedness): Quanto si capisce bene la differenza tra lo stato attuale dell’informazione e lo stato di sufficienza atteso? E ci si aspetta che questo stato atteso cambi? Quanto si comprendono i problemi da risolvere per arrivarci? Questo aspetto è cruciale perché la nostra definizione di maturità è relativa a uno stato atteso. È più alta in progetti di routine con esperti, più bassa in situazioni nuove.

Categoria 3: Provenienza (Da dove viene l’informazione)

L’ultima categoria riguarda come l’informazione è stata sviluppata. Si divide in Maturità dei Prerequisiti e Processo di Generazione e Validazione.

Sottocategoria: Maturità dei Prerequisiti

• Fondatezza (Groundedness): Quanto erano disponibili tutti i prerequisiti necessari per generare e validare l’informazione? Quanto pesano le assunzioni fatte? La fondatezza diminuisce se si sono dovute fare molte assunzioni significative, o se la fiducia in esse è bassa. Le assunzioni sono comuni in concurrent engineering o quando si anticipano i task.
• Tracciabilità (Traceability): Quanto sono note le fonti dei prerequisiti usati? È importante poter risalire a chi ha fatto cosa, quando, con quali input e strumenti, per poter ricreare il contesto in cui i risultati sono stati ottenuti.
• Attendibilità della Fonte (Trustedness): Quanto ci si fida dell’informazione specificamente in base ai prerequisiti usati e alle loro fonti? La fiducia può mancare se non si sa chi ha generato l’info, se è inesperto, se l’info è vecchia, o se si basa su descrizioni ritenute obsolete.

Sottocategoria: Processo di Generazione e Validazione

• Adeguatezza del Processo (Process Suitability): I processi e i modelli usati per generare l’informazione erano appropriati per l’uso atteso? (es. un’analisi FEM lineare non va bene per studiare il buckling). Bisogna fare attenzione, perché molti tool CAE mostrano risultati allo stesso modo, indipendentemente dall’adeguatezza dei modelli usati.
• Rigore (Rigour): La meticolosità nell’eseguire i processi di generazione e verifica. Un calcolo su foglio elettronico è rigoroso se è stato controllato a mano o se lo stesso foglio è stato usato con successo in passato. Un approccio rigoroso riduce gli errori.
• Validità (Validity): La credenza nell’informazione rivelata dai processi di validazione intrapresi. La validazione può aumentare la fiducia o rivelare che l’informazione è invalida (es. non riflette dati empirici, ci sono errori nel processo).

Mettere alla Prova la Tassonomia e Guardare Avanti

Abbiamo cercato di valutare questa tassonomia confrontandola con 11 framework precedenti: nessuno copriva tutti e 18 gli aspetti identificati qui. Inoltre, abbiamo cercato di rendere le definizioni il più chiare e distinte possibile, pur mantenendo termini riconoscibili dalla letteratura dove fattibile. Abbiamo anche verificato che la tassonomia fosse applicabile a diversi tipi di informazione (documenti, disegni, parametri numerici), mostrando come ogni aspetto possa essere interpretato concretamente.

Questo lavoro è un punto di partenza. La tassonomia potrebbe informare lo sviluppo di approcci pratici per:

1. Valutare la maturità: Si potrebbero creare strumenti (magari delle griglie di valutazione o checklist) basati su questi 18 aspetti. Alcuni aspetti potrebbero essere misurati automaticamente (es. stabilità tramite log dei file), altri richiederebbero valutazioni soggettive esperte. Una valutazione multidimensionale potrebbe aiutare a decidere quando rilasciare informazioni, come gestire la concorrenza, dove allocare sforzi di validazione, o quali metodi specifici usare per gestire l’immaturità (es. robust design per problemi di nitidezza, design freeze per instabilità, test mirati per validità).
2. Gestire l’informazione immatura: Capire *quali* aspetti della maturità sono carenti può suggerire azioni mirate. Inoltre, sarebbe fantastico se i software di design (CAD, CAE, Office) permettessero di indicare formalmente la maturità delle informazioni, cosa che oggi spesso non fanno, oscurando lo stato preliminare dei dati (pensate a un pezzo riutilizzato da un vecchio progetto: sembra finito, ma magari non lo è affatto per il nuovo contesto!). Visualizzare la maturità potrebbe migliorare enormemente la comunicazione e il coordinamento.

Infine, c’è da studiare le dipendenze tra questi aspetti. Ad esempio, un’informazione con poca profondità è probabilmente anche poco stabile. Capire queste relazioni potrebbe aiutare a propagare i cambiamenti di maturità (anche in negativo, se si scopre un difetto) a tutte le parti interessate.

Spero che questa esplorazione della maturità dell’informazione possa essere uno spunto utile per chiunque si occupi di progetti complessi. Lavorare con informazioni preliminari è una sfida quotidiana, ma forse, con una mappa un po’ più chiara, possiamo navigarla un po’ meglio.

Fonte: Springer