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

Non ingegnerizziamo troppo La complessità L'eterna lotta tra la complessità necessaria e la semplicità imposta dall'alto! Più cerchi di entrare nei dettagli, più vedi gli occhi del tuo interlocutore vetrificarsi come una finestra durante una gelata invernale. Immaginiamo la scena: hai passato settimane a progettare un'architettura software elegante e robusta, considerando scalabilità, manutenibilità, sicurezza e tutti quei dettagli che fanno la differenza tra un sistema che funziona e uno che funziona bene. Arrivi alla presentazione con il tuo diagramma architetturale, orgoglioso come un genitore il primo giorno di scuola del figlio. Ed ecco che inizia il teatrino. Qualunque architettura hardware/software tu abbia in mente, prima o poi dovrà passare al vaglio di qualcuno – che si tratti del team leader, di Ferdinando l'innovatore nella tradizione, o, addirittura, dell'amministratore delegato. Più si sale nella scala gerarchica, più diventa improbabile che il tuo interlocutore colga i dettagli tecnici: quello che conta davvero, nel loro mondo, è la percezione della complessità. In pratica, più il tuo schema appare complicato, più automaticamente verrà etichettato come costoso e lungo da realizzare, anche se, in realtà, la sostanza potrebbe essere molto semplice. È paradossale: non sempre ciò che sembra elaborato è difficile da implementare, così come un semplice schema con due blocchi e una freccia non garantisce necessariamente una soluzione facile. Il trucco sta nel trovare quel delicato equilibrio, tra un design sufficientemente articolato da coprire tutte le esigenze e una semplicità tale da far dire a chi non ha voglia di addentrarsi nei dettagli tecnici: "Il progetto DEVE essere semplice!" E, credetemi, ho sentito alcune frasi che vi faranno sorridere (o rabbrividire) per la loro ovvietà. "Non ingegnerizziamo troppo" (era una semplice architettura client-server) – parola detta da un ingegnere che, evidentemente, ha dimenticato l'ingegneria. "Ma dobbiamo fare così tanti microservizi? Non possiamo farne solo due?" – verrebbe da chiedersi allora perché fare dei microservizi. "Ma non possiamo usare direttamente il back-end senza passare dal front-end, a questo punto?" – certo, e l'utente scriverà i dati direttamente nel database. "Perché un database non relazionale, se abbiamo quelli relazionali?" – come se la relazionalità fosse una feature aggiuntiva che si può installare pagando un abbonamento . pro Il principio ( ) viene spesso frainteso come . C'è una sottile ma cruciale differenza tra semplificare qualcosa e renderlo semplicistico. Il vero principio KISS diventa allora imprescindibile. Ovviamente, non si tratta di semplificare a tal punto da compromettere le funzionalità essenziali del sistema, ma di evitare inutili complicazioni che, a ben vedere, sono spesso frutto di una mentalità che premia la complessità solo perché ingegneristica. La sfida è ardua: dove si trova il giusto confine tra una progettazione sufficientemente sofisticata e una eccessiva complicazione che rende il progetto irriconoscibile agli occhi dei decisori? Questa è una lezione che, purtroppo, non si apprende da un manuale, né in un corso universitario, ma solo attraverso l'esperienza sul campo – attraverso il confronto con innumerevoli architetture e il confronto con i relativi problemi che ne derivano. KISS Keep It Simple, Stupid Keep It Stupidly Simple sembra Quando si tratta di presentare un progetto, è importante ricordare che la semplicità, se ben dosata, è la chiave del successo. Mentre i tecnici possono apprezzare la ricchezza dei dettagli e la logica sottostante, a livelli decisionali più alti l'unica variabile che conta è quella percepita: complessità equivale a costi e tempi maggiori. Quindi, se il tuo interlocutore è il in materia tecnica – o meglio, se il suo focus è esclusivamente sulla semplicità apparente – il tuo progetto deve risultare limpido e diretto, senza inutili fronzoli. Solo così potrai superare le barriere del gergo tecnico e far comprendere che, in fondo, la vera ingegneria sta nel saper dosare la complessità per ottenere soluzioni efficaci e sostenibili. vero incompetente L'esperienza ti insegna che ogni freccia in più nel tuo diagramma deve guadagnarsi il diritto di esistere. Ogni componente aggiuntivo deve portare un valore che supera il costo della sua complessità. È un'arte sottile, raffinata attraverso anni di progetti, bug, deploy falliti e notti insonni a chiedersi "Perché ho pensato che fosse una buona idea?" La ricerca della perfezione tecnica può effettivamente diventare un problema quando si trasforma in perfezionismo fine a sé stesso. Nel frattempo, continueremo a sorridere pazientemente mentre qualcuno suggerisce di "Usare direttamente il backend senza frontend". La best practice per fallire con stile? Progetta un’architettura dove la validazione di una data viene fatta da un microservizio dedicato, e mettilo bene in evidenza nello schema a blocchi che mostrerai al management.

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