Come digitalizzare la Pubblica Amministrazione.

Una storia di punti e di funzioni

Corrado Tru
Jul 24, 2018 · 12 min read

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”[1].

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 [1], anche se in realtà qualunque altro tipo[1] 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. 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 [1], anche se in realtà
qualunque altro tipo di “metro” potrebbe essere adeguato. 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.

Pubblicato originariamente su iMille.org

Functuion Point Digitpa Diego Piacentini

About Help Legal