Il paradosso dell’analisi funzionale che nessuno legge

In teoria, ogni progetto IT parte da un documento fondamentale che definisce cosa deve fare il sistema, come deve comportarsi e quali problemi deve risolvere. Questo documento ha un nome altisonante: analisi funzionale. Nella pratica, però, questo pilastro della metodologia progettuale si trasforma spesso in un rituale vuoto, un documento che viene creato, approvato entusiasticamente e poi dimenticato nel profondo di qualche cartella aziendale.

Il mito della documentazione perfetta

Alcune figure manageriali credono fermamente che raccogliere verbali delle riunioni sia sufficiente per sostituire un’analisi strutturata. Questa fede incrollabile ha qualcosa di toccante, specialmente quando tali verbali si contraddicono a vicenda senza che nessuno se ne accorga.

Il problema è che la memoria umana è notoriamente inaffidabile in contesti complessi. Affidarsi esclusivamente a verbali scritti durante riunioni caotiche significa costruire su sabbie mobili.

Il circo delle riunioni di raccolta requisiti

L’analisi funzionale inizia tipicamente con una serie di incontri che dovrebbero essere scientifici e metodici. La realtà assomiglia più a una seduta collettiva in cui ogni partecipante interpreta un ruolo diverso, spesso senza avere la minima idea di cosa stiano facendo gli altri.

Si convocano esperti di dominio che dovrebbero possedere conoscenza enciclopedica del settore. Si coinvolgono stakeholder, termine che in teoria indica persone con interesse nel progetto ma che nella pratica include chiunque abbia abbastanza tempo libero per partecipare a riunioni infinite. Si consultano utenti finali, quando va bene, o i loro manager, quando si vuole trasformare il tutto in un campo minato di aspettative irrealistiche.

Questo mosaico di personalità porta con sé bagagli diversi: alcuni hanno competenze reali, altri una passione smisurata per il “fare finta di capire”. Il risultato è un processo che assomiglia più a una commedia di improvvisazione che a uno scambio di informazioni strutturato.

Il paradosso dell’approvazione cieca

Uno degli aspetti più grotteschi dell’analisi funzionale riguarda il suo destino finale. Dopo settimane di lavoro, revisioni e discussioni, si produce un documento di centinaia di pagine che viene approvato con entusiasmo religioso. Il problema? Nessuno lo ha davvero letto.

È simile alla firma di contratti assicurativi: tutti annuiscono vigorosamente senza aver compreso una singola riga. La scusa preferita è sempre “È troppo tecnico”, pronunciata dalle stesse persone che poi si lamenteranno che “Non era abbastanza dettagliato”. Il paradosso è evidente: si chiede precisione ma si rifiuta la complessità necessaria per ottenerla.

Questa dinamica crea un circolo vizioso. Gli analisti producono documenti sempre più dettagliati per coprire ogni eventualità, ma la probabilità che vengano letti diminuisce proporzionalmente all’aumentare delle pagine. Più è completo, meno è utilizzato.

La comunicazione come campo minato

Il primo grande ostacolo di ogni analisi funzionale è rappresentato dalla comunicazione insufficiente tra le parti. Quando clienti, utenti finali, team di sviluppo e management si incontrano, spesso parlano lingue diverse senza rendersene conto.

Il business parla di obiettivi strategici. Gli utenti descrivono problemi quotidiani. Gli sviluppatori ragionano in termini di architetture. Il management pensa a budget e tempistiche. Questa torre di Babele aziendale genera requisiti mal definiti e aspettative divergenti, producendo soluzioni che soddisfano solo convenzioni burocratiche.

L’arte dell’ambiguità strutturata

Anche quando la comunicazione funziona, spesso ci si trova di fronte a requisiti intrinsecamente poco chiari. Le richieste arrivano ambigue, contraddittorie o prive di dettagli essenziali.

Un classico esempio: “Il sistema deve essere veloce e facile da usare”. Cosa significa veloce? Millisecondi o secondi? Facile per chi? Per un esperto o per un novizio? Senza parametri misurabili, ogni requisito diventa un test dove ognuno vede quello che vuole vedere.

Il mostro dello scope creep

Durante l’analisi funzionale emerge il più pericoloso dei mostri progettuali: lo scope creep, l’espansione incontrollata dell’ambito. Ogni riunione porta nuove esigenze, “piccole aggiunte” che sembrano marginali ma che cumulativamente fanno lievitare costi e tempi in modo esponenziale.

Il problema è che ogni richiesta, presa singolarmente, sembra ragionevole. “Sarebbe utile se…”, “Visto che ci siamo…”. Ma la somma di cento piccole cose è un progetto completamente diverso, con complessità e rischi moltiplicati.

La resistenza come sabotaggio involontario

Un altro fenomeno che complica l’analisi funzionale è la resistenza al cambiamento. Gli stakeholder abituati a processi consolidati o sistemi obsoleti reagiscono con scetticismo, se non con ostilità aperta, a proposte innovative. “È sempre stato fatto così” diventa il mantra che blocca ogni miglioramento.

Questa resistenza non è sempre irrazionale. I sistemi esistenti, per quanto imperfetti, sono conosciuti. Il nuovo è incerto, richiede apprendimento, può comportare rischi. Ma quando la paura del cambiamento prevale sulla necessità di evoluzione, si finisce per costruire versioni leggermente migliorate di sistemi già inadeguati.

Il labirinto dei sistemi legacy

Nei contesti aziendali reali, raramente si parte da zero. L’analisi funzionale deve fare i conti con limitazioni tecniche, incompatibilità e documentazione inesistente. Integrare sistemi moderni con piattaforme legacy può raddoppiare la complessità del progetto.

La guerra fredda delle priorità

In ogni progetto esistono stakeholder con obiettivi differenti, spesso in conflitto. Il marketing vuole funzionalità accattivanti, le operations privilegiano stabilità, l’ufficio acquisti cerca contenimento dei costi. Bilanciare queste richieste diventa un esercizio diplomatico impossibile.

Le decisioni finali accontentano parzialmente tutti, scontentando completamente ognuno. Il risultato sono revisioni continue, ritardi e un sistema che non eccelle in nessuna direzione.

Il culto del “sì, sì, sì, certo”

Forse il problema più subdolo delle riunioni di analisi funzionale è la cultura dell’approvazione acritica. Il “sì, sì, sì, certo” è diventato l’affermazione passivo-aggressiva per eccellenza, pronunciata con la stessa convinzione di chi dice “sto bene” mentre è evidentemente malato.

È il suono del conformismo aziendale. Questo atteggiamento è comprensibile: sfidare il consenso richiede coraggio e può essere socialmente scomodo. Ma il costo è altissimo: mesi di sviluppo basati su incomprensioni che avrebbero potuto essere risolte con un semplice “aspetta, non ho capito”.

Come salvare l’analisi funzionale

Nonostante tutte le sue criticità, l’analisi funzionale resta fondamentale. Non può e non deve mancare. Ma serve un approccio diverso.

Prima di tutto, documentazione leggibile. Meglio documenti più brevi ma compresi che tomi enciclopedici ignorati. Secondo, verifiche continue. Non basta approvare il documento, serve testare la comprensione attraverso esempi concreti e scenari reali. Terzo, creare spazi sicuri dove dire “non ho capito” sia visto come segno di professionalità, non di incompetenza.

L’analisi funzionale deve diventare un dialogo continuo, non un evento puntuale. Le incomprensioni vanno intercettate subito, non scoperte mesi dopo durante i test. E forse, soprattutto, serve riconoscere che un buon “ma cosa state dicendo esattamente?” vale più di mille “sì, sì, sì, certo”.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT