TESTI[1039]

In tanti anni di lavoro ho letto centinaia di e-mail, report e documenti aziendali. Quasi tutti scritti in fretta, spesso pieni di formule automatiche, frasi fatte e parole usate “perché si è sempre fatto così”. È curioso: nel mondo dell’IT e del project management, dove si misura tutto, la precisione sparisce appena si prende in mano la tastiera. Si parla di efficienza, ma si scrive con sciatteria. Eppure la qualità del pensiero si riconosce anche da una virgola al posto giusto. Perché chi scrive male, quasi sempre, pensa in modo confuso. E le conseguenze poi si riflettono sul progetto...

Questo articolo dialoga idealmente con il libro Project Management Emergente, che ho letto e da cui ho tratto molti spunti per ripensare il ruolo del project manager nell’epoca dell’incertezza. Le riflessioni di quel volume, unite alle idee di Ulrich Hermanns sul “quarto shock”, tracciano insieme un nuovo orizzonte per la disciplina.

L’altro giorno, in un raro slancio di ordine domestico, ho deciso di mettere mano a un paio di scaffali della mia libreria. Fra volumi dimenticati e vecchi appunti, mi è capitato tra le mani qualcosa che non ricordavo nemmeno di possedere: *Io sono Giorgia*, l’autobiografia dell’attuale presidente del Consiglio. Nulla contro la persona – non è questo il punto – ma molto, moltissimo ci sarebbe da dire sulle scelte politiche del suo partito, specie di fronte al silenzio e alle ambiguità che circondano il genocidio in Palestina. Ma non è questo l’argomento che voglio affrontare qui. Chi mi legge sulla *Stultifera Navis* sa che il tema che porto avanti è quello del **project management hackerato**, un modo diverso di pensare la gestione dei progetti, più critico e sistemico, meno allineato al gergo aziendale e più vicino all’analisi delle strutture profonde del potere e dell’organizzazione. Così, invece di riporre quel libro, ho deciso di liberarmene: l’ho lasciato in una di quelle edicole di *bookcrossing* che amo frequentare, nella speranza di separarmene per sempre. E proprio lì, come spesso accade quando si lascia spazio al caso, ho trovato qualcosa di molto più stimolante: un libro dimenticato ma in ottimo stato, quello che troverete citato in appendice. Leggendolo, ho cominciato a riflettere su alcune idee che collegano l’economia, la politica e la gestione dei progetti. Idee che, come scoprirete tra poco, partono dal semplice atto di “alzare” o “abbassare” i tassi di interesse e arrivano a raccontare molto di più: il modo in cui governiamo sistemi complessi senza mai controllarli davvero.

Chi lavora nella gestione di progetti software ha spesso come riferimento le metodologie agili nate in ambienti angloamericani. Questi approcci hanno portato valore, ma tendono a trasformarsi in schemi rigidi e poco adattabili alle reali dinamiche dei team. In Software Development Rhythms, il prof. Kim Man Lui e Wing Lam Chan propongono una prospettiva diversa, radicata nella cultura professionale cinese e basata sul concetto di ritmo organizzativo. L’idea centrale è che il ritmo emerga dalla sinergia tra pratiche diverse, armonizzate per diventare più efficaci insieme che separatamente. Il libro è strutturato in due parti: la prima introduce il concetto di ritmo e ne esplora le basi teoriche, la seconda mostra come combinarlo con approcci come Scrum, Lean, CMMI o TDD per risolvere problemi concreti. Il risultato è un testo accessibile, ricco di esempi e casi reali, che invita a riconsiderare lo sviluppo software come un processo da orchestrare, non solo da eseguire.

Viviamo immersi in un ecosistema manageriale dominato da modelli anglosassoni, spesso più attenti alla forma che alla sostanza. Manuali, slogan e metodologie “chiavi in mano” promettono risultati rapidi, ma trascurano la complessità e la profondità necessarie per trasformare davvero un’organizzazione. In questo contesto, ho scelto di esplorare prospettive non anglosassoni sul project management e sulla gestione della conoscenza. Il primo passo mi porta in Giappone, dove la Project Management Association of Japan ha sviluppato il P2M, un approccio che integra gestione dei programmi, innovazione strategica e capitalizzazione della conoscenza aziendale. Dopo aver consultato le risorse gratuite online, ho scoperto un modello che privilegia il valore sostenibile e la continuità operativa.

Resilienza nei team di progetto non è resistere agli urti, ma trasformare l’incertezza in conoscenza operativa. Provo a spiegare il mio punto di vista su come linguaggi, pratiche riflessive, regia temporale, leadership diffusa e sostenibilità organizzativa rendano un gruppo capace di apprendere mentre agisce. Dal caso software alla pubblica amministrazione, emerge un metodo per metabolizzare errori e vincoli, evitando la retorica “agile” senza sostanza. La resilienza diventa igiene del discorso, governo dei ritmi, cura dell’energia collettiva. Una critica al tecnicismo vuoto e alla resilienza di facciata chiude il quadro, con il suggerimento all'uso di metriche che misurino apprendimento, cooperazione e debito di resilienza permanente accumulato, per migliorare veramente.

Nel lavoro quotidiano — tra riunioni interminabili, gerarchie immobili e parole come “collaborazione” svuotate di senso — l’intelligenza delle persone non manca: viene sprecata. Non per ignoranza, ma per paura. Non per carenza di idee, ma per eccesso di controllo. In questo articolo ho scelto di confrontarmi con Giuseppe Conte, professionista che da trent’anni riflette sulle trasformazioni del lavoro e della tecnologia con un approccio critico e filosofico. Ne è nata una conversazione che tocca temi come la fiducia, la delega, l’ascolto e la fatica del decidere. Il risultato è un’intervista narrativa, composta da quattro domande e da risposte dense, nate dall’esperienza diretta. Una riflessione per chi fatica a farsi ascoltare, per chi ha smesso di proporre, per chi sente che il proprio pensiero — quando non è omologato — viene trattato come un problema. Ma anche per chi ha ancora il coraggio di fidarsi.

In un panorama editoriale dominato da manuali prevedibili e linguaggi stanchi, Office Monsters: A Survival Guide to Corporate Madness emerge come un’opera necessaria. Martin Eppler e Andri Hinnen compongono un bestiario contemporaneo che mette in scena i mostri interiori, relazionali e sistemici che infestano le organizzazioni. Dalla Yes Yeti al Project Zombie, ogni creatura rappresenta un archetipo comportamentale tanto grottesco quanto riconoscibile. Con uno stile ibrido – tra saggio illustrato, manuale narrativo e mappa mentale – il libro offre uno strumento per nominare l’assurdo senza accusare, per diagnosticare il disfunzionale senza moralismi. L’ironia diventa dispositivo critico, il linguaggio un antidoto alla stupidità sistemica. In questo articolo ne esploriamo struttura e potenza, immaginando un PMO non come bunker operativo, ma come tenda da campo per domatori di mostri. Perché nelle organizzazioni moderne, il vero coraggio non è uccidere il mostro, ma imparare a conviverci senza farsi divorare.

In un mondo che premia la disponibilità continua e l’iperproduttività, dimentichiamo spesso una verità semplice: ciò che è sempre accessibile perde valore. Questo saggio esplora come il principio di scarsità influisca sulla percezione del valore nel project management. Essere sempre presenti, offrire troppo, rispondere a tutto può ridurre l’efficacia percepita del proprio ruolo. Al contrario, dosare la presenza, scegliere il momento giusto, valorizzare il silenzio può rafforzare la leadership. La scarsità, intesa non come mancanza ma come misura, diventa così una leva strategica per migliorare l’efficienza, l’autonomia del team e la qualità delle decisioni.

Questa riflessione nasce da una conversazione avvenuta in forma privata, dopo la pubblicazione di un mio articolo su Stultifera Navis. Un lettore mi ha contattato per chiedermi un parere. Lavora in un contesto complesso, con un team sotto-dimensionato, risorse scarse, e un flusso di priorità che muta più volte nel corso della stessa giornata. La sua area è quella della documentazione tecnica, ma le sue parole potrebbero valere per molti altri settori marginalizzati nella retorica agile. Il problema che mi pone è semplice, e insieme radicale: “Ci sono giorni in cui la documentazione viene trattata come un fardello, appena meno trascurabile dei test. Posso usare l’Agile per proteggere il mio lavoro? O rischio solo di essere travolto dall’ennesimo giro di sprint che non tiene conto della realtà?” A questa domanda ho deciso di rispondere così: non con un consiglio, ma con una presa di posizione.

Nel lessico tecnico contemporaneo parole come DevOps, Agile e ITIL circolano con la leggerezza di slogan, spesso svuotate del loro significato operativo. Questo articolo propone una riflessione critica sull’uso del linguaggio nei progetti IT, interrogando non solo i metodi ma anche il modo in cui li raccontiamo. A partire dalla distinzione aristotelica tra episteme e techne, fino alla sociologia della tecnica di Latour, il testo esplora il valore del “saper fare” come pratica linguistica e progettuale. Un invito a riconnettere teoria e azione, linguaggio e realtà, nell’epoca delle metodologie seriali e delle promesse automatiche.

I progetti informatici contemporanei presentano livelli di complessità senza precedenti. La gestione di infrastrutture cloud, lo sviluppo di software distribuiti e l'integrazione di sistemi eterogenei richiedono metodologie avanzate per il controllo delle performance. Tuttavia, un paradosso emerge costantemente: molte organizzazioni falliscono nonostante dispongano di strumenti metodologici sofisticati e competenze tecniche elevate.

Esiste un paradosso al cuore dell'esperienza manageriale contemporanea che merita una riflessione più profonda di quella che solitamente gli riserviamo. Osservo da anni, nelle sale riunioni e nei corridoi delle aziende dove si decidono le sorti dei progetti, un fenomeno curioso: più informazioni accumuliamo, più sembriamo perdere la capacità di comprendere. Più strumenti di misurazione raffiniamo, più ci allontaniamo dalla sostanza di ciò che dovremmo misurare. Non si tratta della banale osservazione che "troppa informazione confonde" — questa sarebbe una critica superficiale che non coglie la natura più sottile del fenomeno. Si tratta piuttosto di riconoscere che l'ignoranza, in molti contesti organizzativi, non è un accidente ma una costruzione deliberata, una forma di sapienza mascherata che permette al sistema di funzionare secondo logiche che altrimenti entrerebbero in crisi.

Perché serve pensare prima di pianificare Questo testo si rivolge a chi guida progetti in ambienti tecnologicamente avanzati e organizzativamente complessi: chief technology officer, portfolio e project manager, responsabili dell’innovazione, architetti del software, team lead. A coloro che non cercano solo strumenti, ma modi di pensare e strutturare il lavoro in maniera più intelligente, sostenibile, orientata al valore. In contesti dove il cambiamento è continuo e le risorse limitate, progettare significa prima di tutto mettere ordine nei significati. Temi come la documentazione, l’architettura modulare e la roadmap non sono semplici strumenti tecnici, ma dispositivi che rendono leggibili e negoziabili le intenzioni. Se affrontati con consapevolezza, diventano leve strategiche per generare coerenza, responsabilità e orientamento tra chi decide, chi costruisce e chi verifica.

In un mondo che ha delegato alle macchine la capacità di riconoscere i pattern, recuperare l'antica saggezza astronomica nella comunicazione e nell'organizzazione del lavoro diventa un atto di resistenza antropologica. La follia di chi rallenta in un'epoca di accelerazione.

Nei progetti complessi, la conoscenza spesso si disperde prima ancora di consolidarsi. Questo articolo nasce da un'esperienza sul campo: osservare come si lavora, come si dimentica, come si scrive (o non si scrive) ciò che dovrebbe restare. Non è una teoria sulla documentazione, né una guida tecnica. È una riflessione su ciò che rimane — e su ciò che andrebbe custodito con più attenzione.

C'è un momento, nella giornata di ogni sviluppatore, project manager o consulente, in cui si ferma davanti al monitor e si chiede: "Quanto tempo ci vorrà davvero per completare questo task?" È un istante di vulnerabilità professionale, dove l'esperienza incontra l'incertezza, dove la metodologia si scontra con la realtà imprevedibile del lavoro umano. Quei numeri che abbiamo imparato a chiamare "story points" promettono di risolvere questo dilemma, di trasformare il caos della creatività in sequenze ordinate e prevedibili. Ma cosa accade quando la promessa non mantiene la realtà?

Un saggio critico che ripensa il project management alla luce delle trasformazioni della conoscenza, integrando approcci filosofici, epistemologie non occidentali e nuove pratiche organizzative.

In questo saggio, esploro la figura del project manager come agente etico e osservatore sistemico. Partendo da un’esperienza maturata in ambiti ad alta intensità operativa, l’autore sviluppa una riflessione che intreccia pensiero orientale, scienze cognitive e filosofia pratica. Il progetto emerge così non come sequenza tecnica, ma come forma del fare che esige presenza, discernimento e responsabilità relazionale. Una lettura necessaria per chi intende la leadership non come imposizione, ma come tensione trasformativa.

La presente riflessione si colloca all’intersezione tra la filosofia del tempo, le neuroscienze cognitive applicate e la teoria sistemica della complessità. Intende proporre una lettura integrata del concetto di “tempo” come risorsa cognitiva, affettiva e organizzativa, capace di informare tanto la gestione strategica dei progetti quanto le pratiche individuali di autoregolazione. Il quadro teorico di riferimento attinge da tre tradizioni: la fenomenologia del tempo vissuto (Husserl, Merleau-Ponty), il costruttivismo sistemico (Luhmann, von Foerster), e le neuroscienze affettive orientate alla regolazione emotiva e alla tolleranza della frustrazione (Damasio, Mischel, Panksepp).