Come digitalizzare la Pubblica Amministrazione. Una storia di punti e di funzioni

di Corrado Truffi.

Ovvero, per digitalizzare la Pubblica Amministrazione serve una nuova relazione con i fornitori di servizi software

In un articolo di qualche tempo fa su Agenda Digitale.it, Alfonso Fuggetta metteva il dito sulla piaga di un problema che affligge l’informatica pubblica italiana: l’inadeguatezza dei meccanismi del procurement pubblico, con un codice degli appalti ancora troppo pensato per lavori e forniture e poco per servizi e – a maggior ragione – per servizi di natura molto particolare come quelli digitali:

Se il digitale e l’innovazione sono temi veramente importanti, come è possibile che il procurement pubblico sia gestito secondo regole che vanno (forse) bene per ponti e strade, con procedimenti che trattano i servizi e progetti digitali alla stregua di commodity e con prezzi schiacciati in modo irresponsabile verso il basso?

Sappiamo bene che il problema dell’efficacia e dell’efficienza della PA nell’approvvigionarsi di lavori, beni e servizi non è limitato al digitale (si veda in proposito quanto ha scritto Estella Marino qui su iMille). Tuttavia, nel caso dei servizi informatici, ad un generico problema di lentezza nella fornitura, se ne aggiunge uno di tipo vorrei dire strutturale, che attiene alla difficoltà intrinseca di misurare – e quindi dare un valore economico – il prodotto realizzato.

****

Nella passata edizione del ForumPA, ho ascoltato un’interessante e divertente intervista di Luca Attias a Diego Piacentini, durante la quale il commissario del Team per la trasformazione digitale ha ribadito il suo stupore – e la sua contrarietà – rispetto all’ossessione della Pubblica Amministrazione italiana per i punti funzione (Function Point). Ed è di pochi giorni fa un nuovo intervento di Piacentini su Medium, peraltro interessantissimo per molte altre ragioni, nel quale ritorna en passant sull’inutilità di quella misura. Piacentini ha molte ragioni, poiché ingabbiare uno sviluppo software in ambito gestionale, che è un processo assieme tecnologico, organizzativo e sociale, entro una metrica rigida e con molte falle, è uno dei motivi che rende inefficiente, conflittuale e troppo costoso il rapporto cliente/fornitore per la PA.

Breve spiegazione nel merito per chi non è esperto del ramo (chi è del mestiere può saltare il capoverso): i Punti Funzione sono una misura della dimensione del software, pensata molti anni fa avendo in mente i linguaggi procedurali tradizionali (Cobol e simili) e soprattutto un processo di sviluppo del software di tipo deterministico, da svilupparsi a cascata: (1) si raccolgono i requisiti del software, li si formalizza, il committente approva il documento, (2) si scrivono le specifiche dettagliate, (3) si scrive il codice software, (4) si fanno i test, (5) si mette in produzione il software. Per misurare i Punti Funzione correttamente, bisogna conoscere bene tutte le funzioni da sviluppare e i dati da gestire, ossia bisogna essere arrivati almeno alla fase (2) di cui sopra o, adottando qualche semplificazione, a una situazione intermedia fra fase (1) e fase (2). Questo era – teoricamente – del tutto possibile nel mondo informatico del passato, con tecnologie uniformi e relativamente semplici, e soprattutto adottando rigorosamente un processo a cascata. La realtà dell’informatica odierna, tuttavia, è radicalmente diversa per due motivi fra loro interrelati e che si alimentano a vicenda: dal lato tecnologico, le applicazioni software non sono più fatte semplicemente di codice compilato, ma sono “composizioni” scritte utilizzando diversi linguaggi, richiamando servizi esterni, correlandosi con altre applicazioni, integrandosi con servizi cloud, ecc. Dal lato organizzativo e sociale, si è capito che gran parte del software che digitalizza processi umani ed organizzativi (a parte quindi forse i componenti embedded, i firmware e il software di automazione industriale) non può essere progettato efficacemente “a cascata”, perché i requisiti degli utenti (a) non sono così chiari all’inizio del processo (b) quasi sempre cambiano durante il processo, vuoi perché appunto l’analisi ne svela aspetti inizialmente inespressi, vuoi perché si modificano le condizioni a contorno – modifiche normative, scelte politiche diverse, ecc. Per rispondere a questa instabilità dei requisiti, che rende il software un oggetto che deve essere progettato in modo radicalmente diverso da quello che si può utilizzare, ad esempio, per progettare un ponte, sono state studiate diverse metodologie di sviluppo di tipo iterativo e incrementale, che assumono al loro interno il rischio del cambiamento continuo. Attualmente, la metodologia più consolidata è quella dello sviluppo Agile, con varie declinazioni e con propaggini anche nella gestione dell’esercizio dei sistemi (DevOps). L’essenziale delle metodologie Agile è comunque l’iterazione e la costruzione per prototipi, in un contesto di progetto nel quale il costo e i tempi sono fissati (si stabilisce un budget iniziale e si definisce la durata fissa delle varie iterazioni), mentre l’obiettivo (scope) di progetto è definito solo a grandi linee, poiché esso è definibile solo attraverso una progressiva “scoperta”.

Si tratta, in molti sensi, di un processo sociale, realizzato attraverso una continua interazione e collaborazione fra utente e fornitore, dove il patto implicitamente sottoscritto fra gli attori è quello di arrivare fin dove è possibile con le risorse (tempi e costi) assegnate inizialmente. È chiaro che un simile approccio è l’esatto contrario della progettazione tradizionale, di derivazione ingegneristica, dove lo scopo è (o dovrebbe essere) totalmente definito (progettazione esecutiva), e gli eventuali incidenti di realizzazione modificano costi e/o tempi.

Quindi, misurare preventivamente la dimensione di uno sviluppo software in termini di Punti Funzione (associando poi ad essi una produttività e un costo fisso) significa negare la possibilità di adottare pienamente una metodologia di sviluppo Agile, poiché la stima iniziale è per definizione “errata”. La cosa divertente – o deprimente, fate voi – è che la gran parte degli appalti pubblici degli ultimi anni richiedono più o meno esplicitamente l’adozione di metodologie Agile (è la moda…) e, nel contempo, presuppongono la stima e la remunerazione del software attraverso i Punti Funzione.

Nel mio lavoro di redazione di offerte tecniche, ho sviluppato una vasta serie di “bugie” metodologiche per dimostrare l’indimostrabile e rendere compatibili Punti Funzione e metodi Agili, ma sapendo benissimo che si tratta di palliativi o, nella migliore delle ipotesi, di soluzioni utili a garantire un minimo di decenza nel rapporto contrattuale fra cliente e fornitore. Ritengo però che sarebbe il momento di cambiare radicalmente approccio – anche approfittando del ruolo che il Team per la trasformazione digitale ha in questo momento (e speriamo ancora a lungo) nell’indirizzare l’informatica pubblica. Purtroppo devo dire che, a dispetto delle dichiarazioni di Piacentini, proprio recentemente la “vecchia politica” dell’informatica pubblica si è presa una bella rivincita licenziando, proprio nel nuovo sito di documentazione delle norme della PA digitale voluto da Piacentini, un aggiornamento delle linee guida sulla misurazione del software che ribadisce la prevalenza dei function point, pretendendo addirittura di dimostrare che essi sono una buona metrica anche nel caso di sviluppi di tip Agile [1].

Ma andiamo con ordine, e approfondiamo.

Chiariamo subito che il problema a causa del quale le Amministrazioni pubbliche tendono a continuare ad utilizzare “a tutti i costi” i Punti funzione è reale: se affido un appalto, devo essere sicuro che quello che ho chiesto venga consegnato, e che il prezzo pagato sia quello giusto. È molto difficile invece, per un funzionario pubblico, accettare un’idea come quella Agile, che dice in sostanza “iniziamo, e vediamo dove arriviamo con le risorse e il tempo disponibili”, perché in questo modo è difficile difendersi da un fornitore che ti dicesse che con quelle risorse si può arrivare solo a metà di quello che tu avevi in testa, non perché sia impossibile, ma perché vuole lucrare sulla sua posizione e lavorare di meno e guadagnare di più.

Sottolineo anche che il “danno” provocato dall’utilizzo dei punti funzione come metrica in associazione con l’uso di un approccio Agile è fondamentalmente nel fatto che in pratica in queste condizioni non si fa un vero sviluppo Agile, ma una sua caricatura e, quindi, se ne riducono i vantaggi. Tale situazione è particolarmente grave se si prende sul serio l’obiettivo di innovare realmente le soluzioni digitali offerte dalla pubblica amministrazione ai cittadini, che per essere efficaci dovrebbero essere progettate secondo criteri di design altamente collaborativo e niente affatto deterministico – esattamente quello che propugna in tutte le sedi il Team per la trasformazione digitale.

In realtà, anche chi ha sviluppato i metodi Agile si è ovviamente posto il problema della stima del software, sia sviluppando tecniche di stima “interna” da parte dei singoli team di sviluppo, sia individuando metriche empiriche come gli story point, il cui valore tuttavia è di norma definito in modo indipendente in ciascun progetto (in pratica, il team individua una misura campione – una specie di “metro” – valido però solo per quel singolo progetto). Probabilmente per questo motivo, chi vorrebbe una stima “oggettiva” della dimensione di un software non prende in considerazione tali tecniche, sebbene esse siano ben consolidate e dispongano anche di varianti in grado di definire misure “normalizzate”[2].

Tuttavia, il problema è, come sopra accennato, più a monte. Anche ci si decidesse di utilizzare gli story point o qualcosa di simile al posto dei function point, resterebbe il problema della stima “iniziale” del software, ossia in pratica della determinazione del prezzo di un dato sviluppo software prima che esso sia stato realizzato. Allo stato attuale, le pubbliche amministrazioni risolvono tale questione essenzialmente in due modi, il primo dei quali nettamente prevalente:

• Approvvigionarsi di servizi software attraverso contratti quadro nei quali viene stimata una quantità massima di Function Point e/o di giorni/persona da erogare, su richiesta, adottando un dato livello di produttività del lavoro (FP per giorno). Il fornitore offre un prezzo unitario per Function Point (o per giorno/persona, sempre convertibili in FP secondo la produttività data), e il problema della stima effettiva del costo di un dato oggetto software è spostato sul singolo intervento che viene richiesto nell’ambito del contratto, nel quale si dovrà trovare il modo di accordarsi su un numero sensato di FP e/o di giorni/persona, trovandosi per l’ennesima volta nella impossibilità di prendere sul serio i metodi Agile.
• Richiedendo interventi specifici “chiavi in mano”, nei quali i requisiti siano sufficientemente definiti fin dalla richiesta. Questo metodo, potenzialmente, potrebbe essere il migliore per un approccio Agile, visto che il risultato sarebbe di fatto la definizione di un budget e un tempo fisso, con uno scope di progetto ben definito ma, nei fatti trattabile.

Soprattutto nel primo caso, la determinazione del prezzo unitario per FP genera spesso una competizione al ribasso fra le aziende, solo parzialmente limitata dall’attuale obbligo di formulare appalti nei quali il prezzo può valere al massimo il 30% all’interno della valutazione complessiva di un’offerta. Tale competizione, a sua volta, genera a cascata una serie di effetti che potremmo chiamare “effetto ipocrisia” (o, se volete, conflitto di interessi). La sequenza potrebbe essere descritta così: 1) l’amministrazione stabilisce un valore dell’appalto abbastanza alto (un prezzo per FP sufficientemente remunerativo, a volte perfino troppo) 2) le aziende, in competizione fra loro, esprimono prezzi per FP perfino troppo bassi, non remunerativi. In genere, almeno una delle aziende fa vero e proprio dumping (apparente, come vedremo fra poco) e a volte è proprio tale azienda a vincere. Negli ultimi grandi appalti pubblici Consip non sono stati rari sconti attorno o anche superiori al 50% e, in ogni caso, lo sconto proposto è difficilmente inferiore al 30% mentre ad esempio nei lavori pubblici, dove pure la crisi ha fatto aumentare il livello di sconti, la media si aggira sul 25%. 3) aggiudicare con uno sconto così elevato fa fare una (apparente) bella figura al buyer della Pubblica Amministrazione – anche se a mio giudizio un’aggiudicazione con sconti simili significa che hai sbagliato le stime, non che hai fatto risparmiare la tua amministrazione 4) poi, in fase di erogazione, il trucco è semplice: dato che la misura in FP resta pur sempre opinabile, e tanto più opinabile se pretendi di combinarla con metodi e tecnologie difficilmente compatibili, ti accordi tacitamente per accettare stime “abbondanti”, di modo che il prezzo per FP formale – troppo basso – diventi economicamente sostenibile.

Naturalmente, questo modo di gestire gli appalti non è la regola ed esistono sia amministrazioni attente che fornitori seri, tuttavia le situazioni nelle quali la cattiva moneta scaccia quella buona non sono rare, e bisognerebbe trovare il modo di porvi rimedio.

Torniamo allora al punto di partenza. Con cosa possiamo sostituire o almeno completare i Function Point? O, più in generale, come possiamo trovare un modo più sensato di misurare la produttività dei servizi software anche adottando metodi di lavoro più adeguati al tempo della trasformazione digitale?

Mi permetto di proporre due o tre tracce.

Primo. Appalti un po’ più piccoli, orientati alla trasformazione digitale, con uno scope univoco e ben definito (la seconda strategia sopra richiamata, usata troppo raramente dalle amministrazioni). Per riuscirci, le amministrazioni devono avere all’interno qualcuno che conosca bene i processi di business e anche l’informatica, non devono affidarsi completamente ai fornitori. E’ una delle cose sulle quali Piacentini in questi anni ha più insistito, credo non a caso. In questa ipotesi, l’amministrazione potrebbe essere in grado di controllare l’operato del fornitore, accettando anche revisioni ragionevoli del prodotto, senza il timore di restare in balia del potere e degli esclusivi interessi del fornitore stesso.

Secondo. Nel caso di appalti più omnicomprensivi, di gestione ed evoluzione dei sistemi, spesso comunque inevitabili e necessari, la stima di ciascun intervento dovrebbe adottare un criterio adeguato ai metodi Agile, pur consentendo all’amministrazione una verifica ex post di produttività, Ci sono diversi modi per farlo. Ad esempio:

• budget e tempi di un certo intervento sono direttamente definiti dall’amministrazione: si torna al primo caso di cui sopra: in pratica, ogni singolo intervento diventa un “chiavi in mano”.
• Budget e tempi sono contrattati inizialmente fra cliente e fornitore, e fissati, una volta definito in modo sufficiente lo scope. Dato che c’è un’inevitabile livello di parziale indeterminatezza nello scope (è il succo della tecnica Agile), cliente e fornitore si assicurano reciprocamente circa la congruità del risultato individuando un meccanismo per valutare ex-post la dimensione del prodotto realizzato, definendo un range di accettazione (ad es. + o – 15% rispetto a una dimensione ipotizzata inizialmente).

In questa ipotesi, e solo in questa ipotesi, una misura come i FP potrebbe tornare utile, tenuto conto che esistono applicazioni che consentono di calcolarli in modo automatico a partire dal software realizzato [3],  anche se in realtà qualunque altro tipo di “metro” potrebbe essere adeguato. Il calcolo degli Automated Function Point ha ovviamente i suoi limiti, primo tra tutti quello di non considerare la complessità non funzionale di un’applicazione. Tuttavia, agli scopi di fornire un parametro ragionevole di confronto statistico, è probabilmente migliore e sicuramente più oggettivo delle stime manuali che si pretende di fare nelle fasi iniziali di uno sviluppo. Infatti, il processo potrebbe funzionare in questo modo:

• si concorda solo un livello di produttività obiettivo degli sviluppi del software (FP per giorno/persona + o – 15%);
• Si definisce budget e tempo di intervento;
• Al termine dello sviluppo (esauriti budget e tempo assegnati), si effettua il calcolo automatico;
• Se la produttività è risultata coerente con l’ipotesi, non ci sono problemi. In caso contrario, si dovrà analizzare in dettaglio i motivi ed, eventualmente, il fornitore dovrà essere soggetto a penali.

La differenza fra un simile processo e la situazione attuale, apparentemente piccola, è in realtà sostanziale. L’accordo cliente/fornitore è esplicito in due momenti cruciali, ma non basato su stime impossibili né sull’ipocrisia. Infatti, la stima della dimensione del software (il primo momento cruciale) è esplicitamente provvisoria e si traduce soprattutto nella definizione di un budget e di un tempo di realizzazione fissi mentre si accetta che il risultato abbia una certa variabilità. Ciò rende possibile concentrarsi proprio su tale risultato, in quanto il team di sviluppo può utilizzare in pieno la metodologia Agile e, inoltre, ha tutto l’interesse a realizzare un buon prodotto nei tempi assegnati, in quanto comunque vincolato, sia pur in modo flessibile, ad una certa produttività. Il secondo momento cruciale, infatti, è una misura ex-post, che ha il vantaggio di una maggiore oggettività e anche di essere meno onerosa rispetto a complesse elaborazioni ex-ante.

Naturalmente, anche in questo caso resta il problema del dumping sul prezzo da assegnare all’unità di prodotto. Ma si tratta di un problema che dovrebbe essere risolto in altro modo, a prescindere da qualunque altra considerazione: in primo luogo adottando formule di calcolo del punteggio economico basate su funzioni che rendano via via meno convenienti sconti elevati e, in secondo luogo e soprattutto, definendo basi d’asta meglio stimate.

Insomma, fossi un responsabile dei sistemi informativi di una pubblica amministrazione, mi attrezzerei prima di tutto per fare ogni volta che sia possibile appalti singoli per lo sviluppo di nuove soluzioni, limitando i contratti omnicomprensivi soprattutto alla gestione corrente dei sistemi, al supporto utente e alla manutenzione correttiva. Inoltre, farei in modo di internalizzare almeno un po’ di competenza tecnologica, quella sufficiente a capire se il fornitore sta tentando di approfittare del suo potere. Infine, metterei a punto meccanismi di stima e valutazione delle dimensioni del software come quelle che ho sopra tratteggiato.

****

Il lettore lontano dai misteri dei servizi informatici per la pubblica amministrazione probabilmente avrà trovato un po’ astrusi e forse sofistici questi ragionamenti. Eppure sono convinto che la trasformazione digitale della PA, per essere reale, ha anche bisogno di trovare il modo di definire un rapporto fra cliente pubblico e fornitore privato che funzioni meglio, in modo più trasparente e conveniente per entrambi gli attori. Troppa ipocrisia e troppe assurdità in questa relazione generano sprechi, scaricano sul pubblico eccessi di costi, e – paradossalmente – limitano anche la capacità del privato di aumentare la propria produttività, poiché la tentazione di lavorare in una logica “estrattiva” di risorse pubbliche senza preoccuparsi più di tanto dell’efficienza è, nella situazione attuale, molto forte per le imprese.

[1] Per essere onesti, il documento citato ha anche qualcosa di utile, nel sottolineare soprattutto che la misura della dimensione del software non può limitarsi alla valutazione “funzionale” (quella, appunto, dei Function Point), perché dovrebbe riguardare anche molte ulteriori caratteristiche non funzionali spesso estremamente rilevanti, e anch’esse niente affatto facili da misurare. Le metriche non funzionali proposte sono probabilmente l’aspetto più utile del documento.

[2] La metodologia SAFe (Scaled Agile Framework), ad esempio, definisce una tecnica per l’individuazione di un “metro” unificato per tutti i team di sviluppo di un’azienda.

[3] Il calcolo degli Automated Function Point ha ovviamente i suoi limiti, primo tra tutti quello di non considerare la complessità non funzionale di un’applicazione. Tuttavia, agli scopi di fornire un parametro ragionevole di confronto statistico, è probabilmente migliore e sicuramente più oggettivo delle stime manuali che si pretende di fare nelle fasi iniziali di uno sviluppo.