Il software che nessuno usa

Il software abbandonato è quasi sempre il risultato di un divario tra chi commissiona e chi usa, tra ciò che viene richiesto e ciò che è realmente necessario. L'analisi funzionale è (anche) la pratica di stare vicino a chi lavora per capire cosa fa davvero, non solo cosa dice di fare. Un ragionamento sul costo invisibile delle funzionalità costruite per nessuno, tra dati mal citati, operatori ignorati e software gestionali usati come sofisticate rubriche.

Esiste una statistica che circola nei meeting di progettazione software da oltre vent'anni, e che quasi nessuno si è mai preso la briga di verificare davvero. Jim Johnson, presidente dello Standish Group, la presentò in un keynote nel 2002 ad Alghero: su quattro applicazioni aziendali analizzate, il 45% delle funzionalità non veniva mai usato, e il 19% raramente. Da quel giorno quei numeri hanno cominciato a girare, crescere, generalizzarsi... citati ovunque come se fossero il risultato di uno studio su migliaia di prodotti, quando nascevano da quattro applicazioni interne.

C'è qualcosa di meraviglioso da osservare, qui: la statistica più usata per dimostrare che le funzionalità vengono costruite senza verificare se servono è essa stessa una funzionalità costruita senza verificare se reggeva il peso che le veniva dato.

Il dato nel tempo è stato aggiornato, studi dello stesso Standish Group stimano che solo il 20% delle funzionalità venga usato di frequente, mentre il 50% non viene quasi mai toccato, ma la cosa interessante non è il numero esatto: è che quel numero esiste perché il problema esiste.

Ed è quasi sempre lo stesso problema!

L'errore classico è credere che il problema sia tecnico. Che il software venga abbandonato perché ha dei bug, perché l'interfaccia è ostile, perché il fornitore non ha formato bene gli utenti. Tutte cose vere, quando accadono. Ma raramente è lì il vero attrito.

Il punto in cui le cose si inceppano, molto spesso viene prima: nel momento in cui qualcuno decide cosa costruire (o cosa acquistare).

C'è una distanza - enorme, e quasi sempre invisibile - tra chi commissiona un software e chi lo usa:

• Il direttore firma il contratto;
• Il responsabile IT gestisce l'installazione;
• L'operatore che ci lavora ogni giorno non era in nessuna delle riunioni.

All'operatore che deve lavorare con quel software nessuno ha chiesto niente. Mai. E lui, il giorno dopo il go-live, torna a usare il foglio Excel che aveva prima: perché "con quello so dove mettere le mani."

E come dargli torto? È razionalità pura: uno strumento che non si adatta al tuo flusso di lavoro reale è peggio di nessuno strumento, perché ti chiede di cambiare il modo in cui pensi senza darti nulla in cambio.

L'analisi funzionale nasce esattamente per colmare questa distanza. Non è una fase del progetto, è la pratica di stare abbastanza vicino a chi lavora da capire cosa fa davvero, come lo fa, dove potrebbe cambiare senza resistenze, dove deve per forza cambiare perché sta creando un problema (e qui l'analisi funzionale fa un passo oltre, prevedendo le conseguenze, introducendo la soluzione, pianificando la formazione necessaria e propedeutica ad un cambiamento privo di resistenze).

Quando un operatore dice "ho bisogno di vedere lo storico degli ordini", sta dicendo qualcosa di apparentemente semplice. Il problema è che "storico degli ordini" per lui significa una cosa molto specifica: vuole sapere se quel cliente ha già comprato quel prodotto in quella configurazione, perché se sì, sa già che probabilmente chiederà uno sconto. Non sta chiedendo un archivio, ma una risposta a una domanda che formula mentalmente ogni volta che apre una scheda cliente.

Se chi costruisce il software non sa, o non vuole sapere, questa cosa (o se si ferma alle parole e non arriva a scavare fino al processo sottostante), inevitabilmente finirà per costruire qualcosa di tecnicamente corretto e funzionalmente inutile.

È come il lavoro di un tornio a controllo numerico: puoi avere la macchina più sofisticata del reparto, con tolleranze al micron, ma se il disegno tecnico che hai in mano riporta le misure sbagliate... otterrai un pezzo perfetto nei dettagli ma inutilizzabile nell'assemblaggio. L'errore non era nella lavorazione, l'errore è stato fatto al momento in cui qualcuno ha trascritto le specifiche. Sbagliate. Perché non aveva idea di cosa fosse quel pezzo di metallo e dove dovesse andare.

L'analisi funzionale, in un mondo perfetto, andrebbe fatta prima, non dopo, e andrebbe fatta sul serio. Il paradosso è che questa fase viene spesso compressa o saltata proprio per risparmiare tempo. "Sappiamo già cosa ci serve", si dice. E forse è vero. Ma sapere cosa ci serve è cosa diversa da sapere cosa ci serve per arrivare a quel risultato nel modo migliore possibile. Il secondo caso richiede di entrare nel processo, osservare, fare domande scomode, rompere abitudini che nessuno mette in discussione da anni perché "si è sempre fatto così."

Ho visto aziende che usano sistemi gestionali da migliaia di euro come sofisticate rubriche di indirizzi. Non perché fossero distratte o incompetenti. Perché nessuno - in nessun momento del progetto - ha pensato di chiedere: Mostrami come lavori oggi. Passo per passo.

Per fare un esempio davvero pratico: quando ho visto per la prima volta il programma Magistra - il software per la gestione del laboratorio galenico di Galeno Sistemi srl - ho immediatamente capito che un farmacista che allestisce una preparazione non ragiona come un magazziniere, anche se di fatto gestisce un magazzino; ragiona come un artigiano con responsabilità cliniche: ogni preparazione ha una storia, una prescrizione, un paziente. Il software che non capisce questa differenza diventa un ostacolo burocratico, non uno strumento. E un ostacolo lo si evita, non diviene qualcosa che si usa ogni giorno ma qualcosa che ogni giorno viene ignorato.

Magistra quella differenza l'ha capita, ed è interessante proprio perché nasce da quella comprensione: il programma, al quale ho lavorato anch'io in occasione del suo trentennale, non tratta il farmacista come un magazziniere, parte dal suo gesto, dalla preparazione come atto che ha una storia e un paziente dietro. Per questo non viene evitato ma utilizzato sempre di più. Per questo chi lo usa collabora con gli sviluppatori proponendo modifiche e nuove funzionalità, spesso mettendo a disposizione anche la sua esperienza diretta sul campo. Perché se il software non parte dal gesto reale, diventa burocrazia; se parte dal gesto reale, può diventare metodo.

La domanda che in tante aziende manca, quasi sempre, è anche la più semplice da fare: "Mi fai vedere come lavori?"

Non "come pensi di lavorare". Non "come vorresti lavorare". Come lavori, adesso, con quello che hai, in questo preciso momento. La risposta a quella domanda vale più di qualsiasi capitolato tecnico.

E di solito nessuno la fa.

Dove finisce il caos, inizia la chiarezza. Se sei arrivato fin qui, sai già che il feed non è che rumore. Io lo chiamo Veleno, ma non credere che sia un'esagerazione... infatti è anche peggio del veleno: il feed è una dipendenza che ti ruba la vita, una scimmia seduta sulla tua spalla che ti controlla, che ti usa.

Se vuoi pensare chiaro in un mondo confuso, insieme a me, puoi seguirmi dove il veleno non arriva:

• sul mio sito scriptoriumaeternum.net;
• oppure sul mio SubStack - Segni di Vita, dove potrai ascoltare la versione audio degli articoli.

E se preferisci pensieri brevi, da sessanta secondi alla volta, cerca i video dei miei Minuti di Lucidità sui social, su Telegram e su WhatsApp: iscrivendoti o seguendomi riceverai una notifica quando pubblicherò qualcosa, sarà molto comodo per non perdere i prossimi contenuti.

Il feed sparisce. Le parole restano. E ti cambiano da dentro.

Da bambino avevo un poster che diceva:

Non camminare davanti a me, potrei non seguirti; non camminare dietro di me, potrei non guidarti; cammina al mio fianco...

Quindi sì, seguimi. Ma camminiamo insieme.