Michele PinassiTL;DR L’ennesima storia di ordinaria burocrazia di quando anche pagare i servizi scolastici offerti dal proprio Comune attraverso le procedure telematiche diventa una odissea.
“Burocrazia − una difficoltà per ogni soluzione.”
Herbert Samuel
Arrivano i bollettini di pagamento dei servizi scolastici di mio figlio. Fortunatamente, da qualche tempo è possibile pagarli comodamente via Internet, senza doversi recare in Posta con conseguente coda e spreco di tempo, attraverso lo strumento PagoPA.
Si può pagare usando l’app IO, inquadrando il qrcode stampato sul bollettino, oppure attraverso altri portali di pagamento messi a disposizione dalle amministrazioni.
Pagare via PagoPA (anche attraverso l’app IO), però, comporta anche che ogni transazione viene gravata delle spese del gestore del pagamento, tipicamente tra i 50 centesimi e 1€: non è possibile, al momento, accorpare più bollettini e pagare in una unica transazione, riducendo i costi.
Altre piattaforme, come ad esempio la “plugandpay” che viene messa a disposizione da diverse amministrazioni comunali, permette di accorpare fino a 5 bollettini riducendo conseguentemente gli oneri fissi: considerando che spesso parliamo di cifre di poche decine di euro, anche solo 1€ di transazione rischia d’incidere non poco (ma poi, perché dover pagare per …pagare?).
Insomma, per tornare al punto, vado sulla piattaforma plugandpay del mio Comune per il pagamento dei bollettini e mi metto, diligentemente, a inserire i vari bollettini. Già il limite a 5 mi sta un po’ stretto (ma perché questo limite?) ma vado oltre e procedo al pagamento. Inserisco i dati, autorizzo la transazione dal gestore della carta di credito e…SBAM! “Errore tecnico, riprovare”. Poco male, penso, riproviamo con il pagamento! E invece no: per motivi incomprensibili, il carrello è stato svuotato e dovrei iniziare da capo a re-inserire tutti i dati relativi ai bollettini da pagare!
Mi chiedo se chi ha progettato il sistema abbia considerato l’eventualità che un pagamento potrebbe non andare a buon fine, conservando –come vorrebbe il buon senso!– i dati all’interno del “carrello” virtuale per consentire all’utente di tentare ancora.
Evidentemente no, ma questo è solo uno dei tanti, tantissimi casi in cui il problema non è la “tecnologia” ma di chi progetta in modo inutilmente complicato e, spesso, contro-intuitivo. In chi realizza portali (chi ha avuto a che fare con il sito web dell’INPS sa bene di cosa parlo…) complicati, disomogenei, spesso farraginosi e complessi.
Potrei fare decine di esempi su come molti portali, soprattutto della pubblica amministrazione, adottino strutture, procedure e terminologie inutilmente complicate.
Ne abbiamo già parlato anche su questo blog, come nel post sul rinnovo della patente di guida (oggetto, inoltre, di una segnalazione anche all’Ufficio per la semplificazione e la sburocratizzazione, rimasta ovviamente senza risposta), di come moltissime procedure messe in atto dalle PA siano spesso gravate da inutili complicazioni, spesso più utili al burocrate di turno che al cittadino.
Complicazioni che non solo rendono la vita più difficile al cittadino ma, talvolta, aumentano anche il rischio di errore e conseguenti problemi. Eppure, la tecnologia renderebbe davvero moltissime antipatiche incombenze più leggere, come appunto il pagamento delle tasse e delle imposte. Basterebbe applicare il principio del KISS –Keep it simple, stupid-, tornando a considerare la tecnologia uno strumento al servizio della collettività, non una “religione” per pochi eletti.
È dalla cosiddetta “Legge Stanca” del 1994 che si parla di accessibilità dei siti web istituzionali, attraverso l’emanazione di linee guida costantemente aggiornate dall’AgID per rispondere alle esigenze di massima fruibilità da parte dei cittadini, soprattutto quelli meno capaci.
Tali linee guida, però, si riferiscono esclusivamente alla possibilità di accedere ai contenuti anche attraverso strumenti per sopperire a eventuali disabilità (es. browser per ipovedenti), non a buone pratiche per ridurre elementi inutili, procedure ridondanti, passaggi superflui o funzionalità contro-intuitive. Eppure, l’accessibilità dovrebbe passare anche attraverso questi paradigmi, poiché “click inutili” equivalgono a tempo sprecato, che equivale a un aumento della frustrazione dell’utente e, di conseguenza, a una disaffezione nei confronti degli strumenti tecnologici.
In buona sostanza, quindi, una pessima piattaforma tecnologica spesso crea più danni della mancanza della piattaforma stessa, con l’aggravante che, nel caso di una PA, gli stakeholders spesso non hanno né le competenze né le capacità per chiedere un miglioramento della stessa. Che, in molti casi, altro non è che una qualche piattaforma sviluppata da una azienda privata a cui l’amministrazione pubblica ha assegnato l’appalto, con conseguenze scarico di responsabilità.
In teoria, il cittadino potrebbe rivolgersi al Difensore Civico Digitale, figura prevista dal Codice dell’Amministrazione Digitale a difesa del rispetto della normativa CAD -Codice Amministrazione Digitale-. Che all’art 53 “Siti Internet delle pubbliche amministrazioni”, specifica che “Le pubbliche amministrazioni realizzano siti istituzionali su reti telematiche che rispettano i principi di accessibilità, nonché di elevata usabilità e reperibilità, anche da parte delle persone disabili, completezza di informazione, chiarezza di linguaggio, affidabilità, semplicità dì consultazione, qualità, omogeneità ed interoperabilità.“
Insomma, i principi sarebbero indicati in normativa. Il problema è che nelle PA mancano spesso le competenze minime necessarie per comprendere il problema, almeno dal punto di vista tecnico. Con il risultato che abbiamo sotto gli occhi.
(quasi) tutti contenti, quindi, dalla società privata che si garantisce qualche commessa pubblica al politico di turno che può farsi bello, a mezzo stampa, dell’innovativo servizio offerto alla cittadinanza. Il cittadino? Beh, a quello spesso resta solo la rabbia e la frustrazione di non riuscire a effettuare neanche un semplice pagamento online. A cui si aggiunge, talvolta, pure la frustrazione di credere (erroneamente) di non essere lui in grado di farlo…
Hai trovato utile questo articolo?
4 comments
He… Il problema è che complicato per l’utente == guadagno per qualcuno.
Il qualcuno che ad es. si fa pagare lo sviluppo di un complesso porcale con complessa manutenzione al posto di un sito banale con molta meno manutenzione. Qualcun altro approva e magari incassa un “dono” per l’approvazione. Il solo modo di cancellare questo aspetto, non sempre provabile, ma il cui sospetto aleggia assai, è semplice: la PA DEVE avere un IT INTERNO, esclusivamente pubblico che si basa esclusivamente so Software Libero e NON prevede alcuna interfaccia proprietaria al servizio.
Ad es. IO dovrebbe essere illegale: il servizio si prevede API REST che permettono a chiunque di scrivere il proprio client MA la sola implementazione fornita è una crapplicazione per sistemi Android/iOS ovvero proprietari e pure extracomunitari, di aziende soggette al Patriot Act ovvero per definizione incompatibili col GDPR UE al di là d’ogni possibile garanzia.
Allo stesso modo le banche dovrebbero esser costrette come ogni altro servizio “essenziale” ad avere API standard, es. OpenBank SENZA i limiti “per i non operatori finanziari” per cui chiunque possa usare il servizio con un client proprio, ovvero ad es. disporre pagamenti e vedere le transazioni da un’app desktop FLOSS senza passare dal porcale bancario di turno, senza obbligo surrettizio di smartphone con la SCUSA della PSD2 che in effetti *vieterebbe* nello spirito questo approccio (ammesso il soft-token, non ammesso operare sullo stesso dispositivo completamente per evitare che una compromissione di questo posta generare operazioni apparentemente legittime, cosa che sta avvenendo sempre più).
Solo siamo MOLTO distanti da questo e sorvegliare piace a tutti, politicanti inclusi, anche considerato le “porte girevoli” col “privato”…
Grazie Kim per il tuo contributo alla discussione. Concordo con il fatto che andrebbero prodotte API aperte, a disposizione della comunità, ma questo porterebbe –secondo la mia visione e considerando la situazione attuale– a una vera e propria “esplosione” d’incidenti informatici, dettati da svariati fattori tra cui gli errori di progettazione e sviluppo. Realizzare prodotti di qualità costa molto, spesso più di quanto si sarebbe disposti a investire. Le conseguenze sono tanti prodotti sviluppati male, che mettono a rischio non solo l’operatività del servizio ma anche, e soprattutto, i dati degli utenti.
Buongiorno,
condivido l’articolo, ma vorrei offrire qualche spunto in più, con una visione leggermente diversa.
Parlo per esperienza diretta. Il più delle volte il problema deriva da chi sviluppa i programmi, che è più interessato alla funzionalità dell’algoritmo ma meno, molto meno, all’esperienza utente. Ciò prescinde dal fatto che l’applicativo sia sviluppato internamente o esternamente.
Il problema non è la cattiva volontà ma, come detto nell’articolo, culturale, e per questo più difficile da affrontare.
E si vede già da come gli informatici (e non solo) scrivono i documenti (tendenzialmente, illeggibili e poco utili, quando si scrivono). Parlo sia della manualistica utente, sia dei documenti tecnici. E uno ci può mettere tutta la buona volontà, definire la metodologia, correggere quanto fatto, portare esempi. Ma è quasi sempre una battaglia persa. E se ci si rivolge all’esterno, poi, il più delle volte diventa un vero e proprio bagno di sangue.
Insomma, redigere una normativa per principi è (abbastanza) facile, poi però una PA con poche persone dedicate all’informatica si deve organizzare nell’ambito del budget e delle risorse a disposizione, che generalmente sono molto limitati (esempio pratico: su una amministrazione di 80 persone, 8 sono dedicate all’informatica – un numero teoricamente equo rispetto ai compiti istituzionali. Ecco la ripartizione: 2 per la gestione dell’infrastruttura, 1 per l’helpdesk agli utenti interni, 3 per lo sviluppo di applicativi e 2 per la sicurezza informatica. Insomma, è come cercare di vincere la guerra avendo a disposizione un pacchetto di noccioline).
La soluzione? Senza levare nulla al lavoro svolto dal gruppo Developers Italia e dal gruppo Designer Italia, c’è ancora molto da fare nel mettere a disposizione di tutte le PA strumentazione di facile utilizzo.
Mettere software a riuso sviluppato senza la logica del riuso, è praticamente inutile. Anzi dannoso, perché l’amministrazione deve comunque valutarlo prima di procedere all’acquisto (come se la valutazione non costasse nulla. E più il software è complesso, più la valutazione costa).
Un esempio: basta provare a cercare nel catalogo del riuso i programmi per la gestione del protocollo informatico, a leggere la documentazione, a provare a installarli. Altro che logica KISS! Ma è chiaro che le società esterne che hanno sviluppato quei prodotti hanno tutto l’interesse a proporre soluzioni complesse, perché poi è necessario rivolgersi a loro.
Eppure, il sistema di gestione informatica dei documenti è obbligatoria per tutte le PA. E allora, perché i gruppi di cui sopra non sviluppano un prodotto in riuso sviluppato secondo la logica KISS (vallo a far capire anche ai Developers), con una architettura a micro-servizi e un’attenzione all’esperienza utente? Boh. Forse è più facile continuare a scrivere normative tecniche particolarmente complesse, imporre obblighi (a volte inutili) e prevedere sanzioni. Tanto, mal che va, la colpa è del burocrate di turno.
Con buona pace dell’efficienza della Pubblica Amministrazione, e dei relativi costi.
Grazie Enrico per il tuo interessante e prezioso contributo. Condivido quanto hai scritto e, in merito ai numeri del personale ICT nelle PA, l’esempio che hai portato è probabilmente uno dei più “virtuosi”, poiché sono a conoscenza di svariate PA che, al loro interno, non hanno nessun tecnico ICT. Al massimo, qualcuno che ci mette (tanta) buona volontà…