Blueprint: la mappa per un tesoro garantito

L’Ape Regina disorganizzata

Elia aveva un talento naturale per la tecnologia. Quando lo conobbi, il suo talento confinava letteralmente con la magia. Al pari di un mastro muratore che ti tiene su una palazzina con fil di ferro e una tenaglia, Elia era il tipo di ragazzo che riaccendeva un server con un fermaglio da ufficio e del nastro isolante. A vent’anni era già un richiestissimo freelance in quel di Milano. Il suo forte era l’assemblaggio di PC da gaming customizzati. In quel mondo si era costruito una fama e i gamer spendevano delle piccole fortune. Il mio primo raffreddamento a liquido del processore l’ho visto realizzare a lui in un epoca in cui non esistevano i kit pronti ne un internet dove scovarli ed ordinarli.

Il suo ufficio, che chiamava affettuosamente The Hive (L’Alveare), era la manifestazione fisica della sua mente brillante: un labirinto di cavi non etichettati, post-it volanti con password scadute e impegni scritti e chissà se dimenticati. I suoi appunti scritti avevano un livello di dettaglio che, su una scala da 1 a 100, valeva 2. Schemi elettrici disegnati a mano sul retro di scontrini di pizzerie. Scatole vuote di pizza da asporto abbandonate sotto un enorme banco da lavoro che, se ricordo bene, misurava almeno 4×2 metri. Circa 8 metri quadrati di attrezzi, disordine, residui di cibo e bicchieri di caffè sparsi ovunque. Alimentatori morti e schede madri cannibalizzate di elettronica sparse letteralmente ovunque, anche in bagno accatastate insieme a scatole piene di nulla. Prima di capire il suo genio, pensai sinceramente si trattasse di un “idiot savant” con la mania dell’accumulo. Tuttavia, aveva un senso dell’umorismo irresistibile misto a quell’aria da “non so neanche io perché siamo qui”.

Dal momento che non si campava di soli PC customizzati, il suo secondo lavoro, quello che per sua ammissione costava la fatica vera, era la manutenzione di PC da ufficio, Server e sistemi di stampa. A Milano già allora era pratica diffusa l’affidarsi a contratti di assistenza con persone come Elia. Tuttavia, per essere un manutentore, aveva una filosofia particolare sulla manutenzione: “Se funziona, non toccarlo, e soprattutto non pulirlo”, aveva la convinzione atipica, che se pulivi un pc dalla polvere, questo smetteva di funzionare. Era cosciente e fiero della sua abilità di riparare ogni cosa. Essenziali per esprimere al massimo il suo talento erano tre elementi: tempo, caffeina e pizza. Non importava in quale ordine. Ah, dimenticavo: Elia era anche un programmatore pazzesco. In un pomeriggio scrisse un software di chat che chiamava un IP conosciuto sulla LAN e, se dall’altra parte rispondeva qualcuno, i due IP potevano chattare salvando il contenuto della conversazione in un file di testo su entrambe le macchine. Le cose di Elia funzionavano, ma solo grazie a Elia.

L’alveare disordinato

La crisi arrivò con il progetto Hammurabi, un’ambiziosa rete di smart office per l’importante rinnovo di uno studio legale. Il nome richiamava il Codice di Hammurabi (circa 1754 a.C.), una delle più antiche raccolte di leggi scritte, incisa su una stele di diorite e promulgata dal re babilonese Hammurabi. È famoso per aver stabilito il principio della legge del taglione (“occhio per occhio, dente per dente”), sebbene l’applicazione della pena dipendesse spesso dalla classe sociale dei soggetti coinvolti. A pensarci oggi, non proprio molto “avvocatesco”, ma allora – parliamo del 1999 – al socio fondatore sembrava una trovata geniale. E comunque chapeau per l’avvocato che aveva dato un nome ad un suo progetto.

Elia, non aveva neanche gareggiato con altri per il prezzo, fu cercato ed ingaggiato senza trattativa, il suo prezzo sarebbe stato pagato a prescindere. Sarebbe fuori di testa anche oggi come atteggiamento, tuttavia mi piacque perché confermava il talento del personaggio. Forte della sua genialità disorganizzata, aveva promesso tempi rapidissimi. L’installazione iniziale andò bene. Non passarono tre mesi che un aggiornamento di sistema richiesto dal cliente causò un blackout parziale della rete. Il server conteneva non solo i sistemi di gestione paghe e stipendi, bensì anche tutti i documenti di tutto lo studio legale. Cause rimandate, appuntamenti saltati e la reputazione di Elia appesa ad un filo come la responsabilità sul conto da pagare. Il cliente lo chiamò in preda al panico ed Elia convinto delle sue ragioni lo tranquillizzò. Armato del suo solito ottimismo e della sua memoria infallibile, si precipitò in loco. La mia vita si incrocio con la sua appena due giorni prima. Quel giorno ero con lui. Quel giorno la sua “mappa mentale” fallì.

• Dipendenze ignote: lo schema della rete esisteva solo nella sua mente e, per qualche gioco del destino, non coincideva con la realtà.
• Zero documentazione: non c’era un diagramma che mostrasse come i diversi sottosistemi (telefonia VoIP, videosorveglianza, accesso ai file) interagissero tra loro.
• Comunicazioni fallite: non potendo essere in due posti contemporaneamente, chiese al suo neo-assunto Jacopo che era con noi di riavviare alcune macchine virtuali. Ma Jacopo non aveva idea di cosa stesse facendo, né perché Elia usasse nomi di fantasia senza un elenco formalizzato.

Io non lavoravo con lui, ero lì per puro caso, spinto dalla simpatia verso un personaggio conosciuto poco prima durante un corso sulle tecniche di vendita. In quel caos mi sentivo meno utile di Jacopo. Elia mi confessò il giorno dopo che la mia capacità di “diagnosi differenziale” lo aveva aiutato a scartare progressivamente le varie cause del guasto sistemico. In qualche modo si era sentito supportato. Una parte del suo lavoro, soprattutto quella che riguardava gli impianti di rete, era uguale alla mia. Dopo dieci ore di caos, con il cliente furioso e la reputazione in gioco, Elia riuscì a ripristinare il sistema. Ma il danno era fatto: aveva compromesso la fiducia del cliente, aveva perso Hammurabi, una referenza preziosa e, cosa peggiore, o forse per fortuna, aveva perso un po’ della sua sconfinata fiducia in sé stesso. Capì abbastanza in fretta che qualcosa doveva cambiare.

La “Conversione” a una nuova coscienza del lavoro

Parlammo tutto il pomeriggio successivo dell’accaduto. Sconfortato, Elia si prese due giorni di pausa per digerire le composte e dure parole del cliente, che non lo riteneva all’altezza della reputazione che gli era stata raccontata. Per Elia fu peggio che rinunciare al contratto di manutenzione una volta scaduta la garanzia del sistema. Capì che la sua genialità aveva sbattuto violentemente contro un muro, e sul muro a caratteri cubitali era scritto come un grafito “anche la tua mente fallisce”.
Ragionammo insieme e giungemmo a un’unica conclusione sensata: doveva imparare a documentare il perché e il come. Sebbene non fosse un mio problema, la sua vicenda mi insegnò qualcosa di importante. E ne approfittai per imparare con lui, quindi decidemmo di fare qualcosa insieme. Il suo primo passo fu drastico: ripulì The Hive e buttò via tutti i post-it, i cartoni delle pizze e le inutilità varie che rendevano quel posto indegno di un luogo dove ordine, ragionamento e intelligenza devono essere gli strumenti per raggiungere gli obiettivi. Quando vide pulito e ordinato The Hive nei suoi occhi traspariva un po’ di tristezza. Sapeva, o forse immaginavo che sapesse, che il ragazzotto nerd che amava essere e fare lo strano doveva convertirsi alla migliore versione di se stesso.

Iniziammo a studiare i metodi di progettazione ingegneristica del software. Partimmo da li perché riconoscemmo che la progettazione del software si ramificava attraverso molte funzioni diverse di cui si doveva tener conto e ragione. Inoltre la logica applicata era quella che meglio sposava il tema dei nostri obiettivi. Fu allora che scoprimmo dopo aver scartato qualche alternativa, la potenza del Blueprint. Un documento, semplice, potente e strutturato. E faceva al caso nostro perché era il meglio orientabile in infinite direzioni. Il Nostro interesse era costruire un metodo standard. Rielaborammo in un lavoro a 4 mani la struttura di base di un Blueprint di progetto, focalizzandoci sui capitoli e sotto capitoli essenziali da cui si ottiene la seguente impalcatura fondamentale.

Struttura Base del Blueprint di Progetto

I. Visione e Contesto (Il Perché)

• 1. Obiettivi e Scopo: Definizione chiara dell’obiettivo del progetto e dello scopo del documento.
• 2. Stakeholder : Identificazione dei soggetti coinvolti e mappatura delle loro esigenze primarie.
• 3. Vincoli: Elenco delle limitazioni tecniche, di budget o temporali e delle ipotesi fatte in fase di progettazione.
• 4. Risultati attesi: cosa ci si spetta che il progetto produca.

II. Architettura e Componenti (Il Cosa)

• 4. Panoramica Architetturale: Rappresentazione schematica con diagrammi ad alto livello del sistema e della sua divisione in moduli principali.
• 5. Moduli e Sottosistemi: Descrive ruoli e responsabilità di modelli, persone, e prodotti. Le loro interdipendenze e la gestione della comunicazione e direzione tra le parti.
• 6. Stack Tecnologico: Elenco delle tecnologie, framework, strumenti scelti e motivazione della scelta.

III. Funzionamento e Flussi (Il Come)

• 7. Flussi Operativi e Casi d’Uso Chiave: Descrizione sequenziale e schematica delle interazioni più importanti
• 8. Modelli: Struttura dei principali elementi del “sistema” a progetto e relazioni tra le entità.

IV. Strategie e Governance (Le Regole)

• 9. Gestione Errori e Resilienza: Strategie di error handling, logging e gestione dei fallback (come il sistema reagisce ai fallimenti).
• 10. Sicurezza e Rischio: Modelli di gestione delle procedure di sicurezza applicate.
• 11. Criteri di Qualità e Testing: Strategia per l’assicurazione della qualità, tipi di test e metriche di successo.

V. Implementazione e Futuro (Il Durante e il Dopo)

• 12. Roadmap Evolutiva: Timeline per la realizzazione delle diverse fasi di progetto.
• 13. Mantainance Strategy: Indicazioni su come il sistema verrà supportato, aggiornato ed evoluto nel tempo.

Questa struttura offre una visione completa e interdipendente, garantendo che ogni aspetto del progetto sia chiaramente definito prima di iniziare l’implementazione. E’ solo un gradino.

Blueprint: “The Powered Hive”

Quando Elia ottenne un nuovo contratto, di li a molto poco, presentò immediatamente il Blueprint al cliente. Il cliente comprese una roadmap chiara, capiva cosa stava pagando e quando lo avrebbe ricevuto. Il Blueprint costruiva da subito nella mente del cliente il “Valore” delle sue scelte.
Era il primo Blueprint che usciva da quando era nato il nostro lavoro. Mi chiamò relativamente subito per darmi la notizia dell’ottimo esito, della riuscita del documento e del utilità profonda del nostro operato. Mi raccontò che la prima reazione del cliente fu il preoccuparsi della serietà del documento e che quindi avrebbe fatto lievitare il costo del prodotto finale. Spiegò al cliente che invece, lavorare con un progetto lo avrebbe tutelato da costi latenti e dal pericolo della “non qualità”. Valutammo questa reazione del cliente come un effetto collaterale accettabile e arginabile, considerato il beneficio a lungo termine della metodica. Eravamo soddisfatti, contenti e ci sentivamo cresciuti.

L’ex genio del caos aveva trovato la sua nuova magia: l’Organizzazione. Elia non era diventato meno geniale, ma aveva trasformato la sua intuizione in processo documentato. “The Hive” era ancora produttivo e ben lontano dal tornare ad essere un nido di confusione. Era diventato una centrale operativa efficiente, dove il Blueprint era la prima cosa che si consultava e l’ultima che si aggiornava. La disorganizzazione giovanile Di Elia si trasformo nella sua più grande risorsa di scalabilità professionale.

Per diverso tempo ho mantenuto i contatti con Elia. Per anni, fino al 2006 The Hive rimase un punto di riferimento per gamer, professionisti e anche di amici malati di pizza e pizzate notturne. Era rimasto ironico e mentalmente disorganizzato, ma sul lavoro era diventato esempio di organizzazione e precisione. Il lavoro organizzato era diventato la cura di un esistenza disorganizzata. Di li a poco persi i contatti con lui, e seppi solo tempo dopo da comuni conoscenze, che l’alveare era rimasto impigliato nei capelli rossi di una Irlandese. Il Buon Elia era migrato verso prati verdi e cieli grigi e buona birra.

Perché Blueprint?

Il Blueprint non è un termine astratto: è un documento tecnico concreto, una bussola progettuale che guida il team dall’idea iniziale fino alla realizzazione finale. In origine, il termine “Blueprint” indicava i disegni tecnici stampati su carta cianografica. Oggi, nel mondo digitale, mantiene la stessa funzione: è la versione strutturata di un piano. Un Blueprint di Progetto descrive in modo chiaro e formale l’intero “sistema-progetto“. Lo chiamo così perché un progetto è un insieme di azioni finalizzate al conseguimento di un obiettivo, mentre un sistema è un insieme organico di elementi interconnessi. Unire “sistema e progetto” significa dare forma a una entità che non è la mera somma delle parti, bensì unisce in maniera organica due dimensioni complementari in un unico ambiente sinergico. La chiarezza data da un vocabolario comune e la tracciabilità delle azioni sono intrinsecamente la ragione non unica del raggiungimento degli obiettivi di progetto scritti nel Blueprint. Unire progetto e un sistema non significa semplicemente sommare due concetti, ma fondere metodo e struttura in un’unica entità capace di generare un risultato superiore.

Quando e dove applicare la metodica Blueprint

Qui mi esprimo in maniera un po’univoca per indole e per deformazione esperienziale. Personalmente, nel corso degli anni, il Blueprint è stato trasformato da me nelle versioni che mi facevano più comodo al momento e in base al progetto. L’ho usato per piccoli software, talvolta con un ampio livello di dettaglio; e l’ho usato per grandi progetti di consegna impianti con un basso livello di dettaglio, perché semplicemente fungeva da roadmap per la costruzione di un progetto seguendo modelli di Project Management più appropriati. In qualche caso è stato solo una scaletta scritta di pensieri da organizzare. Il Blueprint non è solo un documento da archiviare, oppure può diventare esclusivamente tale. È uno strumento di lavoro vivo e versatile, cruciale se vogliamo affidarci esclusivamente a lui, oppure essenziale, e può essere anche solo un “Living Document” valido per qualunque altra definizione. Posso affermare con certezza che il “Blueprint è un metodo, o un modo di pensare strutturato” e come tale non ha un recinto entro il quale rinchiudere la sua utilità o funzione. Costruire con metodo per procedere con sicurezza aiuta a evitare il rischio di navigare a vista, accumulando debito tecnico a ogni passo ed avvicinandoci alla meta attraverso un maggior numero di successi. Concludo col fatto che il Blueprint è divenuto negli anni a seguire una metodica ampiamente copiata, inflazionata, personalizzata e rinominata e mille altre cose, incluso l’essersi evoluta in base agli ambiti e contesti di applicazione. Troverai addirittura l’applicazione del modello Blueprint a investimenti finanziari o addirittura intimamente fusa a Business Plan e tutto questo è reso possibile proprio grazie alla versatilità del suo schema di base.

Spero ti sia utile. Grazie del tuo tempo.

L.C.