Prosegue l’analisi del documento “U.S. Digital Services Playbook” iniziata qui.
Play 6
“C’è un unico responsabile”
Gli americani individualisti credono che la soluzione migliore sia avere una persona con l’autorità di gestire la realizzazione del prodotto e che sia responsabile del successo come del fallimento.
Noi italiani, che abbiamo chiaro il concetto di team e lavoro di squadra, preferiamo quasi sempre:
- un responsabile, possibilmente di altissimo livello, che si prende il merito dell’eventuale successo;
- un folto gruppo di responsabili che prendono le decisioni;
- un numero illimitato di responsabili su cui ricade la colpa dell’eventuale fallimento (la matematica aiuta col noto caso di 1/infinito).
Play 11
“Sicurezza e privacy sono gestite con processi riutilizzabili”
Le questioni di sicurezza e privacy sono spesso risolte in due modi, entrambi poco efficienti.
- Affrontandole quando il servizio è in fase avanzata di realizzazione o pronto per l’entrata in produzione. In questo caso il danno è duplice: si ha un ritardo nella messa in produzione ed è molto probabile che le questioni di sicurezza e, più spesso, quelle di privacy entrino in conflitto con le regole di business causando una revisione delle specifiche.
- Prendendole in considerazione nelle fasi di analisi e progettazione, quindi nel momento giusto, ma partendo da una situazione di tabula rasa. In questo caso la parola chiave è “riutilizzabile”. Pare infatti che, soprattutto per la privacy, la cultura dominante sia quella del considerare ogni situazione un caso unico, cosa vera nel decennio scorso ma certamente non oggi.
Play 12
“Misurare per decidere”
In questo schema il suggerimento migliore è certamente quello di (cercare) di misurare il comportamento degli utenti in tempo reale, cioè studiare come questi interagiscono col servizio. E’ un’attività diversa dai test di usabilità che, se fatta in modo aggregato e in ambiente di produzione, può portare a scoprire problemi ignorati dagli stessi utenti.
Play 13
“Open data, open source, open mind”
Si raccomanda di abbracciare il concetto “open” in tutti i suoi aspetti:
- raccogliere e rispondere al feeback degli utenti;
- diffondere i dati;
- realizzare API per consentire a terzi l’interazione diretta col servizio;
- arrivare a condividere pubblicamente il processo di sviluppo e i relativi progressi.
Anche in questo caso una parola è interessante: “collaborare”.
Se la collaborazione è uno dei parametri di riferimento del successo di un progetto, non solo l’approccio “open” ne diviene la naturale conseguenza ma, soprattutto in Italia, si possono ridurre i problemi che nascono quando le valutazioni e le decisioni sono un “affare” riservato a pochi.
Lo schema dello schema
Interessante è anche il modello utilizzato per presentare gli schemi: un breve paragrafo che definisce il concetto con un’accurata scelta di termini è seguito da una check list che guida la realizzazione e da un elenco di domande di verifica.
Il pattern è di nuovo quello noto: obiettivo + procedura + verifica del risultato.
Una critica
Per qualche misterioso motivo, nel playbook non si trova la consueta pagina con nomi, titoli accademici e collegamenti ai siti personali di chi ha contribuito a realizzarlo.