The Power of LiquidTeam

In questo articolo parlerò di un caso studio, lo sviluppo del modello BIM del velodromo Maspes Vigorelli, che ho recentemente avuto l’onore di portare all’ultimo SAIE, nell’arena dedicata agli interventi dei membri del BUGItaly, all’interno della manifestazione più ampia, denominata Digital&Bim.

Figura 1

 

Un edificio per cui il termine di tempio dello sport non è abusato, un piccolo stadio da circa 7000 posti a sedere, ma con componenti tecniche di tutto rilievo. Giusto per permettervi di inquadrare meglio l’entità del lavoro, parliamo di una pista con curve paraboliche, circa 2 km di ringhiere di ogni forma e tipo, e una struttura che ha richiesto la modellazione dell’equivalente di 720000 kg di acciaio.

Cercherò di parlarvene a trecentosessanta gradi, quindi vedremo cosa è stato fatto, da chi, intendendo non da che società, ma da che tipologia di team, e anche e sopratutto come è stato fatto.

Figura 1 - Rendering modello velodromo Maspes Vigorelli.

Figura 2 – Chi, Cosa, Come

L’intervento è consistito in un Cad to BIM con ausilio per alcune parti di un rilievo con nuvola di punti focalizzato su 4 BIM Use :

  • 3D Autoring.
  • Record Keeping.
  • 2D documentation.
  • Asset Management.
Figura 3 - Usi del modello.

Figura 3 – Usi del modello.

Hanno collaborato alla stesura del progetto 31 BIM Specialist ( si è trattato della loro tesi a conclusione del master per BIM Specialist denominato Masterkeen®) e hanno completato il lavoro in 20 business day effettivi, dovendo tra l’altro rimodellare una parte consistente a circa metà del tempo a loro disposizione. Ora, 31 BIM Specialist è una “potenza di fuoco” senz’altro consistente, ma io vi inviterei a riflettere anche sulle problematiche di gestione che un gruppo molto consistente di lavoro, può comportare. Consapevoli che team così numerosi non sono la norma nello sviluppo di progetti anche complessi, abbiamo voluto dimostrare che il framework di team management che stiamo sviluppando denominato LiquidTeam® è efficiente anche in presenza di gruppi di lavoro numerosi.

Figura 4 - Chi e in quanto tempo.

Figura 4 – Chi e in quanto tempo.

Il segreto per la gestione di questa squadra è stato il fatto che si trattava, appunto, di un LiquidTeam®, termine che abbiamo cognato in AM4 e di cui abbiamo parlato abbondantemente qui. Si tratta di una visione del team basata su quattro pilastri fondamentali:

  • Comunicazione efficace.
  • Capacità di Problem solving.
  • Metodo decisionale.
  • Strategia in tempo reale.

Pilastri, che si traducono in un team dotato di elevatissima competenza tecnica, di capacità di adattamento, con un attitudine spiccata al Problem solving, in cui ogni membro è in grado di prendere decisioni allineate alla visione comune valutandone le ricadute sul team stesso.

Figura 5: Pilastri del LiquidTeam®

Un équipe con queste caratteristiche permette di destrutturare i ruoli e i compiti canonici del BIM al suo interno, con indubbi vantaggi: il primo e forse più eclatante, consiste nel fatto che il capo progetto può presentarsi con un “banale” elenco di cose da fare e/o richieste ed essere ragionevolmente sicuro che saranno effettuate correttamente.

Figura 6 - To Do

Figura 6 – To Do

Parlando di richieste la prima  è stata di identificare alcuni referenti per i ruoli e le mansioni normalmente svolte dalle tradizionali figure “istituzionali del BIM”.

Figura 7: I ruoli Bim destrutturati all’interno del team.

Figura 7: I ruoli Bim destrutturati all’interno del team.

Qui abbiamo già il primo (ed enorme) cambiamento di paradigma:

Il gruppo sa valutare le competenze dei suoi membri spesso meglio di un manager che osserva dall’esterno.

Figura 8: Il team è in grado di valutare le competenze dei membri che lo compongono.

Figura 8: Il team è in grado di valutare le competenze dei membri che lo compongono.

É un principio che scombina un pò il pensiero tradizionale ma che, per esempio, è stato utilizzato durante la seconda guerra mondiale dall’esercito britannico: gli incursori dietro le linee nemiche si sceglievano i propri compagni di avventura (e spesso anche il capo dell’operazione stessa).

Vediamo quali sono stati i principali compiti di questi referenti:

  1. Collegamento tra il team e il responsabile di progetto e viceversa. É inefficiente comunicare informazioni ad ogni singolo membro del team e molto spesso mail e quant’altro raggiungono l’obbiettivo in maniera troppo tardiva. Allo stesso modo è difficile dall’esterno avere sempre l’esatto polso della situazione di quanto sta avvenendo all’interno del team. Più avanti vedremo come queste problematiche sono state risolte.
  2. Il secondo compito riguarda lo svolgimento delle mansioni di verifica e controllo.
  3. Il terzo quello di record, cioè mantenere uno storico delle decisioni principali prese durante lo svolgimento del lavoro e delle ragioni precise per cui sono state prese.
Figura 9 - Compiti dei referenti.

Figura 9 – Compiti dei referenti.

 

Capiamo ora come questi compiti sono stati assolti:

il processo di comunicazione si è esplicato attraverso rapidi brifing giornalieri con il responsabile progetto e attraverso un flusso di informazioni che si è avvalso di strumenti molto semplici ma efficaci. Trello® per la pianificazione delle operazioni, Conductor® che tramite l’interfaccia con Trello® e  Autodesk Revit® permette di assegnare compiti ai membri del team e all’inverso segnalare criticità trovate nel processo di moderazione. Slack® che sempre attraverso il suo collegamento con Trello® permette di richiedere assistenza a specialisti esterni al team di modellazione. Slack® è stato anche il canale principale per comunicazioni di altra natura come vedremo fra poco.

Figura 10 - Software alla base dello scambio di informazioni.

Figura 10 – Software alla base dello scambio di informazioni.

Per quanto riguarda il processo di verifica e controllo si è esplicato in questo modo: da documentazione appositamente predisposta, i membri del team si assumevano la responsabilità di portare a termine un compito (per esempio la modellazione di una specifica famiglia) lo eseguivano e (sempre rimanendo in ambito famiglie) Document controller e Family manager procedevano alla validazione dell’elemento, che solo dopo questa fase di controllo veniva messo a disposizione dell’intero team. Nel caso di non corrispondenza alle necessità comportamentali richieste per elelemento o agli standard definiti in fase di analisi, l’oggetto tornava dal suo creatore per gli aggiustamenti del caso. Questo ha fatto si che sin da subito nel modello non entrassero elementi che poi avrebbero potuto pregiudicarne il funzionamento.

A fine giornata gli stessi referenti hanno avuto il compito di fornire un piccolo report, diffuso via Slack® , dell’attività svolta dal team e, come accennato in precedenza, delle decisioni prese; un archivio utilissimo per mantenere l’allineamento delle informazioni all’interno del team ma, sopratutto, utilissimo nel caso si desiderasse fare un debrifig a lavoro ultimato anche a distanza di tempo. Cosa ha funzionato e cosa è migliorabile al termine del lavoro? Il termine corretto per descrivere questa esigenza è Kaizen (miglioramento continuo). Ho accennato prima al fatto che a un certo punto è stato necessario rimodellare una consistente parte del progetto, abbiamo avuto la possibilità di innalzare molto la qualità del modello e abbiamo deciso di coglierla. La cosa interessante è stato che quello che originariamente era stato modellato in 5 giornate è stato rifatto in 3. Probabilmente questo stesso team a seguito di un attento debrifing e sulla base di quanto imparato sarebbe in grado di tagliere i tempi di esecuzione di un progetto simile di un ulteriore 30%. Troppo spesso questo momento di analisi di quanto fatto è ignorato! noi riteniamo che sia invece estremamente produttivo e per questo l’abbiamo inserita tra le strategie di implementazione di un LiquidTeam®.

Figura 11 - Obbiettivi dei Report.

Figura 11 – Obbiettivi dei Report.

Veniamo al workflow seguito per lo sviluppo del progetto, che per esigenze di semplificazione è stato compresso in sei punti fondamentali:

  1. Analisi.
  2. Definizione standard.
  3. Creazione template.
  4. Modellazione.
  5. Sviluppo script.
  6. Redazione relazione informativa.

Ognuno di questi punti è stato assegnato a un piccolo gruppo di membri del team che, avendo tutti una elevata competenza, erano sostanzialmente intercambiabili. Di seguito alcuni degli ambiti in cui la fasi di analisi si esplicata:

  • Valutazione della documentazione trasmessaci.
  • Ricerca di eventuali punti critici.
  • Identificazione di parametri specifici in relazione ai BIM use richiesti.
  • Redazione di un primo elenco di famiglie necessarie e relative caratteristiche.
  • Etc.

Contemporaneamente alla fase di analisi il team si è dotato degli standard necessari allo svolgimento del lavoro, in questa fase il ruolo del “BIM manager” è stato semplicemente quello di controllo e approvazione, quello del BIM Coordinator destrutturato all’interno del team stesso.
Sottolineo che questo gruppo era alla prima esperienza su un progetto particolare come uno stadio, e ha dovuto quindi pensare a tutto, dagli standard di nomenclatura, alle guide per una modellazione efficace; fra poco vedremo quali sono stati i risultati di questo sforzo.

Definizione Standard e Regole

Figura 12 – Definizione standard e Regole

Venendo ad aspetti di natura più squisitamente tecnica il modello è stato suddiviso in 8 parti (file) e si è scelto di operare con un workset unico per ogni file; l’elevata comunicazione interna al team infatti ha permesso una organizzazione meno rigida a tutto vantaggio della velocità di esecuzione. Ancora una volta la forte competenza tecnica di ogni membro del team è stata un arma vincente per contenere i tempi. Non solo, questa struttura dei file in abbinamento a regole di modellazione precise e condivise ha permesso di assemblare modelli federati di peso inferiore ai 200 MB. La leggerezza è un paradigma che a pervaso l’intero lavoro. I file federati possono essere aperti con PC di fascia media; data la natura dell’opera ci siamo infatti posti il problema che il modello potesse essere fruibile anche da enti pubblici che non necessariamente hanno a disposizione computer specificatamente dedicati alla gestione di modelli tridimensionali complessi.

Figura 13 - Suddivisione del progetto.

Figura 13 – Scomposizione del progetto.

Per l’aspetto CDE ci siamo invece affidati ad AutodeskVault®. Che ha permesso la creazione di una efficiente struttura delle cartelle ma sopratutto una rigida regolamentazione degli accessi sia in relazione ai ruoli svolti dai membri del team sia in relazione al singolo utente.

Esempio di struttura cartelle in Autodesk Vault®

Figura 14 – Esempio di struttura cartelle in Autodesk Vault®

Permessi di accesso e lavoro alle cartelle in funzione dei ruoli.

Figura 15 – Permessi di accesso e lavoro alle cartelle in funzione dei ruoli.

Definizione ruoli in Autodesk Vault®

Figura 16 – Definizione ruoli in Autodesk Vault®

In fine abbiamo redatto una relazione informativa, da non confondersi con un capitolato informativo e/o Bep, ma da intendersi come un manuale d’uso del modello, sviluppato in accordo con i riferimenti normativi, in modo che tutto o in parte possa confluire in un capitolato informativo, qualora il committente lo ritenesse opportuno in caso di successivi interventi.

Sezioni relazione informativa.

Figura 17 – Sezioni relazione informativa.

In un articolo come questo non è possibile esaminare nello specifico la struttura e il contenuto di questa relazione, voglio solo sottolineare la presenza all’interno di questo documento di un allegato con mappe di processo sviluppate con sintassi BPMN 2.0.  Questa che vedete in Figura 18 rappresenta il processo per aggiornare il file Taxonomy del sistema di classificazione. Crediamo molto infatti nella rappresentazione grafica dei processi (con uno strumento che permetta una sintassi corretta) come veicolo per la corretta e rapida comprensione degli stessi.

Mappa di processo per l’aggiornamento del file Taxonomy in Autodesk Revit®.

Figura 18. – Mappa di processo per l’aggiornamento del file Taxonomy in Autodesk Revit®.

Tutto questo ha permesso di sviluppare elaborati, ricchi di informazioni: dalla codifica della posizione e natura di ogni componente della struttura, fino alla rappresentazione grafica di script pensati appositamente per valutazioni di asset management. A titolo di esempio in Figura 19 potete vedere i risultati di uno script che permette il calcolo della valorizzazione di un posto a sedere in funzione del tipo di evento che si sta svolgendo all’interno dello stadio e una serie di altri parametri (vicinanza delle vie di fuga etc.). In Figura 20 i risultati di un altro script che calcola la percentuale di irraggiamento solare di una superficie (utile per esempio per ottimizzare l’irrigazione delle zolle del campo).

Script per la valorizzazione dei posti a sedere in funzioni di variabili. Autore: Pasquale Idone.

Figura 19 – Script per la valorizzazione dei posti a sedere in funzioni di variabili. Script: Pasquale Idone.

Figura 20 – Script per il calcolo dell’irraggiamento solare di una superficie – Script: Domenico Longo

Infine quest’ultimo (Figura 21), che permette di colorare gli elementi del modello in funzione della data di ultima e prossima manutenzione.

Script per l’identificazione cromatica degli elementi in funzione delle date di manutenzione. Script: Mauro Sogni.

Figura 21- Script per l’identificazione cromatica degli elementi in funzione delle date di manutenzione. Script: Mauro Sogni.

Numerosi altri script, sono stati sviluppati, con l’accortezza però, di usarli esclusivamente per accelerare la modellazione e/o superare alcuni limiti degli strumenti, in modo da non pregiudicare in nessun modo l’uso futuro del modello.

Qui mi fermo, prima che quest’articolo diventi illeggibile per eccessiva lunghezza, permettetemi solo di ringraziare ancora una volta i membri del team che hanno partecipato alla realizzazione del modello (li trovate elencati qui sotto), per l’enorme quantità di energia, entusiasmo e competenza che vi hanno riversato.

BIM Team:

Agnello Cinzia, Alessandro Tondin, Andrea Begnardi, Angelica Crisci, Arianna Perelli, Corio Simone, D’Orazio  Eugenio, Falvo Caterina, Forliti Sara, Gangai  Tommaso Aldo, Girgenti Simone, Giuseppe Esposito, Guardascione Ilaria, Idone Pasquale, La porta Serena, Ligori  Viola, Longo Domenico, Luca Biancolini, Parriello Vesy, Piezzo Umberto, Pittau Alessandra, Polizzotto Roberto, Rosati Luca, Rusconi Antonio, Sabelli Gelso, Sala Matteo Gabriele, Santi Matteo, Sogni Mauro, Terribile Luigi, Zampar Marco, Zyberaj Ergi.

 

Scarica PDF

 

 

No Comments

Leave a Comment


Time limit is exhausted. Please reload CAPTCHA.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.