Costruire software per la PA italiana nel 2026: vincoli, opportunità e quello che abbiamo imparato

Il software per la pubblica amministrazione italiana ha una pessima reputazione tra gli sviluppatori. Interfacce degli anni novanta, processi kafkiani, cicli di approvazione che durano più di una legislatura. Ogni sviluppatore ha almeno una storia da raccontare a cena su un appalto pubblico andato storto.

Noi pensiamo che sia un'occasione.

Non perché siamo ottimisti per temperamento. Ma perché quando tutti scappano da un settore, chi ci rimane ha meno concorrenza e più spazio per fare le cose come si deve.

Il mercato che nessuno vuole fare (e perché ci siamo dentro)

La percezione dominante è questa: il software pubblico è un cimitero di buone intenzioni. Gare vinte al ribasso, capitolati tecnici scritti male, committenti che non sanno cosa vogliono, collaudi infiniti. Il risultato, spesso, è software che nessuno usa davvero.

Questa percezione è fondata. Non la stiamo smentendo.

Quello che la percezione non cattura è la domanda reale che c'è sotto. I comuni italiani gestiscono infrastrutture fisiche — strade, ponti, edifici scolastici — con strumenti che non hanno mai smesso di essere fogli Excel. Gli enti di protezione civile raccolgono dati su frane e alluvioni che raramente diventano informazione utile in tempo reale. Le città metropolitane spendono budget significativi su manutenzione preventiva senza poter misurare se stanno anticipando i guasti o semplicemente spostando la spesa in avanti.

Questi non sono problemi di digitalizzazione. Sono problemi di decisione. La tecnologia è il mezzo, non il fine.

Abbiamo scelto questo settore perché i problemi sono reali, le conseguenze sono concrete (una strada non manutenuta uccide, non solo costa), e la qualità media delle soluzioni esistenti è così bassa che alzarla non richiede genialità. Richiede rigore.

Cosa significa davvero "fare digitale" in un comune italiano

I veri ostacoli non sono tecnici

La prima cosa che abbiamo imparato lavorando con le PA locali è che il problema raramente è tecnologico. Il problema è umano e organizzativo.

Un comune di ventimila abitanti ha un ufficio tecnico con tre o quattro persone. Queste persone gestiscono pratiche edilizie, manutenzione stradale, sicurezza idrogeologica e altri dieci dossier in parallelo. Non hanno tempo per imparare un nuovo software, non hanno budget per formazione continuativa, e non hanno nessuna garanzia che il sistema che adottano oggi sarà ancora supportato tra tre anni.

Abbiamo perso settimane, in fase di analisi, a costruire funzionalità che sembravano ovvie su carta e che nessuno avrebbe mai usato in produzione. Non per mancanza di buona volontà. Per mancanza di tempo. Un tecnico comunale non apre il software a colazione per esplorare nuove funzionalità. Lo apre quando ha un problema urgente da risolvere e vuole risolverlo in tre minuti.

Questo ha cambiato il modo in cui progettiamo tutto.

Quando i dati esistono ma non vengono usati

C'è un paradosso che abbiamo incontrato più volte: la PA italiana ha più dati di quanti pensi. Sopralluoghi fotografati su smartphone, ispezioni registrate su moduli cartacei poi scannerizzati, segnalazioni dei cittadini archiviate in cartelle di posta elettronica.

Il problema non è la mancanza di dati. È che i dati non parlano tra loro, non sono strutturati, e soprattutto non producono informazione azionabile. Un dirigente non può aprire un file Excel con duemila righe e capire in trenta secondi dove concentrare il budget di manutenzione del prossimo trimestre.

La risposta che diamo non è "più dati". È "meno rumore". Prendere quello che già esiste, strutturarlo, e restituirlo in una forma che aiuta chi decide a decidere meglio. Non a decidere di più.

La cultura del "ho sempre fatto così"

Questo è il più sottovalutato degli ostacoli.

Non si tratta di resistenza al cambiamento come concetto astratto. Si tratta di un calcolo razionale che chi lavora in PA fa ogni giorno: il rischio di adottare qualcosa di nuovo è mio (se va male, rispondo io), il beneficio è dell'organizzazione. In assenza di incentivi chiari, la scelta conservativa è quella sicura.

Noi non pensiamo che il problema siano le persone. Il problema è il sistema di incentivi. Il nostro compito, quando lavoriamo con un cliente, è ridurre il rischio percepito al punto in cui provare qualcosa di nuovo diventa la scelta razionale. Non la scelta coraggiosa.

Come lavoriamo: tre principi non negoziabili

Dati misurabili o non parliamo

Non accettiamo obiettivi del tipo "migliorare l'efficienza operativa" se non riusciamo a definire insieme una metrica concreta. Quanti sopralluoghi al mese? Quanto tempo passa tra la segnalazione di un problema e la sua presa in carico? Qual è il costo medio per chilometro di manutenzione stradale?

Se non riusciamo a misurare il punto di partenza, non abbiamo modo di sapere se il software sta aiutando o se sta solo aggiungendo un passaggio in più al processo esistente. E aggiungere passaggi in più è esattamente quello che vogliamo evitare.

Questo ci ha messo in difficoltà con qualche committente che preferiva obiettivi vaghi. Lo accettiamo come costo.

Semplicità operativa come requisito, non opzione

Il software pubblico funziona meglio quando non si nota.

Quando un tecnico apre un'applicazione e trova esattamente quello di cui ha bisogno, senza dover navigare menu profondi o ricordare configurazioni, quello è il risultato giusto. Non è semplice da costruire. Richiede molte iterazioni, molti colloqui con chi usa il sistema davvero, e la disponibilità a togliere funzionalità invece di aggiungerle.

La complessità è un costo. Spesso lo paga chi non l'ha decisa.

Un dirigente decide che il sistema deve avere quaranta viste personalizzabili. Il tecnico che lo usa tutti i giorni impara a ignorarle tutte tranne due. Le trentotto viste inutilizzate costano tempo di sviluppo, costano manutenzione, costano confusione. Questo è il ciclo che cerchiamo di interrompere.

Tempo dell'utente come bene scarso

Ogni interazione che richiede più di trenta secondi senza restituire un valore chiaro è un'interazione che stiamo rubando a qualcuno che ha un ufficio tecnico da gestire.

Questo suona ovvio. In pratica lo violano quasi tutti.

Moduli con venti campi obbligatori quando sette sarebbero sufficienti. Report che richiedono un'esportazione in Excel per essere leggibili. Flussi di approvazione a cinque passaggi per operazioni di routine. Ogni singola di queste scelte ha una giustificazione tecnica o normativa. Messe insieme, producono software che le persone evitano ogni volta che possono.

Cosa NON facciamo

Questa sezione è quella che scriviamo per noi, non per impressionare nessuno.

Non usiamo la parola "innovazione" come argomento di vendita. L'innovazione è un risultato, non una promessa. Se quello che costruiamo aiuta un comune a ridurre i costi di manutenzione o a prevenire un cedimento infrastrutturale, l'innovazione c'è stata. Se non succede, la parola era solo marketing.

Non costruiamo sistemi configurabili a sessanta parametri. Ogni parametro in più è una decisione che trasferiamo all'utente. A volte è giusto. Spesso è una forma di pigrizia progettuale: invece di capire cosa serve davvero, mettiamo tutto e lasciamo che sia l'utente a scegliere. Il risultato è che l'utente non sceglie, usa i default, e i default raramente sono ottimali per il suo contesto.

Non costruiamo dashboard piene di metriche che nessuno guarda. Abbiamo imparato a chiedere, prima di aggiungere qualsiasi visualizzazione: questa informazione cambia una decisione? Se la risposta è no, o se non riusciamo a rispondere, quel grafico non entra nel prodotto. Un quadrante vuoto è meglio di un quadrante pieno di numeri che non producono azione.

Dove siamo adesso

Abbiamo due prodotti in produzione.

ROADS (Risk-Oriented Asset Decay Surveillance) è un sistema di sorveglianza per la manutenzione delle infrastrutture stradali, pensato per le amministrazioni comunali italiane. Aggrega dati di ispezione, li struttura in base a criteri di rischio, e aiuta i responsabili tecnici a prioritizzare gli interventi. Non sostituisce il giudizio tecnico. Lo supporta con dati organizzati.

Grumbo è un sistema per la valutazione del rischio idrogeologico — frane, alluvioni, instabilità dei versanti — che integra dati satellitari e di campo per produrre stime di rischio a scala territoriale. Il target sono gli enti di protezione civile, le amministrazioni regionali e le compagnie assicurative che devono ragionare su questo tipo di rischio.

Entrambi sono strumenti operativi, non dimostratori. Li usiamo come banco di prova dei principi che abbiamo descritto sopra. Quando sbagliamo — e lo facciamo — lo vediamo prima perché i clienti li usano davvero.

Sul lavoro quotidiano: siamo un team piccolo, il che significa che ogni persona che entra porta peso reale e ha impatto reale. Non c'è uno strato di management che filtra il feedback degli utenti dalla squadra tecnica. Quando un tecnico comunale ci dice che una funzionalità non funziona come si aspettava, quella conversazione arriva direttamente a chi l'ha costruita. Preferiamo tenerla così.

Se questo modo di lavorare ti suona familiare — se hai un problema reale, dati che esistono ma non parlano, e la sensazione che le soluzioni sul mercato siano troppo generiche o troppo costose per quello che offrono — scrivici. Non cerchiamo clienti per cui fare una demo. Cerchiamo collaborazioni con chi ha voglia di affrontare i problemi con rigore, misurare i risultati e ammettere quando qualcosa non funziona.

Ci trovi su ignicraft.com/contatti.