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

È troppo tecnico La documentazione di analisi "È troppo tecnico" è una frase che fa particolarmente ridere quando viene pronunciata da qualcuno che lavora nel settore tecnologico. Ma la vera perla è che questa frase viene pronunciata da persone che hanno scritto sul biglietto da visita, non dal tizio che fino a ieri catalogava manoscritti medievali e oggi si è trovato catapultato contro la sua volontà in una software house. Information Technology Come direbbero dei famosi comici, "Ma è del mestiere, questo?" e "No, è gente presa dalla strada". Queste battute, seppur ironiche, svelano una verità scomoda: spesso chi parla di tecnologia non ha mai messo piede nei meandri delle scelte tecnologiche, e si limita a ripetere frasi fatte, senza comprendere appieno la complessità che si cela dietro ogni pezzo di software. La documentazione poi è un capitolo a parte. Esistono due scuole di pensiero, entrambe ugualmente disfunzionali. La prima è quella che potremmo chiamare "l'approccio enciclopedico": produciamo tonnellate di documenti, preferibilmente tutti con lo stesso titolo ma contenuto diverso, sparsi in cartelle dal naming creativo tipo "Documentazione_Finale_V3_Questa_Volta_Davvero_NEW". Documenti talmente dettagliati che per leggerli tutti servirebbe una vita umana, sempre che qualcuno sappia dove trovarli. L'evoluzione più moderna di questa modalità è far produrre tonnellate di documenti soporiferi all'intelligenza artificiale generativa, tutti diversi, ma tutti uguali. All'estremo opposto c'è la scuola del , dove la documentazione è vista come una perdita di tempo al pari del leggere i termini e condizioni di un servizio online. Qui torniamo alla famosa e suprema , quell'e-mail riassuntiva post-riunione che dovrebbe sostituire un'intera analisi funzionale. tanto chi la legge minuta Il contenuto di queste è un capolavoro di vaghezza diplomatica. "Verificare con Margherita", "Fare un check", "Approfondire questo aspetto" sono le frasi più ricorrenti, traducibili in "Nessuno ha la più pallida idea di come funzioni questa cosa e nessuno vuole prendersi la responsabilità di decidere". Come un gigantesco gioco dell'oca dove ogni casella rimanda a qualcun altro. minute Ed è qui che entra in scena il povero analista funzionale, spesso uno sviluppatore come Vincenzino prestato al ruolo, costretto a scavare tra le ambiguità e a indagare come stanno veramente le cose. Non è che possa sedersi e aspettare che i responsabili prendano le redini – l'analista, sveglio e attento, deve colmare quel vuoto decisionale, fingendosi l'autorità che manca. E, con tutta la modestia del caso, una volta raccolte le proprie considerazioni, chiede conferma: "Sono sulla strada giusta, vero?" In questo modo, fa credere che le decisioni siano state prese dai vertici, quando in realtà lui è colui che ha dovuto improvvisare il piano d'azione. Ferdinando, dal canto suo, eccelle nel non prendere decisioni. La sua specialità è rimandare ogni scelta a una fantomatica dove, guarda caso, si deciderà di fare un'altra riunione. prossima riunione Il risultato? Vincenzino finisce per fare delle scelte sensate basate sulla sua esperienza, per poi presentarle in modo che sembrino decisioni prese collegialmente: "Come avevamo discusso nell'ultima riunione…" (che nessuno ricorda), "Come suggerito da Ferdinando…" (che non ha mai suggerito nulla), "Seguendo le indicazioni emerse…" (che non sono mai emerse). E se il progetto va male? Beh, è ovvio che è colpa degli sviluppatori che sono lenti a fare le modifiche. In tutto questo, Ferdinando continua a trovare la documentazione , mentre sfoglia distrattamente l'ennesima che non leggerà mai, programmando l'ennesima riunione dove non si deciderà nulla. Perché nel suo mondo, l'importante non è capire, ma far sembrare di aver capito. troppo tecnica minuta Tutto questo ci ricorda che nel mondo IT la differenza tra il dire e il fare è abissale. Tra l'essere e il ridurre tutto a una serie di , c'è un mondo di sfumature che solo chi è veramente immerso nel mestiere può comprendere. E forse, in fondo, è proprio questa ironia – il fatto che, per avanzare, si debba sempre inventarsi soluzioni sul momento, mentre le vere decisioni restano un mistero – a rendere il nostro lavoro così intrinsecamente affascinante e, al contempo, frustrante. troppo tecnico e-mail-minuta E in quel caos, il vero eroe è sempre l'analista funzionale, l'uomo o la donna che, tra una riunione e l'altra, riesce a dare un senso a tutto questo disordine, facendo sembrare che ogni decisione, anche se presa all'ultimo minuto, sia il risultato di una strategia impeccabile. Generalmente l'analisi funzionale ottiene un sacco di approvazioni entusiastiche, ovviamente senza che nessuno abbia realmente capito o letto quello che è stato scritto. È quasi come se, in ogni riunione, il documento diventasse il protagonista silenzioso di un rituale burocratico: lo si presenta, lo si sfoglia sommariamente – magari solo per dare l'impressione di averlo esaminato – e poi, a colpi di "Ottimo, approvato!", si proclama il successo della fase di analisi. Questo fenomeno non è casuale: è il riflesso di un sistema in cui l'approvazione è vista come una formalità necessaria per certificare l'ovvietà di certe scelte, piuttosto che come il frutto di un'analisi critica e approfondita. Eppure, nonostante questa routine, il documento rimane il fondamento su cui si costruiscono decisioni importanti. Ma il paradosso è evidente: approvare entusiasticamente ciò che nessuno ha letto a fondo è un segnale tanto di fiducia nel processo quanto di una certa compiacenza nell'accettare il buio dell'ignoranza condivisa. In sostanza, l'analisi funzionale diventa un monumento all'arte di apparire competenti, anche quando, in realtà, il vero valore si perde tra le pieghe di una burocrazia che premia più il gesto che il contenuto. Ricordo ancora i giorni in cui l'università ci presentava i linguaggi estremamente formali come la panacea per la definizione di requisiti e specifiche. Il professore, con la sua aria da saggio rigorista, ci spiegava come forzare gli esperti di dominio ad abbracciare queste notazioni, quasi come se si trattasse di un rito di passaggio: meno parole discorsive, più simboli e formule, per eliminare ogni possibile ambiguità. Immaginate la scena: un'aula gremita di studenti con appunti meticolosamente presi, mentre il docente si dilettava nel tracciare diagrammi e logiche che, a suo dire, avrebbero dovuto rendere il processo di definizione dei requisiti limpido come l'acqua di un ruscello alpino. Eppure, una volta usciti dai banchi dell'università, la realtà si è rivelata ben diversa. Nel mondo del lavoro, abbiamo scoperto che non tutti condividono l'amore per la precisione matematica e l'astrazione logica. Alcuni colleghi, e persino clienti, sembrano avere una sorta di rifiuto psicologico nei confronti di documenti scritti in un italiano semplice che, magari, contengono anche solo un paio di termini tecnici. Se quella barriera è già abbastanza alta da far storcere il naso a una comunicazione , immaginate la fatica che farebbero a decifrare quei linguaggi di definizione altamente formalizzati, dove ogni virgola e ogni parentesi contano! leggera Il paradosso è palpabile: mentre in teoria la formalizzazione estrema promette di eliminare ogni equivoco, nella pratica essa si trasforma in un'arma a doppio taglio. Da un lato, si offre una precisione quasi chirurgica, che potrebbe evitare interpretazioni multiple di uno stesso requisito; dall'altro, si crea un divario insormontabile tra chi è abituato a un linguaggio tecnico denso e chi invece preferisce una comunicazione più accessibile e discorsiva. In effetti, ho assistito a meeting in cui la semplice presenza di una formula matematica o di una notazione formale faceva scattare un muto terrore negli occhi di alcuni stakeholder, come se stessero per leggere le istruzioni di un manuale per un'astronave aliena. E così, nella quotidianità lavorativa, il compromesso si impone quasi per forza: si cerca di bilanciare la necessità di precisione con la semplicità comunicativa, adottando un linguaggio ibrido che da un lato rispetta la logica dei formalismi e dall'altro si sforza di essere comprensibile anche a chi non ha trascorso notti insonni a decifrare algoritmi complessi. E qui è dove l'ironia del nostro mestiere si fa più evidente: abbiamo a che fare con persone, non con macchine, e le macchine a volte sono più tolleranti dei loro creatori quando si tratta di capire concetti espressi in maniera oscura. Forse, in fondo, il segreto sta proprio nell'equilibrio: non c'è una soluzione universale che possa andare bene per tutti i contesti e per tutte le persone coinvolte. Mentre alcuni apprezzano la rigidità e la chiarezza dei linguaggi formali, altri trovano conforto nella ricchezza e nella flessibilità di un linguaggio discorsivo, che, pur correndo il rischio di ambiguità, permette un'interazione più naturale e meno intimidatoria. Così, mentre si continua a insegnare e a studiare le tecniche più avanzate per definire requisiti e specifiche, rimane la consapevolezza che, nella realtà del lavoro quotidiano, la comunicazione deve essere adattabile e, soprattutto, umana. Perché, in fin dei conti, i progetti IT non sono soltanto una questione di numeri e simboli, ma di persone che collaborano, comunicano – a volte in modo imperfetto – e, con tanta pazienza, riescono a trasformare idee astratte in soluzioni concrete. E se un giorno ci ritroveremo a dover decifrare un documento redatto interamente in linguaggio formale, speriamo di avere, accanto a noi, quel manager che, nonostante tutto, ha imparato a parlare anche la lingua dei sognatori. La best practice per fallire con stile? Fai in modo che un documento di centinaia di pagine, venga subito approvato all'unanimità, senza neppure una critica.

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