L'autore ha trascorso buona parte della sua vita professionale cercando di capire se il problema nei progetti IT fosse il codice, i processi o semplicemente... le persone. Dopo anni passati tra sprint infiniti, task manager mai aggiornati e riunioni in cui nessuno sa perché è lì, ha deciso di iniziare a scrivere. Non per insegnare qualcosa – non è così presuntuoso – ma per documentare l’assurdità sistematica che regola il mondo del lavoro tecnologico.
 
 Il suo curriculum assomiglia a una mappa caotica del mondo IT: sviluppatore per necessità, analista per errore, project manager per disperazione. Ha lavorato in startup che si credevano unicorni e in aziende consolidate che comunicavano ancora via fax. Ha scritto codice, lo ha spiegato ai clienti, poi ha fatto finta di capirli quando volevano esercitare il diritto di recesso.
 
 È convinto che l’ironia sia l’unico strumento realmente efficace per descrivere l’IT contemporaneo, perché la realtà, così com’è, sarebbe troppo crudele da accettare senza riderne. Nei suoi scritti racconta ciò che molti pensano ma pochi osano dire: che dietro ogni buzzword c’è spesso una grande confusione, e dietro ogni "best practice" si nasconde una verità scomoda.
 Insoddisfatto dall'uso dell'intelligenza artificiale generativa nella scrittura del software, ha pensato di iniziare a usarla per scrivere ed illustrare (male) i libri.&nbsp; 
 Non ama definirsi scrittore, preferisce "testimone esausto". Scrive per chi ha sopportato l’ennesima call inutile, per chi è stato assunto come esperto ma trattato come stagista, per chi ha imparato a parlare fluentemente il burocratese aziendale senza mai capirlo davvero.
 
 Oggi continua a lavorare nel settore, nonostante tutto. Forse per masochismo, forse per avere materiale per nuovi libri. Ma di sicuro, con una tastiera in mano, ha trovato un modo per vendicarsi.&nbsp;

Roberto Cappa

Scopri l’autore che racconta con ironia feroce il caos nei progetti IT, tra analisi disfunzionali, sviluppo disordinato e vita d’azienda surreale.

Roberto Cappa - Autore ironico sul mondo IT e aziendale

"Non funziona niente!" non è un libro di project management. È più un esorcismo. Un manuale di auto-difesa passiva-aggressiva per tutti coloro che, almeno una volta nella vita, hanno guardato un Gantt chart e pensato: “Ok, ma chi ha autorizzato questa follia?”. Dimentica i manuali seriosi pieni di diagrammi, acronimi e consigli scritti da chi non ha mai visto un utente reale. Questo libro è una raccolta spietata di episodi vissuti, raccontati con uno stile irriverente, cinico al punto giusto, ma profondamente onesto. L’autore – sopravvissuto a decine di progetti IT condotti con l’infallibile metodo “tanto in qualche modo lo facciamo” – ci accompagna nei meandri del management folle. In queste pagine troverai:
 <ul><li>l’arte di raccogliere requisiti tramite interpretazione libera di frasi dette a voce, in riunioni dove nessuno prende appunti;</li><li>team che passano mesi a personalizzare software perfettamente funzionante fino a renderlo inutilizzabile;</li><li>l’intramontabile paura di essere “early adopter“… anche per tecnologie lanciate nel 2012;</li><li>naturalmente, l’ossessione per la scalabilità infinita – a patto che costi zero e non richieda manutenzione;</li><li>la leggendaria tecnica della “crisi pianificata”, dove si parte in pochi, in ritardo, e si finisce in dodici a lavorare gratis nei weekend – tutto per l’obiettivo, ovviamente;</li><li>il mito del fullstack developer onnisciente, invocato per risparmiare assumendo uno che “sappia fare tutto”, cioè niente bene;
</li><li>lo stile “diversamente Agile”, dove si seguono tutte le cerimonie Scrum… senza capirne il senso, ma con una bella bacheca colorata;</li><li>l'ossessione della riunione: ogni problema, anche il più banale, merita un tavolo tecnico, una call plenaria e, perché no, una task force;</li><li>la farsa delle priorità urgenti, dove ogni pulsante diventa una bomba da disinnescare e tutto è “emergenziale” – tranne il buon senso;</li><li>l’emozione di scoprire all’una di notte che il piano di rollback esiste solo nei sogni del CTO;</li><li>un esilarante bestiario degli utenti che aprono ticket con messaggi tipo “non va”.</li></ul>Popolato da personaggi indimenticabili come Ferdinando, il manager che pontifica di blockchain senza sapere che non è un cocktail, Margherita, l’utente che sa tutto tranne perché fa quello che fa, e Vincenzino, lo sviluppatore brillante che inizia a spegnersi dopo la terza call alle 9 del mattino, questo libro è una vera e propria tragicommedia aziendale.
 Ogni capitolo si apre con una frase realmente pronunciata da qualcuno (tra cui, inspiegabilmente, chi aveva potere decisionale). Il libro non ti darà soluzioni. E va benissimo così. Perché il vero scopo è farti ridere, riflettere e – perché no – sentire meno solo. È dedicato a chi lavora nell’IT, ma anche a chi lo subisce. È un tributo ironico e dissacrante a un settore che riesce a essere all’avanguardia e preistorico allo stesso tempo. Se hai mai sentito la frase “Tanto il software lo fa da solo”, questo libro è per te. Se l’hai detta… beh, è ancora più urgente che tu lo legga.
 
 Acquistalo ora. È l’unico progetto ben progettato che leggerai quest’anno.
 
 Disclaimer legale: ogni riferimento a persone reali è puramente intenzionale. Se ti riconosci, non preoccuparti: non sei solo. Ce l’abbiamo con tutti.

Introduzione

Cos'è e com'è strutturato questo libro

Il progetto IT

Così è già deciso, l'udienza è tolta! - L'analisi di fattibilità

Fai tu una minuta della riunione? - L'analisi funzionale

Abbiamo sempre fatto così - La raccolta dei requisiti

La funzione incarnata - Le user stories

È (quasi) sempre così - La definizione delle specifiche

E il codice fiscale non ce lo metti? - La definizione del modello dati

È troppo tecnico - La documentazione di analisi

Quanto ci vuole? Ma soprattutto, quanto ci costa? - La stima

Le avete messe le penali? - Il contratto di fornitura

Innoviamo nella tradizione - La scelta delle tecnologie

Il matrimonio combinato - La partnership

Possiamo metterci il nostro logo? - Make or buy

Non saremo degli early adopter? - Essere al passo coi tempi

È solo qualche milione - La scalabilità e le performance

A prova di acaro - La sicurezza

Pennello e tavolozza - UI/UX e design dell'interfaccia utente

Integrazione: è fondamentale, ma dopo - Gli integration pattern

Non ingegnerizziamo troppo - La complessità

Bisogna centralizzare - I design pattern

Microliti - Il disegno dell'architettura

Mashup nell'era dei microliti - I microfrontend

ORM: Object-Relational Mayhem - L'accesso ai dati

Il cloud è solo il computer di qualcun altro - L'infrastruttura

Bisogna raggiungere l'obiettivo - La pianificazione

Il mito del fullstack developer - Le figure professionali

Diversamente agili - Il metodo di sviluppo

Per fare un tavolo ci vuole il legno - Lo stato avanzamento lavori

La sindrome del fornitore fantasma - La consulenza

È urgente ed emergenziale - La gestione delle priorità

Sottosviluppo con l'AI - I nuovi strumenti a supporto dello sviluppatore

Nascondo il bug con una grossa mano - Il test e il debug

Intermezzo - La triade maledetta

Fuori è ancora giorno - Il rilascio in produzione

Copiamo i file su un server in FTP - DevOps e CI/CD

Che succede? - Il monitoraggio

Non funziona niente! - L'assistenza e il ticketing

Abbiamo i backup? - La gestione delle emergenze e il disaster recovery

Qualcuno ha un manuale? - La documentazione

Obsolescenza non programmata - La manutenzione evolutiva

I segnali di allarme

Epilogo

Ringraziamenti (e supplica finale)

Libro cartaceo

eBook Kindle

English edition

I segnali di allarme Per concludere questo lungo excursus sul mondo dei progetti IT, proviamo a riassumere quali sono i segnali d’allarme: quelle cose che, quando le vedi, sai che stai per cadere nel baratro. C'è infatti un’amara verità sui segnali d'allarme nei progetti IT: sono incredibilmente coerenti e prevedibili. Gli stessi pattern si ripetono da decenni, attraverso tecnologie, metodologie e culture aziendali diverse. Questo è sia deprimente che stranamente confortante. Deprimente perché significa che continuiamo a commettere gli stessi errori nonostante tutta la nostra esperienza collettiva. Confortante perché significa che, con un po' di attenzione e coraggio, possiamo realmente imparare a riconoscere i progetti problematici prima che ci travolgano. La capacità di ignorare segnali d'allarme evidenti è però purtroppo una competenza affinata con cura nel nostro settore, un'arte tramandata di progetto in progetto, come una maledizione ancestrale o una pessima abitudine di programmazione. Eppure, proprio come nei film horror, i segnali ci sono sempre, chiari come il sangue che cola dalle pareti (che nel nostro caso potrebbe essere una metafora fin troppo accurata). La vera sfida non è identificare i segnali – quelli sono evidenti per chiunque abbia vissuto abbastanza progetti per sviluppare un po' di intuizione. La sfida è creare culture organizzative dove questi segnali possano essere discussi apertamente e affrontati onestamente, invece di essere ignorati fino a quando il disastro diventa impossibile da negare. Perché alla fine, la capacità di riconoscere i segnali d'allarme non è solo una competenza tecnica – è una competenza umana, basata sulla volontà di vedere la realtà per quello che è, non per quello che vorremmo che fosse. E in un'industria ossessionata dalla prossima grande innovazione tecnologica, questo tipo di onestà fondamentale potrebbe essere la skill più rivoluzionaria di tutte. Quindi la prossima volta che ti ritrovi in una riunione di kickoff, ascoltando timeline impossibili, promesse vaghe e piani privi di sostanza, ricorda: non sei paranoico, stai semplicemente prestando attenzione. E in un mondo di persone determinate a ignorare l'acqua che sale intorno a loro, essere quello che nota le prime gocce non è pessimismo – è sopravvivenza. La sindrome delle timeline magiche Il primo e più evidente segnale d'allarme è quello che gli antropologi dell'IT chiamano "la sindrome delle timeline magiche". Si manifesta tipicamente nelle fasi iniziali, quando qualcuno con un'autorità inversamente proporzionale alla sua conoscenza tecnica annuncia date di consegna che sembrano essere state estratte da un cappello magico, o più probabilmente, da quella parte dell'anatomia umana raramente associata al pensiero razionale. "Sei mesi dovrebbero essere più che sufficienti per rifare completamente il nostro sistema legacy di 15 anni, no?" chiede innocentemente Ferdinando, mentre il team tecnico cerca di mascherare espressioni che oscillano tra l'incredulità e il terrore puro. Il calendario di questi progetti sembra scritto da autori di fantasy, ricco di eventi impossibili che accadono in sequenze implausibili, culminando in un lieto fine che ha la stessa probabilità di realizzarsi della tua vecchia fantasia di diventare un ninja astronauta. Il segnale diventa ancora più evidente quando le domande su come siano state stimate queste date vengono accolte con risposte del tipo "è una priorità aziendale" o "il mercato lo richiede", come se queste frasi avessero qualche misterioso potere di alterare le leggi fisiche del tempo e della complessità computazionale. Il paradosso della documentazione di Schrödinger Un altro indicatore precoce è quello che potremmo chiamare "la documentazione di Schrödinger": requisiti che esistono e non esistono simultaneamente, fino a quando non è necessario assegnare colpe per qualcosa che è andato storto. "Avevamo detto chiaramente che il sistema doveva supportare questo caso d'uso!", afferma categoricamente qualcuno, riferendosi a una conversazione di corridoio avvenuta tre mesi prima, mentre il team tecnico scorre freneticamente documenti, e-mail e messaggi, trovando solo vaghi accenni a funzionalità definite in termini così ambigui che potrebbero significare praticamente qualsiasi cosa. La documentazione nei progetti problematici è come quel famoso gatto quantistico: teoricamente esiste in uno stato di sovrapposizione, potendo significare tutto e il contrario di tutto finché qualcuno non la osserva direttamente. E quando finalmente viene osservata, magicamente collassa nello stato che è più conveniente per chi non deve implementarla. Il miraggio delle risorse "presto disponibili" "Attualmente siamo un po' sotto organico, ma stiamo assumendo e presto avremo tutte le risorse necessarie." Questa frase, pronunciata all'inizio di un progetto, dovrebbe attivare lo stesso istinto di sopravvivenza di un rumore metallico in una foresta deserta durante una gita in campeggio. È l'equivalente professionale di "torno subito" nei film horror – un chiaro segnale che le cose non andranno come previsto. Il miraggio delle risorse è particolarmente subdolo perché, a differenza di una timeline irrealistica (che almeno ha date concrete), si basa su promesse vaghe che sono impossibili da verificare fino a quando non è troppo tardi. Nei casi più estremi, questo fenomeno si manifesta con team che lavorano con "risorse condivise" – quel concetto magico per cui lo stesso sviluppatore dovrebbe lavorare contemporaneamente a tre progetti prioritari, ciascuno richiedente il 100% del suo tempo, come se fosse un esperimento di fisica quantistica sulla bilocazione. La mancanza di decisioni tecniche fondamentali "Possiamo iniziare a sviluppare mentre decidiamo l'architettura." Questa affermazione dovrebbe far scattare tutti gli allarmi antincendio mentali di cui disponi. È l'equivalente di iniziare un viaggio cross-country senza decidere la destinazione, il percorso, o se si viaggia in macchina, a piedi o a dorso di lama. I progetti che iniziano senza decisioni fondamentali sull'architettura, sugli strumenti o sulle metodologie sono condannati a passare più tempo a rifare il lavoro che a farlo. La comunicazione unidirezionale Un segnale d'allarme sottile ma letale è la comunicazione che scorre in una sola direzione: dall'alto verso il basso, senza feedback sostanziale che risalga la catena di comando. Nei progetti sani, l'informazione circola come l'acqua in un ecosistema ben bilanciato. Nei progetti problematici, l'informazione scende come una cascata e scompare in un buco nero. Le domande tecniche vengono accolte con risposte vaghe o, peggio, con silenzi imbarazzati. Le preoccupazioni vengono annotate in qualche misterioso documento che nessuno rivedrà mai. Se ti ritrovi in riunioni dove il tuo ruolo sembra essere quello di un ornamento d'ufficio piuttosto che quello di un partecipante attivo, probabilmente sei già nel territorio dei progetti dannati. Il test del feedback loop Una delle differenze fondamentali tra difficoltà normali e patologie è il feedback loop. Nei progetti sani, i problemi vengono identificati, discussi apertamente e affrontati, creando un ciclo di apprendimento e miglioramento continuo. Nelle patologie, i problemi vengono ignorati, nascosti o, peggio ancora, puniti quando vengono segnalati. Se dopo tre sprint consecutivi gli stessi problemi continuano a presentarsi nelle retrospettive senza alcun tentativo concreto di risolverli, non stai assistendo a "normali difficoltà di progetto" ma a un pattern patologico di evitamento. Il paradosso della complessità Le difficoltà normali tendono a diminuire con il tempo, man mano che il team acquisisce familiarità con il dominio e la tecnologia. Le patologie, invece, generano una complessità che cresce in modo esponenziale. Se sei da mesi dentro un progetto e ogni giorno sembri capire meno di quando hai iniziato, non è "la curva di apprendimento" – è un segnale che qualcosa di fondamentale non funziona nell'approccio. La complessità accidentale (quella non inerente al problema ma generata dal modo in cui lo affrontiamo) è come una febbre nel corpo del progetto: un po' è un normale segno che il sistema sta lavorando, troppa è sintomo di un'infezione che potrebbe risultare fatale. Il test della trasparenza Nei progetti sani, c'è una trasparenza quasi brutale: i problemi sono visibili, le metriche sono chiare, lo stato del progetto è noto a tutti. Nei progetti patologici, regna l'opacità: lo stato reale è avvolto nel mistero, sostituito da una narrazione ufficiale sempre più distaccata dalla realtà. Se ti ritrovi a presentare dashboard rassicuranti mentre internamente sai che il progetto sta implodendo, o se il tuo team utilizza un linguaggio in codice per discutere i veri problemi lontano dalle orecchie del management, hai oltrepassato il confine tra difficoltà e patologia. L'indice di turnover Le persone lasciano i lavori per molte ragioni, ma tendono a fuggire in massa dai progetti patologici. Se noti un esodo di talenti, specialmente di quelli più esperti e rispettati, non è solo una coincidenza sfortunata o "il normale mercato del lavoro IT". Il test è semplice: quando le persone se ne vanno, ascolta attentamente le loro ragioni. Le difficoltà normali generano frustrazione ma anche un senso di sfida e opportunità di crescita. Le patologie generano un senso di futilità – la sensazione che nessuno sforzo individuale possa fare la differenza in un sistema fondamentalmente compromesso. Il rapporto tra riunioni e lavoro effettivo In un progetto sano, le riunioni servono a facilitare il lavoro. In un progetto patologico, le riunioni sostituiscono il lavoro. Se il tuo calendario è così pieno di meeting sulla "strategia di progetto", "allineamento degli stakeholder" e "check veloce" che non hai letteralmente tempo per implementare ciò che viene deciso in queste riunioni, hai un chiaro segnale d'allarme. La regola empirica è semplice: se passi più tempo a parlare di quello che farai che a farlo effettivamente, non stai affrontando le normali difficoltà di coordinamento di un progetto complesso – stai partecipando a un elaborato rituale di procrastinazione organizzativa. L'importanza del dissenso costruttivo In ogni sistema complesso, il dissenso non è solo utile – è essenziale per la sopravvivenza. Una delle scene più comuni e più letali nei progetti IT è la riunione dove tutti annuiscono in accordo a un piano che privatamente considerano delirante. Questo fenomeno, che gli psicologi sociali chiamano "pensiero di gruppo", è responsabile di alcuni dei più spettacolari fallimenti nella storia dell'IT. Il pensiero di gruppo si nutre di due paure primordiali dell'ambiente aziendale: la paura di sembrare incompetenti e la paura di risultare non collaborativi. Insieme, creano la tempesta perfetta dove idee oggettivamente terribili ricevono approvazione unanime. Il segnale d'allarme è semplice ma spesso ignorato: se in una riunione con dieci professionisti esperti non emerge nessun disaccordo sostanziale su un piano complesso, non stai assistendo a un miracolo di allineamento – stai vedendo un gruppo di persone che hanno deciso, consciamente o meno, che la loro sopravvivenza sociale è più importante della verità. Il dissenso costruttivo non è l'arte di essere contrari a tutto, né quella di demolire le idee altrui. È la capacità di esprimere preoccupazioni legittime in modo che possano essere ascoltate e integrate nel processo decisionale. Un segnale positivo in un progetto è la presenza di quello che potremmo chiamare "dissenso rispettoso" – la capacità dei membri del team di esprimere dubbi, proporre alternative e sfidare supposizioni senza che questo venga percepito come un attacco personale o una mancanza di spirito di squadra. Se nel tuo team le persone prefissano ogni critica con quindici minuti di scuse e rassicurazioni ("Non voglio sembrare negativo, e apprezzo tantissimo il lavoro fatto, e forse è solo una mia impressione, ma mi chiedevo se forse potremmo considerare..."), hai un chiaro segnale che il dissenso non è veramente benvenuto, ma solo tollerato come un inevitabile fastidio. Nei progetti sani, esiste spesso un ruolo, formale o informale, di "avvocato del diavolo" – qualcuno il cui compito è mettere in discussione le ipotesi, identificare i potenziali punti deboli e costringere il team a giustificare le proprie decisioni. Questo ruolo non è popolare – nessuno ama la persona che continuamente chiede "Ma cosa succede se...?" o "Abbiamo considerato che...?". Eppure, è fondamentale. È il sistema immunitario del progetto, che identifica e neutralizza le minacce prima che possano fare danni irreparabili. L'assenza di questo ruolo, o peggio, la sua presenza ma con nessun impatto reale sulle decisioni, è un segnale d'allarme significativo. Se le obiezioni vengono ascoltate educatamente e poi ignorate sistematicamente, non hai un processo decisionale – hai un teatro decisionale, dove le conclusioni sono predeterminate e il dibattito è solo uno show per dare l'illusione di diligenza. Nei vecchi tempi, i minatori portavano canarini nelle miniere di carbone come sistema di allarme precoce: se il canarino smetteva di cantare o, peggio, moriva, era il segnale che l'aria era diventata tossica e che era tempo di evacuare. Nel mondo dell'IT, alcuni membri del team assumono naturalmente questo ruolo: sono i primi a notare i problemi, a esprimere preoccupazioni, a mettere in guardia dalle direzioni pericolose. Questi "canarini digitali" sono incredibilmente preziosi, anche se spesso vengono etichettati come "negativi", "non collaborativi" o "difficili". Il modo in cui un'organizzazione tratta i suoi canarini è uno dei più potenti segnali d'allarme disponibili. Se le persone che segnalano problemi vengono marginalizzate, ignorate o, peggio, punite, hai un'organizzazione che ha deciso di disattivare i suoi allarmi antincendio perché il suono è fastidioso. Nei progetti sani, chi solleva preoccupazioni legittime viene ascoltato e rispettato, anche quando le sue previsioni sono scomode. Nei progetti patologici, queste voci vengono silenziate, fino a quando si arriva all'inevitabile punto in cui tutti fingono di essere sorpresi del disastro che almeno tre persone avevano esplicitamente previsto sei mesi prima. La retrospettiva onesta Uno strumento potente per coltivare il dissenso costruttivo è la retrospettiva autenticamente onesta – non il rituale di fine sprint dove tutti dicono educatamente che "dovremmo comunicare meglio", ma una vera analisi di ciò che sta funzionando e ciò che sta fallendo. Il segnale d'allarme qui è sottile ma cruciale: se le tue retrospettive non generano mai disagio, probabilmente non stanno facendo il loro lavoro. Il dissenso costruttivo richiede la capacità di dire verità scomode, e le verità scomode raramente generano sensazioni piacevoli quando vengono espresse per la prima volta. Se esci da ogni retrospettiva sentendoti bene riguardo al progetto, indipendentemente dallo stato reale del lavoro, è un segno che il tuo team ha imparato a evitare i problemi veri in favore di discussioni sicure ma superficiali. L'arte di ascoltare i segnali Riconoscere i segnali d'allarme è solo il primo passo. Il vero test è come reagisci quando li individui. Perché, sfortunatamente, la consapevolezza non garantisce l'azione – molti di noi hanno assistito all'intero ciclo di vita di un progetto condannato, riconoscendo ogni segnale lungo il percorso, ma rimanendo comunque fino all'amaro epilogo. Una delle ragioni è ciò che gli psicologi vedono come la tendenza a raddoppiare su un corso d'azione fallimentare perché abbiamo già investito troppo per abbandonarlo. È la stessa psicologia che ti fa rimanere a una festa terribile perché "ormai sono qui" o continuare a guardare una serie TV che non ti piace più perché "ho già visto quattro stagioni". Un'altra ragione è il fenomeno del "boiled frog" – l'idea che se metti una rana in acqua bollente, salterà via immediatamente, ma se la metti in acqua fredda e aumenti gradualmente la temperatura, non percepirà il pericolo fino a quando non sarà troppo tardi. I problemi nei progetti IT spesso crescono così gradualmente che ci adattiamo a livelli di disfunzione che, visti dall'esterno, sembrerebbero completamente inaccettabili. Ma forse la ragione più profonda è che riconoscere veramente i segnali d'allarme richiede il coraggio di agire di conseguenza. E agire spesso significa affrontare conversazioni difficili, sfidare gerarchie stabilite o, nel caso estremo, decidere che è tempo di cercare pascoli più verdi altrove. Questa è forse la lezione più importante: i segnali d'allarme sono inutili se non sei disposto ad ascoltarli. Sono come quei sogni profetici nei film fantasy che l'eroe inizialmente ignora, solo per ritrovarsi esattamente nella situazione che era stata prevista.

"Non funziona niente!" non è un libro di project management. È più un esorcismo. Un manuale di auto-difesa passiva-aggressiva per tutti coloro che,