Tu vuo’ fa’ l’americano (prima parte)

playbook

In ogni sport di squadra gli schemi di gioco sono l’elemento fondamentale per raggiungere il successo, ma è guardando una partita di football americano che se ne capisce più facilmente il valore.

Nonostante le squadre della NFL siano affollate di atleti di altissimo livello, a fare la differenza sono la qualità degli schemi di gioco e la fedeltà con cui essi sono applicati da tutti i giocatori.

Gli spettacolari touchdown e sack sintetizzano, traducendolo in immagini, il valore dei complessi schemi di gioco.

La scorsa estate il neonato “U.S. Digital service”, un team di esperti creato dal governo statunitense, ha usato il concetto dello schema di gioco (play) nella stesura della guida per le agenzie governative che devono realizzare servizi web destinati ai cittadini. Naturalmente il documento si chiama “U.S. Digital Services Playbook“.

Al confronto con l’enorme quantità di materiale prodotto prima dal CNIPA e poi dall’Agenzia per l’Italia Digitale, l’impostazione scelta dall’amministrazione Obama può apparire insufficiente al limite del ridicolo.

Considerando però i dieci anni di gestazione e la ventina di milioni di euro serviti a dare alla luce Italia.it o gli esempi di (in)usabilità di vari portali destinati ai cittadini, forse conviene analizzare un po’ meglio la soluzione americana senza archiviare come banalità i tredici schemi di gioco che propone.

Seguendo lo stesso schema del playbook e sorvolando sui suggerimenti più scontati, come l’adozione della metodologia agile, si può iniziare osservando che già nella brevissima introduzione ci sono elementi a cui non siamo abituati:

  • si chiarisce che i cittadini si aspettano di interagire col governo mediante tutti i canali digitali esistenti;
  • si ammette che troppi servizi digitali della pubblica amministrazione non funzionano bene (dopo poche righe è già chiaro che cosa s’intende per “funzionare bene”).

Il pattern è quello sacrosanto: ammettere gli errori + farsene carico + proporre una soluzione.

Play 1

“Individuare le necessità degli utenti del servizio”.

Tralasciamo l’orrendo caso in cui si realizzano servizi senza coinvolgere gli utenti e consideriamo quello in cui sono presi in considerazione tutti gli stakeholder.

Bilanciando gli interessi degli stakeholder per realizzare un prodotto di valore, occorre usare come riferimento le reali necessità degli utenti. Infatti, mentre è sempre possibile arrivare a un compromesso sulla soddisfazione degli altri stakeholder, ogni riduzione di valore per gli utenti danneggia tutti i soggetti interessati, spesso indirettamente e sul lungo periodo.

Play 2

“Considerare l’intera esperienza di utilizzo del servizio, compresi i passaggi che non coinvolgono strumenti digitali”.

Questo è una regola ampiamente disattesa: si progettano sistemi pensati per esistere in un mondo a parte senza influenzare ed essere influenzati dal contesto in cui vivono gli utenti. Un esempio comune è quello delle procedure che, senza una reale necessità, sono pensate per essere completate in un’unica sessione costringendo l’utente a ripetere tutti i passaggi della sequenza nel caso in cui debba temporanemente interromperla (spesso il tocco di classe è non segnalare l’esistenza del bizzarro vincolo).

 Play 5

“Il budget e i contratti sono fondamentali”

La gestione del budget deve essere affidata a persone competenti: questo è uno dei punti cardine per gli statunitensi; in Italia si deve aggiungere che il budget deve esistere non solo per la creazione del servizio ma anche per la sua gestione e manutenzione nel corso degli anni. Reperire le risorse di anno in anno è la strategia migliore per far sparire improvvisamente un servizio, riuscendo così a trasformare un valore per gli utenti in una perdita.

I contratti devono essere precisi e flessibili in modo da agevolare la consegna del prodotto e, soprattutto, la ricerca della miglior soluzione disponibile e delle moderne metodologie di sviluppo. Devono inoltre consentire al committente di apportare modifiche in corso d’opera senza che queste diventino tragedie greche o trattative arabe.

Naturalmente (!) la proprietà di quanto realizzato deve essere del committente. Quest’ultimo punto è interessante soprattutto per le pubbliche amministrazioni; infatti suggerisce che, mentre i servizi e i prodotti indifferenziati, come le connessioni di rete o le apparecchiature, possono essere tranquillamente noleggiati, ciò che è realizzato per soddisfare specifici bisogni del committente dovrebbe rimanere sotto il suo controllo con sicuri vantaggi per la qualità e il gestione dei costi.

(il tour negli USA continuerà in un prossimo post).football-icon