Checklist e web project management

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?

Così non va Delicious

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

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.zipaltra_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?

Quanto lavoriamo

Il Web Design Survey 2010 di A List Apart che ho analizzato qualche giorno fa contiene anche una sezione di statistiche dedicate alle ore lavorate in una settimana.

Tra i diversi grafici (suddivisi per età, sesso, tipo di organizzazione), ne manca però uno relativo alla distribuzione per titolo professionale. Partendo dai dati grezzi a disposizione, ho ricostruito questo grafico.

Si nota subito che la maggior parte dei lavoratori, indipendentemente dal titolo professionale, lavora tra le 40 e le 49 ore. In generale la distribuzione avviene quasi tutta in questo intervallo e in quelli immediatamente precedente e successivo, cioè nella fascia 30-59 ore, come era forse lecito aspettarsi.

Avrei forse preferito una suddivisione diversa nel questionario, per esempio 31-40 invece di 30-39: chi lavora le canoniche 40 ore settimanali avrà scelto l’intervallo 40-49, che avrei dedicato a chi fa qualche straordinario.

Tra le professioni che indicano di lavorare più ore (fascia 40+) troviamo il creative director, l’art director, il web director, l’usability expert e il project manager. Questo dato, se analizzato insieme alla distribuzione per luogo di lavoro, indica che chi lavora più ore è generalmente un dipendente piuttosto che un libero professionista.

E’ interessante paragonare questo dato con i risultati di un sondaggio condotto su un campione di freelance da Elance e pubblicato da Freshbooks e che sembra in qualche modo confermare quanto emerso.

 

Il censimento dei web project manager 2010

E’ ormai il quarto anno che A List Apart propone un sondaggio molto dettagliato rivolto ai professionisti del web e da qualche giorno sono disponibili i risultati dell’ultima edizione.

Nel 2007 e nel 2008 ho cercato di dare una lettura di questi dati in riferimento alla professione del web project management. Vediamo se in questi anni qualcosa è cambiato e se comunque possa emergere qualche informazione interessante che aiuti a spiegare la crescita di questa disciplina.

Percentuale di web project manager

Non ci sono sostanziali differenze rispetto agli anni scorsi: la percentuale di web project manager si attesta intorno al 4%.

Distribuzione per gruppo di età

Anche in questo caso il trend è confermato, con un lieve aumento degli over 65, rispetto alle altre professioni. Difficilmente si entra nel mondo del lavoro come web project manager, ma lo si diventa dopo altre esperienze lavorative.

Distribuzione per sesso

Il web project management si conferma una disciplina maschile, anche se la crescita delle donne è costante.

Distribuzione per tipo di organizzazione

Anche in questo caso le informazioni degli anni scorsi sono confermate. Rispetto alle altre professioni, è molto più probabile trovare un web project manager in una piccola organizzazione, indice che si tratta di una figura strategica in realtà in cui è fondamentale, per la sopravvivenza, il rispetto dei tempi e dei costi.

Salario

Lieve incremento per quanto riguarda i salati rispetto alle altre discipline, si passa dall’8.7% del 2008 all’11.6% del 2010. La maggior parte dei web project manager ha avuto un aumento di salario negli ultimi due anni.

Istruzione

Il web project management è tra le professioni in cui è più diffusa la laurea e il diploma universitario. Rispetto alla scorsa rilevazione, diminuisce sensibilmente l’importanza attribuita al titolo di studio in aiuto alla professione.

Soddisfazione per il proprio lavoro

Dopo la brusca caduta del 2008 rispetto al 2007, migliora la soddisfazione dei web project manager per il proprio lavoro.

Blogging

Non più fanalino di cosa, ma quasi. Il web project manager non ha tempo, o passione, di scrivere un blog.

Formazione

Il web project manager è tra i professionisti che più sono coinvolti in eventi formativi.

Lacune e competenze tecniche

Il web project manager sembra trovarsi più a suo agio con lo sviluppo backend, piuttosto che frontend o di interfaccia, segno forse che diversi web project manager provengono da questo campo.

Serenità per il futuro

Come gran parte delle altre professioni relative al web, il web project manager confida in opportunità di crescita nel prossimo futuro.

Libera professione

La maggior parte dei web project manager lavora in azienda, confermando come si tratti di una professione che richiede uno stretto contatto e conoscenza del team di lavoro.