Si conclude questa miniserie dedicata alla gestione delle comunità wiki analizzando i tipici ostacoli che si possono frapporre per il successo di un wiki. Esistono infatti dei veri e propri ‘anti-pattern’ che si instaurano per contrastare l’adozione di uno strumento di conoscenza collaborativa: conoscerli significa prevenirli e limitarne l’impatto.

Dopo aver visto quali possano essere le iniziative di successo da mettere in atto per promuovere lo strumento wiki nell’ambito della comunità di competenza, questo mese concludiamo con alcune considerazioni legate ai possibili problemi che si possono verificare che potrebbero minare il successo dell’iniziativa: una scarsa adozione dello strumento e, peggio ancora, un affievolimento delle attività della community stessa.

Quello che vedremo in questa puntata è per molti aspetti una rivisitazione di alcune cose già affrontate nei mesi scorsi, anche se in questo caso cambieremo il punto di vista della trattazione focalizzando l’attenzione su ciò che è meglio non fare e sugli errori da evitare.

Wiki sempre e comunque

Il processo di adozione del wiki dovrebbe essere vissuto con naturalezza dai vari partecipanti, che dovrebbero iniziare a usarlo non per un preciso ordine dall’alto, ma per personale convinzione dei concreti benefici derivanti dal suo utilizzo.

Per questo motivo si dovrebbe sempre cercare di tenere sotto controllo l’umore dei vari componenti il gruppo di lavoro in modo da prendere coscienza immediatamente sul nascere di segni di avversione o insofferenza per lo strumento o per alcune nuove funzionalità che si stanno introducendo. In caso si riscontrassero problemi, sarà bene rallentare il numero e la frequenza dei rilasci delle nuove funzionalità e stabilizzare la piattaforma sul set massimo di funzionalità che garantisca confort di utilizzo a tutti i membri della community.

In questa fase si potrà sfruttare il tempo valutando il tasso di confidenza e il reale utilizzo del wiki o di alcune sue funzionalità specifiche: una buona pratica potrebbe essere quella di individuare i punti critici o le funzionalità meno note o usate, e abilitare sessioni di formazione; la formazione dovrebbe essere sempre poco formalizzata e strutturata, per non dar adito a creare che “tanto c’è qualcuno che mi toglierà di impiccio anche se non uso o uso male il wiki”: sì a qualche evento estemporaneo, no a calendari di formazione o corsi istituzionali. Potrà essere utile invitare i membri che hanno difficoltà in sessioni di lavoro collaborativo, oppure organizzare eventi di tipo Barn Raising (vedi primo articolo della serie) in cui si possa familiarizzare con lo strumento o con le parti che hanno evidenziato le maggiori criticità; si potrà qui finalizzare il lavoro nella realizzazione di alcune pagine specifiche (p.e., per realizzare la propria pagina personale).

Alcuni antipattern e le loro soluzioni

Chi usa un wiki da molto tempo sarà spesso portato a considerarlo uno strumento di uso quotidiano anche per svolgere compiti apparentemente inusuali; se da un lato questo potrà aumentare la produttività di alcuni, potrebbe al contempo creare disagio agli altri, fornendo un alibi a non intervenire.

Ad esempio, per velocizzare la realizzazione della base di conoscenza con le informazioni che si vogliono inserire, si finisce a volte con utilizzare il wiki come un raccoglitore di appunti evoluto o come strumento di prototipizzazione della base di conoscenza; l’idea è quella di creare prima lo scheletro di base, esempio creando una serie di pagine bianche collegate fra loro in modo da creare l’ipertesto, e solo in un secondo momento procedere con l’inserimento dei contenuti.

Per alcuni questo modus operandi non permette in realtà di velocizzare di molto il lavoro, ma viene visto soprattutto come un modo per coinvolgere gli altri: “Guardate… ho creato lo schema dei contenuti; per adesso ci sono pagine bianche o appena abbozzate; lascio agli altri il completamento dei contenuti”. Purtroppo a volte accade esattamente il contrario, visto che per gli altri può esser vissuto come un modo di “subire” il wiki o l’operato dei “bravi contributori” (champion), andando ad amplificare la sindrome da foglio bianco (antipattern: White page).

Oppure potrebbero insorgere comportamenti che portino a trovare una giustificazione nel non fare alcuna modifica al wiki, con la scusa di non voler invadere l’orticello di altri. Il concetto che si radica è: “Questa pagina l’ha fatta Tizio e non vorrei essere invadente; meglio se la completa lui. Quella l’ha fatto Caio…” e così via. Nel caso in cui la persona che ha creato la pagina, o ha la responsabilità di seguire determinate sezioni del wiki, ricopra un ruolo di alto livello nella gerarchia o abbia una riconosciuta autorevolezza nel gruppo, l’effetto di blocco da parte degli altri potrà essere ancor più evidente (antipattern: Manager Lockdown).

Tutti questi problemi essere facilmente superati agendo sul gruppo (frenare l’entusiasmo di un champion troppo propenso alla iperproduzione “letteraria”), ma anche usando alcuni semplici trucchi sullo strumento: l’inserimento di pagine pre-compilate o di template che agevolino la compilazione può essere un buon modo per facilitare il superamento di questo blocco. Nuovamente si può ricorrere a sessioni di lavoro di gruppo (l’ormai noto Barn Raising) o semplicemente creare mini-staff di lavoro che si occupino di temi specifici.

Il problema del blocco reverenziale (Manager Lockdown) si può superare in vari modi, ad esempio lavorando sugli eventi sociali per limitare gli effetti della organizzazione gerarchica, o mettendo in luce che anche chi sta in alto ha gli stessi dubbi e difficoltà nel trovare soluzioni a problemi, nello scrivere sul wiki.

Continuiamo di seguito ad analizzare alcuni antipattern nelle situazioni in cui si vengono a manifestare, mettendo in guardia sulle condizioni che portano alla loro insorgenza e suggerendo le possibili soluzioni praticabili.

La palestra di prova

Una soluzione che erroneamente talvolta viene introdotta per consentire di prendere pratica con lo strumento e superare la paura di iniziare a lavorare con il wiki è quello du predisporre pagine o sezioni o interi wiki di prova, isolate dal resto (antipattern: Sandbox) e che quindi non hanno alcuna attinenza con il tema del wiki ma che hanno lo scopo di provare a creare, scrivere, modificare, linkare etc.

Se questo da un lato crea un senso di sicurezza contro gli errori che si potrebbero creare sul “wiki vero” , dall’altro può amplificare la paura di andare in scena con un pubblico vero. Di fatto distrae dal lavorare sui contenuti veri (dove i concetti di vero o falso sono già di per s� inutili) e potrebbe far passare il concetto che il wiki è uno strumento complesso che richieda una fase di addestramento prima di passare a scrivere contenuti veri e propri. Ricordate che i wiki spesso hanno meccanismi di storicizzazione dei contenuti, che quasi mai nulla è perso (o scritto) per sempre e che, al limite, le operazioni pericolose (cancello una pagina) possono essere fatte con l’ausilio di un utente esperto che non dovrebbe fare il lavoro al posto di, ma eventualmente a fianco di.

Si ricordi a tal proposito che i moderni wiki hanno strumenti di audit più o meno sofisticati (che ci dicono chi ha fatto cosa e quando): è bene far comprendere che queste funzionalità non sono altro che comodi ausili a supporto per comprendere meglio l’evoluzione del contenuto. Non devono mai essere presi a scusa per non fare o essere considerati una barriera che blocchi l’iniziativa dei singoli.

Oppositori, sabotatori e distruttori

Le persone coinvolte nel processo di adozione graduale e incrementale sono molto importanti sia in un senso che nell’altro. Se più volte abbiamo citato la necessità e utilità di incentivare la partecipazione alla comunità tramite il coinvolgimento di alcune figure leader come i champion o il guru (che, usando una metafora ciclistica, devono “tirare il gruppo”), non si deve mai dimenticare che in questo variegato mondo troveremo anche persone che per i motivi più disparati (convenienza personale o “politica”, diffidenza verso l’innovazione, ignoranza dell’iniziativa) si troveranno a opporsi al wiki e al suo successo.

“Vandalismo”

In passato abbiamo parlato degli atti di “vandalismo”, ovvero attività volte all’inserimento volontario di contenuti inesatti, modifica di parti con l’intento di alterarne il significato, e così via. Gli atti di vandalismo (e quindi di conseguenza i “vandali”) possono essere facilmente individuabili con strumenti tecnici (tramite un aumento dei livelli di restrizione o per mezzo di ACL più definite) oppure con un maggior controllo sul processo, cosa questa che è preferibile perche’ a volte troppi controlli e limitazioni potrebbero avere l’effetto di inibire anche chi non ha affatto propositi vandalici.

In definitiva si ricordi che la protezione contro gli atti vandalici tramite la creazione di controlli esterni (regole di creazione o di modifica) può dar luogo a un eccessivo over-control che rischia di rallentare o bloccare del tutto il crescere del wiki e della comunità che ci ruota intorno. Si finisce per incorrere nell’antipattern OneWayStreet: il flusso diventa a senso unico ed è poco collaborativo poich� alcuni scrivono e altri leggono e basta.

“Bullismo”

Purtroppo i vandali non sono l’unica figura negativa di cui tener conto. Esistono pericoli più subdoli, meno evidenti ma altrettanto dannosi. Uno di questi è rappresentato dall’antipattern Bully (letteralmente “bullo” o “prepotente”). Il bully agisce spesso non direttamente contro il wiki: esso per lui non è che uno strumento, ovvero il banale effetto finale di un qualcosa di più grande che rappresenta ai suoi occhi il vero nemico da combattere. Un bully piuttosto agisce contro le persone della comunità, criticando e ironizzando sulle attività della stessa, ridicolizzando il lavoro svolto dai singoli; a volte si porrà con un atteggiamento apparentemente favorevole o disponibile ma nei fatti sarà scettico o contrario al wiki, per esempio non usandolo in favore dello scambio di messaggi di posta, memorizzando in locale tramite documenti sul proprio PC informazioni e contenuti che invece era bene condividere, oppure usando un altro strumento personale di note (note-taking tool alla Evernote, per capirsi).

Più alto è il ruolo ricoperto nella gerarchia del Bully maggiore sarà il danno che potrà apportare e più difficile sarà cercare di convincerlo o al limite a tamponare e rendere inoffensive le sue azioni.

Il bully non agisce mai con il preciso scopo di rompere la scatola per il solo gusto di farlo. Spesso è animato da precise motivazioni personali: rancori pregressi, incapacità di riconoscersi nelle dinamiche di gruppo che si stanno creando, gelosia per i nuovi legami che stanno nascendo e che magari lo vedono escluso. Un motivo potrebbe risiedere nel fallimento passato di una sua iniziativa analoga e quindi agirà per facilitare nuovamente l’insuccesso dato che non vuole che qualcuno riesca dove lui ha fallito. Un altro motivo potrebbe essere legato al fatto che il bully abbia evidenziato la necessità di risolvere problemi diversi (ma senza mai avere avuto la voglia o la capacità di provare a risolverli) da quelli sui quali la comunità si sta orientando. Se il bully è anziano potrebbe avere un atteggiamento del tipo: “Ormai ho visto tanta acqua scorrere sotto i ponti e non credo in questa iniziativa che si presenta come l’ennesima per risolvere un problema che qui non si ha la reale volontà di risolvere”.

Tutti questi atteggiamenti possono essere devastanti sia per gli effetti diretti sia perche’ spesso molto contagiosi. La cosa più importante da fare è cercare di riconoscerli prima possibile, a esempio parlando con le persone, osservandone i comportamenti, usando strumenti di comunicazione alternativi che garantiscano la riservatezza e permettano di aprirsi e far venir fuori la verità; in questo senso la comunicazione scritta virtuale è meglio della chiacchierata a voce, e, in tale ambito di scrittura, l’instant messaging è ancor meglio della mail.

Scetticismo

In genere non è difficile riconoscere uno scettico o un oppositore, visto che potrebbe essere egli stesso, in cerca visibilità, a mettersi in mostra. Disinnescare lo scettico non è in genere troppo difficile, ad esempio coinvolgendolo direttamente o cercando di inserire fra gli obiettivi della community le sue necessità. Far capire che il suo apporto può essere utile e che anzi potrebbe lui stesso diventare un champion, permette di ribaltare in poco tempo gli equilibri. Se è vittima di un fallimento passato si potrebbe fare in modo di usare in modo costruttivo questa cosa: “La tua esperienza passata potrebbe essere molto utile per evitare di fare errori analoghi, te la senti di prendere il controllo di un gruppo di lavoro che analizzi il percorso che stiamo facendo e ci permetta di indirizzarlo al meglio?”.

Se semplicemente è geloso di dinamiche del gruppo e teme di restare escluso, proviamo a dargli visibilità tramite un incarico significativo, ma non critico (specie se si tratta di persona con un carattere difficile da trattare), che lo faccia accettare dal gruppo e lo faccia sentire parte importante del meccanismo.

Personalmente, per gestire queste situazioni, ho fatto tesoro di quanto ho avuto modo di imparare nelle discipline delle arti marziali (in particolare T’ai Chi e Aikido) e nella improvvisazione teatrale: il muro contro muro non funziona quasi mai, l’opposizione netta e decisa non convincerà mai chi sta di fronte a noi. Meglio sfruttare la rincorsa di chi ci corre incontro e, spostandosi dalla sua traiettoria, farlo muovere dove vogliamo che vada. Il nostro “no” secco, oltre a non convincere l’altro, porterà entrambi in una situazione “forza contro forza”, di stallo, da cui non si potrà ricavare un vantaggio per nessuno dei due.

Lo strumento “universaletermonucleareglobale”

La semplicità con cui un wiki ci permette di inserire contenuti può portare alla sua adozione all’interno della organizzazione come strumento per raccogliere informazioni sui temi più disparati con cui i vari membri del gruppo si trovano a dover lavorare: issue tracking, project management, organizzazione degli appuntamenti, archiviazione dati, data insert, appunti e note elettroniche, agende, rubrica di gruppo e così via

Sull’organizzazione degli spazi di lavoro dei wiki si è parlato negli articoli precedenti: qui ribadiamo che il wiki, specialmente se organizzato con un unico spazio di lavoro, finisce per assumere il ruolo dello strumento “per tutto e per tutti” (antipattern OneHammerForAll), dove si annegano documenti diversi per contenuto, per natura, per interesse, per gruppo di pertinenza e per ciclo di vita: alcune cose cambiano molto di rado ma vengono messe insieme o accanto a cose che cambiano con estrema frequenza. L’effetto più evidente può essere quello della perdita di orientamento all’interno della mappa del wiki, con una sempre maggior difficoltà a trovare le informazioni che servono.

Ma al di là del semplice aumento della complessità e quantità dei contenuti, anche la presenza di documenti molto diversi per natura e per gruppo di interesse porta da un lato a una complicazione nel processo di gestione evolutiva del sistema; l’esempio più banale a cui possiamo pensare è quello in cui si debba aggiornare il sistema software, cosa che si complica per mancanza di un accordo su quale sia il momento o il modo migliore o sul cosa aggiornare visto che di fatto il wiki è usato da gruppi con esigenze le più differenti fra loro.

Secondariamente questo fenomeno può anche creare un senso si spaesamento negli utenti che perdono il contatto con lo strumento, finendo per considerare il wiki un “coso” troppo vasto per comprenderlo (anche se magari la “totale comprensione” non è n� richiesta n� necessaria) o per sentirsi a loro agio (“Tutte le volte che cerco qualcosa non la trovo oppure ho il sospetto che ce ne sia dell’altra”).

Meglio quindi pensare a una ristrutturazione per aree di competenza o tematiche, pensando alle esigenze e al modo di lavorare o all’oggetto del lavoro delle persone che useranno le varie istanze o spazi del wiki.

Dal sospetto al terrore

Al culmine della scala delle figure che per vari motivi possono mostrarsi indifferenti, diffidenti, o addirittura, ostili nei confronti del wiki troviamo coloro che nutrono un atteggiamento di paura quasi terrore per questo strumento e per il nuovo modo di lavorare che questo impone (antipattern WikiPhobia).

Queste persone non comprendono o non gradiscono l’idea di base dello strumento, trovandosi in disaccordo con la filosofia aperta e condivisa delle informazioni: in questo caso frasi del tipo “ma quali sono i miei documenti?”, “chi ha modificato questa mia pagina?”; “perche’ non usiamo il vecchio modo?”, “meglio che mi stampi tutta ‘sta roba perche’ non so che fine farà”, possono essere i campanelli di allarme che lo spirito non è compreso.

Quindi cosa fare in questo caso? Come possiamo limitare i danni o gli ostacoli che ci verranno frapposti verso la diffusione del wiki all’interno dell’organizzazione? Cosa possiamo aspettarci da chi ragiona in questi termini? È possibile convincere chi soffre di wikifobia dei vantaggi che apporterà, anche per loro, una base di conoscenza collaborativa?

Spirito collaborativo per passi graduali

Probabilmente il modo migliore è cercare di far comprendere il reale spirito collaborativo di questo strumento, partendo nel convincere prima coloro che sono meno ostili all’innovazione. Per i casi più difficili, sui quali è necessario adottare una politica specifica, si potrà pensare di operare per eliminare il problema alla radice: presentare il wiki non come un wiki ma come un nuovo sistema di gestione dei contenuti (CMS) o, se le sigle spaventano, come un nuovo motore di HTML dinamico. Evitare quindi di dare l’accesso in editing a tutti gli inguaribili wikifobici, facendo credere che in realtà solo alcuni operatori (già l’uso di questo termine desueto può rassicurare chi si sente minacciato da un mondo che gli cambia sotto i piedi), opportunamente addestrati, autorizzati e individuati, potranno inserire i contenuti sotto il rigido controllo di un comitato centrale (altro termine che ricorda tempi che furono). Pian piano che il sistema prende piede, si potranno inserire fra gli “operatori” anche i wikifobici, magari spacciando tale cambiamento come un fantomatico corso di formazione o come promozione sul campo.

Quando sarà il momento di svelare la reale natura del “motore per HTML”, se queste persone non ricoprono ruoli potenti, dove questa circumnavigazione potrebbe dar luogo a reazioni pericolose, probabilmente le paure saranno già state sostituite da un confortevole senso di fiducia e di appartenenza al gruppo.

Build it and they will come (?)

Ricordiamoci che gli utenti/contributori che useranno il wiki sono di fatto una community che pur essendo interessate o accomunate da un obiettivo (usufruire dei contenuti o metterne a disposizione alcuni di loro creazione), sono comunque una comunità di persone. Per questo motivo concentrarsi solo sugli strumenti potrebbe essere uno sbaglio. Lo slogan “Build it and they will come” è quanto mai riduttivo e fuorviante in questo caso.

Il wiki è uno strumento innanzitutto sociale, poi tecnico

Per questo può essere un grave errore lavorare per mesi per progettare e implementare il miglior wiki possibile sotto il punto di vista dell’architettura e della tecnologia, senza alcuna considerazione degli aspetti sociali e umani. Il fatto che il team di progetto (quello che implementa il wiki nelle varie funzionalità) sia composto da un gruppo persone disgiunto da quello degli utilizzatori finali non può che aggiungere criticità alla situazione. Il rischio (antipattern: DesignByCommittee) è quello di ottenere un perfetto strumento ma freddo e incapace di cogliere le necessità reali della comunità che gravita intorno allo strumento. Al solito, lo strumento tecnico ha anche la sua importanza; ma molto più importante è tutto il processo di gestione delle persone che useranno lo strumento; il rischio è quello di riporre una cieca fiducia solo nel lavoro dei progettisti.

Una via di uscita a questo scenario, peraltro promossa in altro ambito anche dalle metodologie agili di sviluppo del software, è quella di provare fin da subito a rompere il datato schema per cui chi sviluppa non parla con chi usa, e invece dare maggior peso allo user group. Provare a limitare l’effort della parte di sviluppo non è necessariamente un boomerang, anzi: accontentarsi anche di uno strumento meno evoluto potrebbe alla fine non essere affatto limitante e. Provare a mescolare i due gruppi (inserire gli stakeholders nel work comittee di lavoro) e allertare fin dai primi momenti i vari champion del gruppo di lavoro perche’ spingano nel rompere le barriere creando commistioni fra i due team e fra i relativi punti di vista. Cercare di promuovere il senso di appartenenza al gruppo (al wiki) lavorando sulla identità che le persone ricoprono all’interno del wiki (promuovere la pagina personale, evidenziare quali contenuti una persona ha inserito e quali contenuti sono stati maggiormente commentati o letti).

Un evento di tipo BarnRaising potrebbe essere molto utile per creare il clima adatto e far comprendere che la fase di build è finita (o che comunque si innesta in quella di utilizzo) e finalmente si può iniziare a collaborare. Durante il periodo di adozione, si cerchi anche di contenere i “troppo entusiasti”, che per la troppa voglia di partecipare potrebbero finire per chiudere in un angolo i “timidi”, coloro che non hanno ancora preso dimestichezza con lo strumento tecnico o con le dinamiche di una community. Si cerchi di capire che attivare un wiki non è come seguire le tradizionali tecniche per la realizzazione di un software o di un qualsiasi altro prodotto, dove prima un numero ristretto di sviluppatori costruisce e poi un grande numero di utenti usa. Qui vale la regola per cui è meglio partire con una struttura semplice che permetta di iniziare a usare lo strumento e poi semmai, in un secondo momento, raffinare o ingrandire. Evitare quindi l’antipattern TooMuchStructure.

Flat usage

Un fattore che capita di rado, ma che è utile prendere in esame, è quello legato a una qualche politica di controllo sugli accessi al fine di esigere il pagamento per il servizio erogato; qui si potrebbero ad esempio contemplare modalità di conteggio legate alla percentuale di utilizzo di un wiki inteso come servizio erogato (in epoca di cloud è una ipotesi non molto remota) o come piattaforma su cui il wiki si appoggia.

A volte alcuni siti o servizi online hanno messo a disposizione servizi basati su formule che prevedono conteggi particolari in funzione del tempo di utilizzo o dello sfruttamento del bene (per esempio, banda/dati inviati o letti, numero di contenuti postati su un CMS, etc.).

Storicamente gli analisti ci dicono che queste pratiche commerciali spesso hanno il solo effetto di disorientare il cliente che deve dedicare parte del suo tempo a pensare cosa sia meglio fare o scegliere. Ricordiamoci che il nostro obiettivo è quello di favorire l’uso del wiki (sia in lettura, ma sopratutto in scrittura), per cui è essenziale rimuovere ogni fattore che richieda uno sforzo di ragionamento di contorno non finalizzato alla mera operazione di editing. Un wiki quindi dovrebbe essere sempre utilizzabile senza alcuna ansia da conto a fine mese o bolletta da pagare.

Conclusione

Con queste considerazioni, si conclude questa miniserie dedicata alla gestione di uno strumento di collaborazione e condivisione, aspetto importante per una pratica del Project Management non rigidamente “tradizionale”. Come si è potuto constatare non si sono minimamente presi in considerazione gli aspetti tecnici su come si installi o si configuri un wiki, ma ci siamo concentrati sugli aspetti di gestione delle persone e delle dinamiche che si instaurano nella community che ruota intorno al wiki.

Se appoggiato su solide basi teoriche e pratiche di gestione del progetto, quelle che tradizionalmente vengono studiate e applicate, l’argomento delle dinamiche personali e dei meccanismi di funzionamento dei gruppi di lavoro è un aspetto del Project Management che riveste grande importanza e su cui torneremo nuovamente sulle pagine di MokaByte.