Gli articoli più letti nel 2011

Fine anno. Questi sono i 5 articoli più letti e pubblicati nel 2011 su Fucinaweb. La classifica tiene conto sia delle visite del sito, sia delle letture tramite il feed RSS.

Guerrilla web project management

Le slide con l’audio della mia presentazione a Better Software dello scorso giugno. Come può evolvere la professione del web project management in un mondo complesso?

Dietro le quinte di un progetto

Il blog della BBC è una ricca miniera per imparare da casi concreti il design e redesign di un progetto web.

Progettare con la carta

La creazione di bozzetti di carta è un approccio quantitativo che permette di valutare e migliorare in poco tempo diverse soluzioni per la progettazione di un servizio.

Checklist e web project management

Cosa hanno in comune un chirurgo e un web project manager? L’uso delle checklist per ridurre la probabilità di errore.

A ogni cosa il suo nome

figo.psd e che_palle.zip: quando è il caso di definire una nomenclatura condivisa.

La battaglia dei cloni di documenti

Un web project manager produce molti e diversi documenti tra cui analisi, presentazioni, benchmark, debrief, a volte anche wireframe. Lavoro per diverse aziende e capita che sia invitato a utilizzare dei modelli già realizzati con loghi, colori e font istituzionali.

È qui che comincia la battaglia. Se per realizzare la documentazione ho impiegato un paio d’ore, cercare di farla rientrare nel modello che mi è stato consegnato è spesso un’impresa titanica.

Il problema è che non si tratta, nella maggior parte dei casi, di veri e propri modelli, ma di cloni di documenti che sono stati svuotati del contenuto e cui mancano delle vere linee guida di formattazione.

Il tipo e la dimensione dei font e le spaziature non sono stati realizzati come degli stili, ma sono stati applicati al testo all’occorrenza. E se anche sono stati utilizzati degli stili, lo si è fatto solo per il testo principale e (forse) per una tipologia di intestazione.

È un approccio inefficiente per diverse ragioni:

  • ogni volta che viene inserito un nuovo elemento, ad esempio un titolo, questo va copiato e incollato mutuandolo dal precedente
  • si perde il valore “semantico” del documento: un’intestazione dovrebbe essere tale perché questa informazione è stata specificata nel documento, mentre in questi documenti lo è semplicemente perché utilizza un font “più grande” rispetto alle altre
  • la qualità degraderà nel tempo: i primi due documenti rispetteranno in qualche modo lo standard, i successivi perderanno man mano la formattazione voluta
  • è impossibile applicare gli stili in un secondo momento, per esempio nel caso di documenti già realizzati, che devono essere modificati a mano voce per voce

Questo si verifica con i documenti Word, ma non solo. Anche Powerpoint e Keynote soffrono dello stesso problema. Piuttosto che investire una mezza giornata per realizzare delle diapositive master che possono poi essere applicate in ogni presentazione, si preferisce realizzare una presentazione con alcune slide che sono poi copiate e incollate più e più volte.

Quando mi viene proposto di utilizzare un modello aziendale per produrre documentazione, cerco se possibile di farmelo anticipare prima di iniziare il lavoro, così da capire come questi siano realizzati. Se la qualità non è secondo me soddisfacente, ma il numero di documenti che devo preparare è ridotto, inizio subito a utilizzare questi “modelli” per produrre la documentazione.

Se però si tratta di un’attività frequente, di solito preferisco investire un po’ di tempo e ricostruire completamente il modello. L’operazione, di solito, mi richiede circa un paio di ore (nel caso di una presentazione qualcosa di più), ma è tempo ben speso, soprattutto per me.

All’apparenza, rispetto al template che mi è stato consegnato, non cambia nulla. Ma il lavoro di produzione della documentazione diventa molto più efficiente, a tal punto da recuperare molto presto il tempo speso per la ricostruzione del modello.

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?

Il video di Recruitment 2.0

Sono online da qualche giorno i video di Better Software, la conferenza a cui ho partecipato lo scorso Maggio parlando di recruitment con i social network. Potete vedere il video di Recruitment 2.0, ma poiché la ripresa e soprattutto le slide proiettate sono poco contrastate, ho anche caricato su Slideshare una versione della presentazione sincronizzata con l’audio preso dalla sala.

3 cose che ho imparato presentando con le slide

Non sono uno speaker di conferenze professionista: lo faccio nel mio tempo libero e solitamente non più di due volte all’anno. Ho comunque imparato alcune cose che vorrei condividere con voi. No, non sto dicendo di usare un approccio stile Presentation ZenSlide:ology perché, come è chiaro a chi ha partecipato a Better Software 2010, l’ultima conferenza dove ho parlato (di Recruitment 2.0), il 90% delle presentazioni già non usa più punti elenco a favore di foto e contenuti tersi. Mi sto riferendo invece a un piano di riserva nel caso qualcosa vada per il verso storto, ma anche per evitare incomprensioni con il pubblico. Ecco i miei suggerimenti:

  • Realizzate due diversi temi – Avete preparato le slide e le avete anche provate qualche giorno prima in ufficio (magari svegliandovi mezz’ora in anticipo così da non incrociare i colleghi). Quando salite sul palco notate però che la qualità delle lampade del proiettore è scarsa ed è difficile leggere i contrasti. Questo è un problema specialmente se la vostra presentazione non fa uso di punti elenco bianchi su sfondo nero (o viceversa) ma se contiene invece frasi posizionate in punti diversi o sovrapposte a delle foto. Il rischio è che gli “effetti speciali” su cui avete investito delle notti non siano visibili al pubblico e che non riescano quindi a comprendere appieno il vostro intervento. Preparate allora due diversi temi (potete usare sia Keynote sia Powerpoint) in modo che uno sia fortemente contrastato. Se, una volta saliti sul palco, vi accorgete che è difficile leggere le vostre slide, potete applicare con facilità il tema più contrastato. Certo, potete usare questo tema fin dal principio, ma se avete speso ore a rifinire le slide, la probabilità che l’effetto ad alto contrasto non vi soddisfi sono elevate. In questo modo, però, avete una strategia alternativa da usare solo se necessario. Inoltre, non dovete preparare due versioni ogni volta, perché una volta definito un tema che vi soddisfa, lo potete riutilizzare per qualunque presentazione.
  • Inserite il vostro username Twitter in ogni slide – Mentre ero sul palco a Better Software, il pubblico ha cominciato a inviare su Twitter estratti della presentazione. Sfortunatamente, un tweet conteneva lo username sbagliato (avolpon invece di AntonioVolpon) e i successivi retweet e nuovi tweet hanno per la maggior parte utilizzato lo username non esistente. Quindi, se potete, se la cosa non rovina il design delle vostre slide, riservate uno spazio in ogni slide dove inserire il vostro utente Twitter, e non limitatevi solo alla prima o all’ultima slide.
  • Se costruite una storia, aspettate il vostro pubblico – Sono un grande ammiratore di Made to Stick, e da quando l’ho letto cerco dove possibile di inserire una storia in ogni mia presentazione (a Better Software ho parlato delle mie diverse opportunità di lavoro, partendo dal servizio militare). State però attenti se la storia è un contenuto necessario per capire il resto della vostra presentazione. Se è così, e la vostra presentazione inizia dopo una pausa, o se il pubblico può scegliere tra diverse sessioni concorrenti (e quindi deve spostarsi di sala in sala) vi suggerisco di non inserire la storia nelle prime slide, ma di aspettare (ragionevolmente) che il pubblico sia entrato in sala.