Merita molto il ‘manifesto’ di Tom Loosemore (co-founder di UK Digital Government Service (GDS) originariamente pubblicato sul blog di Public Digital col titolo: Internet-era ways of working.
Chi come il sottoscritto prova da decenni a scardinare l’approccio difensivo della Pubblica Amministrazione nel progettare soluzioni utili per gli utenti, ovviamente plaude convinto a questo manifesto e lo sposa in pieno, pur con la consapevolezza che i soloni di turno troveranno un infinità di motivi per definirlo inapplicabile alle nostre latitudini, appiattiti come sono sugli obblighi e sugli adempimenti che rappresentano la loro comfort zone ideale.
Ciò che mi spinge e mi motiva comunque a farlo – come farò anche a IcityLab2018 –, è il link logico e funzionale ai principi di progettazione britannici (vera e propria bibbia scritta con il contributo di Tom Loosemore) che dal lontano 2012 ho imparato ad apprezzare, studiare e, con estrema difficoltà, ad applicare nei progetti che gestisco.
Non da meno un link più che funzionale e strutturale al manuale di service design che andrebbe affisso in tutti gli uffici pubblici.
Il manifesto per scardinare la PA italiana
Detto ciò mi avventuro nella traduzione (con piccolissime escursioni personali in aggiunta), accettando nei commenti ogni miglioria e/o correzione:
La nostra definizione di digitale recita: “Applicare la cultura, i processi, i modelli di business e le tecnologie dell’era di Internet per rispondere alle aspettative sollevate della gente.”
Si ok, ma sicuramente dopo aver sentito questo slogan ci chiederanno: “Si, indubbiamente è bello e ci sta! Ma come posso realizzarlo nella mia organizzazione?”
Bella domanda.
Innanzitutto, abbiamo riflettuto molto per dare una buona risposta a questa domanda. Inoltre, siamo anche consapevoli di aver commesso negli ultimi 20 anni, molti errori nel rilascio di servizi pubblici digitali. Però da ogni errore abbiamo imparato qualcosa. Dunque, la risposta alla domanda potrebbe essere più o meno una cosa del genere: “Inizia con il preparare una lista di cose da fare per rendere queste nuove metodologie di lavoro tipiche dell’era di internet, delle azioni concrete”.
Sia chiaro però che l’elenco che proponiamo non va inteso come sostitutivo ai principi generali di progettazione. Piuttosto va inteso come una scatola degli attrezzi e, ovviamente, ci vorrà anche una discussione utile, per ottimizzarlo.
Progettare i servizi per rispondere ai bisogni reali degli utenti e mai per rispondere alla convenienza organizzativa ed economica dell’istituzione per cui si opera
- Utilizzate tutte le informazioni rese disponibili dai ‘sistemi’ ma aggregatele con le conoscenze acquisite degli utenti in modo che diventino la base del manuale di progettazione; cercate di stimolare sempre la ricerca e la condivisione delle conoscenze acquisite dagli utenti e fatele diventare uno sport di squadra.
- Anteponete la verità dei dati alle intuizioni. Ma prendete in considerazione prima di tutto le conoscenze acquisite degli utenti.
- Osservando gli utenti precoci (tipicamente i nativi digitali) potrete sviluppare la consapevolezza di come le tecnologie emergenti possono alterare i comportamenti comuni e crearne addirittura di nuovi.
Mettere alla prova le teorie più rischiose con gli utenti reali
- Identificare e testare teorie e ipotesi sui modelli operativi e sulle tecnologie, nonché sui modelli di business a sostegno e sulle progettazioni dei servizi da erogare.
- Verificate il rischio del lavoro di squadra. Questa è spesso una delle metodologie più rischiose e dunque va verificato a priori se il team è in grado di lavorare bene insieme. Questo assunto va reso esplicito da subito e testato al più presto.
- Create una cultura attraverso la quale il team è responsabile dei rischi a cui va in contro e non nasconde gli eventuali errori di percorso; alimentare false certezzeè comodo e confortante, ma altresì pericoloso.
La squadra che gestisce la messa in esercizio dei servizi digitali dev’essere rinforzata e possedere competenze multidisciplinari
- Ingaggiate dei veri specialisti che mettano in gioco la loro predisposizione nonché le loro abilità. Lasciate perdere le rockstars.
- Coinvolgete subito tutto il capitale umano utile e disponibile sin dall’inizio della progettazione, a cominciare dagli esperti legali. Soprattutto ricordatevi di includere il responsabile della sicurezza nel team.
- Il team deve poter gestire le proprie regole a garanzia dei processi per cui è preposto in piena libertà; non lasciare mai che altri processi dettino le regole al team.
- Implementate il team affiancandone degli altri, non creando un super team, ovvero una squadra ancor più grande. Ciò va fatto in modo incrementale e solo quando serve. Mai azzardandolo in anticipo.
- Un buon team non deve obbligatoriamente adattarsi alla struttura organizzativa esistente, e questo assunto, se praticato è quasi sempre una buona cosa.
- Progettate, sperimentate e imparate dagli errori.
- Garantite all’interno di ogni gruppo che la definizione delle priorità sia chiaramente attribuita a un singolo responsabile del prodotto erogato.
- Dotate la squadra di tutti gli strumenti e dell’ambiente più idoneo per poter svolgere al meglio il proprio lavoro.
Lavorate sodo per rendere le cose semplici
- I team che progettano servizi digitali dovrebbero essere ossessionati dal rendere i propri servizi semplici da usare, semplici da comprendere e semplici da modificare.
- Spesso ciò significa ricominciare da capo e ridisegnare il processo a ritroso, partendo dal risultato desiderato.
- Per i servizi esistenti e già in esercizio, è necessario ripartire dai principi base e sfidare ogni regola, abitudine e prassi che possa creare complessità o confusione per gli utenti.
- Siate prudenti e dubbiosi rispetto alle ultime tecnologie disponibili. Dedicatevi prima a risolvere le cose che non funzionano, a misurarne i difetti e ridurre le richieste di assistenza. Solo dopo potrete lanciarvi nell’innovazione tecnologica all’ultima moda.
Per sentirsi tranquilli (e sicuri) è necessario progettare servizi digitali con una certa dose di agibilità e flessibilità
- Non ci si può considerare al sicuro stando fermi. Agilità e consapevolezza delle minacce sono i nostri amici migliori.
- E’ necessario far penetrare la consapevolezza della sicurezza nella mentalità di tutti i componenti del team: per progettare i servizi, i sistemi e i processi con la sicurezza ben ferma nella mente (security by design).
- E’ fondamentale comprendere le potenziali minacce, in particolare il modo in cui i dati potrebbero essere utilizzati in modo improprio. In questo modo potrete rendere la vita più dura possibile a tutti coloro che cercano di danneggiare la vostra organizzazione o i vostri utenti.
- E’ altresì necessario ragionare in modo sistemico e non limitarsi agli obblighi del proprio perimetro operativo. Bisogna comprendere, valutare e gestire tutti i rischi, dal software alla catena di fornitura dei dati e non limitarsi a controllare solo l’infrastruttura sistemistica.
Essere consapevoli degli obblighi verso gli utenti e della gestione dei loro dati personali
- Riducete al minimo i rischi, riducendo al minimo la conservazione dei dati personali degli utenti. Praticare la privacy by design.
- Spiegate agli utenti quali dati deteniamo su di loro, come li utilizziamo e chi è il responsabile.
- Permettete agli utenti di controllare i dati personali che gestite. Ciò aiuta a rispettare i loro diritti contro l’uso improprio e li protegge dalle frodi.
- Progettate i servizi con un accesso ai dati personali strettamente necessario. Non dovete mai progettare funzioni che richiedano un uso massivo di dati personali.
- Offrite agli utenti delle modalità semplici per risolvere i problemi.
Iniziate con poco e ottimizzatelo attraverso l’iterazione. Iterare, incrementare e ripetere
- Le modifiche e i miglioramenti devono diventare effettivi in poche ore e non in mesi, ciò significa rendere il miglioramento del software facile e sicuro. La distribuzione continua del codice è un elemento essenziale e non negoziabile. L’implementazione continua (beta perpetua) è un esercizio virtuoso e apprezzabile.
- Le valutazioni continue sulle performance applicative devono essere accompagnate dall’osservazione degli utenti.
- Se il codice applicativo non viene testato, è quasi certo che non funzionerà.
- Non fissatevi su un’unica potenziale soluzione del problema: esplorate tutte le possibilità attraverso la ricerca e la prototipazione.
- L’iterazione deve essere applicata alle politiche e alle pratiche interne tanto quanto al software.
Costruire sistemi aperti rende le cose migliori
- Rendete trasparenti le cose. Esercitate la comunicazione Agile.
- E’ buona prassi iniziare la progettazione usando dei prototipi per raccontare una storia, impostare una visione e costruire una comprensione condivisa. Poi i prototipi vanno buttati.
- Utilizzate gli strumenti aperti e liberi che Internet mette a disposizione e siate disponibili al software aperto e libero.
- L’adozione di standard aperti permette di evitare il blocco esercitato dai fornitori di software proprietari (vendor lock-in).
- E’ importante distribuire prodotti funzionanti piuttosto che manualistica, documentazione a corredo, modelli a tendere o sentenze tipiche del RAG (nota: metodologia di Project Management).
- La trasparenza, l’ascolto, le dimostrazioni, le valutazioni continue tramite la riesamina paritaria, per dimostrare i progressi e per valutare i cambi di rotta, devono diventare pratiche permanenti, anche nell’ottica estrema che potrebbe portare all’abbandono di un servizio deciso di comune accordo con gli utenti.
- Gestire efficacemente i servizi erogati, significa stare sul pezzo andando a vedere regolarmente, e di persona, se le cose funzionano.
Finanziate i team, non i progetti
- Progetti e programmi possono essere i motori che generano problemi di “Legacy”. Meglio fornire finanziamenti stabili al team di prodotto/servizio invece di insistere sul finanziamento di grandi progetti. (nota: Il team product è costituito da diverse figure: product manager, il capo degli sviluppatori, il program manager, il sales director, il marketing manager, il capo dell’operation, il coordinatore del team di assistenza, ecc.).
- Prestate attenzione a come scrivete i mandati iniziali dei progetti (i cosiddetti “business case”), ed evitate che le regole di bilancio e quelle sui contratti non dettino il “come” verranno fatte le cose, e perfino il “cosa” verrà prodotto. Gestire i processi in modo snello e agile (nota: lean e agile sono metodologie per ottimizzare e gestire l’organizzazione del lavoro spesso applicate alla produzione del software) diventa fondamentale a medio termine.
- Richiedete disponibilità di budget per il miglioramento continuo. La combinazione di competenze di cui necessita il team e la sua stessa dimensione sono destinate a cambiare spesso. E’ dunque necessario far capire queste necessità a chi ha responsabilità di bilancio nell’organizzazione.
- Non dovete preoccuparvi di chiudere i finanziamenti a quei servizi che non funzionano (adottando la metodologia Agile queste sospensioni saranno facilitate, immediate e indolori).
Conviene essere prudenti sulle singole tecnologie. Prese singolarmente non sono utili
- Bisogna essere consapevoli che che l’evoluzione tecnologica non si ferma mai, quindi è necessario progettare i sistemi al fine di una costante evoluzione, quasi ad accettare le tecnologie emergenti come semplici prodotti del mercato da aggiungere alla bisogna.
- Sviluppare le capacità istituzionale per individuare potenziali competenze condivise all’interno dell’organizzazione e investirle nei team che producono componenti e piattaforme comuni.
- Considerate sempre in modo critico i servizi che dovete ingegnerizzare. Riflettete su come stanno scalando, evolvendo. Su cosa state acquisendo o affittando (ma ricordate sempre che non potete permettervi di esternalizzare i rischi).
- Vanno incentivate le capacità di comprendere come si evolvono tecnologie e le pratiche ad esse associate; similmente vanno incentivate le capacità di sperimentazione creativa basate su queste nuove opportunità che la tecnologia offre. Ciò significa utilizzare tecniche come la mappatura di Wardley (nota: sistema di elaborazione di mappe mentali) e allo stesso tempo dare tempo e spazio ai team per esplorare.
Considerate i dati come fossero un’infrastruttura
- Offrite dati di buona qualità con responsabilità chiare, piuttosto che enormi quantità di dati annegate in inutili cataloghi.
- Garantite la trasparenza dei dati e incentivate premialità per far emergere dati utili e condivisi per l’intera organizzazione.
- Utilizzate metadatazione e identificatori standard per agevolarne l’utilizzo.
- Preferite la messa in disponibilità come servizio in tempo reale al tipico scaricamento da server.
Il digitale non è solo il canale on-line
- Applicate questi approcci a tutti i servizi, compresi quelli analogici come le lettere, le riunioni, le relazioni personali, gli spazi fisici e persino il confezionamento delle pratiche.
- Progettate tutti i servizi con una visione olistica, come fossero parte di un insieme. Non un’applicazione, un sito web o singoli processi applicativi separati e isolati rispetto agli altri.
- Le componenti offline di un servizio dovrebbero utilizzare esattamente gli stessi dati e strumenti delle componenti online. It’s one service!
Infine: modificate una qualsiasi di queste regole prima di fare qualcosa di distruttivo. È meglio essere pragmatici e fare piccoli progressi, piuttosto che attendere circostanze perfette, che non arriveranno mai, e rimanere immobili.
Questa lista non è scolpita nella pietra. Anche se offre diversi di punti di partenza, non è saggio avventurarsi nell’implementarli tutti, dappertutto, o tutti insieme in una volta. Come sempre, è meglio iniziare dalle piccole cose, scegliendo attentamente un piccolo progetto e concentrandosi sugli obbiettivi che riteniamo più importanti per la nostra organizzazione. E’ dunque necessario che i team ripetano più volte i passi che li aiutano a svolgere al meglio il loro lavoro. Poi, è bene che il tempo e lo spazio siano anche costellati da eventuali errori, e che questi vengano sfruttati per aggiornare e migliorare la lista.
Internet e i suoi modelli sono ancora giovani; c’è tempo sufficiente per migliorarci dandoci dentro con passione.
