Home » Archivi per Stewart Mader

lug
9

La vera sfida dei wiki è entrare nel flusso

Un bell’articolo pubblicato sul blog di Stewart Mader fa il punto sulle dinamiche organizzative tipiche dei wiki interni, e si focalizza su una questione – a dire il vero – assai dibattuta tra gli smanettoni che si occupano di ‘sta roba, ovvero la distinzione tra “fuori-dal flusso” e “dentro-il-flusso”.

L’articolo si intitola significativamente “In-the-Flow & Above-the-Flow: Two Types of Wikis at Work” ed è stato scritto da un vicepresident si Socialtext, un big vendor del settore.

Di che si tratta? E’ presto detto: il senso dell’articolo è che se consideriamo i wiki unicamente come oggetti che si pongono al di fuori dei normali flussi di lavoro (ad esempio come enciclopedie, indici, repository o altri spazi di publishing  destinati a una conoscenza incrementale sganciata dall’operatività) la dinamica di questi oggetti sociali rischia di assestarsi su una bassa percentuale di partecipanti molto motivati, lasciando da parte tutti gli altri.

Cito dall’articolo:

Above-the-flow wikis are used lightly (when at all) by large groups of people. Many are encouraged to participate, but participating is rarely an urgent or critical-path activity. Lurking is extremely common, and the bulk of content comes from <5% of users who are either personally invested in the success of the project or just love to publish. Wikipedia works because of the law of large numbers: A small percentage of a huge number is still a large number.

Diverso è il caso dei wiki usanti dentro i flussi di lavoro: qui troviamo piccoli tema di persone che invece di usare la mail o cartelle di rete condivise utilizza uno strumento di colalboration per portare avanti le normali attività. Senza troppi clamori.

La differenza è sostanziale, e può essere rappresentata – classicamente – in questo modo

due tipi di wiki

Nel primo caso abbiamo wiki con grande partecipazione di – tutto sommato – poche persone, mentre nel secondo caso avremo tanti wiki a cui partecipano poche persone ciascuno (i membri di un team interfunzionale, di un dipartimento eccetera) e che nel complesso coprono però gran parte dell’azienda.

Questa è la vera sfida, ed è naturalmente molto più complicata della creazione di un’enciclopedia interna, perché

  • richiede la partecipazione di tutti, a diverso titolo
  • cambia il modo di lavorare di tutti, a diverso titolo
  • inaugura dinamiche solo parzialmente prevedibili

E’ una differenza sostanziale,  e voglio aggiungere una cosa: le grandi rivoluzioni avvengono quanto tante persone, in modo più o meno coordinato passano individualmente ad utilizzare nuove tecnologie spesso per scopi eterogenei ed individuali (pensate alle mail) e credo che potremo dire di avere fatto un reale passo in avanti davvero solido solo quando saremo riusciti a catturare la coda lunga dei processi operativi all’interno delle nuove dinamiche collaborative.

giu
26

Altre risorse sui wiki interni

Recentemente Matthew C. Clarke ha pubblicato su Boxes and Arrows un bel caso di studio che raconta il loro percorso di adozione dei wiki interni nella sua società, la Corvu.  Stiamo parlando di migliaia di persone che si occupano di Software per aziende (performance management).

Il loro problema era trovare un sistema per ottimizzare la redazione di documentazione tecnica che poi viene rilasciata al cliente, su ciascuno dei prodotti commercializzati così come sui prodotti in fase di sviluppo.

L’articolo si intitola significativamente Control and Community: A Case Study of Enterprise Wiki Usage, e vi consiglio caldamente una lettura attenta, perché entra nel merito di molte questioni concrete quali i permessi, le revisioni, il controllo, le motivazioni individuali che stanno dietro ad un progetto collaborativo di questo tipo.

Wiki Workflow Diagram

Segnalo solo alcuni spunti:

  • Il senso di appartenenza come veicolo per una anarchia sostenibile nei wiki pubblici
  • La moderazione come elemento importante nei wiki aziendali, per gestire l’alto numero dei contributori che spesso non hanno vincoli reciproci
  • La necessità nei wiki interni di gestire le risorse centralmente, evitando il proliferare di wiki autonomi di singoli settori (questo è un problema loro; in Italia, ma quando mai?)
  • Il vantaggio di creare una navigazione familiare e comprensibile (nel loro caso era l’elenco dei prodotti)
  • L’opportunità di segnalare in evidenza chi è l’autore primario della singola pagina, ovvero il creatore
  • in alcuni casi la necessita di avere pagine che solo un gruppo scrive (nel loro caso gli ingegneri di Ricerca & sviluppo) e gli altri possono solo commentare
  • La ricerca costante di sponsorship al più alto livello possibile
  • Lavorare con i champions
  • Identificare le persone-chiave che devono contribuire dando cose di qualità e dando anche autorevolezza allo spazio
  • Nel loro caso, l’importanza di coinvolgere dei revisori finali del materiale che poi va in mano ai clienti
  • L’importanza dell’integrazione con LDAP e del single sign-on
  • Ovviamente le funzionalità WYSIWYG
  • La possibilità di aggiungere allegati documentali alle pagine
  • L’importanza della creazione di una massa critica di contributori e di contenuti
  • L’importanza di imparare a spedirsi link invece di contenuti. Se qualcuno chiede qualcosa via mail la persona risponde creando una pagina wiki e poi mandando il link

Insomma, leggetevi l’articolo perché nel vale la pena.

Risorse Wiki

Steward Mader elenca una serie di prodotti per enterprise wiki che rispettano i requisiti necessari per creare wiki in azienda. Il problema è che sono tutti proprietari. A parte uno, ovvero  Mindtouch – Deki, l’unico prodotto distribuito anche in open source e che è abbastanza solido (per Mader) per le necessità aziendali.

Andatevi comunque a leggere la scheda dedicata a Mindtouch su Wikimatrix.

Altri articoli interessanti (tutti tratti da FutureChanges)

E per finire…

una bella presentazione su Slideshare dedicata al progetto wiki della John Hopkins University

mar
24

Per cosa usare i wiki interni? Ecco qualche idea

Sembra stia diventando un po’ un tormentone: per che cosa possiamo usare queste piattaforme di collaborazione? In realtà la domanda è un po’ forviante, a mio parere, perché queste tecnologie hanno potenzialità – e ambizioni – più vaste della semplice applicazione locale.

Quello che voglio dire è che un wiki è un oggetto talmente plastico che tende a sostituire, come nuovo paradigma (tanto per fare le persone colte…), e a sovrapporsi a interi processi operativi, riconfigurandoli. In realtà è la cosa più vicina che conosca ad una general pourpose technology (come l’energia elettrica, tanto per capirci), capace di accogliere istanze, attività, processi assai eterogenei.

Detto questo, vi segnalo l’utlimo post di Nicolò Tosi, dedicato proprio ad esaminare i possibili usi dei wiki in azienda.

Nicolò ne elanca 10

  • Sviluppo software
  • E-Learning
  • Project Management
  • Informazioni generali e Knowledge Management
  • Comunità di pratica o user group
  • Ad-hoc collaboration
  • Supporto tecnico
  • Marketing e Customer Relationship Management
  • Resource Management
  • Ricerca e Sviluppo

Ma come ho detto è veramente difficile creare una tassonomia, anche solo provvisoria: ogni elenco sarà sotituito dalla Nuova Cosa Nuova che qualcuno si inventerà.

Nel frattempo vi segnalo un nuovo articolo di StepTwo dedicato al caso della intranet di EUMETSAT, che ha fatto di recente ampio uso sia dei forum che dei wiki per la collaborazione tra i dipendenti. Il risultato sembra molto interessante:

Screenshot wiki EUMETSAT
Screenshot wiki EUMETSAT

Infine, grazie a Wekey e a Stewart Mader ecco due presentazioni di due wiki aziendali, rispettivamente di SAP e Seibert.

ott
25

Usare i wiki per i report

Per quelli che ancora pensano ai wiki interni in termini di Wikipedia..

E già che ci siamo beccatevi anche l’articolo di S. Mader: “5 usi concreti dei wiki dentro l’organizzazione“.

Ciao