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

Copiamo i file su un server in FTP DevOps e CI/CD La che questo Ferdinando utilizzava rappresenta uno di quei casi studio perfetti di come non gestire un ambiente di produzione. È l'equivalente informatico di fare un intervento chirurgico con un coltello da cucina: tecnicamente possibile, ma con un rischio inaccettabile e conseguenze potenzialmente catastrofiche. tecnica di deploy via FTP Modificare direttamente i file sui server di produzione attraverso FTP viola praticamente ogni principio fondamentale di gestione del software moderno. Si gioca alla roulette russa con l'infrastruttura aziendale, dove ogni deploy diventa un momento di tensione collettiva e preghiera silenziosa. La fragilità di questo approccio è particolarmente allarmante: un singolo errore di battitura, un copia-incolla impreciso o una distrazione momentanea possono tradursi in un downtime completo del sistema. Non c'è margine di errore, nessuna rete di sicurezza, nessuna possibilità di rollback rapido. Questa metodologia arcaica ignora completamente decenni di evoluzione nelle pratiche DevOps. Nessun controllo di versione, nessun ambiente di staging per i test, nessuna automazione, nessuna possibilità di rollback immediato, nessuna garanzia che le modifiche funzionino in modo coerente e, soprattutto, nessuna tracciabilità di chi ha fatto cosa e quando. Il paradosso è che pratiche del genere sopravvivono spesso nelle aziende sotto l'illusione di essere o , quando in realtà rappresentano una bomba a orologeria che inevitabilmente esploderà, causando danni ben superiori al tempo risparmiato con questa presunta . più veloci più pratiche efficienza La vera ironia della situazione è che esistono strumenti e processi che rendono il deploy sicuro, affidabile e ripetibile, richiedendo uno sforzo iniziale di configurazione ma risparmiando innumerevoli ore di stress, debugging e scuse ai clienti per i downtime inaspettati. Ma forse per alcuni Ferdinando del mondo, l'adrenalina del deploy manuale in produzione è un'esperienza che nessun processo automatizzato potrà mai sostituire. La configurazione errata degli ambienti rappresenta uno dei problemi più pericolosi. Quando un'applicazione funziona perfettamente in sviluppo ma crolla misteriosamente in produzione, spesso la radice del problema risiede proprio in queste sottili differenze ambientali che nessuno ha documentato o standardizzato. Le pipeline instabili o parzialmente automatizzate creano quella che potremmo chiamare : l'apparenza di modernità senza i benefici reali. Queste implementazioni ibride, dove alcuni passaggi sono automatizzati mentre altri richiedono intervento manuale, spesso combinano il peggio di entrambi i mondi: la complessità dell'automazione con l'inaffidabilità dei processi manuali. La carenza di test automatici adeguati è probabilmente il difetto più comune e dannoso. Molte organizzazioni si illudono di fare CI/CD quando in realtà stanno semplicemente automatizzando il processo di introduzione di bug in produzione. Senza una solida copertura di test, ogni deploy diventa un atto di fede, e la pipeline serve solo ad accelerare l'iniezione di problemi nel sistema piuttosto che a garantirne la qualità. Illusione DevOps Inoltre, la gestione inadeguata dei rollback è particolarmente pericolosa perché i suoi difetti emergono solo nei momenti più critici. È come scoprire che il paracadute d'emergenza è difettoso solo quando quello principale ha già fallito, non il momento ideale per fare questa scoperta. Molti team si concentrano esclusivamente sul percorso felice del deploy senza mai testare adeguatamente le procedure di rollback, fino a quando non si trovano in una crisi reale. La scarsa gestione della configurazione trasforma ogni deploy in un'avventura imprevedibile. Le password hardcoded, i percorsi assoluti, le dipendenze non specificate, sono tutte mine nascoste pronte a esplodere nel momento meno opportuno. Infine, i problemi di comunicazione e coordinamento rivelano un fraintendimento fondamentale dello spirito DevOps. La buona pratica DevOps, infatti, non riguarda solo gli strumenti o l'automazione, ma fondamentalmente la collaborazione e la responsabilità condivisa. Quando sviluppatori e operazioni continuano a lavorare in , anche con la più sofisticata pipeline CI/CD, si stanno semplicemente automatizzando i conflitti esistenti invece di risolverli. silos La vera ironia è che molti di questi problemi emergono proprio nelle organizzazioni che adottano il DevOps per i motivi sbagliati: per una vaga promessa di maggiore velocità, o perché . tutti lo stanno facendo La best practice per fallire con stile? È arrivato il momento del deploy. Copia i file direttamente dal tuo computer al server di produzione, e incrocia le dita.

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