Sviluppo software nella PA, ecco gli approcci

L’evoluzione agile all’interno della PA

Scovare dei requisiti è una procedura alquanto dispendiosa sia in termini di tempistica, sia per quanto riguarda l’utilizzo di risorse. In questo dialogo tra committente ed analista l’esperienza è fondamentale, insieme alle tecniche^[1] sviluppate in decenni di analisi dei requisiti, tecniche che aiutano l’analista a svolgere la propria attività maieutica, a guidare il chiarimento dei requisiti in modo rapido ed efficiente, perché il tempo e le risorse che abbiamo a disposizione per chiarire i requisiti sono sempre più limitati. Nonostante le tecniche basate sul dialogo, sulla formulazione di domande, sull’analisi delle risposte (feedback), sul fare emergere velocemente punti di attenzione e sull’aumento progressivo del livello di precisione e di chiarezza dei requisiti, la presenza di sistemi sempre più dinamici, con esigenze mutevoli, ha visto come risposta al problema l’adozione di approcci agili^[2].

Il focus di questi approcci è la centralità dell’utente, il riconoscimento di valore per la prototipazione continua, entrambi guidati dal principio secondo cui il software evolve nel dialogo con gli stakeholder. Questo significa costruire soluzioni partendo da user stories^[3], mock-up^[4], wireframe^[5], fino a prototipi^[6] funzionanti, capaci di stimolare il confronto e far emergere in modo maieutico i veri bisogni dell’utente. I tool di design collaborativo come Figma^[7] e Balsamiq^[8] giocano un ruolo chiave in questa fase, consentendo la creazione rapida di interfacce, con l’obiettivo di facilitare la visualizzazione delle idee e la pianificazione del design prima dello sviluppo effettivo.

Affinché questa tipologia di approcci funzioni, ha bisogno di co-progettazione. Serve un rapporto basato sulla fiducia, su obiettivi condivisi, in cui il committente viene “portato” nel team di lavoro del fornitore. Il coinvolgimento del committente assume un ruolo molteplice, aiutando a sviluppare storie che corrispondono ai requisiti, definendo le caratteristiche da includere in ogni release, nonché allo sviluppo dei test di accettazione per controllare che il sistema soddisfi i suoi requisiti. Se tale ruolo in ambito privato è sempre più diffuso, nella PA le logiche formali degli appalti ostacolano fortemente ogni possibilità di co-progettazione. Una barriera che rischia di rallentare la trasformazione digitale in atto nel settore pubblico.

Committente e fornitore: un antagonismo positivo

Il rapporto tra PA e fornitori è regolato da gare pubbliche, affidamenti formalizzati, milestones contrattuali e, molto spesso, un’idea ancora rigida di prodotto finito. In tale contesto, l’accordo quadro^[9] rappresenta uno strumento utile per le pubbliche amministrazioni che vogliono gestire appalti in modo rapido e conveniente, in quanto permette di gestire le esigenze in modo flessibile, affidando all’impresa solo gli interventi effettivamente necessari, quando necessario. Nonostante la possibilità  per le amministrazioni di disporre di uno strumento contrattuale da personalizzare in base alla strategia da perseguire, nella prassi si tende ancora a cristallizzare lo sviluppo in fasi e deliverable eccessivamente rigidi, dove ogni avanzamento progettuale viene subordinato a un collaudo formale, che ne condiziona la liquidazione economica. Qui si inserisce un meccanismo che potremmo definire di antagonismo positivo, in cuiil fornitore è orientato al raggiungimento degli obiettivi progettuali, ma al contempo deve tutelarsi, consapevole che il riconoscimento economico è vincolato all’approvazione formale del rilascio.

Dal lato opposto, il committente pubblico non può sostenere costi per attività che non siano pienamente tangibili, concluse e certificate. A mediare tra queste due posizioni, si colloca la necessità, sempre più avvertita, di promuovere processi di innovazione sostanziale, in coerenza con i principi alla base della digital transformation della PA. Il risultato di questa dinamica è una distorsione dell’approccio agile, il quale finisce per essere applicato in maniera solo apparente. Le iterazioni, anziché essere momenti di confronto e revisione, si trasformano in fasi di consegna formalizzata, anche laddove si tratti in realtà di prototipi. I Minimum Viable Product (MVP), nati per esplorare rapidamente le esigenze reali degli utenti e consentire correzioni in corso d’opera, perdono così la loro natura sperimentale e diventano versioni preliminari da sottoporre a collaudo. La pubblica amministrazione, pur consapevole della difficoltà di definire integralmente i requisiti sin dalle fasi iniziali, è spesso costretta a operare come se ciò fosse possibile, generando una discrepanza tra la metodologia dichiarata e le pratiche effettivamente adottate.

La prototipazione come servizio: un nuovo modello possibile

A fronte delle trasformazioni metodologiche introdotte dalle pratiche agili, occorre riflettere su come tali approcci possano essere integrati nei processi di procurement pubblico. Un’integrazione effettiva, tuttavia, presuppone il riconoscimento del valore delle attività  di comprensione dei requisiti come parte integrante del ciclo di vita del software, non come una fase propedeutica e separata. In questo senso, potrebbe risultare utile interrogarsi su come valorizzare, anche a livello contrattuale, quelle  fasi intermedie di co-creazione (es., design sprint, test di usabilità, sviluppo iterativo di prototipi, cicli di revisione condivisa).

Tali momenti, soprattutto negli approcci agili, rappresentano passaggi fondamentali per la corretta definizione dei requisiti, e ancora di più in contesti caratterizzati da un’elevata complessità organizzativa o tecnologica. Ciò comporta, in prospettiva, la possibilità di evolvere rispetto a un modello di affidamento centrato esclusivamente sulla logica dei rilasci a collaudo, per considerare invece formule più orientate al servizio, al processo e alla alla coerenza con gli obiettivi di trasformazione digitale del sistema pubblico.

Nel panorama della digitalizzazione pubblica, si osserva una crescente consapevolezza circa la necessità di adottare modelli operativi capaci di coniugare rigore procedurale e flessibilità progettuale. In particolare, nei contesti in cui i requisiti non possono essere pienamente definiti a priori, per complessità organizzativa, numero di stakeholder coinvolti o grado di innovazione richiesto, risulta strategico introdurre modalità che valorizzino le fasi esplorative e iterative del progetto. In mancanza di un adeguato riconoscimento contrattuale, però, queste fasi rischiano di non essere né formalizzate né remunerate, compromettendo la qualità del risultato e disincentivando l’adozione di approcci innovativi. Questo tipo di assetto si rivela particolarmente utile nei contesti in cui è richiesto un elevato livello di adattabilità e una capacità di risposta rapida alle esigenze che emergono nel corso dei lavori.

I prossimi passi per lo sviluppo software nella PA

Il tema diventa più urgente se pensiamo all’integrazione delle tecnologie emergenti, a partire dall’intelligenza artificiale, dove è difficile specificare ex ante che cosa un sistema basato su AI farà, o dovrebbe fare. In linea con le evoluzioni normative europee in materia di AI (ad esempio, l’AI Act e le relative sandbox normative), l’esplorazione di soluzioni che considerino la possibilità di istituire anche a livello contrattuale spazi di sperimentazione regolata, potrebbero costituire ambienti giuridicamente protetti in cui testare soluzioni innovative, validare ipotesi progettuali e affinare progressivamente i requisiti, senza compromettere i principi di trasparenza, rendicontabilità e tutela dell’interesse pubblico. Innovare, in ambito pubblico, significa anche assumersi la responsabilità di gestire l’incertezza in modo strutturato. Creare le condizioni affinché tale incertezza sia governabile, documentabile e finalizzata a risultati di maggiore qualità costituisce una delle sfide centrali dei prossimi anni.

Note

^[1] Tecniche come i workshop sui requisiti, l’analisi degli scenari di operatività utente (casi d’uso), la quantificazione dei livelli di servizio sugli aspetti non funzionali (prestazioni, carichi, sicurezza), la valutazione di prototipi delle interfacce utente.

^[2] cf. la letteratura di riferimento, a partire da Cohn, Mike (2004). User Stories Applied: For Agile Software Development. Addison-Wesley. ISBN 0321205685 e successive evoluzioni.

^[3] User story:è una descrizione concisa di una funzionalità o una caratteristica del sistema, espressa dal punto di vista dell’utente finale. Le user story sono utilizzate in metodi di sviluppo agile, come Scrum, per comunicare i requisiti in modo semplice e focalizzato sui bisogni degli utenti.

Le user stories sono presentate seguendo il seguente formato:
“Come <tipo di utente>, voglio <obiettivo> in modo che io possa <risultato atteso/beneficio>.”
Esempio: Come utente, voglio scaricare i dati in modalità batch in un file Excel, in modo che io possa analizzarli e condividerli facilmente.

^[4] cf. Armando Fox, David Patterson. Engineering Software as a Service: An Agile Approach Using Cloud Computing. ISBN 978-0984881246.

^[5] Wireframe è uno schema a blocchi che delinea l’ossatura e l’idea di un progetto.

^[6] Il prototipo è il modello finale, che include anche la parte interattiva, ovvero la simulazione dell’interazione tra l’utente ed il sistema.

^[7] Figma è un’applicazione web collaborativa per il design di interfacce, con funzionalità aggiuntive offline tramite applicazioni desktop per macOS e Windows.

^[8] Balsamiq Wireframes è uno strumento per la creazione di wireframe, utilizzato principalmente da sviluppatori, designer e progettisti per prototipare interfacce utente e schermate di siti web e applicazioni.

^[9] L’accordo quadro è disciplinato all’articolo 59 del decreto legislativo 36/2023 (Nuovo Codice Appalti) dove viene definito “accordo concluso tra una o più stazioni appaltanti e uno o più operatori economici, il cui scopo è quello di stabilire le clausole relative agli appalti da aggiudicare durante un dato periodo, in particolare per quanto riguarda i prezzi e, se del caso, le quantità previste”.