Vantaggi collaterali

Tra le metodologie di sviluppo software che si sono dimostrate valide ce n’è una particolarmente interessante per la realizzazione di prodotti su misura: si tratta dell’approccio basato sul concetto di Minimal Marketable Feature (MMF).

Una MMF è la funzionalità più piccola possibile che deve essere realizzata per fornire un valore al cliente.

La feature è qualcosa che viene percepito dall’utente come un valore ed è quindi marketable perché porta vantaggi al cliente sotto forma di aumento dei ricavi, riduzione dei costi, ritorno d’immagine, fidelizzazione, ecc. Inoltre  è minimal poiché se fosse ridotta anche di poco non fornirebbe più tale valore.

Nello sviluppo di applicativi su commissione l’approccio basato su MMF presenta non pochi vantaggi però, per fornire un contributo utile ai non addetti ai lavori, sorvoliamo su quelli tecnici e commerciali, come la qualità delle specifiche e un miglior modello contrattuale, per evidenziare due vantaggi collaterali che sconfinano nella psicologia.

TheDoctorIsIn

Stabilizzare l’obiettivo

Nei progetti di piccole e medie dimensioni non è raro che una funzionalità sia definita solo in base all’obiettivo da raggiungere realizzandola con uno sviluppo incrementale e (micro)iterativo. In tal modo si ottengono quasi sempre buoni risultati in termini di tempi e costi di realizzazione.

Se però la funzionalità non è messa subito in produzione, in modo da diventare uno strumento utilizzabile dagli utenti, c’è il rischio che questi elaborino altri metodi per raggiungere il risultato voluto, spesso più tortuosi, o che tentino, magari involontariamente, di incorporarla all’interno di altre funzionalità non ancora realizzate.

La conseguenza è un progetto il cui l’obiettivo continua a cambiare, anche se di poco, con effetti negativi sui tempi e i costi di realizzazione e, soprattutto, sulla qualità del prodotto.

Stabilizzare il contesto

Non è raro che un software per la gestione delle informazioni venga realizzato come parte di un processo di riorganizzazione aziendale, spesso coincidente con un aggiornamento tecnologico. Un esempio tipico è il passaggio dal foglio elettronico gestito da un singolo utente a una piattaforma web di condivisione ed elaborazione dei dati.

In teoria sono le procedure e il contesto in cui esse nascono a influenzare il prodotto software che consentirà di metterle in pratica. In realtà l’influenza è reciproca.

La (ri)progettazione delle procedure aziendali è un processo per fasi caratterizzato da revisioni anche consistenti; se durante tale processo sono disponibili alcune funzionalità dell’applicativo, queste, attraverso un meccanismo di feedback, possono influire sul processo confermando o smentendo precocemente la validità delle scelte e stimolando la nascita di nuove soluzioni ispirate dall’utilizzo in ambiente di produzione.

Inoltre, similmente a quanto detto per la stabilizzazione degli obiettivi, disporre al più presto di alcune funzionalità contribuisce a evitare che la progettazione delle procedure aziendali entri in un ciclo infinito di revisioni.

Errore 404: il tuo sito non esiste (e tu?)

Un tempo si diceva “Se non sei su Internet non esisti”, oggi suona meglio “Se esisti non puoi non essere su Internet”.
D’altra parte non è raro vedere un nativo digitale cercare qualcosa scrivendo direttamente nella casella di ricerca di Facebook.

La reazione della piccola azienda, dello studio professionale o del singolo professionista è una e ovvia: “Mi faccio il sito!” (o la pagina Facebook).

keep-calm-and-go-online

Fino a qualche anno fa questo era il momento in cui iniziavano i problemi: aprire e gestire lo spazio web, registrare il sito e crearne struttura e contenuti provocava forti mal di testa e risultati letteralmente inguardabili.

Oggi non è più così: con un po’ di pazienza e qualche decina di euro chiunque può procurarsi un sito web più che dignitoso. Anche i casi più gravi di analfabetismo informatico non sono un problema se si dispone di un amico “smanettone”.

L’ostacolo dei testi è superato attingendo a piene mani a quanto disponibile in rete o clonando la brochure aziendale. Accantonando i timori di violazione del copyright, che per i testi delle presentazioni aziendali è statisticamente nullo, si riesce con poca fatica ad “andare online”.

E il lancio pubblicitario? Google e Facebook forniscono strumenti “fai da te” che consentono un controllo accurato dell’investimento e permettono di sperimentare quasi in tempo reale le idee e strategie. Inoltre mettono a disposizione consulenti per sviluppare soluzioni pubblicitarie su misura.

Lo scenario è indubbiamente roseo e lo diventa ancor di più se si considera che, soprattutto per le entità medio-piccole, la facilità d’accesso agli strumenti di misura dei risultati raggiunti funziona da antidoto per le fumose promesse dei costosi consulenti pubblicitari sopravvissuti agli anni ’90.

Naturalmente c’è un problema.

Avere un sito web di buona qualità è un obbligo e non un vantaggio competitivo.

E’ come il vestito per una cena di gala: si nota se non è all’altezza di quello che indossano gli altri invitati (e ovviamente se manca del tutto) ma non sortisce quasi alcun effetto se elegante e alla moda.

Ovviamente c’è una soluzione, che è…

No, in questo caso non ci sono soluzioni preconfezionate ma solo qualche suggerimento.

  1. Decidere il livello della propria presenza sul web: nonostante quello che raccontano i venditori di soluzioni (qualsiasi esse siano), non tutti sono obbligati a fare il salto nel web 2.0. Un’azienda o uno studio professionale può scegliere di utilizzare la Rete solo come vetrina, limitandosi a fornire informazioni sui servizi e i prodotti offerti.
  2. Un approccio più moderno si basa sull’ormai noto concetto di “produrre contenuti interessanti“. In questo caso è fondamentale capire di quali risorse si dispone per evitare casi simili a quello descritto nel racconto “La triste storia delle notizie sul sito”.
  3. Un ulteriore salto nel presente consistere nel tuffarsi, senza salvagente, nel mare dei social media e del dialogo totale con i (potenziali) clienti. Fare questa scelta obbliga a:
    • evitare follie come costringere tutti i dipendenti a iscriversi a Facebook, inserendo tra gli amici la pagina ufficiale dell’azienda e invitando parenti e conoscenti a fare altrettanto;
    • cercare il supporto di figure esterne in grado di accompagnare l’azienda su un percorso, inevitabilmente lungo e impegnativo, di definizione e mantenimento di una solida “presenza digitale”; non è necessario rivolgersi a costosissimi “guru” ma occorre certamente qualcuno con esperienza e una minima impostazione teorica.
  4. Se l’azienda ha una caratteristica unica, sia essa prodotto o servizio, che la distingue nettamente dai concorrenti, si può allora incentrare esclusivamente su di essa la strategia della presenza web. Questa soluzione ha il vantaggio di essere meno impegnativa e lo svantaggio di non essere sempre applicabile. Anche in questo caso occorre un aiuto esterno, soprattutto perché è difficile che proposte originali e di qualità nascano all’interno dell’azienda.
    E’ da sottolineare che non si tratta del caso in cui il consulente pubblitario di turno è talmente bravo da riuscire a trovare la “caratteristica unica” in qualsiasi cliente gli capiti a tiro.
  5. Indipendentemente dalla strategia scelta, il sito deve essere impeccabile; utilizzando i social media i margini di manovra ed errore sono molto ridotti ma po’ d’attenzione è comunque necessaria, ad esempio per evitare psichedelici accostamenti di colori.

keep-calm-and-stay-online

Attraversare la finestra: oltre gli open data

René Magritte - The Human Condition

Da anni nella Pubblica amministrazione circola l’idea dei dati aperti. Nel mondo i buoni esempi non mancano; per l’Italia basta fare un giro dei principali siti (in genere facenti capo alle Regioni) per vedere come l’idea sia stata colta e implementata, a volte bene, con dataset completi, nel formato corretto e corredati dalle necessarie schede di metadati che ne illustrano il contenuto, e a volte male, magari confondendo il concetto di open data con la semplice pubblicazione di materiale informativo.

Si tratta in generale di dati statistici, quindi già sottoposti a una prima interpretazione del curatore, e più rarfamente di dataset “elementari”, che forniscono un livello di dettaglio non aggregato.

Questi dati sono quasi sempre immagini periodiche (in genere annuali) o una tantum di una situazione; come tali, per quanto alta sia la frequenza di aggiornamento, si tratta di informazioni statiche che non consentono di avere a disposizione l’attuale situazione ma solo quella a una certa data. Inoltre non consentono interrogazioni mirate ma solo uno scarico indiscriminato.

Concetto ben diverso, e purtroppo quasi ignorato, è quello dei servizi aperti, ovvero web service più dinamici che consentono l’interrogazione di uno stato attuale e non di una “fotografia” in un dato momento.

Qualche semplice esempio: la statistica degli incidenti automobilistici dell’ultimo decennio può essere utile per la pianificazione di interventi di manutenzione urbanistica o per orientare campagne di sicurezza stradale ma non ci dice se l’autostrada su cui siamo è percorribile. Un elenco del numero di ricoveri ospedalieri può agevolare l’ottimizzazione delle risorse condivise tra varie strutture sanitarie ma non dice a un medico se il paziente che ha di fronte sia stato già ricoverato. Ancora, i millimetri di pioggia annuali possono essere utili per valutare i cambiamenti climatici ma non ci aiutano a sapere se domani pioverà.

Ferma restando quindi l’indubbia utilità degli open data, ovviamente quando implementati secondo le regole, sarebbe immensamente utile, per una vera e propria cooperazione applicativa, peraltro prevista e in parte già implementata, l’apertura di open services interrogabili dinamicamente e soprattutto interattivamente (quindi non solo per estrarre dati ma per compiere azioni: inviare un modulo, comunicare la modifica di una situazione, ecc.). Ciò fornirebbe la possibilità di creare, all’interno della Pubblica amministrazione, ma anche e soprattutto verso privati, dei servizi ad alto valore aggiunto, consentendo attraverso un dialogo reale tra differenti sistemi la realizzazione di “incroci virtuosi” in grado di semplificare e velocizzare procedure e percorsi.

(Si veda in proposito anche l’interessante documento Per una Strategia Digitale delle Amministrazioni Pubbliche del Paese di Alfonso Fulgetta)

Dei contratti e delle pene 3

ladro_ideaDopo aver bocciato le due soluzioni più intuitive per la gestione del rapporto cliente/fornitore nello sviluppo di piccoli software personalizzati, proviamo a proporre una soluzione. Nessuna delle idee esposte è originale ma si vuole unirle in una ricetta di taglio pratico.

Per la tipologia di progetti presi in considerazione i rischi da mitigare sono i seguenti.

  • Incertezza sugli obiettivi da raggiungere: soprattutto quanto si tratta di sistemi per la gestione delle informazioni, è comune che l’acquisto di un software personalizzato sia parte di un processo di revisione delle procedure aziendali; in tal caso gli obiettivi possono non essere del tutto definiti o cambiare parzialmente con l’evolvere della revisione.
  • Ottenere un prodotto incompleto: per diverse ragioni, tra cui quella finanziaria, c’è il pericolo che il progetto sia interrotto prima del previsto, col rischio di ottenere un prodotto inutile o molto carente e lasciando il cliente a metà del guado.
  • Esplosione dei costi: mescolando una lista di funzionalità stilata con l’intento di prevedere ogni futura esigenza con qualche errata scelta archittetturale i costi possono superare di molto la previsione anche prima di vedere avvicinarsi la fine del progetto.
  • Mancato pagamento: se il progetto si protrae troppo ed è soggetto a cambi di rotta, il cliente potrebbe non essere in grado o non avere intenzione di pagare per intero il lavoro svolto.

Per ridurre i rischi si possono adottare le seguenti tecniche.

  • Redigere un breve documento che inquadra il prodotto da realizzare all’interno degli obiettivi del cliente evidenziando sia i benefici che si vogliono ottenere che l’impatto sulle procedure aziendali. In teoria dovrebbe essere scritto dal cliente ma può anche essere preparato dal fornitore con il pretesto di dimostrare che ha ben compreso il contesto e gli obiettivi. L’utilità principale di tale documento è mantenere il progetto in carreggiata e rendere espliciti i cambi di rotta.
  • Esprimere le caratteristiche richieste mediante la tecnica delle storie utente (user story) che hanno il vantaggio di definire quali sono i risultati che il cliente vuole ottenere indipendentemente dal come tali risultati saranno ottenuti. Le funzionalità più complesse o per le quali c’è un’evidente difficoltà di comunicazione possono essere descritte utilizzando i casi d’uso (use case) che consentono di risolvere ogni ambiguità definendo nel dettaglio il comportamento del sistema dal punto di vista del cliente.
  • Iniziare definendo le storie utente solo ad alto livello (es. “emissione fattura”) raffinandole successivamente solo quando si decide di realizzarle.
  • Chiarire che i costi di realizzazione calcolati sulla base delle storie di alto livello sono solo una stima.
  • Realizzare il prodotto per fasi rilasciando per ognuna di esse un prodotto funzionante che fornisce solo le funzionalità che realizzano l’insieme di storie che si è deciso di implementare.
  • Far scegliere al cliente quali storie realizzare nella prossima fase. Sono da evitare la pianificazione delle fasi successive e la definizione di priorità.
  • Indicare i costi della singola fase in base alle storie di cui è richiesta la realizzazione; se possibile esplicitare i costi della singola storia per consentire al cliente di scegliere anche in base a considerazione economiche.
  • Prevedere un tempo di utilizzo “in produzione” delle storie implementate prima di scegliere cosa sviluppare nella fase successiva.
  • Concordare il pagamento dopo il rilascio di ogni versione e prima dell’avvio della successiva (e non solo l’emissione della fattura!). Fornire esplicitamente la garanzia illimitata per i difetti di realizzazione eliminando così l’antipatica abitudine di ritardare i pagamenti per ottenere una garanzia implicita.

Utilizzando questa metodologia il cliente è in grado di gestire l’investimento nel tempo in funzione delle funzionalità richieste; ha inoltre la possibilità di interrompere o sospendere il progetto quando ritiene di aver raggiunto gli obiettivi o i vincoli di spesa.

Nello stimare i costi, il fornitore deve considerare l’eventualità di dover reingegnerizzare alcune funzioni già realizzate sulla base di quanto emerge raffinando nuove storie utente. Tale evento è una caratteristica della metodologia e non un errore di cui trovare un responsabile.

Quanto proposto, oltre a richiedere un cambio di mentalità, ha lo svantaggio di non permettere la definizione certa della data di completamento del progetto nel suo complesso ma solo delle singole fasi. In realtà si tratta di un difetto molto piccolo se si considera che i progetti a data fissa (fixed time) non sono quasi mi conclusi nei tempi previsti.

Dei contratti e delle pene 2

TimeAndMaterialRiprendiamo il discorso sulle tipologie di contratto per progetti medio piccoli (qui la prima parte) prendendo in considerazione il modello “time and material” (T&M).

Il T&M è quel tipo di contratto con cui il cliente paga in base al tempo di presenza (o utilizzo) delle risorse umane impiegate e al consumo di materiali.

Non è molto utilizzato per i piccoli progetti ma ha un certo fascino, soprattutto nei seguenti casi.

  • Il committente vuole flessibilità e controllo nella gestione dei tempi di sviluppo e nelle modalità di lavoro; funziona bene quando il cliente ha le competenze necessarie per la conduzione del progetto sia dal punto di vista dei requisiti che da quello della gestione delle persone.
  • Le funzionalità da realizzare non sono del tutto definite.
  • Il progetto deve iniziare in tempi molto brevi; spesso per motivi di politica aziendale o esigenze finanziarie.

Il problema fondamentale del T&M è che il rischio è fortemente sbilanciato dal lato del cliente.

  • Occorre una gestione molto accurata dei tempi e dei costi che, oltre a essere difficile da ottenere, richiede l’impegno di personale qualificato. La prassi di delegare l’attività di controllo al fornitore semplifica la gestione ma rientra nel noto caso della “volpe a guardia del pollaio”.
  • Il fornitore non ha alcun interesse a contenere i costi.
  • Se si riesce a contenere i costi, tipicamente imponendo un tetto per intervallo di tempo, la durata del progetto si allunga a piacere (del fornitore).

La combinazione peggiore è quella di utilizzare il T&M delegando in toto al fornitore la gestione del progetto.

Insomma, per lo sviluppo personalizzato di piccoli e medi sistemi di gestione delle informazioni anche questa non pare una buona soluzione; nella prossima puntata esploreremo un altro approccio.

Evoluzione

worker“Se non è rotto non ripararlo”.

Ma quando si tratta di applicativi realizzati su misura una piccola dose di evoluzione è spesso necessaria.

Quello che capita con piccoli software è che, se tutto procede senza problemi per un certo tempo, finiscono per essere considerati da utenti e manager come la macchinetta del caffè: fondamentale per il funzionamento dell’ufficio ma degna di nota solo quando si rompe.

In realtà uno dei grossi vantaggi di un sistema di gestione delle informazioni costruito su misura è la capacità di evolversi sia per rispondere a nuove esigenze sia per stimolare l’adozione di procedure migliori.

Periodicamente si dovrebbero coinvolgere tutti i soggetti interessati all’uso del sistema per valutare la convenienza di aggiornarlo rispondendo alle seguenti domande.

Ci sono attività ripetitive che si possono delegare all’applicativo?
Classici esempi sono i report periodici e i controlli di coerenza sui dati (sia durante l’inserimento sia periodicamente con precessi automatici).

L’applicativo prevede la gestione di tutte le informazioni di cui gli operatori hanno bisogno?
Tipicamente si tratta di quelle informazioni che affollano gli spazi destinati alle annotazioni o, peggio, finiscono sui post-it incollati al monitor.

Esistono procedure, interne o esterne all’applicativo, durante le quali gli operatori commettono sempre gli stessi errori?
Se si tratta di funzionalità del sistema è necessaria una revisione dell’usabilità; se sono attività non informatizzate potrebbe essere il momento di renderle tali.

Ci sono eventi che sarebbe utile venissero segnalati via email?
Classici casi sono l’accettazione dell’ordine e l’avvenuta spedizione della merce.

Sarebbe utile una dashboard?
Si tratta di un “cruscotto” che, visualizzando un ridotto numero di indicatori, consente agli operatori e ai manager di conoscere rapidamente la situazione delle informazioni e dei processi gestiti dall’applicativo. Esempi di indicatori sono il numero di ordini in attesa, il tempo massimo e medio di evasione di una richiesta o il livello di scorte di un magazzino. Una versione limitata della dashboard può essere messa a disposizione dei clienti.

Smartphone?
Anche nel caso di prodotti non progettati per essere utilizzati da smartphone, o che non trarrebbero vantaggio da un uso in mobilità, può essere conveniente rendere accessibili alcune funzioni come, per esempio, la dashboard.

spyPer rispondere alle suddette domande, oltre che intervistare gli interessati, si può sfruttare l’opportunità di avere un sistema funzionante e trarre prezioni indicazioni osservando gli operatori mentre lo utilizzano.

 

Dei contratti e delle pene

FixedPriceFixedScope-300x150

“Non c’è più lealtà che garantisca i contratti, mentre le garanzie si sprecano al punto da far dannare i contraenti.”
William Shakespeare

C’è un mondo dove non abitano agili project manager e non si trovano responsabili degli acquisti che sgranocchiano function point a colazione.

E’ il mondo dei progetti software che si misurano in migliaia di euro dove s’incontrano piccoli imprenditori con ottime idee, soci di studi professionali in espansione e dirigenti di quei dipartimenti che producono risultati.

E’ il mondo dove un progetto si gestisce in quattro semplici passi:

  1. Definire le caratteristiche del prodotto da realizzare (fixed scope).
  2. Concordare il prezzo (fixed price), con o senza contratto scritto.
  3. Realizzare il tutto (più o meno in fretta).
  4. Essere pagati (più o meno in fretta).

Il fascino di una così semplice ricetta è che i clienti amano i progetti a prezzo fisso: sono rassicuranti e facili da comprendere perchè, avendo ben chiare le idee di ciò che si vuole, è facile capirne il “costo al chilo”.

Inoltre non è raro che una delle parti aggiunga come incentivo la data limite per la consegna (fixed time).

Falling-300x156

Il granello di sabbia che inceppa il meccanismo è l’ormai nota convinzione di poter individuare, e quindi fissare a priori, le funzionalità di un sistema la cui creazione è quasi sempre di qualcosa di nuovo che nessuno ha realizzato in precedenza. Prendiamo questa motivazione come una verità rivelata e continuiamo l’analisi.

Mentre le specifiche del progetto, evidentemente dotate di volontà propria, cambiano allegramente, il cliente e il fornitore si rattristano sempre più e il rapporto tra i due diventa una partita a scacchi (o un incontro di wrestling) con in palio l’aggiunta o la rimozione di funzionalità e lo spostamento del termine di consegna.

In apparenza, il più debole dei due è il fornitore che finisce quasi sempre per assecondare le richieste per non perdere il cliente e mantenere viva la speranza d’essere pagato per il lavoro già fatto (le politiche di pagamento sono un altro interessante capitolo).

In realtà, una volta fissati il compenso, i costi e la data di consegna, l’unico margine di manovra che rimane al fornitore è accumulare debito tecnico. Dal punto di vista del cliente tale debito corrisponde a un prodotto di bassa qualità perché difficile da modificare e soggetto al tipo di difetti che emerge solo dopo un uso intensivo o in condizioni limite.

La situazione è perdente per entrambi: il cliente rischia di spendere troppo rispetto alla qualità ottenuta mentre il fornitore di lavorare in perdita o subire un danno d’immagine per aver realizzato un pessimo prodotto.

La soluzione, squisitamente teorica, di aumentare i margini del contratto per includere i rischi del fornitore derivanti da uno sviluppo del tipo “tutto fisso” è difficilmente praticabile perché richiede non comuni livelli di fiducia e correttezza professionale.

Il modello di accordo che fissa requisiti, tempi e costi non funziona quasi mai. Ignorando la natura imprecisa e mutabile dei requisiti ne amplifica i rischi poiché spinge le parti coinvolte a proteggersi nel peggiore dei modi:

  • il fornitore cercando di anticipare il più possibile la definizione di quanto deve realizzare;
  • il cliente aumentanto il più possibile le funzionalità richieste.

Insomma la “fissazione di fissare tutto” non è affatto una buona idea; nella prossima puntata esploreremo un altro approccio.

La decima sinfonia di Beethoven

Beethoven

Era una bella mattina di primavera del 1827 e Ludwig van Beethoven si era svegliato stranamente di buon umore: nonostante fosse logorato dalla malattia, stava pensando a un motivetto musicale.

Nell’arco della mattinata il motivetto divenne un tema. “Wunderbar!”, pensò Beethoven, “Suona proprio bene!”.

Nel primo pomeriggio Beethoven cominciò a pensare a dei movimenti: il primo riprendeva il tema che gli era venuto in mente e lo sviluppava in un allegro; il secondo era un adagio maestoso; il terzo rallentava e il quarto sfociava in un allegro veloce.

“Altro che Inno alla gioia!”, si disse Beethoven, “qui vien fuori una sinfonia coi fiocchi”. Aveva ragione: la sua decima sinfonia sarebbe stata un inno alla vita.

Per sera aveva già pensato agli archi e agli ottoni. Aveva concepito un modo completamente nuovo di usare gli strumenti; persino al triangolo aveva riservato una parte incredibilmente lunga. Si addormentò pensando: “Domani la trascrivo!”.

Il giorno dopo Beethoven non si sentiva bene. Fece appena in tempo a dire “Amici, ho finito la decima!” e morì, indispettito per non aver trascritto il suo capolavoro, che andò perduto per sempre.

Morale: ricordatevi di salvare, anche più volte, il documento su cui state lavorando.

La differenza tra sintomo e diagnosi

doctor

Quando andate al pronto soccorso, si spera il meno possibile, non dite “ho una colica” ma “mi fa male qui” e indicate approssimativamente il basso addome (questo ovviamente se è lì che vi duole).

Al pronto soccorso non vogliono sapere la vostra diagnosi, che può essere errata, bensì i sintomi, in modo che il medico di turno possa fare, lui sì, la diagnosi.

L’errore denominato jumping to conclusions (letteralmente “saltare alle conclusioni”) è ben noto a chi studia le tecniche di problem solving e si applica a molti altri campi, non solo a quello medico. Per esempio, nei processi di informatizzazione aziendale compare sotto diverse forme (e a differenti livelli di pericolosità).

Un caso tipico è quando si presenta un’esigenza e qualcuno, saltando direttamente alle conclusioni, pensa la soluzione, presentandola poi agli informatici. La frase classica che viene detta all’informatico di turno (o, peggio, a un venditore) in questi frangenti è “Ci serve il programma X”. Certo, il programma X potrebbe essere la scelta giusta, allo stesso modo in cui al pronto soccorso potreste effettivamente avere un colica, ma le reali probabilità sono molto più basse di quanto non ci si aspetti.

Al pari del medico, l’informatico gradirebbe conoscere non la vostra diagnosi ma i vostri sintomi. Spiegategli quale è la vostra esigenza; per farlo, dovrete prima chiarirla a voi stessi e potreste addirittura scoprire che la soluzione che vi serve non è nemmeno informatica ma puramente procedurale.

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

alberto-sordi-maccarone

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.