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.

Progettare applicazioni mobile

Non si ferma la pubblicazione nel blog Internet della BBC, già tema di un mio precedente intervento, di articoli che spiegano nel dettaglio il processo di progettazione di siti e servizi.

Questa volta tocca all’applicazione iPhone del player che permette di rivedere i programmi trasmessi dall’emittente britannica.

E come sempre gli spunti non mancano, soprattutto perché non è presentato unicamente il risultato finale, ma anche le scelte che hanno portato alle diverse scelte progettuali, con particolare riferimento a quello che funziona meglio in ambito mobile:

  • non condensare troppe funzionalità in ogni schermata
  • tenere in considerazione i problemi di banda che possono verificarsi durante lo streaming
  • sfruttare la possibilità di presentare interfacce e funzionalità diverse in portrait e landscape

Dietro le quinte di un progetto

Non sapete quanto mi piacerebbe scrivere in questo sito come si articola nel dettaglio il processo di progettazione e creazione di un progetto online, soprattutto di uno di grandi dimensioni che vede coinvolte molte e diverse professionalità.

Ma non lo faccio.

Non lo faccio non perché voglia tenermi ben stretto tutto quello che ho imparato in questi 15 anni di lavoro.

Non lo faccio perché non posso.

Non posso perché a monte della mia attività di consulenza (e, in passato, di dipendente) c’è quasi sempre un accordo di riservatezza: non posso parlare dei dettagli del mio lavoro.

Non giudico se quella di far firmare clausole del genere sia una strategia efficace, ma mi dispiace non poter condividere esperienze o casi di studio pratici che difficilmente trovano posto nei libri. La realtà è spesso diversa da quella che si legge nei testi accademici.

Quello degli accordi di riservatezza è però un vizio che si propaga con una certa velocità. Se fino a ieri interessava le aziende di grandi dimensioni, mi capita sempre più spesso di sentire amici e colleghi che si trovano a firmare un accordo di questo tipo anche per progetti di poche migliaia di euro.

Ma non è di questo che volevo discutere oggi (segnalazioni riguardo la vostra esperienza nei commenti sono comunque molto bene accette, se non altro per capire l’entità del fenomeno).

C’è infatti chi per fortuna non ha problemi a condividere nel dettaglio la propria esperienza, come nel caso della BBC.

Un esempio su tutti è il redesign del meteo, che è stato descritto magistralmente dal team di lavoro in BBC Weather: Design Refresh in Pictures. Perché magistralmente?

  • Perché indicano l’intero processo di progettazione e non solo una parte
  • Perché presentano grafici e diagrammi (come quello relativo alle 5W – Who, When, Why, Where, What) che si aprono a tutto schermo, così da leggere per intero quello che c’è scritto, senza segreti
  • Perché elencano le parti del sito precedente a cui hanno rinunciato, e il motivo
  • Perché non si vergognano di far vedere che tutto prende vita dai bozzetti su carta (ne scrivevo giusto qualche settimana fa)
  • Perché indicano chiaramente la vision e come ogni professionista al lavoro sfrutti le proprie competenze per raggiungere gli obiettivi
  • Perché sottolineano l’importanza delle icone e della infografica (quella fatta bene) in un progetto di questo tipo.
  • Perché sapevano che descrivere nel dettaglio la complessa macchina del redesign avrebbe attirato le (inevitabili) critiche di chi si trovava meglio con la versione precedente (vedi i commenti 12 e 13)
  • Perché scrivono nero su bianco il nome delle agenzie e dei partner che li hanno aiutati nella progettazione del sito, invece di tenerli nascosti (magari facendo firmare un documento di riservatezza, giusto per ritornare al tema iniziale)

La possibilità di condividere così nel dettaglio la propria esperienza deriva probabilmente anche dal fatto che la BBC è pagata dalle tasse dei contribuenti e questo è un modo di far capire come sono impiegati questi soldi e di ritornare un po’ della conoscenza maturata.

Sarebbe allora bello che la Rai facesse lo stesso, ma vista la qualità dei progetti che mettono online forse sono ancora nella fase precedente, quella in cui devono ancora imparare come si fa a realizzarlo, un sito.

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.

Un po’ d’ordine alle riunioni

Questo video contiene una calzante metafora del lavoro del web project manager: molti progetti da gestire allo stesso momento, in varie percentuali di completamento, con attori diversi con cui comunicare.

Lo stesso avviene durante i meeting. Il project manager si trova a gestire la riunione, proiettare l’agenda assicurandosi che tutti i cavi siano collegati e che la rete funzioni, prendere appunti così da poter redigere la relazione, oltre naturalmente a portare il caffè. Il rischio è quello di perdere per strada dei dettagli importanti.

E da quando ho perso più volte questi dettagli utilizzo qualche accorgimento, soprattutto per i meeting dal carattere prevalentemente operativo.

Cerco di scrivere e anticipare l’agenda via email. Spendere 15 minuti per elencare i punti principali da discutere nel corso del meeting vi permette di chiarire sia gli argomenti che meritano di essere affrontati, sia l’ordine con cui avete intenzione di presentarli. Può essere utile proiettare l’agenda così che sia accessibile da tutti nel corso della riunione. Se infatti il meeting dura un’ora e dopo 40 minuti state ancora discutendo dei primi 2 punti su 10, è il caso di preoccuparsi e velocizzare. Già che avete scritto l’agenda inviatela ai partecipanti al meeting, ma non aspettatevi che tutti la leggano. Chiedete comunque sempre conferma relativamente a eventuali altri punti da aggiungere.

Quando possibile registro l’audio della riunione. Per quanto sia sviluppata la vostra capacità di gestire più attività contemporaneamente, c’è comunque un limite. Invece di prendere appunti, gestire la conversazione e mandare avanti le slide, cercate di capire se sia possibile registrare l’audio. A parte un consenso da parte dei presenti (non fate i furbi registrando senza dire nulla) serve poco altro. Quasi sicuramente sarete in meeting con un portatile, da cui potete agevolmente registrare dal microfono interno (per Mac uso WireTap Studio), ma potete utilizzare un registratore portatile o anche applicazioni per il cellulare.

Anche se siete comunque riusciti a prendere degli appunti impeccabili, sapere che avete una registrazione pronta in caso di dubbio fa sempre comodo. Per riascoltare la registrazione utilizzo ExpressScribe, un freeware che permette di comandare molto facilmente da tastiera la velocità della riproduzione, così da poter trascrivere i punti salienti della conversazione. Se siete interessati all’argomento registrazione, vi rimando a un interessante articolo scritto da Sam Barnes per il suo blog (in inglese).

Se la registrazione dell’audio non è un’opzione chiedete se un vostro collega può aiutarvi a prendere appunti, così da confrontarli al termine della riunione.

In ogni caso non fate passare troppo tempo, altrimenti si riveleranno pressoché inutili.