TESTI

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).

Nel pensiero di Niklas Luhmann, il concetto di autopoiesi — mutuato dalla biologia di Maturana e Varela — descrive la capacità di un sistema di produrre e riprodurre autonomamente i propri elementi, mantenendo la propria identità operativa. Applicato ai sistemi cognitivi, questo implica che ogni atto di conoscenza non è ricezione passiva di dati, ma generazione interna di senso. Un’organizzazione, dunque, non “immagazzina informazioni”: le seleziona, le codifica, le interpreta secondo le proprie strutture. Questo spiega perché due contesti possano reagire in modo radicalmente diverso allo stesso stimolo informativo. L’autopoiesi, così intesa, restituisce dignità e complessità alla gestione della conoscenza: non un flusso neutro, ma un processo selettivo, situato e riflessivo. Costruire ambienti informativi significa allora rendere visibile e coltivabile questa capacità generativa.

Eraclito scrive: «Nel medesimo fiume entriamo e non entriamo, siamo e non siamo»¹. La frase, apparentemente paradossale, offre una delle descrizioni più asciutte e radicali del reale: ogni cosa è attraversata dal mutamento, eppure questo mutamento non è disordine. È forma in divenire, una dinamica interna che segue un principio, un logos. Non siamo di fronte all’entropia, ma a un ordine che si esprime nel fluire.

Il conflitto, nei progetti, non è un’eccezione. È la norma. Non tanto nella forma esplosiva della lite, quanto nell’attrito silenzioso delle incomprensioni, nella frizione tra priorità divergenti, nei fraintendimenti tra ruoli e aspettative. Ogni progetto è un terreno attraversato da tensioni – culturali, emotive, cognitive – che si manifestano a più livelli: tra stakeholder, all’interno del team, nel rapporto con i clienti. Non è un male, ma un dato strutturale. La vera questione, allora, è come affrontare il dissenso in modo intelligente.