Raffaele Persichetti

Uno dei widget del Guiwiki di Poste Italiane

Stamattina ho sorriso leggendo l’articolo di Peter Gremett chiamato Using Wikis to Document UI Specifications nel quale l’autore elenca i benefici che ne verrebbero ad una grande azienda se utilizzasse un sistema di wiki per documentare gli standard relativi alle interfacce utente (o user interface che dir si voglia).

Ho sorriso perché è una cosa che con il mio gruppo di lavoro abbiamo fatto lo scorso anno in Poste Italiane pubblicando un wiki chiamato “Guiwiki” nel quale sono riportati gli standard grafici (codici colore, tipo e dimensione dei font, formattazione tabelle….) da seguire nel momento in cui si vuole sviluppare un applicazione per la intranet aziendale.

Il Guiwiki riporta tutti gli standard definiti e mette a disposizione gli strumenti di collaboration tipici dei wiki per mettere a confronto sviluppatori e gruppo di lavoro della Comunicazione Interna che si occupa di definire gli standard delle interfacce grafiche.

Ogni volta che vi è un dubbio o ci si accorge che non è stato definito uno standard grafico per una determinata funzionalità, grazie agli strumenti di collaboration, ci si confronta ed alla fine si definisce lo  standard aggiornando contestualmente il manuale.

In una grande azienda come Poste Italiane, che sviluppa moltissime  applicazioni per uso interno ogni anno, rivolgendosi spesso a società esterne e sviluppatori non a conoscenza dei nostri standard,  l’adozione di questo strumento ha portato molti benefici come la sensibile riduzione degli interventi di correzione di interfacce grafiche realizzate fuori standard e la conseguente riduzione di tempi e costo di sviluppo.

L’articolo di Peter Gremett riporta quelli che sono i principali benefinci provenienti dall’utilizzo di un wiki per documentare gli standard delle interfacce grafiche.

Collaboration

Collaboration is the single best advantage of a wiki spec over a traditional one. The supposition of a wiki is that there are many authors and contributors to the document, and therefore, you have the right environment for collaboration. This is a huge advantage for product specifications. As the interaction designer you don’t have to sit in a cube by yourself and define everything on your own. It’s fine not knowing all the answers and you can rely on your team to help fill in the blanks.
Team members can add clarifications, details, or make edits to content. Oftentimes, the details and clarifications build upon one another to complete the document. For example, if the designer has specified the layout and behavior for a button, the tech writer can add in the rollover text without disturbing the designer or the flow of the project process. To follow the example further, the tech writer can then add the help content to the wiki, allowing the engineer to upload the information onto a server and post the URL. The transparency and collaboration are quite amazing. Team members are able to get the information they need to perform their jobs and help the project along.

Speed

Speed is a major benefit of wiki specs. This is also why it’s a good match for agile projects. Speed comes in two forms: writing and consumption. It’s easy to add content because of the WYSWIG interface. As you begin writing content, it can be instantly viewed by team members. I have found that the sooner you post sketches and thoughts the better. It gets the whole team collaborating and they can offer feedback immediately.

Flexibility

A wiki spec is extremely flexible. This characteristic allows you to morph its structure and organization as the project evolves, reflecting the nature of agile processes. The team is able to keep up with the changes that occur in an agile project because all edits can be instantly viewed. Additionally, if anyone wants to be informed of the most recent wiki changes, an email notification system can be set up by any team member.

Reversible

In the event that a change was accidental or a major disagreement arises, the wiki spec can be reverted to its previous version. This does not happen very often, but when it does, it’s a real life saver.

Mi sento allineato con le sue considerazioni ma vorrei aggiungere anche il fattore Engagement perchè avere a che fare con uno strumento che funziona e che fa finalmente collaborare le persone riducendo il lavoro di chi (il mio gruppo di lavoro) deve valutare se un applicazione è in linea o meno con gli standard grafici e di chi sviluppa l’applicazione mette buonumore, voglia di lavorare e fare bene.

Vi presento una interessante presentazione a cura di Toby Ward,  CEO di Prescient Media e navigato consulente nell’ambito di internet e delle intranet.

In questa preseentazione Toby introduce ed analizza il concetto di ECM, Enterprise Content Management.

Nella presentazione si analizzano i concetti di :

• CM, Content Management, la tecnologia ed i processi attraverso i quali vengono creati e pubblicati onlin contenuti,
• WCM, Web Content Management,  lo strumento specificatamente dedicato per la pubblicazione su siti web internet o intranet
• ECM, Ovvero la strategia e la tecnologia necessarie per la gestione dei contenuti nelle imprese medio-grandi.

Procede poi con l’analisi di scenari, la presentazione di casi d’uso e prodotti disponibili.

Da non perdere

Toby Ward descrive il caso di successo del portale intranet di Nordea. Di seguito una mia traduzione in italiano di questo interessantissimo caso di studio..

Nordea è una delle più grandi banche del nord Europa con 10 milioni di clienti (di cui 4,6 milioni fruisce i servizi web), 1100 filiali e 29000 dipendenti. Nordea nasce dalla fusione di 4 gruppi bancari per offire servizi a 4 diverse nazioni, ogniuna con una propria lingua e cultura.

Nel 2000 ogniuna di queste 4 banche aveva la sua intranet, nel 2002 è stato implementato un design comune.
Dal 2005 Nordea ha dato vita ad un unico portale per tutti i dipendenti.

Oggi la intranet di Nordea ha queste caratteristiche:

• 150.000 pagine
• 600 redattori
• contenuti in 6 lingue: Inglese, Danese, Svedese, Finlandese, Norvegese, Svedese-Finlandese (quest’ultimo credo sia un dialetto) (continua…)

Si è tenuto lo scorso 27 ottobre presso la Sede ABI di Milano il workshop Le Intranet bancarie, una giornata dedicata alla presentazione dei risultati dell?’Osservatorio Intranet Banche di ABI Lab e School of Management del Politecnico di Milano

(continua…)

Riporto un interessante articolo scritto dal mitico Gerry Mc Govern pubblicato su Webpronews dal titolo “Intranets Must Be Task-Centric“.

Il buon Gerry sintetizza il motivo per cui le intranet costruite su di un modello organizzativo (ovvero con i contenuti organizzati come le strutture organizzative dell’azienda) falliscono sempre ed illustra quindi perchè quelle costruite sui Task sono le più efficaci.

segue l’articolo in lingua orginale.

(continua…)

Paul Chin  un consulente IT e scrittore freelance http://www.paulchinonline.com/  analizza l’importanza di chi è alla giuda di una intranet e delle qualità che tale guida dovrebbe avere.  L’articolo in lingua inglese prosegue elencando i modi in cui il leader NON deve gestire il grande e multidisciplinare gruppo di vari professionisti cui è a capo.

(continua…)

Quando la conoscenza strutturata diventa opportunità di business

Riporto alcuni estratti di un articolo interessantissimo di Salvatore Roberto Capacchione pubblicato su Comunitazione

Il valore aggiunto di una corretta gestione della conoscenza aziendale è un valore ecomicamente rilevante, un fattore decisivo da mettere a bilancio tra le voci attive. (continua…)