Perversioni Metriche e Nebbie Epistemiche

Perversioni Metriche e Nebbie Epistemiche di Marco Gentili Le conseguenze dell’errato e improprio uso della misura dei Function Point sono già state nitidamente denunciate; le azioni correttive conseguenze atte ad evitarle già chiaramente identificate. Non rimane altro da fare che denunciare le perversioni metriche, oggi sempre più palesemente evidenti nella gestione della relazione cliente-fornitore. Bisogna che Amministrazioni Appaltanti e Fornitori ICT, esperti di Software Measurement, Project Management e Quality Management, abbiano, tutti assieme, la volontà di denunciare la “Nebbia Epistemica”, la verità avvelenata che offusca l’uso contrattuale del Function Point, Quali sono le perversioni metriche? Dall’inizio degli anni ’90 mi sono occupato dell’utilizzo delle misure funzionali del software, principalmente i Punti Funzione (Function Point: FP) secondo la definizione di conteggio datane dall’IFPUG, per il governo della relazione tra Cliente e Fornitore. Questo non mi rende un esperto della stima o della misura dei Punti Funzione, ma certamente mi ha fatto maturare una certa sensibilità nell’uso di queste misure in ambito contrattuale, con il vantaggio di aver giocato, nel tempo, tutti i diversi ruoli: - quello del Fornitore IT che sviluppa software applicativo; - quello del Cliente, principalmente pubblico, che detto software richiede; - quello di monitore inteso come parte terza, indipendente rispetto a Fornitore e Cliente, di supporto all’azione di Project Management esercitata da quest’ultimo sul progetto di sviluppo software affidato al primo. Ritengo che le conseguenze dell’errato e improprio uso della misura dei FP siano state nitidamente identificate e denunciate da tempo. Così come anche le azioni correttive per evitare dette conseguenze sono già state chiaramente identificate. Per questo vorrei limitarmi a denunciare quelle che non posso fare a meno di chiamare le “Perversioni Metriche”, oggi sempre più palesemente evidenti nella gestione della relazione cliente/fornitore per quanto attiene allo sviluppo di software applicativo. - la facile via di fuga offerta dal backfiring1, che genera false stime della dimensione funzionale considerando unicamente le risorse economiche disponibili con effetti di trascinamento dalle voci di costo dei precedenti bilanci, senza analizzare il costo di software equivalenti funzionalmente, cosa che riduce il numero dei FP ad essere direttamente proporzionali al costo facendo si che il costo del FP non dipenda più dalla tecnologia, dalle funzionalità richieste e persino dalla modalità d’appalto; 1   Le   cosiddette   tecniche   di   “backfiring”   ricavano   il   numero   di   FP   in   maniera   meccanicistica   utilizzando   relazioni   prestabilite   di   corrispondenza  tra  la  quantità  degli  elementi  non-­‐funzionali  e  il  numero  di  FP.  Si  basano  su  presupposti  metodologici  diversi   rispetto   alla   metodologia   standard   dei   Function   Point,   che   è   stata   sviluppata   proprio   per   fornire   un   risultato   indipendente   dalla   tecnologia   e   dal   numero   di   componenti   non   funzionali   dell’applicazione   SW.   Le   corrispondenze   su   cui   si   fondano   le   pratiche  di  backfiring  si  basano  su  dati  statistici  e  la  loro  significatività  è  strettamente  legata  alla  significatività  del  campione   statistico  utilizzato  e  alla  identificazione  dei  corretti  parametri  per  la  corrispondenza.       1 - - - il falso mito del costo unitario del FP, che rende il FP di fatto una nuova “valuta”, così che il FP non è più correlato al ciclo di vita adottato per lo sviluppo software, alle fasi di detto ciclo effettivamente richieste ed attuate, ai deliverables contrattualmente richiesti, al valore d’uso del software; valuta utilizzata perfino per pagare cose molto diverse dallo sviluppo software come la consulenza, l’acquisizione dati, la gestione documentale, l’help desk ed il contact center per il supporto all’utente; le perdute misure “non funzionali”, legate alla qualità del software da realizzare secondo le caratteristiche di qualità definite dalla ISO/IEC 25012; come anche alla produttività dello sviluppo, alla velocità di rilascio del software, all’incidenza dei costi di manutenzione; ed ancora alla difettosità, alla copertura dei casi di test, al livello di documentazione fornita; per finire trascurando anche il potenziale utilizzo delle funzioni implementate (fattore d’uso) e la frequenza media di utilizzo da parte degli utenti in un dato periodo di riferimento; l’inconsulto ribasso di prezzo del FP, come del GP (giorno-persona), conseguenza dell’attenzione parossistica, eliminate le misure non funzionali, al solo costo del software unitamente, negli ultimi due anni, al ricorso al criterio del prezzo più basso per l’appalto dello sviluppo di software e dei servizi ICT, che invece richiederebbero, come anche previsto dal Codice degli Appalti (D. Lgs 163/2006 e s.m.i.) il criterio dell’offerta economicamente più vantaggiosa. Se queste “Perversioni Metriche” sono note e ampiamente discusse, meglio tentare di rispondere nel prosieguo ad alcune domande che gli esperti del settore IT si fanno: 1. Perché il prezzo del FP è sceso negli ultimi anni a ritmi vertiginosi? 2. Perché il prezzo dei servizi professionali segue un trend di ribasso eccessivo? 3. Come si riduce il costo del lavoro? 4. Come si diminuiscono l’impegno e le competenze? 5. Come si può garantire il soddisfacimento dei requisiti di qualità del Sw e non solo funzionali? 6. Come devono evolvere i contratti per consentire un uso appropriato delle metriche per il Sw? 7. Come dissolvere la “Nebbia Epistemica”? 1. Perché il prezzo del FP è sceso negli ultimi anni a ritmi vertiginosi? Semplice: è sparito l’oggetto della Misura! A significare che chi appalta, la Pubblica Amministrazione in testa, è incapace di conoscere le proprie esigenze di sviluppo Sw: - non sa programmare gli sviluppi (pianificazione); - nè definirne requisiti e modalità di realizzazione, per analizzarne la fattibilità preventivamente e propedeuticamente all’appalto (studi di fattibilità). Sembra che in chi appalta rimanga solo la volontà di assicurarsi un budget per lo sviluppo software, prescindendo da definite esigenze reali, in questo modo, propagando storicizzate voci di costo. Questo è particolarmente evidente nel diffuso utilizzo di “contratti quadro” per lo sviluppo software, sprovvisti di requisiti da implementare, parametri qualitativi da rispettare, basati solo sul costo unitario del FP o, peggio, dell’impegno in GP. Questo rende facile il dilagare dei (finti) virtuosi risparmiatori, interessati solo a dimostrare una presunta ottimizzazione dei costi sulla base di fallaci affermazioni del tipo: “Quest’anno il FP mi costa meno dell’anno scorso!”. 2 Questi illusi risparmiatori sono generalmente inabili ad esercitare un adeguato governo degli interventi realizzativi, per mancanza delle stima ex ante e dei controlli ex post e dell’imprescindibile confronto tra sviluppi software pianificati e consuntivati, oltre che per i reiterati rifacimenti in corso d’opera conseguenti alla mancata preventiva definizione dei requisiti necessari. Costoro di fatto, che ne siano coscienti o meno, si trovano ad applicare una sorta di “Legge di invarianza” che si può sintetizzare nella banale formuletta: N° FP x Costo FP = Importo a Base d’Asta x ( 1 - Sconto % ) che, come già detto, ha l’effetto di ridurre il FP ad una mera valuta, come l’Euro. Questa “Legge di invarianza” si è dimostrata terribilmente efficace nel diffondere la “Nebbia Epistemica”: Le affermazioni sui FP ... risultano "vere" non rispetto alla realtà, ma a quella mescolanza di vero e falso che è "il finto", una "realtà seconda", costruita per gli scopi più diversi. L'effetto più interessante di questa condizione è che permette di diffondere il falso praticamente senza conseguenze. Nel frattempo l'informazione falsa sarà diventata "realtà seconda", avrà fatto il danno che doveva fare. Quali sono le conseguenze negative di questa situazione? Quando gli argomenti fallaci non vengono smascherati, ma anzi si moltiplicano, ne deriva una situazione che chiamo di “Nebbia Epistemica”, una sfiducia generalizzata nella possibilità di riconoscere il vero, la ragione, il torto. Paradossale che queste parole, che così bene si adattano alle affermazioni sui FP, le abbia integralmente “rubate”2 a chi le ha utilizzate per parlare del concetto di verità nel discorso politico. Si potrebbe concludere che le verità sui FP sono analoghe alle verità che ci somministra la politica in questi tristi momenti di recessione economica. 2. Perché il prezzo dei servizi professionali segue un trend di ribasso eccessivo? E’ evidente che nell’acquisizione di servizi di sviluppo di software applicativo è data un’enfasi patologica al prezzo, nell’appalto pubblico è ancora più evidente, infatti si assiste a: - gare d’appalto tragicamente basate sul criterio del ribasso di costo, invece che dell’offerta economicamente più vantaggiosa, che potrebbe contemplare anche aspetti legati alla qualità del processo di sviluppo e del prodotto software; - gare che, basate sull’offerta economicamente più vantaggiosa, mascherano il criterio del ribasso di costo attribuendo alla componente di prezzo punteggi uguali o superiori a 60 punti su cento, di fatto minimalizzando la valutazione degli aspetti di qualità dell’offerta. - sconti che in alcuni casi risultano superiori al 50% dell’importo a base d’asta; - importi a base d’asta illogicamente definiti sulla base del prezzo aggiudicato della gara precedente, cosa che porta nel giro di qualche anno a prezzi ridicoli. 2     Esprimo   il   mio   debito   verso   la   Prof.ssa   Franca   D’Agostini   del   Politecnico   di   Torino,   che   le   ha   usate   per   parlare   del   concetto   di   verità  nel  discorso  politico  nell’interessante  libro,  dove  fornisce  un  contributo  imprescindibile  all’uso  pubblico  del  concetto  di   verità,  che  consiglio  vivamente:    “Verità  avvelenata,  buoni  e  cattivi  argomenti  nel  dibattito  pubblico”,  Boringhieri,  2010.   L’unica   licenza   poetica   che   mi   sono   permesso   è   quella   di   sostituire   al   concetto   originario   coniato   dalla   D’Agostini   di   “grigiore   epistemico”,  quello  più  figurativo  ed  evocativo  di  “Nebbia  Epistemica”.       3 Da tutto ciò discende l’implicita assunzione che servizi ICT e di sviluppo software si acquistano come commodity: simili a postazioni di lavoro, arredo per ufficio, ecc. E’ evidentemente sbagliato ed improprio, in questo modo si disconosce il valore della qualità: - del processo produttivo, disinteressandosi del processo di sviluppo adottato e delle modalità di assicurazione e controllo della qualità messe in atto; - del servizio acquistato, nel caso del software della sua qualità intrinseca: difettosità, usabilità e manutenibilità in testa a tutte le altre caratteristiche di qualità; - della documentazione, a corredo del software (tecnica, di gestione, utente). In questo modo si trascurano i costi della NON qualità del Software che peraltro sono subiti dall’acquirente in differita rispetto: - al momento di acquisto: la stipula del contratto di sviluppo; - a seguito dello sviluppo: è tipico che i difetti si manifestino nel 12-24 mesi successivi al momento della messa in produzione del software sviluppato. Il disconoscimento del valore della qualità da parte dell’acquirente porta alla riduzione dei prezzi e quindi, inevitabilmente, dei costi del lavoro da parte del fornitore. 3. Come si riduce il costo del lavoro? Ridurre i costi del lavoro significa abbattere il costo aziendale del dipendente, ovvero aggirare l’elevato cuneo fiscale, l’accantonamento del TFR, gli oneri previdenziali e sanitari. Tutto ciò si fa precarizzando il rapporto di lavoro: - da un lato riducendo i dipendenti a tempo indeterminato, mediante licenziamento o part time coatto; - dall’altro ricorrendo al subappalto (palese o, in molti casi occulto) o utilizzando consulenti, così generando una “catena alimentare” di imprese alla ricerca dell’abbattimento del costo del lavoro. Questa “catena alimentare” degli specialisti ICT la vedo rapresentata come in Fig.1.: Consulente < PM Impresa < Grande Impresa Nazionale < Impresa Multinazionale Figura 1 – Catena alimentare degli specialisti ICT La situazione è talmente estremizzata che alla fine della “catena alimentare” troviamo perfino i pensionati: costoro, garantiti di una base retributiva percepita (la pensione), si offrono sul mercato come consulenti a costi da COLF, così peggiorando la situazione di chi cerca lavoro non essendo ancora un pensionato. 4 Una rielaborazione dei dati rilevati da IDC nel 2012, si veda la Fig.2, fornisce la dimensione oggettiva dell’abbattimento delle tariffe per i profili professionali afferenti allo sviluppo del software. Figura 2 – Tariffe 2012 i profili professionali coinvolti nello sviluppo del software Avendo potuto dare un occhiata ai dati 2013, di prossima pubblicazione sempre a cura di IDC, posso dire che nel 2013 le tariffe sono scese ulteriormente, mediamente dello 0,6% a livello paese e dello 0,3% per quanto concerne la Pubblica Amministrazione, il settore dove l’abbattimento tariffario è più marcato. Sarà questo un indizio che la Pubblica Amministrazione è anche il luogo dove la nebbia epistemica è più fitta? Temo proprio di si! Purtroppo non è finita qui: se ridurre i prezzi del software, come visto, significa ridurre i costi del lavoro, disconoscerne la qualità significa diminuire impegno e competenze. 4. Come si diminuiscono l’impegno e le competenze? All’abbattimento del costo del lavoro si aggiunge la contrazione dell’impegno persona e l’alleggerimento delle competenze, altri due elementi utili per contrarre ulteriormente i costi. Le strategie di riduzione dell’impegno prevedono la rivisitazione del processo di sviluppo del Sw, tipicamente privato: - della piena applicazione delle funzioni di assicurazione e controllo qualità; - della progettazione ed esecuzione della quantità di test effettivamente necessari; - della quantità e qualità delle documentazione tecnica ed utente necessaria. In concomitanza alla riduzione dell’impegno, le strategie di riduzione delle competenze si basano: - sull’utilizzo di professionalità junior invece che senior, che produce la mancata formazione di seniores; mentre un tempo un’azienda formava un programmatore junior cobol e, all’evolvere delle tecnologie di sviluppo, lo trasformava, investendoci, in un programmatore senior java; oggi se dopo java s’affermerà un nuovo tipo di paradigma di sviluppo, si sostituiranno i programmatori java, ormai inutili, con nuovi programmatori juniores esperti del paradigma emergente; - sulla negazione di qualsiasi investimento formativo sui dipendenti; dimostrata dal fatto che ormai le persone, per partecipare ad un convegno, si mettono in ferie e che le certificazioni sempre più in voga sono prese, quasi esclusivamente, su iniziativa e investimento individuale, soprattutto nei periodi di disoccupazione o sott’occupazione. 5 5. Come si può garantire il soddisfacimento dei requisiti di qualità del Sw e non solo funzionali? Siamo proprio sicuri di volerci fare (ancora) questa domanda? Non è difficile identificare una terapia efficace per contenere le perversioni metriche denunciate all’inizio di quest’articolo. Si potrebbe iniziare a rispondere consigliando che la stipulazione dei contratti per la progettazione, realizzazione, manutenzione, gestione e conduzione operativa di sistemi informativi automatizzati sia preceduta: - • dall'esecuzione di studi di fattibilità volti alla definizione degli obiettivi organizzativi e funzionali; - • dalla valutazione ex ante della congruità tecnico-economica. Si potrebbe continuare a rispondere consigliando che l'esecuzione dei contratti sia oggetto di: - periodico monitoraggio in itinere (SAL, quantità, qualità). - verifica ex post dei risultati conseguiti con particolare riguardo ai costi e benefici, anche mediante l'adozione di metriche di valutazione dell'efficacia, dell'efficienza e della qualità. Suggerimenti condivisibili, facilmente enunciabili, evidentemente molto più difficilmente attuabili. Non ricordate di aver già letto qualcosa a questo proposito? La terapia sinteticamente delineata non è certo innovativa, nè mi permetto di ascrivermene il merito d’ideazione: ho volutamente riutilizzato le parole contenute nel D. Lgs. del 12 febbraio 1993, n. 39, “Norme in materia di sistemi informativi automatizzati delle amministrazioni pubbliche”. Quello istitutivo: - dell’AIPA (poi CNIPA, DigitPa ed ora AgID); - della formulazione dei pareri di congruità tecnico-economica, assurdamente obbligatori e non vincolanti, propedeutici all’indizione di una gara pubblica d’appalto; - del monitoraggio dei contratti di grande rilievo; - della verifica dei risultati conseguiti per il tramite di detti contratti. Sono passati vent’anni, significa che sono vent’anni che si accumulano risposte alla domanda “Come si può garantire il soddisfacimento dei requisiti di qualità del Sw e non solo funzionali?”. Ne cito solo qualcuna per scandire il periodico esprimersi degli esperti su questi temi: - 2004 Convegno CNIPA e relativi atti “Metriche per lo sviluppo del Sw: stato dell’arte”; - 2005 Linee guida CNIPA “Qualità dei beni e dei servizi ICT per la definizione d il governo dei contratti della PA”; - 2006 Linee guida CNIPA “Uso della misura funzionale del Sw in ambito pubblico” (Man 2, Cap. 9); - 2010 Linee guida CNIPA “Verifica dei risultati degli interventi ICT d’innovazione” (Man 12). Per tutte le “cose dette”, per la quantità delle “cose scritte”, mi chiedo se ha senso porsi ancora domande su come garantirsi la qualità del software. E’ ora per questo di cambiare domanda. 6. Come devono evolvere i contratti per consentire un uso appropriato delle metriche per il Sw ? Siamo sicuri che questa sia la domanda giusta? 6 Non credo che l’appropriato uso di metriche per il software (tra cui i FP) ed il raggiungimento di un prezzo congruo del FP e dei servizi professionali (tariffe €/GP), sia ormai un problema di evoluzione dei contratti. Ho già evidenziato come da vent’anni su come evolvere i contratti si è già detto tutto, o perlomeno molto. Evidentemente averlo detto non è bastato, ne consegue che limitarsi a ripeterlo non può essere sufficiente, ma non mi sottraggo e lo faccio sinteticamente: - Redigere gli studi di fattibilità prima dei contratti, in modo da esplicitare le motivazioni dello sviluppo software, i requisiti e vincoli, le modalità realizzative, la stima dei tempi e dei costi, anche verificando l’applicabilità delle misure funzionali al caso di specie. - Utilizzare metodi di stima della dimensione funzionale (non utilizzare il backfiring), ne esistono diverse tipologie (misure estrapolate, campionate, complessità media, Early &Quick FP). - Stilare contratti realistici perché applicabili, così da distribuire percentualmente l’impegno nelle fasi del ciclo di vita del software; valutare l’impatto della modifica dei requisiti; utilizzare anche le metriche di qualità non funzionali; considerare i casi di riuso, replicazione e adattamento del software; applicare adeguate modalità ̀ di determinazione dei corrispettivi, ricordando che non esiste un prezzo unico del punto funzione. Piuttosto, coerentemente alle considerazioni sinora fatte, la domanda che è necessario e impellente farsi è: “Come dissolvere la Nebbia Epistemica?” 7. Come dissolvere la Nebbia Epistemica? Evidentemente la “Nebbia Epistemica” è un problema, sicuramente non un problema tecnico, piuttosto un problema che definirei politico. Come tutti i problemi politici richiede l’identificazione di una controparte e l’elaborazione di una “piattaforma” con la quale affrontarla. Cercare come controparte un interlocutore politico mi pare molto difficile di questi tempi di politica fibrillante e governi transitori. Chi potrebbe essere comunque? Il Ministro del Lavoro? Il Commissario per l'attuazione dell'Agenda Digitale? Onestamente non saprei dire. Più facile cercare un interlocutore operativo, uno di questi tre, o tutti e tre: - l’Autorità di valutazione dei contratti pubblici (AVCP); - la centrale acquisti CONSIP; - l’Agenzia per l’Italia Digitale (AGID). Imprescindibile prima aver realizzato una ampia convergenza sulle “Perversioni Metriche” da parte delle associazioni rappresentative di tutti i diversi stakeholder: - i Fornitori ICT, rappresentati da Confindustria (ASSINFORM) o Confcommercio (ASSINTEL); - le associazioni interessate al Software Measurement (GUFPI-ISMA, SiFPA, GIMETRICS); - le associazioni di Project Management (ISIPM, PMI) e Quality Management, (AICQ); - le associazioni ICT (AICA, itSMF). così da elaborare una visione condivisa, una piattaforma comune: - di denuncia delle “Perversioni Metriche”, - di proposizione delle azioni correttive, tra quelle di cui si parla da vent’anni, - di definizione della roadmap per porle in essere. Bisogna avere tutti insieme la volontà di dissolvere la “Nebbia Epistemica”, di rifiutare la “Verità avvelenata”! 7 Bibliografia [1] Franca D’Agostini, Verità avvelenata, buoni e cattivi argomenti nel dibattito pubblico, Boringhieri, 2010 [2] Alessandro Alessandroni (a cura di), Metriche per lo sviluppo del Sw: stato dell’arte, CNIPA, 2004 [3] Marco Gentili (a cura di), Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione d il governo dei contratti della Pubblica Amministrazione, CNIPA, 2005 [4] Marco Gentili (a cura di), Uso della misura funzionale del Sw in ambito pubblico, Manuale 2, cap. 9, delle Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione d il governo dei contratti della Pubblica Amministrazione, CNIPA, 2006 [5] Marco Gentili (a cura di),Verifica dei risultati degli interventi ICT d’innovazione”, Manuale 12 dellle Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione d il governo dei contratti della Pubblica Amministrazione, CNIPA, 2010 [Author(s) Photo] Marco Gentili Laureato in Fisica, membro del Comitato Scientifico dell’Istituto Italiano di Project Management, ha sviluppato e applicato metodiche afferenti all’ICT Governance & Management, alternandosi tra pubblico (AIPA, CNIPA, DigitPA) e privato. E’ il curatore delle “Linee guida sulla qualità dei beni e servizi ICT per la definizione ed il governo dei contratti della PA” pubblicate da CNIPA, scaricabili dalla home page dell’Agenzia per l’Italia Digitale. Email: marco.gentili@gmail.com ---------------------------------- 8