In questo articolo parliamo di come promuovere l’adozione del wiki: se quindi nella puntata precedente abbiamo parlato di ‘people wiki’ patterns (e antipatterns), questo mese parliamo di ‘wiki adoption’ pattern.
Condividere la conoscenza all’interno di un gruppo non può limitarsi alla sola installazione di un wiki, ma deve necessariamente curare gli aspetti legati alla gestione delle persone ed evitare gli errori. Dopo le tecniche da perseguire per la gestione delle persone, questo mese ci concentriamo sulle tecniche per ottimizzare l’adozione del wiki all’interno della community (wiki adoption pattern).
Scegliere il wiki: caratteristiche del prodotto
Lo strumento che si vuole utilizzare deve soddisfare alcune importanti caratteristiche in modo da agevolarne l’installazione, la configurazione e l’uso: si consiglia quindi sempre di sceglierne possibilmente uno che sia “open”, che permetta di contare su una comunità di sviluppatori ampia e attiva, che disponga un un gran numero di estensioni e plugin.
Potendo scegliere è meglio optare per uno basato su una tecnologia che si padroneggia o che si conosce o per la quale si possono reperire risorse (programmatori) internamente o comunque in modo semplice: per esempio, per ogni modifica che si vuole apportare, poter eseguire regolarmente test di non regressione e continuous integration può essere un’arma vincente per consentire una rapida evoluzione dello strumento senza interrompere il servizio.
Purtroppo non sempre è possibile scegliere un prodotto basato su una tecnologia conosciuta in azienda: p.e. siamo una software house Java-oriented ma scegliamo un wiki in PHP perch� ha una grandissima diffusione e una popolazione di sviluppatori molto più ampia degli equivalenti scritti in Java.
Per l’installazione e attivazione del wiki, fra le varie tattiche che si possono mettere in atto, spesso viene consigliato un approccio a basso profilo in cui si parte dall’introduzione su ambiti circoscritti, eventualmente attivando il wiki su sistemi in hosting esterni e divulgando la sua presenza su un ristrettissimo insieme di persone disposte a giocare il ruolo di Champion o Gardner.
Spesso questo approccio “carbonaro”, che prende il nome di Flying Under the Radar (FUR) pattern o Wiki Ninja proprio perch� caratterizzato quasi dalla “segretezza”, ha, fra le altre cose, lo scopo di vincere le resistenze o comunque di ri-convincere le persone quando in azienda si sono avute già in passato esperienze magari non positive con strumenti web 2.0: l’obiettivo è di poter disporre nel più breve tempo possibile, di risultati dimostranti i vantaggi derivanti dall’uso del wiki, grazie alla collaborazione del ristretto gruppo di fedelissimi e alla focalizzazione su contesti piccoli e circoscritti (p.e. partendo dalla gestione di un ristretto insieme di informazioni o di progetti). Questo approccio, oltre a evitare di incappare nello scetticismo o peggio ancora nell’avversità degli oppositori (che ricordiamo rappresenta un particolare personaggio/pattern di cui si è parlato la volta scorsa), permette di scansare le pastoie burocratiche che si possono incontrare in azienda per poter realizzare un nuovo progetto e ottenere i fondi necessari per agire. Il punto fondamentale di questo approccio è capire quando è il momento di abbandonare la modalità “carbonara” per passare a una forma di azione ufficiale e pubblica, magari andando ad abbracciare gli strumenti che sono già presenti in azienda (momento in cui si organizzerà un evento di presentazione, magari un Barn Raising, come abbiamo visto il mese scorso).
Funzionalità abilitanti
Di seguito proponiamo alcune funzioni che probabilmente non appariranno sconvolgenti o rivoluzionarie ai più, ma che altresì potranno dare un valido aiuto per facilitare l’uso del wiki.
Automatic Index
Un sistema di Automatic Index è sicuramente una requisito utile: dato che il successo di un wiki è dato anche dall’interesse dei partecipanti di andare spesso a controllare i nuovi contenuti, un modo per creare interesse è quello di evidenziare il processo di crescita dei contenuti, magari con una pagina di indice generata e aggiornata automaticamente oppure con una o più pagine di panoramica generale (Overview Page) che potranno essere usate sia per la composizione della home page del wiki, sia per l’inclusione del wiki all’interno di altri elementi ad uso della comunità; partendo da questo tipo di contenuti generati automaticamente, infatti, si potranno comporre in modo semplice altri flussi informativi come canali RSS, stream di news per la pubblicazione su social network esterni al wiki, oppure contenuti gestiti opportunamente da un sistema CMS e inseriti in box appositi all’interno del portale aziendale, della comunità etc.
Content Alert
Una funzione molto usata è quella che risponde al nome di Content Alert, con la quale gli utenti sono avvertiti, tramite un messaggio in pagina, che il contenuto che stanno leggendo è incompleto, non corretto, parziale o che semplicemente necessita di una revisione. Wikipedia, ad esempio, fa un uso massiccio di questo meccanismo che permette sia di avvertire gli utenti dello stato del contenuto che vanno a visualizzare, sia di coinvolgerli nel processo di produzione.
Figura 1 – Messaggio di avvertimento su wikipedia: la pagina che si sta leggendo non può essere considerata completa, dato che mancano alcune informazioni. Si esorta il lettore a contribuire completando quanto manca.
email to wiki
La email to wiki, una delle funzionalità che personalmente preferisco, si basa sulla possibilità di “postare” contenuti direttamente tramite un messaggio di posta elettronica: al momento della iscrizione al wiki l’utente infatti riceve un indirizzo di posta destinatario (p.e. giovanni-124556@mail.mywiki.it) tramite il quale si potranno inviare contenuti in modo asincrono e senza necessariamente essere connessi al portale o senza dover usare un browser (anche se, a dire il vero, con i nuovi smartphone questa limitazione è sempre meno un problema).
Tale possibilità è molto comoda nel caso in cui il wiki sia protetto (p.e. dietro firewall, VPN etc.) oppure non sia possibile accedere al momento alla rete interna. Nella maggior parte dei casi si usa questa funzionalità per inviare contenuti multimediali (foto, video, re-twit etc.) prodotti ad esempio con uno smartphone. Se inoltre il wiki dispone di una versione mobile app (meglio se per iPhone e Android) si semplificherà enormemente il lavoro degli utenti esterni tanto da poter dare grosso impulso al successo del wiki stesso (vedi pattern Poker più avanti).
Tags
Meno rivoluzionaria la possibilità di poter applicare tag, ossia etichettare in vario modo i contenuti e assegnare delle parole chiave predefinite dal sistema o proposte direttamente dall’utente, al fine di classificare i contenuti stessi: questa funzionalità potrà poi essere associata a un qualche motore di ricerca (full text, tag-search o semantico) o alla classica tag cloud.
Se si sceglie di usare un approccio “aperto” tutti gli utenti potranno inserire i contenuti a loro piacimento, e si potrà in un secondo momento imporre un flusso autorizzativo da parte di un utente con ruolo editor; utile se non indispensabile in questo caso un qualche meccanismo di versionamento dei contenuti al quale si potrà associare un Selective Rollback che permette di eliminare solo alcuni contenuti o determinate versioni di una pagina.
Quoting
Un modo molto efficace per coinvolgere le persone alla discussione su una pagina del wiki, o anche semplicemente alla visione di un particolare contenuto, è dato dalla possibilità di “quotare” ossia “citare” altri iscritti alla comunità del wiki (pattern Quote Partecipants) relativamente a un determinato passaggio o paragrafo del wiki. Sarà capitato a molti lettori di ricevere un messaggio da Facebook “il tuo amico Tizio Caio ti ha citato nel post alla pagina…” e di correre poi a controllare di cosa si trattasse. In molti casi gli utenti di Facebook usano taggare amici e conoscenti su fotografie anche se non sono presenti realmente nella foto, con il semplice scopo di voler attirare la loro attenzione e farli andare a vedere quello specifico contenuto (p.e. “ecco una bellissima torta che voglio far vedere/commentare ai miei amici.”).
Fate sempre attenzione a non abusare di questo meccanismo per non infastidire gli amici o anche semplicemente per non renderlo del tutto inefficace. Inoltre ricordate che l’auto-tagging (Facebook ad esempio è in grado di riconoscere automaticamente se state inserendo il nome di un vostro amico e sostituisce il plain text con il link della persona) a volte può essere dannoso se non si vuole infastidire la persona indicata o semplicemente non si vuole comunicare al mondo che “Mario Rossi è stato taggato in un post che parla di questo o quello”.
Quella del quoting è quindi una importate funzionalità, ma della quale è bene fare un uso moderato e intelligente.
Obsolescenza
La maggior parte della documentazione tecnica che il wiki si propone di raccogliere e organizzare ha un preciso ciclo di vita, al termine del quale finisce spesso per divenire inutile o peggio ancora errata. In tale contesto, al fine di comprendere la validità di quello che sta leggendo, può essere utile per il lettore poter verificare la data di pubblicazione e la data di validità della pagina del wiki: per questo motivo è utile attivare il cosiddetto pattern Built-in obsolescence offrendo all’autore la possibilità di specificare alcune informazioni temporali all’inserimento di nuovi contenuti. Ad esempio si potrà specificare la data di creazione, se il testo ha una scadenza prefissata, se ha un ciclo di approvazione (p.e. fino al giorno X, il documento deve considerarsi in stato di draft), oppure se ha una obsolescenza intrinseca (p.e. un post tecnologico probabilmente avrà valenza per il periodo di vita di tale tecnologia, mentre uno di processo o di project management avrà vita più lunga). Ad esempio ogni articolo di MokaByte, che non è un wiki ma in questo contesto non cambia molto il concetto, ha una data (mese) di pubblicazione, ma non ha nessuna data di scadenza: è lasciato al lettore di valutare la valenza di quanto scritto anche dopo anni dalla pubblicazione. Si noti che inserire le date di pubblicazione in un post in genere non ha un effetto diretto sull’aumento della partecipazione del pubblico al wiki, mentre la sua assenza può avere conseguenze negative agli occhi del lettore: si pensi ai molti quotidiani online che spesso non permettono di ricavare la data di pubblicazione, se non deducendolo dall’URLcosa che può indurre nel lettore il dubbio circa la validità di quanto sta leggendo.
Figura 2 – Alert message relativo alla obsolescenza di un post.
Sebbene nella gestione di un wiki l’aspetto della periodicità delle pubblicazione non sia importante (aspetto invece tipico di un magazine online come MokaByte) e anzi in genere si cerchi di organizzare il lavoro proprio in maniera del tutto libera da scadenze e date di pubblicazione, si tenga presente che creare una qualche attesa nel lettore (p.e. il lunedì esce il report sul wiki del gruppo di sviluppo) può migliorare il rapporto dell’utente magari agendo su una qualche forma di fidelizzazione.
Organizzazione della struttura
Nel caso in cui il wiki sia a supporto di una organizzazione piuttosto grande si può pensare di riorganizzare la struttura in funzione dei contenuti o degli utenti che vi partecipano. Questo tema è piuttosto dibattuto (come dimostrano i molti commenti sia positivi che negativi che si trovano sul Wikipattern.com relativamente al pattern Wiki Spaces); in questo caso possiamo certamente registrare che non esiste una soluzione universalmente accettata e valida per tutti i casi.
Lo scopo delle differenti varianti che si possono adottare è quello di dividere il mega-wiki in sotto parti al fine di contenere meglio i diversi argomenti e di facilitarne così la consultazione o l’inserimento di nuovi.
Il prezzo da pagare (per questo molti mettono in guardia dal non abusare di questo genere di ri-organizzazione) è quello di una frammentazione della conoscenza a discapito proprio di una maggiore semplicità nella condivisione delle informazioni.
Wiki Buckets
Una delle soluzioni più semplici è quella di partire con un approccio soft al problema, introducendo i cosiddetti Wiki Buckets, veri e propri raccoglitori di contenuti e argomenti simili la cui presenza non altera la struttura del wiki: un bucket infatti è una specie di sovrastruttura che offre una vista differente rispetto alla navigazione tradizionale che rimane disponibile e sempre utilizzabile. L’utente infatti potrà utilizzare il wiki come di consueto ma anche andare a cercare i contenuti in determinate aree tematiche semplificando il processo di ricerca e inserimento. Il vantaggio del bucket è quello di permettere l’esistenza di un solo wiki (un unico albero di indicizzazione, un unico sistema di permessi e ACL, una anagrafe dei nomi delle pagine centralizzate) ma al contempo di consentire la nascita di sotto wiki virtuali che potranno essere attivati o disattivati in maniera non distruttiva rispetto al wiki sottostante.
Figura 3 – Una bellissima foto di un “bucket wheel”: non c’entra molto con i bucket di cui si parla nell’articolo, ma la foto era bella e si è pensato si inserirla lo stesso.
Wiki Space
Se necessario, una evoluzione più forte del bucket è quella che prevede di riorganizzare il wiki in tanti spazi di lavoro differenti (Wiki Space) che dal punto di vista operativo sono equivalenti a delle installazioni differenti e indipendenti fra loro. L’utilizzo dei wiki space permette di risolvere il problema del sovraffolamento delle pagine nel caso in cui si debba servire una organizzazione veramente molto grande in cui il numero degli utenti superi le migliaia. L’utilizzo infatti di una sola istanza di wiki può dar luogo a problemi di pagename-clash (conflitto sul nome delle pagine) o duplicazione dei contenuti simili; andando a dividere il wiki in sotto-wiki si dovrà ovviamente optare per una organizzazione logica volta a ordinare le aree tematiche (ovvero p.e. wiki architetturale, wiki applicativo, wiki funzionale, etc.) in modo che si riesca a limitare il problema di eventuali ripetizioni. Nonostante queste raccomandazioni la scelta di optare per una suddivisione del wiki in sotto-parti è una questione quanto mai dibattuta come confermano i molti commenti alla relativa pagina su [1], e che riportiamo qui per chiarezza:
“[…] I have wrestled with this issue myself and I‘ve blogged about it internally a bit. My organisation is project based and team based. I work in multiple teams and generally change project every week or so. If we had a different space for every project and team we would end up with thousands of spaces many of which would just end up dormant. We currently operate with thousands of different databases and the problem is that there is very little collaboration and knowledge sharing between teams. The beauty of a wiki is that it brings everyone within one database and potentially allows everyone to see what everyone else is up to.”
“[…] Wouldn‘t it be better to create multiple spaces and also different groups and then give some spaces to the same group of people. Maintenance effort can be reduced by changing an user‘s membership to the group and all the spaces access will be updated accordingly.”
“[…] dealing with ‘real word‘ organizations of more than a couple hundred people, where you have multiple axes that divide people (site/country/division/department/project/role or specialty/business unit) and yet most people work on teams accross several of these axes. Therefore the creation of a space for every permutation, and granting individuals ‘broadest possible access‘ to each of these permutations, is both an awesome administrative burden and potentially not even feasible — we would have more actual groups than actual employees and perhaps none of the projects would ever reach critical mass. On the other end of the spectrum, if we try to jam everything into one or a few spaces, we definately run into turf wars, non-safe zones, name conflicts, philosophical divides, managerial lock down, not to mention legitimate permission and access control issues.
Typically, the spaces that are ‘naturally‘ made are indeed project centric on a fairly small scale, with one project per team adopting the space for a particular use, but then they are locked down, or isolated virtually, and there is little cross team sharing of practices and content and much duplication of effort. In fact, we have some teams that have multiple spaces, each for a different role but essentailly made up of the same people! We don‘t want to limit these natural seeds, as this is how the wiki will grow, but we do want to encourage them to be tied together and we do want to prevent some of the forseen administrative burden we will encounter if the pattern of ‘one space per team/activity‘ continues.”
“[…] My own view is that this is actually an anti-pattern! It‘s a mistake to lose out on cross-organisational collaboration and mindshare, just because of a few page naming issues.”
“I still stick to this pattern. OK, it does not make any difference if you are using a sub-web/wiki oder a separate wiki. To differentiate information into different Wikis, the lifetime of the information needs to be taken into account (next to the access rights) . Take the team / project example mentioned before:
– The team (People, corporate structure, general regulations, lunchplan) is something that will last longer than the projects. –> This forms a group of its own.
– The projects have a limited lifetime, so they also form a group of their own.
Nel caso in cui si utilizzino wiki differenti, nel caso di cross link fra istanze diverse, sarà bene utilizzare un qualche meccanismo di Interwiki links (che è una feauture spesso offerta dalla installazione stessa del wiki). Potrà bastare anche solo una attenta politica sui nomi delle pagine usando sempre dei permalink.
Adoption
In questa area ricadono quei pattern che cercano di rendere il wiki lo strumento di lavoro indispensabile, cercando di farlo diventare il baricentro del lavoro quotidiano degli utenti della community, semplificando il lavoro di intervento di editing e aggiunta.
Nel primo ambito ricadono certamente alcuni noti pattern come il Launch Menu, il Wiki Poker o il Magnet
Launch Menu
Questo pattern parte dal presupposto di ricavare nel wiki una pagina che contenga un contenuto del quale sia nota l’importanza, l’utilizzo ma anche l’alta variabilità: si pensi al caso del menù culinario di una mensa aziendale, menù che in genere verrà letto da tutti i dipendenti (anche solo per curiosità) e che presumibilmente (o almeno si spera) cambi con frequenza giornaliera. Usare un wiki semplifica lato cucina l’inserimento dei contenuti (il wiki è, o è bene che sia, facile da usare) e ne permette una facile consultazione del menu da parte di tutti; dall’altro attira tutti gli interessati ad andare su una pagina del wiki il cui indirizzo è sempre lo stesso (possibilmente ricavabile con facilità in maniera mnemonica, come www.mycompany/wiki/menu)
Magnet
Strettamente collegato al precedente, è il pattern Magnet che suggerisce di individuare tutte quelle risorse di pubblico interesse all’interno della comunità aziendale e di rimuoverle dai luoghi dove sono consultabili ad eccezione del wiki; lo scopo è quello di rendere il wiki l’unico punto dove trovare tutto quello che serve e di amplificare in questo modo il traffico indiretto sullo strumento: ovvero si deve andare sul wiki per cercare una qualche informazione e in questo modo si rende lo strumento sempre più familiare tanto che lo si userà per ogni altra informazione che si reputi interessante per se stessi o per gli altri. Attenzione a non cadere nell’errore di eliminare troppe informazioni che invece dovrebbero stare in loco; si fa in questo caso l’esempio delle istruzioni dell’estintore antincendio: va bene raccogliere tutti i libretti delle istruzioni delle varie macchine dell’officina in un unico cassetto, ma l’estintore dovrebbe averle attaccate sopra per un pronto e immediato utilizzo.
Poker
Infine il pattern Poker ci dice che, al fine di rendere il wiki uno strumento veramente familiare, quasi indispensabile, è buona cosa predisporre delle aree in cui riportare contenuti ludici (non legati al business del wiki), sociali, di svago. Qui potremo riportare il punteggio del torneo di poker (o di calcetto nella versione italiana), le foto di eventi, feste, eventi sportivi legati alla comunità e così via. Il pattern Poker, unitamente al Quote-Partecipant e alla possibilità di disporre di un canale mobile farà del wiki la versione interna del Facebook che tutti usano a casa (si dice che i social networks tematici saranno il prossimo step a cui dovremo presto abituarci).
Masters and Scribes
Più la complessità del sistema cresce, più aumentano le conoscenze necessarie per poter gestire con completezza e cognizione di causa un determinato argomento. Seguendo tale trend, diventa sempre più difficile trovare qualcuno che conosca molto bene un argomento e che lo sappia raccontare o scrivere altrettanto bene. Può capitare infatti che per descrivere un qualche tema poco noto ci sia necessario più di un’ora, mentre potremmo raccontare in 5 minuti qualcosa su cui lavoriamo da anni (sintesi e capacità di concentrazione sui temi importanti sono più semplici quando si è veramente “dentro” un determinato argomento).
Per questo spesso si consiglia di organizzare delle sedute di Masters and Scribes in cui chi possiede la conoscenza racconta e chi sa scrivere inserisce le informazioni nel wiki: in fondo questo è il tipico pattern di chi svolge regolarmente attività di raccolta informazioni, analista funzionale o simile. Saper fare le domande giuste, saper scrivere, saper filtrare e sintetizzare è una capacità molto importante. In questo pattern, gli “scribi” sono forse una delle ricchezze più grandi che si possono avere in azienda.
Figura 4 – Un antico esempio di messa in pratica del Master and Scribes in un bassorilievo romano che descrive una scena di istruzione con un maestro che detta ai suoi allievi.
Per semplificare ulteriormente il lavoro di inserimento anche per un pubblico esperto, si consiglia di usare pagine di wiki pre-strutturare (Template o Scaffold pattern) cosa che permette di velocizzare molto il lavoro: in questo caso si può pensare di inserire dei template predefiniti nel wiki da usare in funzione del tipo di argomento, cosa che consente anche di creare una certa varietà sulla consultazione dei contenuti.
Intentional Error
L’inventore del primo wiki in rete, al fine di monitorare il flusso delle informazioni e di misurare il livello di diffusione delle cose dette nel wiki verso l’esterno, propose di provare a inserire volutamente informazioni errate (Intentional Error pattern), azione da fare sempre sotto strettissimo controllo per non generare junk-wikies. In tal caso anche la velocità di intervento e correzione di tale informazione errata è un fattore molto importante da valutare: questo fattore a volte viene considerato un vero e proprio KPI (Key Point of Interest) sul quale si possono definire delle metriche di valutazione e crescita della adoption da parte della comunità del wiki. Questo ricorda molto quello che accade in apicoltura, dove fra coloro che allevano api con la volontà di individuare i migliori ceppi genetici, si valuta la velocità con cui le api di una famiglia intervengono nell’eliminare larve uccise dall’apicoltore (spesso si usa azoto liquido per uccidere alcune larve del telaio oppure si forano le cellette con uno spillo, da cui “pin-test”): questo è un aspetto importante per selezionare quelle famiglie con una spiccata propensione igienica, specialmente in questo periodo in cui le api di tutto il mondo sono sempre più minacciate dall’uomo.
Massa critica
In definitiva uno degli aspetti essenziali per fare in modo che il wiki inizi a “funzionare” è dato dal poter disporre di una massa critica di contenuti, cosicche’ successivamente anche altri meccanismi possano attivarsi con maggior successo (p.e. il Viral pattern non funziona bene se non ci sono abbastanza cose nel wiki).
Anche dal punto di vista delle persone, è noto che sia necessario un numero considerevole di contenuti per fare in modo che le persone abbiano interesse nel partecipare e sopratutto nel tornare a visitare il wiki. Per iniziare, si possono utilizzare alcuni repository di contenuti già presenti all’interno della comunità, effettuando una operazione di importazione nel wiki.
Per velocizzare questa prima fase si potranno invogliare le persone a contribuire tramite piccoli contenuti (Small Chunks Contribution) magari seguendo il mantra “1-minute-per edit” dove si deve spendere al massimo un minuto per creare un draft di pagina con una idea o concetto in bozza.
Si agisca molto sul numero dei partecipanti in modo che i nuovi arrivati si sentano parte di una comunità (i pattern sociali di cui sopra potranno aiutare molto in questo caso), lasciando che i vari Champion e Guru guidino la comunità.
L’utilizzo di un portale a supporto di una community online (con tutti gli strumenti sociali che vanno di moda in questo periodo) potrà dare un valido contributo al lavoro dei vari leader della community. L’uso di una TodoList pubblica con l’elenco dei contenuti che ancora devono essere completati o redazionati potrà spingere alla partecipazione volontaria nel completare alcune parti del wiki dove i vari membri si sentono più a loro agio.
Conclusione
In questo articolo abbiamo visto alcune delle più importanti tecniche di gestione del wiki, volte alla adozione dello stesso. Come si è potuto notare, nella maggior parte dei casi si tratta di consigli piuttosto semplici e forse banali, ma il poterli consultare di seguito e in un contesto comune può certamente offrire alcuni spunti interessanti all’attività di gestione del wiki. Nella prossima parte di questa serie parleremo di adoption antipattern e proporremo alcuni importanti raffronti con l’esperienza fatta in MokaByte.
Riferimenti
[1] Wiki patterns