Il problema delle specifiche vaghe nei progetti IT

Esiste un conflitto fondamentale nei progetti IT che causa più problemi di qualsiasi bug. È il fossato tra la precisione binaria richiesta dai computer e il mondo sfumato della comunicazione umana.

I computer operano in un universo dove tutto è definito con precisione assoluta. Zero o uno, vero o falso. Non esistono zone grigie. Questo approccio binario entra in collisione con il modo in cui gli esseri umani descrivono la realtà, fatto di approssimazioni ed eccezioni.

Questa incompatibilità si manifesta con particolare intensità durante la definizione delle specifiche tecniche, dove requisiti vaghi e ambigui devono essere trasformati in istruzioni precise che le macchine possano eseguire senza ambiguità.

La maledizione del “quasi sempre”

Una delle frasi più terrificanti è “Sì, è sempre così… quasi sempre”. Quel “quasi” contiene un universo di complessità nascosta. È come dire che una regola è assoluta tranne quando non lo è.

Nel mondo digitale non esistono approssimazioni. Una condizione è vera o falsa. Non c’è spazio per il “dipende”. Eppure le risposte sono quasi sempre condizionate, sfumate, contestuali.

Gli sviluppatori devono tradurre “È sempre così tranne il giovedì” in logica booleana, scoprendo che nemmeno chi ha fatto quella affermazione sa cosa significhi. “È sempre così, tranne quando non lo è” non è una specifica, è un’ammissione di ignoranza.

Le relazioni che cambiano forma

Le relazioni tra entità sembrano semplici. Uno-a-uno, uno-a-molti, molti-a-molti. Ma mappando processi reali, le risposte sono sempre condizionate: “È uno solo, ma a volte potrebbero essere due”.

Queste ambiguità riflettono la complessità reale, dove le eccezioni sono numerose quanto le regole. Ma per progettare database serve chiarezza assoluta. Un campo può essere nullable oppure no. Una foreign key può permettere duplicati oppure deve essere unica. Non esistono vie di mezzo.

Le riunioni durano ore per arrivare a definizioni come: “Il sistema gestisce una relazione uno-a-uno che occasionalmente potrebbe essere uno-a-due”. Specifiche che non specificano nulla e lasciano gli sviluppatori a dover indovinare l’implementazione corretta.

L’algebra booleana e il linguaggio naturale

I computer ragionano con operatori logici. AND, OR, NOT. Gli esseri umani usano questi concetti quotidianamente, ma con sfumature che la logica formale non cattura.

“Questa azione si verifica se succede A e B”. Poi arriva: “Ah sì, succede con B, oppure anche con C”. L’operatore AND diventa OR. La specifica iniziale era sbagliata.

Il problema è che gli esseri umani ragionano per esempi, non per regole generali. Elencano casi specifici senza astrarre la logica sottostante. Ma spesso le regole generali non esistono. I processi si sono evoluti organicamente, nessuno ha mai formalizzato la logica.

La difficoltà con i concetti astratti

Molte persone faticano con concetti senza rappresentazione fisica. Lo stato di un’applicazione, il flusso di dati, le transizioni. “Se non posso toccarlo, non esiste”.

Spiegare che un sistema può essere in diversi stati porta a metafore fuorvianti che confondono più di quanto chiariscano. Gli esperti di dominio vedono i processi come blob indistinti dove “l’utente clicca e succede la magia”. Non riescono a scomporre in passaggi discreti con input, output e regole specifiche.

Questa incapacità di astrarre rende difficile catturare requisiti in modo strutturato. Tutto diventa un flusso indistinto di azioni senza logica esplicita.

L’ossessione per l’interfaccia

Un fenomeno ricorrente è la focalizzazione sull’interfaccia grafica. Per molti stakeholder, il software è solo quello che si vede. La logica sottostante è invisibile quindi irrilevante.

Le discussioni sui requisiti diventano dibattiti su colori e layout. “Voglio un pulsante qui, grande e blu”. Cosa dovrebbe fare? “Deve sistemare le cose”. Questa superficialità nasconde incomprensione di cosa significhi sviluppare software. Un pulsante è solo un trigger, dietro serve logica, validazioni, gestione errori.

La sottovalutazione sistemica della complessità

“Non puoi aggiungere un pulsante che fa tutto automaticamente?” rivela una concezione magica della programmazione.

Ogni nuova funzionalità ha costi esponenziali. Deve integrarsi, gestire casi limite, essere testata, documentata. Un “semplice pulsante” può richiedere settimane.

Ma questa complessità è invisibile. Gli utenti giudicano la difficoltà dalla semplicità dell’interfaccia, non dalla complessità della logica sottostante.

Il terrore dei casi limite

“Cosa succede se l’utente inserisce dati sbagliati?” Risposta tipica: “Ma perché dovrebbe?”. Come se gli errori umani fossero eventi teorici e non certezze.

La gestione degli errori è vista come pessimismo inutile. “Facciamo in modo che niente vada storto” è una strategia che ignora la realtà. Ma gli utenti sbaglieranno, i sistemi si disconnetteranno, i dati saranno inconsistenti. Non prevedere questi scenari garantisce problemi futuri.

Le specifiche si concentrano sul “happy path”, ignorando percorsi alternativi fino a quando non diventano emergenze in produzione. Poi tutti si chiedono perché il sistema si comporta in modo imprevedibile quando qualcosa non va secondo i piani.

La lacuna di competenza tecnica di base

Forse il problema più preoccupante è la diffusa mancanza di competenze basilari anche tra chi lavora nell’IT. Commerciali che vendono database senza sapere cosa sia una chiave primaria. Manager che discutono architetture senza comprendere concetti fondamentali.

Questi non sono concetti esoterici. Una relazione uno-a-molti significa che un’entità può avere molteplici istanze correlate. Una chiave primaria è un identificatore unico. L’algebra booleana è capire la differenza tra AND, OR e NOT.

Eppure questa ignoranza viene tollerata. Nel settore IT la competenza tecnica sembra un optional. È come avere un venditore di vini che non sa distinguere rosso da bianco.

Come affrontare il problema

La soluzione inizia con il riconoscere il problema. Le specifiche vaghe sono la causa principale di fallimenti progettuali. Investire tempo per chiarire ambiguità all’inizio risparmia mesi di rework.

Serve un linguaggio comune tra business e tecnici. Non pretendere che tutti sappiano programmare, ma nemmeno accettare che termini fondamentali restino misteriosi. Gli analisti devono diventare traduttori attivi. Quando sentono “quasi sempre”, devono scavare per capire cosa significa. Quando incontrano ambiguità, devono costringere a definizioni precise.

E serve cambiare la cultura che considera accettabile vendere tecnologie che non si comprendono. La competenza tecnica di base dovrebbe essere un prerequisito, non un lusso.

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