Checklist e web project management

Pubblicato il da
3

Il tema che più ha incuriosito il pubblico alla mia presentazione a Better Software lo scorso giugno riguarda le checklist.

È un suggerimento che mi sento di dare col cuore a ogni web project manager: usate e fate usare le checklist, cioè delle liste che vi aiutino a verificare di avere svolto tutte le operazioni propedeutiche a una attività successiva. Potrebbe valere la pena creare una checklist per il lancio di un sito, per caricare un’applicazione iOS sull’Apple Store, ma anche per la verifica dei materiali inviati dal cliente, per l’aderenza degli scatti fotografici o delle foto prodotto a determinati standard nonché per i test di funzionalità. Non c’è che l’imbarazzo della scelta.

Ho cominciato a interessarmi di checklist ormai da qualche anno e non è la prima volta che ho l’occasione di parlarne in questa sede (vedi ad esempio “Checklist per l’ultimo miglio“, dove è possibile scaricare un PDF con gli accorgimenti utili prima della messa online di un sito).

Recentemente l’interesse per questa buona abitudine si è rinvigorito dopo che ho letto il libro “The Checklist Manifesto“, scritto dal chirurgo Atul Gawande (se non avete tempo per leggere tutto il libro, trovate degli ottimi spunti anche nell’articolo che lo ha reso famoso). In questo testo Gawande spiega che grazie a delle semplici checklist è riuscito a portare rigore in sala operatoria e ridurre il numero di morti “accidentali”.

Cosa c’entra la chirurgia con il web project management? C’entra, perché le condizioni da cui è partito Gawande per impostare il suo lavoro sono le stesse che affronta un web project manager.

Ogni giorno le situazioni da gestire, da imparare e da svolgere nel modo corretto e in tempi stringenti aumentano. Non è un problema di conoscenza, ma di complessità. Il volume della complessità è tale che esauriamo la nostra capacità di applicare efficacemente la nostra conoscenza.

Di fronte alla complessità e alla pressione si tendono a sottovalutare i processi più semplici, oppure a saltarli credendo che siano opzionali. Ma una dimenticanza o trascuratezza possono avere gravi conseguenze nel futuro.

Alcuni sorridono quando propongo di utilizzare delle checklist, soprattutto perché le considerano uno strumento da pensionati, un elenco di attività talmente ovvio che non vale la pena di essere scritto. E in effetti normalmente non avremmo bisogno di una checklist, se non fossimo assegnati a 5 progetti concorrenti, immersi tra telefonate ed email in un open space insieme ad altri 50 colleghi. Ma purtroppo non è così, ecco perché sono utili.

Le checklist sono invece in grado di aiutare chiunque, sia l’esperto sia il web project manager junior, perché rendono espliciti i passi necessari per raggiungere l’obiettivo permettendo una verifica a posteriori, ma anche perché infondono disciplina e rigore.

Quali sono le caratteristiche delle checklist che funzionano? Anche in questo caso mi faccio aiutare dal testo di Gawande, con alcune mie integrazioni:

  • precisione – non c’è spazio per l’ambiguità in una checklist;
  • facilità di impiego – non c’è tempo per chiedere approfondimenti se qualcosa non è chiaro;
  • inclusione dei temi principali, e solo di quelli – si tende, io per primo, a realizzare checklist onnicomprensive con ogni dettaglio; meglio concentrarsi sui punti principali, massimo 10. Se proprio non è possibile, vale la pena suddividere i punti in più checklist distinte;
  • praticità – nessuna teoria, la checklist contiene azioni che possono essere verificate a posteriori;
  • uso di linguaggio chiaro e semplice – non è una tesi di dottorato, ma uno strumento alla portata di tutti;
  • verifica sul campo – prima di distribuire una checklist è bene che questa venga provata e riprovata;
  • approvazione – va stabilito un momento in cui la checklist viene verificata e approvata primo dello step successivo (ad esempio prima della messa online). Per alcune checklist che ho realizzato ho previsto spazio per la firma di approvazione: non è un contratto, ma apporre una firma è comunque una leva psicologica per un’ultima verifica di sicurezza.

Creare una checklist aiuta anche il confronto. Nessuno è perfetto e sicuramente riceverete feedback dal team che vi permetteranno di rifinire e migliorare la checklist nel tempo.

Quale software utilizzare per creare una checklist? Qualsiasi, da Word a Basecamp, da Excel a una mappa mentale. Personalmente utilizzo The Hit List per Mac e Wunderlist, cross platform e anche web based.

Voi usate le checklist? Avete qualche esperienza o suggerimento da condividere?

Una newsletter è per sempre

Pubblicato il da
2

Steve Jobs was originally obsessed with typography.

No, non si tratta dell’ennesimo tweet in ricordo di Steve Jobs, ma l’oggetto di una newsletter che AppSumo ha inviato lo scorso 6 ottobre, a poche ore dalla morte del CEO Apple.

Non ci sarebbe nulla di strano a cavalcare l’onda di santificazione che si è scatenata, se non fosse che in questo caso la passione di Steve Jobs è stata usata in maniera fin troppo esplicita per proporre l’abbonamento a un servizio di font.

Quando ho ricevuto l’email mi sono limitato a storcere il naso, ma a giudicare da quanto ho letto sull’utente Twitter di AppSumo, si è scatenata una piccola rivoluzione tra gli utenti del servizio che hanno trovato l’oggetto decisamente di cattivo gusto.

Noah Kagan di AppSumo è corso ai ripari informando che la newsletter era stata preparata giorni prima e che si sono dimenticati di intervenire in tempo per modificare l’oggetto. Non sta a me stabilire se questo sia vero (rimane comunque il fatto che Steve Jobs era gravemente malato da tempo, sicuramente prima che l’oggetto venisse scritto), ma lo trovo comunque un esempio significativo per sottolineare l’attenzione che va posta nel realizzare una newsletter.

La newsletter è uno strumento inviato nella casella di posta del destinatario e come tale assume un carattere personale, come se fosse stata forgiata esplicitamente per chi la sta leggendo, anche se così non è. Inoltre, quanto è stata inviata non c’è nulla più nulla da fare: non si può correggere il refuso scoperto nel frattempo, non si può allineare meglio l’immagine, non si può modificare il codice per sistemare la visualizzazione in quel particolare programma di posta. I giochi sono fatti.

Mi capita invece molto spesso di ricevere newsletter che sono evidentemente create troppo in fretta, con oggetti di dubbia utilità, ma anche con link di approfondimento che non funzionano, o che rimandano genericamente alla homepage del sito. E lasciamo stare l’argomento “annullamento iscrizione”, che quando c’è non è detto che effettivamente annulli.

La preparazione di newsletter è, invece, un’attività che va pensata con attenzione, proprio perché state in qualche modo invadendo la spazio privato della casella di posta elettronica di chi la riceverà.

E, giusto per non rimanere nel vago, ecco un esempio meno eclatante di quello di AppSumo che evidenzia come anche una newsletter a prima vista trasparente possa creare un po’ di malcontento in chi la riceve.

Qualche settimana fa insieme a un’agenzia con cui collaboro abbiamo deciso di inviare una newsletter agli iscritti invitandoli a ripensare la propria presenza online. Dopo aver valutato internamente alcune proposte, abbiamo scelto l’oggetto “Il tuo sito è per sempre?”.

Nel corpo dell’email è presente una bella immagine e il messaggio “Non hai sposato il tuo sito. Cambialo.”

Le statistiche hanno riportato un risultato molto buono: il 50% dei destinatari ha aperto la newsletter e di questi un altro 50% ha cliccato sul link per avere maggiori informazioni.

Eppure un paio di iscritti, i classici clienti “con cui si ha più confidenza”, hanno risposto di non aver apprezzato in pieno lo stile del messaggio. Forse non gli è piaciuto l’accostamento del matrimonio a un sito? O, più probabilmente, il fatto di averli in qualche modo invitati a divorziare da qualcosa? O forse ancora si sono domandati perché gli stiamo suggerendo di rottamare il sito: forse pensiamo che faccia schifo?

A posteriori avremmo forse cercato una frase meno ambigua. Ma non lo possiamo più fare: una newsletter è per sempre.

Così non va Delicious

Pubblicato il da
Risposta

Come tutti i web project manager degni di questo nome, ho incubi nei quali il progetto in corso si trasforma in una vera e propria odissea, spesso con le sembianze di una messa online in cui tutto quello che poteva è andato storto.

Questi incubi non si sono per fortuna mai del tutto trasformati in realtà (ho comunque commesso errori), ma purtroppo è quanto è accaduto con il rilascio del nuovo Delicious, il famoso sito di social boomarking di cui sono, o meglio ero, felice utente da anni.

Per i pochi che non lo sapessero, Delicious è un servizio acquisito nel 2005 da Yahoo! e, dopo anni di semi-abbandono, rilevato ad aprile di quest’anno da AVOS System, società dei fondatori di YouTube.

Già da tempo ero a conoscenza della cessione, avendo ricevuto e prontamente risposto a un’email che invitava ad accettare i termini del servizio e la politica di privacy del nuovo proprietario, pena la perdita di tutti i bookmark.

Quello che non mi sarei mai aspettato è di ritrovarmi, il 27 settembre, con un servizio completamente diverso da quello fino ad allora utilizzato, mancante delle caratteristiche basilari e pieno zeppo di errori di funzionamento tanto da sembrare, come ho scritto in Google +, una versione preliminare a uso interno.

Penso sia utile cercare di elencare gli errori principali commessi da AVOS nel proporre il servizio, perché questo tipo di supervisione è uno dei compiti principali del web project manager, anche nel caso di migrazione.

Errori di comunicazione

La prima cosa che mi sono chiesto, visto il risultato, è se fosse proprio necessario andare online con una nuova versione del servizio che stravolgeva la precedente. L’ho inizialmente vista come una mossa per dimostrare che quanto non è stato fatto da Yahoo! in 6 anni di proprietà per l’evoluzione del prodotto, la nuova società è stata in grado di farlo in pochi mesi.

Ho poi scoperto che non si è trattato di un vezzo, ma di una necessità, in quanto gran parte del codice di Delicious si basa su framework interni che Yahoo! non ha ceduto e questo ha richiesto una riscrittura significativa.

Mi sarebbe piaciuto saperlo in anticipo. Sono tornato per scrupolo a leggere l’email che invitava alla transizione, ma che si limita a recitare

To continue using Delicious, you must agree to let Yahoo! transfer your bookmarks and Delicious account information to AVOS

sottintendendo che l’operazione è immediata e si potrà continuare ad utilizzare Delicious, lo stesso Delicious di sempre.

Un po’ di trasparenza in più l’utente se la sarebbe meritata, magari anche solo per compiere un’esportazione di sicurezza, ma soprattutto per capire che avrebbe dovuto mettere in discussione la stabilità del prodotto (back to beta).

Errori di strategia

Siamo sicuri che gli utenti non aspettassero altro che l’introduzione degli “stack”, cioè una collezione di link costruita intorno a una tema comune? Ma, soprattutto, che a favore degli stack sacrificassero altre funzionalità prima presenti come i network di amici, i gruppi di tag, la cancellazione e la possibilità di rinominare i tag? La lista di funzionalità del vecchio sito ancora da migrare è parecchio corposa.

Errori di usabilità

Il problema di un sistema a folksonomy è che tende alla proliferazione di tag utilizzati poche volte. Per evitare in parte questa situazione è sufficiente che il tag venga completato dal sistema mentre si scrive, non fosse altro per evitare la generazione di termini sia al singolare sia al plurale. Ma questa semplice e ormai diffusa caratteristica non fa più parte del nuovo Delicious.

Nella vostra pagina compare l’elenco dei tag ordinati dai più utilizzati ai meno. Da qualche giorno è facile capirlo, perché a lato del tag è indicato il numero di volte che avete usato un tag, ma non era così al lancio. Ad aspettarvi c’era una lista, a prima vista disordinata, di tag, e per di più incompleta: non avevate modo di accedere ai tag meno usati.

Errori di programmazione

Dopo 5 minuti di navigazione nel nuovo sito mi sono accorto di un grave errore: mancava la navigazione su più pagine dei propri link una volta scelto un tag. Mi spiego meglio: se selezionavo “project management” tra i miei bookmark, il sistema mi restituiva la prima pagina con alcuni risultati… senza darmi modo di spostarmi ai meno recenti. Anche questa problematica è stata corretta dopo qualche giorno.

Ancora qualche giorno in più lo ha invece richiesto la correzione di problematiche sia relative alle API (impedendo, di fatto, a servizi terzi di accedere ai contenuti), sia agli RSS e alle procedure di esportazione. Trattandosi in tutti e 3 i casi di comunicazioni verso il mondo esterno, l’impressione di alcuni utenti è stata quella di trovarsi in una stanza in cui c’è un principio di incendio e le porte chiuse a chiave dall’esterno.

Errori di copywriting

Diversi utenti hanno scritto su Twitter di non riuscire più ad accedere alla lista dei propri bookmark. Dopo il panico iniziale, l’arcano è stato risolto. Nella nuova versione non si chiamano più “bookmark”, ma semplicemente “link”. Era necessario modificare questa convenzione?

P.S.: da qualche giorno Fucinaweb ha una pagina in Facebook, un esperimento, ma se avete modo passate per un saluto, vi trovate non solo l’elenco degli interventi di Fucinaweb quando sono pubblicati, ma anche link a risorse e articoli di interesse per chi si occupa di Project Management e User Experience.

A ogni cosa il suo nome

Pubblicato il da
4

Mi trovo dal cliente con l’art director per illustrare la tavole grafiche del progetto. Ha apportato le ultime modifiche ieri sera e non siamo riusciti a rivederle insieme. Apre il portatile e fa doppio clic su figo.psd.

Il collega che si occupa del frontend manda un’email con le ennesime correzioni richieste dall’azienda che si occuperà dell’integrazione. Una volta decompresso il file, nel desktop compare la cartella che_palle.

Sono due esempi, ma potrei tranquillamente continuare per ore e ore senza mai ripetermi. Ok_bis_def.zip, altra_prova.psd, oggi_non_ho_idee.png: ho a disposizione un’intera letteratura di nomi insignificanti e imbarazzanti.

Stufo di passare le giornate a rinominare i file e inviarli ai diversi attori (ammesso che fossi ancora in tempo) ho messo a punto un semplice sistema di nomenclatura che cerco di applicare e  fare applicare.

Il consiglio è quello di partire già dalla stesura dei wireframe, per proseguire nel corso della progettazione grafica fino ad arrivare allo sviluppo delle pagine HTML. Ogni wireframe va correttamente nominato prima di consegnarlo all’art director, che solitamente è ben felice di conservare la creatività per altri compiti.

Ho provato in questi anni diversi tipi di nomenclature, ma quella che si è rilevata più efficace nasce da un compromesso tra nome dal contenuto altamente informativo e semplicità di applicazione della regola.

Un tipico esempio di nomenclatura potrebbe essere il seguente:

  • HP010
  • PR010
  • PA010

I primi due caratteri indicano la sezione del sito a cui la pagina fa riferimento (in questo caso HP sta per homepage, PR per scheda prodotto e PA per processo d’acquisto), mentre il numero indica il progressivo della pagina all’interno della sezione (HP010 potrebbe essere l’homepage generale, HP020 la declinazione per il periodo natalizio, ecc.). Utilizzo le decine e non le unità per rappresentare i progressivi perché, se ci accorgiamo di aver dimenticato un template che “logicamente” va inserito tra altri due, lo possiamo includere (ad esempio HP015).

Come è facile vedere la regola è banale, ma proprio per questo altrettanto semplice da applicare. A me ha risparmiato molto tempo, ma soprattutto ha permesso di verificare a colpo d’occhio se i template realizzati erano, in ogni fase, tutti quelli previsti.

P.S.: se, come me, avete il pallino delle nomenclature, vi rimando a un articolo che ho scritto quasi 10 anni fa (il tempo passa) e che affronta tra le altre cose il tema dei nomi da dare e non dare alle regole CSS: Chi ha paura di Xhtml 8?

Il ruolo delle agenzie nei progetti e-Commerce

Pubblicato il da
2

È uscito in questi giorni per i tipi di Hoepli “e-Commerce, Progettare e realizzare un negozio online di successo“, un manuale scritto da Daniele Vietri e Giovanni Cappellotto.

Il libro contiene anche alcune interviste, tra cui una al sottoscritto, che riporto qui sotto.

Quali caratteristiche deve avere un’agenzia per realizzare al meglio un sito di e-Commerce?

È importante individuare un partner che sia in grado di accompagnare l’azienda non solo nella fase di avvio e di primo rilascio del progetto, ma anche durante i successivi miglioramenti e integrazioni del prodotto che inevitabilmente verranno richiesti. L’agenzia, dopo i primi feedback forniti dalle analisi su utenti e vendite, dovrebbe essere in grado di recepire queste indicazioni e suggerire dei piani di intervento sia nel breve, sia nel medio termine, per esempio con sessioni di test multi-variabile. Molto importante è anche verificare l’esperienza che l’agenzia ha nella progettazione di siti di e-Commerce del proprio settore.

Cosa possono fare i clienti che chiedono un sito e-Commerce per agevolare il lavoro dell’agenzia?

Una delle difficoltà più grandi per il cliente è quella di saper illustrare le proprie esigenze. Alla domanda “qual è l’obiettivo del sito?” può succedere che il cliente risponda passando in rassegna un insieme sparso di componenti che ha notato navigando altri siti, soprattutto quelli dei competitor. Ci si trova allora in riunioni in cui viene chiesto di realizzare la scheda prodotto prendendola da un sito, il carrello da un altro, il risultato ricerca da un altro ancora. In questo contesto è fondamentale il ruolo dell’agenzia nell’aiutare il cliente a individuare in modo corretto e completo i veri requisiti del progetto, così da poter circoscrivere le funzionalità che verranno realizzare per la prima uscita del prodotto e quelle per i rilasci successivi, senza paura di sottolineare le difficoltà e le proprie opinioni in merito. Si fa presto, per esempio, a dire che un sito deve essere accessibile in più lingue, più difficile è gestire le spedizione di prodotto all’estero e risolvere le diverse problematiche di fatturazione o addirittura culturali dei diversi paesi.

Quali sono gli aspetti di un e-Commerce che i clienti trascurano con maggior frequenza?

Spesso gli aspetti più trascurati non riguardano il sito in sé. È certamente importante che il sito sia usabile, veloce, attraente, ma altrettanto importante e forse ancor più importante, è il servizio reso al cliente finale. Come si prevede di gestire la politica di reso? II cliente finale viene guidato in questa procedura o è lasciato in balia di se stesso? Quale potrà essere il tempo medio per la spedizione di un ordine? Esiste un numero verde o un indirizzo mail e quali sono i tempi medi di risposta da parte dell’operatore? Chi si occupa delle foto prodotto e quale è la qualità attesa? Sono domande spesso trascurate, ma che determinano il successo o il fallimento dell’esperienza utente complessiva, di cui quella web è solo una parte.

Quali sono le criticità che sorgono durante la realizzazione tecnica di un e-Commerce?

Le problematiche in ambito tecnico nascono quasi sempre da errori di valutazione in fase di analisi. E i punti dell’analisi che sono più soggetti a errori di valutazione riguardano l’integrazione e la comunicazione con servizi di terze parti e i dettagli della procedura di acquisto, dal momento in cui il cliente finale ha aggiunto un prodotto al carrello fino alla conferma dell’ordine. Se i tempi sono stretti e l’analisi deve essere realizzata in tempi brevi, concentratevi almeno su questi punti.

Nell’ottica di massimizzare le vendite, consiglieresti una piattaforma già pronta o una sviluppata su misura?

La scelta va fatta caso per caso in base ai requisiti del progetto. Se, a fronte dell’analisi dei requisiti e della vendor selection, le modifiche alla piattaforma risultano comunque significative, allora molto probabilmente la direzione corretta è quella della soluzione su misura. Le piattaforme disponibili oggi, sia commerciali sia open source, permettono un livello di personalizzazione tale che possono essere impiegate nella maggioranza dei casi.

Quanto è importante il rapporto con l’agenzia anche dopo la pubblicazione del sito?

È fondamentale, poiché se ogni sito web è una realtà in continua evoluzione, questo vale ancora di più per un sito di e-Commerce, dove è immediata la verifica del successo o del fallimento rispetto ai risultati attesi. Una soluzione di rapporto con l’agenzia potrebbe prevedere la stipula di un contratto di manutenzione annuale che copra la normale assistenza e un certo numero di micro interventi (stimabili per esempio in un monte ore a scalare), lasciando invece sviluppi più corposi a contratti separati.