Bastone o carota?

Originariamente pubblicato su innovatoripa.it il 16 Aprile 2012

Ormai lo sapete I’M FALLING IN LOVE!

Si, mi sono innamorato dei Design principles britannici sui SERVIZI PUBBLICI DIGITALI e mi accingo a commentarne qualcuno, frustrandomi, tafaziandomi e anche incazzandomi non poco.

Tutto inizia con una premessa: ‘These principles are intended to be ‘carrot not stick’. They’re not a list of bad things to be avoided, they’re a set of principles to inspire you, accompanied by examples which explain things further and code and resources which will make the principles easier to follow. We’d love to know what you think — will these principles and examples be useful for you? Please let us know via govuk-feedback@digital.cabinet-office.gov.uk.’

Sinteticamente: ‘NON SIAMO QUI PER BASTONARE NESSUNO, NON ENUNCIAMO QUESTI PRINCIPI PER AFFERMARE CHE TUTTO FA SCHIFO, MA SIAMO QUI PER PORTARE QUALCHE ESEMPIO ISPIRATORE E RENDERE LE COSE PIU’ FACILI. CI PIACEREBBE SAPERE CHE NE PENSATE, DUNQUE FATECELO SAPERE’

Crowdsoucing, co-costruzione, ascolto, analisi dei fabbisogni???? Non lo so, ma mi sembra così chiaro e semplice che rispetto ai nostri pistolotti è già anni luce avanti. E continua la frustazione. Carry on!

Ed eccoci ai 10 comandamenti (in origine erano 7)

1) Start with needs (PARTIRE DAI BISOGNI) *quelli degli utenti, non quelli della Pubblica Amministrazione

The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.

LA PROGETTAZIONE DEVE BASARSI SULLE ESIGENZE REALI DEGLI UTENTI. TUTTA LA PROGETTAZIONE VA FATTA ATTORNO ALL’UTENTE (user centric design ……che bel termine ignorato beatamente nell’italico paese ). BISOGNA CAPIRE I BISOGNI ANALIZZANDOLI IN PROFONDITA’ E NON CADERE NEL SOLITO ERRORE DI FARE DELLE SUPPOSIZIONI (io direi non arrogandoci la boria di sapere cosa i cittadini vogliono). SENZA DIMENTICARE CHE CIO’ CHE CHIEDONO NON RAPPRESENTA SEMPRE UN BISOGNO. Esempi in Italia? Citofanate nei commenti, perchè io non ne vedo.

2) Do less (FARE MENO) e qui parte la ola, perchè questo articolo letteralmente mi arrappa.

Government should only do what only government can do. If someone else is doing it — link to it. If we can provide resources (like APIs) that will help other people build things — do that. We should concentrate on the irreducible core.

LA PUBBLICA AMMINISTRAZIONE DOVREBBE FARE SOLO QUELLO CHE LA PUBBLICA AMMINISTRAZIONE PUO’ FARE (sostituirei ‘dovrebbe’ con ‘deve’). SE QUALCUNO SA FARLO MEGLIO FATECELO SAPERE E GLI OFFRIAMO TUTTI GLI STRUMENTI PER POTER SVILUPPARE AL MEGLIO LE SOLUZIONI. NEL CONTEMPO NOI CI CONCENTREREMO (meglio) SULLA NOSTRA MISSIONE E SUGLI ASSET IRRINUNCIABILI. E dopo l’applauso? Citofonate esempi.

3) Design with data (PROGETTARE CON I DATI)

Normally, we’re not starting from scratch — users are already using our services. This means we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process — prototyping and testing with real users on the live web. We should understand the desire paths of how we are designing with data and use them in our designs.

SOLITAMENTE NON PARTIAMO DA ZERO QUANDO SIAMO CHIAMATI A PROGETTARE SERVIZI. ALLORA IMPARIAMO DA CIO’ CHE SUCCEDE NEL MONDO E DA QUELLO CHE STA SUCCEDENDO SUL WEB PER DISEGNARNE DI MIGLIORI. DOVREMMO CONCENTRARCI DI PIU’ SUI PERCORSI CHE SONO CREATI DAI COMPORTAMENTI DELLE PERSONE E DA COME LORO UTILIZZANO I DATI. (Gli inglesi son fantastici, usano il ‘desire path’, che figurativamente rappresenta il solco della bicicletta che devia dal percorso che gli è stato preconfigurato, per esaltare l’alternativa, la scorciatoia, la creatività e il fai da te……ecco perchè il Civic Hacking è nato da loro…..sospirone)

Comunque, tema difficile perchè in Italia siamo alla fase uno, ovvero alla liberazione del dato, non ancora al suo utilizzo. Appsforitaly? http://www.appsforitaly.org/

4) Do the hard work to make it simple (IMPEGNARSI PER SEMPLIFICARE LE COSE)

Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.

FARE QUALCOSA CHE SEMBRI SEMPLICE, È ABBASTANZA FACILE, FARE QUALCOSA DI SEMPLICE DA USARE È MOLTO PIÙ DIFFICILE — SOPRATTUTTO QUANDO I SISTEMI SOTTOSTANTI SONO COMPLESSI — MA QUESTO È QUELLO CHE DOVREMMO FARE. A chi lo dite. Qui nemmeno le cose che appaiono semplici lo sono. Mi vengono in mente, anche se esco dal seminato, i siti dei provider di telefonia mobile ….. depressione.

5) Iterate. Then iterate again. (RIPETERE, CON INSISTENZA)

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

Difficile da tradurre, perché è un modo di dire e di intendere il concetto di routine ripetitiva (loop), tipicamente anglosassone. PARTIRE DALLE PICCOLE COSE E RIPETERLE CON ENERGIA. PASSARE DALL’ALFA ALLA BETA E AGGIUNGERE CONTINUAMENTE FUNZIONALITA’ E MIGLIORAMENTI IN BASE AI FEEDBACK RACCOLTI Si tratta della teoria (più volte enunciata su questo blog e nei miei scritti) della BETA PERPETUA. Inutile costruire cose complesse e ingestibili, meglio concentrarsi sulle piccole cose, tanto mutano in fretta e non son mai stabili. Mutare al mutare delle abitudini e degli stili. ….molto informatico :-)

ecc. ecc.

Mi fermo, perché tanto è inutile, non avremo mai la capacità di sintesi degli anglosassoni che, per certi versi è devastante e irragiungibile. Mi si perdoni per certe sbavature nella traduzione ma, spero, di aver rappresentato un po’ del loro modo di pensare.

Veniamo ora al tema che pone Salvatore nel suo ultimo post e al ‘problema’ dei linguaggi.

Questa mia escursione nella perfida Albione vorrebbe far riflettere sul fatto che i vari linguaggi non sono un ostacolo se la cultura digitale è condivisa fra la PA e i cittadini. Enunciando i loro principi di design dei servizi pubblici, i britannici si rivolgono a operatori acculturati che possono velocemente correggere gli errori del passato. Da noi, invece, il problema è ancora quello del burocratese e dell’autoreferenza.

A mio modo di vedere l’Action Plan italiano è poco sexy, non tanto perchè non si allinea al linguaggio geek della rete (o meglio: non solo), ma perché è difficile da digerire. E’ un lungo elenco dei TANTI problemi e delle POCHE cose fatte, che mal si adattano a un contesto di DIGITAL GOVERNMENT.

Esempio? Proviamo a leggere questa frase dell’Action Plan: ‘approvazione di un quadro normativo più efficace per la prevenzione e la lotta alla corruzione nella PA al fine di assicurare un miglioramento delle condizioni di mercato per la concorrenza e di favorire il contenimento della spesa pubblica. I provvedimenti all’esame prevedono l’obbligatorietà dell’adozione di piani anticorruzione a carico di tutte le PA, con il coordinamento del Dipartimento della funzione pubblica, l’individuazione di un responsabile della prevenzione della corruzione, la valorizzazione di una rete capillare sul territorio, quella dei Prefetti, nella forma di supporto tecnico e informativo agli enti locali e quali tramiti tra essi e l’Autorità nazionale anticorruzione.’

Ma su che pianeta viviamo? Che lingua parliamo?

Capito ora perché mi son innamorato della perfida Albione?

Originally published at www.innovatoripa.it.