Alberto Mucignat

Sono a Dortmund, Germania del nord. E nevica appalla. Sono partito stamattina da Roma Ciampino e devo dire che sorvolare Roma è un'esperienza (da Fiumicino si passa invece per il mare). Il Colosseo è un'opera monumentale, davvero: è più imponente dello Stadio Olimpico. Va beh, si passa al lavoro, un saluto a tutti e scusate per i pochi post, ma negli ultimi giorni non ho avuto un attimo di tregua. Stanno cambiando un po' di cose... più avanti vi spiegherò.

Sabato sarò a Cesena per tenere un talk su IA e eZpublish. Durante il weekend ho fatto un brainstorming con me stesso e quindi vi segnalo i temi che andrò a trattare:

- IA e CMS: cosa sono
- eZ publish: enterprise key features
- scalabilità dei contenuti
- progettazione dell'architettura delle informazioni
- blueprints e struttura del sito
- creazioni di classi di oggetti in eZ
- il sistema di templating in eZ
- wireframes e template
- relazioni tra contenuti
- categorie
- link tra contenuti e relazioni tra oggetti in eZ
- keywords/tagging
- tags in eZ publish
- flussi di produzione e eZ workflow system
- sistemi di navigazione: menù e breadcrumbs
- personalizzazione (eZ users)

A seguito del mio intervento ce ne sarà un altro su eZ publish, tenuto da Francesco e dal taglio più tecnico.

ps: spero di riuscire a vedere anche qualcuno di quelle zone (Pesaro, Ancona, chennesò )

Momento di gaudio personale: da oggi la mia azienda è ufficialmente partner di eZ systems, l'azienda che sviluppa eZ publish. Per arrivarci ho passato del tempo a contatto con i norvegesi: ho così imparato a conoscerli e ad apprezzare la loro filosofia di community, che condivido appieno e spero di aiutare a sviluppare con il nostro lavoro.
È anche disponibile il comunicato stampa ufficiale (pdf).

Negli ultimi giorni ho risolto (almeno credo) alcuni problemi di lavoro che tiravo avanti da un po' di tempo. A posteriori ho annotato sulla preziosa moleskine le cose che mi hanno aiutato a risolverli. Quello che segue è un piccolo corso alla risoluzione dei problemi. Enjoy!

Oggi ho passato la giornata ad analizzare un progetto web che consiste in qualche decina di categorie connesse tra loro in varia maniera. Diciamo che non si tratta di semplice tassonomia, ma di qualcosa che la mente umana ha tentato di complicare ulteriormente.

Ho passato ore a capire quali documenti ci siano dentro le varie categorie e quale senso ci sia dietro le varie scelte di presentazione (perchè un documento qui e non lì).
A un certo punto, mi sono detto, forse ci vuole un lavoro ad hoc sull'architettura delle informazioni.
Mentre pensavo a tutto ciò, scorrendo categorie e informazioni che si ripetono in sezioni apparentemente diverse, ho ribaltato il ragionamento e mi sono detto: se ci fossero solo 3 categorie cambierebbe qualcosa?

Morale: proporrò di semplificare notevolmente queste catalogazioni e suggerirò di utilizzare tags/keywords per creare associazioni tra contenuti.

A cosa serve parlarne se poi non applichiamo?

La capacità di ascoltare è una qualità importante per ogni project manager. Questo post aggiunge ulteriore chiarezza e le conclusioni sono molto utili:

- presta attenzione alle cose non-verbali (occhi, corpo, ecc)
- non dilungarti troppo
- aspetta il tuo turno di parlare
- mostra la tua completa attenzione
- fai domande interessanti
- per chiarezza, alla fine riassumi tutto

E tu che tipo di ascoltatore sei? Da quel che penso e da quello che mi hanno fatto notare io tendo ad essere #4 THE SELFISH.

Brief = breve riunione tra 2 o più persone. Si usa per farci sentire un po' ammerigani anche noi dell'italì.

Riporto qui le mie regolette base -in via di sviluppo- per essere più produttivo durante i brief:

1. fissare sempre un orario e cercare di rispettarlo: se non riesci ad iniziare in orario il brief, comunicalo subito agli altri


2. focalizzarsi sul tema del brief: prima di entrare in riunione rileggersi il materiale e fare mente locale


3. focalizzarsi sulle persone che partecipano: i loro ruoli e le loro competenze. È importante anche informarsi su di loro per evitare di fare figuracce


4. non distrarsi: il cellulare è il peggior nemico, spegnerlo è buona regola. Usare il notebook è anche peggio.


5. ascoltare quando parlano gli altri: fare disegnini o leggere documenti non aiuta a far capire che li stai ascoltando

Per ora basta. Anzi, regola numero zero: se vuoi rovinare un brief o semplicemente la persona che lo ha organizzato, cerca scrupolosamente di non seguire alcuna delle regolette di cui sopra.

Se dovessi dire delle cose che mi aiutano a velocizzare i progetti:
1. stendere subito la lista delle features e dei casi d'uso utilizzando un wiki
2. condividere subito il wiki con il cliente e con il team di sviluppo
3. arrivare il prima possibile ad un prototipo e poi iterare a go-go
4. sentire spesso il cliente, almeno 2-3 volte alla settimana
5. registrare sempre tutto sul wiki, obbligare il team e il cliente a farlo

Continuo a leggere articoli su Visio, un software che consente di fare schemi e flow charts, molto utili per rappresentare progetti web. Visio funziona solo su Office di M$, mi chiedevo se esisteva un qualche cosa di simile per linux...

Ho scoperto che adesso con Skype si può fare il co-browsing attraverso Jybe, un software geniale e i cui plugin funzionano sia su Internet Explorer che su Firefox.
Con Jybe si può navigare assieme a distanza e testare il funzionamento di un sito: questo aiuta notevolmente il contatto con i clienti e i collaboratori.
Attenzione che l'ho testato per ora solo singolarmente e non come plugin di Skype, però è molto figo e si può chattare direttamente sotto la pagina web.

Se ci penso, oggi leggo i miei feed di lavoro (e non) su bloglines, tengo i miei appunti su un wiki, leggo la posta via browser, i miei bookmark sono su furl, uso skype per parlare chattare telefonare, i forum e i blog per discutere con amici e sconosciuti, ecc ecc.
Di colpo mi accorgo che non ho più bisogno di un ufficio: potrei lavorare (e cazzeggiare) dovunque, fusi orari permettendo.