Calogero (Kàlos) Bonasia

Il presente contributo esplora una prospettiva epistemologicamente fondata e operativamente critica sul project management, superando l’approccio deterministico e prescrittivo dominante. Attraverso un confronto fra la filosofia Kaizen, la teoria della metamorfosi sociale (Beck), il pensiero sistemico (Senge) e la nozione di apprendimento situato, si propone una ridefinizione del progetto come spazio cognitivo aperto, non lineare e trasformativo. La progettualità viene qui intesa come processo evolutivo radicato nella pratica, nella riflessione e nella tensione etica, piuttosto che come dispositivo prestazionale. L’articolo si propone di restituire dignità teorica all’agire progettuale in condizioni di complessità e incertezza, risignificandolo come forma di apprendimento continuo e autocritico.

Il project management non è una tecnica da applicare, né una macchina da programmare. È un modo di stare nel mondo: tra incertezza, decisione e fallibilità. Chi pensa di ridurlo a metodo, a schema, a procedura, non ne ha compreso né la natura né il rischio. Questo breve saggio prova a ricordarlo, senza illusioni e senza compiacenze.

Non è il mestiere che nobilita l’uomo, ma la capacità di attribuirgli un senso. In ambito organizzativo, questa capacità si traduce nella costruzione di strutture narrative condivise: la documentazione non è un atto secondario, bensì il fondamento dell’identità cognitiva di un’impresa.

Nel Rinascimento, gli umanisti condannarono il Medioevo come secoli bui, oscurati dall’ignoranza e dalla superstizione. L’Illuminismo sollevò la ragione come baluardo contro le tenebre della credulità. Oggi, immersi in una rete planetaria che promette accesso istantaneo all’informazione, celebriamo l’intelligenza artificiale come se fosse il coronamento di una lunga marcia verso la verità.

𝑪𝒊ò 𝒄𝒉𝒆 𝒏𝒐𝒏 𝒔𝒊 𝒆𝒍𝒂𝒃𝒐𝒓𝒂, 𝒓𝒊𝒕𝒐𝒓𝒏𝒂. 𝑴𝒂 𝒏𝒐𝒏 𝒓𝒊𝒕𝒐𝒓𝒏𝒂 𝒎𝒂𝒊 𝒄𝒐𝒎𝒆 𝒆𝒓𝒂.Ritorna come caricatura, come spettro che si traveste da radice, come mito vuoto che pretende di diventare identità. Il 25 aprile dovrebbe essere un rito di rigenerazione civile, e invece oggi è minacciato da una classe dirigente che celebra la Resistenza solo quando è costretta, mentre flirta con le ombre che da essa furono sconfitte. Eppure, si ostinano a chiamarlo “governo”. Ma si tratta, più propriamente, di una sindrome: regressiva, afasica, in ostaggio dell’algoritmo e della nostalgia.

25 aprile. Il saluto romano non è romano. Il fascismo non è un’opinione. L’ignoranza non è una scusa.

In un’epoca che proclama la centralità del pensiero ma premia l’automatismo, questo saggio affronta una delle contraddizioni più radicate nel mondo del lavoro contemporaneo: l’intelligenza viene richiesta, ma raramente ascoltata. Tra riunioni inconcludenti, micromanagement paralizzante e tecnologie che promettono efficienza mentre semplificano la complessità dell’umano, si consuma il paradosso dell’organizzazione moderna. Un viaggio critico dentro l’ossessione per il controllo e la paura della decisione, dove la leadership si riduce a gestione dell’immagine e la collaborazione a strategia di sopravvivenza. Un testo che disobbedisce con rigore, scritto per chi non si accontenta più della forma senza sostanza.

Questo testo nasce come riflessione a margine, ma finisce per diventare confine. Tra il tempo vissuto e quello misurato. Tra la parola che abita e quella che transita. Tra l’uomo che lavora e quello che si ripete. Un "saggio aperto", una traccia densa in un mondo di logiche diluite. Per chi lavora nel silenzio delle domande, più che nel rumore delle soluzioni.

In questo dialogo immaginario fuori dal tempo, Fulcenzio Odussomai – filosofo apocrifo e artigiano del pensiero – incontra due figure emblematiche della storia del digitale: Alan Turing, matematico visionario, e Steve Wozniak, ingegnere creativo e giullare del silicio. Ne nasce una conversazione inattesa, intensa e ironica, dove l’errore non è più un nemico ma un maestro, un varco, una soglia di comprensione. Tra aforismi, confessioni e intuizioni, il bug si trasforma in figura simbolica della condizione umana e della progettazione consapevole. Un dialogo sul fallimento come forma di conoscenza, e sul codice come metafora dell’esistenza.

Per uscire dall’acquario non basta saltare. Bisogna smettere di crederci. Smettere di credere che la governance sia progettualità. Che la pianificazione sia conoscenza. Che l’efficienza sia saggezza.

C’è una malinconia sottile che accompagna chi cerca di pensare nell’epoca del rumore. Non una tristezza patetica, ma quella forma strana di lucidità che si prova quando si guarda troppo a lungo una stanza vuota e ci si accorge che qualcosa manca, anche se non si sa bene cosa. È da lì che nasce questa riflessione, scritta in un’ora incerta, quando la luce non è più giorno ma non è ancora sera. Non ha pretese, se non quella di offrire un piccolo varco nel muro compatto delle risposte automatiche. È una passeggiata interiore tra ciò che resta dell’arte, della conoscenza e del silenzio, in un tempo che sembra aver perso il senso del limite. Fulcenzio Odussomai, che scrive queste righe non per insegnare ma per continuare a cercare, sa bene che ogni parola è una provvisoria tregua nel caos, un gesto di resistenza contro la vertigine del troppo.

Il successo, così come viene descritto nelle nostre comunità professionali, ha sempre avuto qualcosa di equivoco. Lo abbiamo rincorso come misura dell’efficienza, del talento, della capacità di portare risultati. Eppure, più ne parliamo, più mi sembra evidente che il suo stesso concetto abbia generato un cortocircuito. Quando lavoro con team di sviluppo, con project manager, con chi si occupa di trasformazione digitale o di coaching Agile, sento spesso parlare di “valore”, di “output”, di “riconoscimento”. Ma raramente si mette in discussione la cornice che definisce tutto questo. È come se ci muovessimo tutti all’interno di un acquario, certi di avere il pieno controllo del nostro nuoto, mentre ignoriamo le pareti di vetro che ci contengono.

E così, il mistero dell’unde malum, di dove nasce davvero il male, non si scioglie mai del tutto. Non si nasconde solo nella psicologia degli individui o nei sistemi che abitano, ma in quella sottile zona di confine dove la ragione smette di interrogare e comincia a giustificare. In quella zona d’ombra dove nessuno è colpevole, eppure tutti lo sono un po’.

Cosa significa davvero progettare un sistema in un mondo che cambia di continuo? Nell’epoca dei microservizi e delle architetture distribuite, il ruolo dell’architetto software non può più essere quello del disegnatore di diagrammi perfetti. Serve una nuova postura: meno prescrittiva, più sistemica, capace di guidare attraverso principi condivisi e non con regole imposte. Propongo una riflessione tecnica e critica sull’architetto come “pianificatore urbano” dei sistemi digitali, tra habitat del codice, autonomia dei team e coerenza evolutiva.

Questo saggio è un "frammento" di un libro mai ultimato. Denso, strutturato e colto, che ripercorre la storia della progettualità dal mondo artigianale alla rivoluzione digitale, con uno sguardo critico sul project management come disciplina tecnico-metodologica. Per accompagnarlo, ecco cinque libri con bibliografia commentata, scelti per approfondire i temi centrali: trasformazione del lavoro, tecniche di gestione, filosofia della tecnica, pensiero giapponese e visione critica del management.

La documentazione non è solo supporto tecnico, ma una vera e propria forma di governo del sapere. Questo saggio esplora la funzione epistemica e politica della documentazione nelle organizzazioni, tra knowledge management, architettura informativa e potere. Perché chi controlla il sapere, controlla l’azione. E documentare bene significa, prima di tutto, pensare meglio.

Tra le promesse più celebrate dei paradigmi Agile e Scrum vi è quella di ridurre l’inerzia burocratica e favorire la snellezza dei processi organizzativi, abilitando le squadre di lavoro a concentrarsi sull’attuazione concreta e sulla consegna continua di valore. Tuttavia, l’applicazione quotidiana di tali metodologie, lungi dal rappresentare un’alternativa realmente efficace alla rigidità organizzativa, rivela spesso una deriva diametralmente opposta.

Viviamo un tempo in cui la velocità è diventata virtù e l’ottimizzazione una fede. Il project management, che un tempo era arte di mediazione tra visione e realtà, oggi rischia di ridursi a un’esecuzione cieca di flussi automatizzati. Ma dietro dashboard perfette e algoritmi intelligenti, resta una domanda cruciale: che cosa stiamo perdendo, mentre crediamo di guadagnare efficienza? Questo non è un rifiuto della tecnologia, né un elogio nostalgico dell’imperfezione umana. È una chiamata al pensiero critico, alla responsabilità, alla capacità di interrogare il contesto prima di aderirvi. Perché non basta prevedere un rischio: bisogna anche comprenderlo. Non basta riallocare una risorsa: bisogna sapere perché lo si fa, e con quali conseguenze. Per dare profondità a questa riflessione, ho selezionato dieci libri che accompagnano e rafforzano il mio punto di vista. Non sono semplici “fonti”: sono compagni di strada. Ogni testo, a suo modo, interroga il rapporto tra sapere, azione, potere e tecnologia. Alcuni parlano di project management, altri di filosofia, altri ancora di etica o di organizzazione. Tutti, però, ci aiutano a mantenere viva una domanda essenziale: vogliamo diventare più rapidi o più consapevoli? La risposta non si trova nei manuali. Ma nella pratica quotidiana del pensiero.

In un’epoca dominata dalla simulazione e dalla velocità, il linguaggio del lavoro si è trasformato in liturgia vuota, e le metodologie nate per liberare sono divenute nuove gabbie simboliche. Questo saggio esplora la crisi epistemologica che colpisce Agile, design thinking e cultura organizzativa, denunciando la deriva performativa del pensiero e invocando una disobbedienza intellettuale fatta di ascolto, dubbio e consapevolezza.

Uno dei principi fondanti dei microservizi è la coesione funzionale. In ambienti monolitici, l’accumulo progressivo di logiche eterogenee porta a un degrado architetturale che rende ogni modifica un rischio sistemico. Nei microservizi, invece, si costruiscono boundary espliciti attorno a funzioni ben delimitate, spesso modellate secondo i concetti del Domain-Driven Design. Questa decomposizione consente una governance più chiara del codice e delle dipendenze, riducendo l’accoppiamento tra componenti e favorendo il cognitive load ottimale per i team. Ma quanto deve essere "piccolo" un microservizio?