Con il nuovo anno diamo inizio sulle colonne di MokaByte a una serie di articoli dedicati al project management visto non solamente come disciplina per la gestione di progetto, ma anche in particolari aspetti collaterali, necessari per ‘fare in modo che le cose accadono’.

Introduzione

Questa nuova serie sarà organizzata con una alcuni articoli centrali dedicati al project management e alcuni argomenti “di contorno” che però si possono certamente considerare indispensabili per la buona riuscita del progetto; si parlerà in questo contesto di come gestire le relazioni interpersonali all’interno dell’azienda, della gestione della conoscenza nel gruppo di lavoro e di come tutte le azioni che si intraprendono nell’ambito di un progetto (ma non solo) possono avere ripercussioni sulla realtà che ci circonda (il team aziendale, la community, il gruppo di lavoro).

Partiamo questo mese subito con un parallelo dedicato a un tema molto caro a noi della redazione di MokaByte (come avremo modo di vedere molti dei pattern che vedremo sono tipici anche nel lavoro quotidiano di gestione di un magazine online), ovvero la gestione e la condivisione della conoscenza all’interno di gruppo.

In tale ambito, fra i vari strumenti che il PM si trova a  dover gestire per  raggiungere questo obiettivo, uno che certamente è sempre più presente nei gruppi di lavoro è il wiki, strumento che pone nella semplicità e facilità di gestione il suo pilastro fondante.

Installare un software di questo tipo è una prassi relativamente semplice; molto più impegnativo è far si che il wiki diventi “lo strumento” di condivisione e di archiviazione delle informazioni; fare sì che il wiki abbia il successo sperato significa trovare il modo corretto per presentare lo strumento a tutto il gruppo,  identificare le persone adatte per la sua promozione, gestire le tipiche dinamiche di reazione alla novità e soprattutto evitare i classici errori che si possono incontrare in un processo di adozione di questo tipo.

In questo primo articolo ci concentreremo sulle persone coinvolte nel processo di gestione e promozione del wiki: nella prima parte vedremo quali sono le azioni da perseguire  e le figure da attivare per  facilitare la nascita e la crescita del wiki all’interno dell’azienda, della intranet o genericamente della community; nella seconda parte invece vedremo quali sono i tipici errori che è bene evitare e che invece di verificano con maggior frequenza in questo contesto. Nel prossimo articolo parleremo invece delle tecniche per facilitare l’adizione al resto del gruppo.

Parleremo in questo contesto spesso di pattern o wiki-pattern (esiste anche un noto sito web [WP]) per indicare quegli schemi comportamentali che si possono mettere in pratica per facilitare l’adozione del wiki  nel gruppo e spingere per la partecipazione al suo uso. Come accade nella progettazione del software, esistono anche in questo caso anche gli antipattern, ovvero errori tipici che si corre il rischio di fare e che possono impedire il successo nel processo di adozione ed utilizzo del wiki.
 

Dare impulso all’adozione del wiki

Come recita un noto adagio, chi ben inizia è a metà dell’opera; quindi se dobbiamo introdurre un nuovo strumento nel gruppo (d’ora in poi useremo questo termine per riferirsi genericamente al team di lavoro  di progetto, a un gruppo in azione all’interno della azienda o alla community di cui si vuole gestire la conoscenza) è estremamente importante trovare il modo giusto per “accenderlo” e presentarlo ai vari membri del gruppo. Da questo punto di vista, la cosa più semplice che si possa fare è mettere in pratica il pattern Invitation che non è altro che un modo per comunicare al gruppo la nascita di questo nuovo strumento di lavoro e per invitarli a usarlo nel modo più assiduo possibile. Non dovrà creare stupore il fatto che alcuni risponderanno con entusiasmo all’invito fin dalla prima comunicazione, mentre altri probabilmente risponderanno con indifferenza, sospetto o addirittura avversione.

Fra i primi probabilmente troveremo i cosiddetti early adopters di nuove tecnologie (probabilmente hanno già installato per uso personale  o per prova un mini-wiki sul loro computer o limitatamente a un ristrettissimo insieme di altri early adopters); gli altri (detti a volte oppositori) sono persone che spesso mostrano una innata avversione per le novità, oppure non sono in un buon momento, forse  stanno vivendo in modo critico determinate scelte nel gruppo o sono in contrasto con il management; oppure semplicemente non hanno la testa libera per loro problemi personali e vivono il cambiamento come una fatica ulteriore; potrebbe trattarsi anche di persone letteralmente oberate di lavoro per cui non hanno modo di pensare ad altro se non a quello che già stanno facendo. È utile ricordare sempre che tutti noi viviamo prima o poi fasi in cui troviamo difficile  aderire a qualche nuova proposta o nuovo modo di lavorare (si veda l’esempio del coltello degli aborigeni in [ASW]).

In questa prima fase l’obiettivo del pattern è semplicemente fare in modo che il messaggio arrivi, cercando di eliminare il classico “ma io non lo sapevo, perchè nessuno me l’ha detto”. Solo in un secondo momento (con altri pattern comportamentali) si dovrà cercare di disciplinare l’entusiasta e di motivare chi fa resistenza. Si potrà in questa fase fornire una breve e informale formazione sul nuovo strumento, cercando di far passare il messaggio circa le nuove opportunità piuttosto che sulle possibili nuove difficoltà. L’invito deve infine fornire il pretesto per tutti per trovare il tempo per fare almeno qualche prova con questo nuovo strumento.

Barn raising

Successivamente all’invito un altro pattern tipico che si consiglia di adottare è quello del Barn Raising; letteralmente il termine “barn raising” deriva da un contesto che non ha nulla a che vedere con i wiki e nemmeno con l’informatica: nella cultura contadina del Nordamerica (ma anche dalle nostre parti presumo che si facesse qualcosa di analogo) indicava infatti un evento durante il quale una comunità di persone si riuniva per lavorare insieme alla realizzazione di un edificio rurale (un “fienile”, appunto “barn”, o genericamente un magazzino) per una famiglia del gruppo o per tutta la comunità. All’evento partecipava anche chi non direttamente coinvolto nelle operazioni di carpenteria, sia per adempiere ad alcuni compiti paralleli (come per esempio nel caso delle donne che si occupavano di preparare il cibo) o semplicemente per stimolare lo spirito di gruppo e la coesione durante il lavoro. Al giorno d’oggi questo tipo di eventi continua più o meno inalterato nelle comunità Amish del nord America e in alcune aree rurali del Canada.

L’idea di base era quella di unire le forze per superare la difficoltà intrinseca di fare un lavoro troppo impegnativo per un singolo individuo. In termini moderni  l’obiettivo era quello di dare un boost al processo di costruzione che avrebbe altrimenti richiesto troppo tempo o non sarebbe riuscito in alcun modo.

In ambito web un Barn Raising è un evento che viene organizzato per mettere insieme un gruppo di persone sia per poter iniziare a discutere sugli argomenti del wiki sia per inserirli nel wiki stesso per cominciare a creare quella massa critica di contenuti che sarà poi uno degli elementi scatenanti il processo di adozione. Il BR dovrebbe fornire la spinta iniziale al processo di popolamento, ma non sono da sottovalutare gli aspetti sociali: incontrare altre persone, condividere idee e pensieri, scambiare opinioni e punti di vista sul wiki e sul flusso delle informazioni all’interno dell’azienda. Spesso lo stesso scambio fra utenti esperti, senior di progetto o di azienda, con i nuovi arrivati è un importante effetto conseguenza di un BR.

Questo genere di eventi devono avere quindi un clima estremamente piacevole e coinvolgente sia per stimolare la partecipazione al gruppo sia per trasmettere la filosofia di base del wiki (lavoro collaborativo).

Dato che si inizia a lavorare tutti nello stesso momento, durante un barn raising si possono abbattere le tipiche difficoltà della sindrome da foglio bianco o della innata difficoltà nell’approcciarsi a un nuovo strumento o al lavoro di gruppo. Il clima piacevole dell’evento può essere alimentato offrendo un finger lunch, bibite, o genericamente pause ricreative.

Può essere una buona idea preparare prima una scaletta o un ordine del giorno per pilotare gli argomenti del  Barn Raising per pianificare quali contenuti andranno sul wiki, stabilire una organizzazione di base; anche inviare a tutti preventivamente la definizione degli standard e sulle convenzioni stilistiche e redazionali può essere utile per evitare inutili perdite di tempo e partire rapidamente con la fase di popolamento.

Durante tutto il processo di utilizzo e di gestione del wiki è importante dare impulso all’aspetto virale del wiki stesso (pattern Viral): l’obiettivo è fare in modo da far comprendere a tutti i membri del gruppo che più persone usano lo strumento e più ampi  saranno i benefici che tutti potranno ottenere. Questo si ottiene sia cercando di spingerne l’uso in tutte le occasioni in cui l’uso del wiki può essere una valida alternativa (o semplicemente una opzione), sia lavorando sulla struttura ipertestuale del wiki.

Nel primo caso il wiki può con successo sostituirsi ad altri sistemi di comunicazione (tipicamente la mail) per quei processi di lavorazione di contenuti in cui c’è qualcuno che scrive, altri che devono leggere  e magari commentare: si pensi a un report di fine progetto che fino al giorno prima doveva essere scritto con un word processor e fatto girare come allegato a una mail, e dove i vari destinatari potevano apporre le loro considerazioni solo come note al documento; l’evoluzione wiki potrebbe basarsi su una pagina, magari linkata alla pagina del progetto. Tutti la possono leggere, commentare, modificare tenendo traccia della storia delle modifiche.

Per il secondo aspetto (lavorare sulla struttura del wiki) si possono seguire molteplici filosofie d’azione: per esempio si può lavorare per mantenere alta la facilità d’uso (limitare l’uso di cross link, preferire per quanto possibile una struttura a livelli piatti o piramidale, a una a grafo interconnesso, etc…), proponendo sempre i vari argomenti in pagine sempre autocontenute, ma spingendo per approfondimenti successivi verso link su altre sezioni del wiki-sito, sezioni che magari sono sotto la responsabilità di persone diverse che quindi possono in qualche modo essere stimolate a inserire, completare revisionare altri contenuti.

Regola del 90-9-1

Si ricordi sempre che, per quanti sforzi si possano fare per cercare di coinvolgere più persone all’uso del wiki (sia in lettura ma anche e soprattutto in composizione), è convinzione diffusa che la Regola del 90-9-1 (che corrispondono alle percentuali di partecipazione) sia valida nella quasi totalità dei casi: tale regola ci dice che normalmente per 100 persone che partecipano al wiki, 90 leggono, 9 commentano e solamente una scrive.

Questo tipo di regola è particolarmente vera nei social network generalisti e “ampi” come  Facebook dove a fronte di pochi prodi contributori esiste una foltissima schiera di persone che non si lasciano sfuggire nemmeno una virgola di quanto scritto da altri ma per mille motivi (dal pudore alla mancanza di idee o semplicemente di voglia) non scrivono.

Ci si può facilmente accorgere di questo fatto mettendo frasi volutamente provocatorie o senza senso o indirizzate a persone che non scrivono mai, per scoprire che in realtà sono perfettamente aggiornate sulle stranezze che quel 1% di utenti scrive (magari con commenti de visu, per strada nel mondo reale). In contesti più  ristretti (p.e. il wiki interno di una azienda) questo fenomeno è meno forte, ma comunque presente.

Questo fatto, se da un lato può scoraggiare quell’1% che scrive, in realtà deve far comprendere che quel che appare in realtà è molto meno di quel che accade e che probabilmente i risultati non sempre sono negativi come appaiono.

Per incentivare le persone a venire allo scoperto si può cercar di incentivare il lavoro dei singoli  dandogli il giusto risalto; il pattern MyPersonalInfo può essere un esempio, pattern che  spinge a dare la visibilità agli autori tramite la pubblicazione della pagina personale con una foto, una biografia o di un blog personale (inserito nel wiki o linkato esternamente). In MokaByte ad esempio ogni articolo ha un box con la foto e biografia dell’autore.

Le persone coinvolte

Dopo aver visto quali possono essere le azioni da intraprendere per dare impulso all’adozione e alla crescita del wiki, vediamo adesso quali figure e quali ruoli possono essere utili per facilitare il successo del wiki all’interno del gruppo di lavoro.

La figura più ovvia che viene in mente nel processo di produzione dei contenuti è il  Contributor, ossia colui che collabora inserendo contenuti di vario genere ma anche collaborando nel migliorare la forma e la veste grafica o procedendo alla revisione dei contenuti. Il Contributor deve essere una persona sufficientemente motivata, con un’innato spirito di iniziativa e a volte (ma non è detto) autonomo nel decidere cosa e dove inserire i contenuti nel wiki. Deve essere addestrato a quelle che sono le linee guida del wiki, le indicazioni sulla struttura e le policy da rispettare. Il suo lavoro è essenziale senza il quale diventa impossibile procedere al completamento del wiki stesso, spesso non è sufficiente per promuovere la crescita del wiki; il Contributor infatti spesso non possiede il carisma necessario per coinvolgere altre persone e dare impulso al wiki, compito che spesso viene svolto egregiamente dal Champion, figura che all’interno del gruppo di lavoro è impersonata da un appassionato del progetto, della tecnologia utilizzata o semplicemente del lavoro in questione.
Il Champion è colui che ha la volontà e le capacità di  creare interesse nel wiki, è capace  di coinvolgere altri all’uso fornendo al contempo anche l’adeguata educazione e gli strumenti per usarlo nel modo opportuno; Il Champion ha anche la capacità di guidare il gruppo gestendo quelle situazioni che potrebbero deviare il percorso di crescita del wiki. Il Champion diventa il punto di riferimento all’interno del gruppo, tanto da diventare “sinonimo di wiki”: gli altri lo identificano come colui in grado di aiutare a risolvere un problema, a capire come e dove inserire un contenuto o viceversa a trovarne uno già presente. Il Champion in genere è un esperto conoscitore sia della materia in esame (il progetto, il core business del gruppo di lavoro  o dell’azienda), sia dello strumento software (il wiki stesso); il Champion ha una mente aperta e disponibile dato che non tiene mai per se’ queste le conoscenze in suo possesso, ma cerca sempre di passarle ad altri coinvolgendo più persone; è un volenteroso promotore del wiki senza mai insistere troppo perchè un approccio “Wiki sempre e comunque” potrebbe essere dannoso, specialmente con gli utenti alla prima esperienza che stanno ancora imparando ad usarlo.

Il focus del Champion è diretto verso il gruppo di lavoro e non ha quindi alcuna capacità o responsabilità di promozione verso l’esterno (altre persone esterne al gruppo, altri ruoli, altri team), compito che invece ricade sull’Ambassador: questo si adopera proprio per coinvolgere altre persone nell’attività di produzione e organizzazione dei contenuti o viceversa nella fruizione. L’Ambassador ha anche la responsabilità di migliorare l’accettazione di questo strumento fra coloro che esternamente al gruppo non lo adottano o vedono l’intera iniziativa con sospetto; per questo spesso ricerca l’appoggio o l’approvazione in persone che, sebbene non abbiano un  coinvolgimento diretto ne’ nel processo produttivo ne’ in quello di consumo (lettura) dei contenuti, ricoprano un ruolo o una posizione nella gerarchia complessiva (oppure un elevato carisma) tale da suscitare rispetto fra i colleghi. Sono questi gli Sponsor (o Patron) del wiki, figure che non agiranno direttamente sul wiki ma il cui appoggio morale può influenzare positivamente tutte le persone che in un modo o nell’altro possano entrare in contatto con il wiki.

Due figure il cui compito è piuttosto ovvio, sono il Maintainer e il PageMaintainer, ai quali viene assegnato il compito di mantenere il wiki nella sua interezza o limitatamente in una parte o pagina. Il loro lavoro è volto a valutare (e autorizzare se necessario) i contributi e le revisioni e correggere eventuali errori o incompatibilità con le regole e le policy redazionali. Sono in genere esperti dell’argomento trattato, spesso ricoprono un ruolo particolare all’interno del progetto o del gruppo di lavoro (anche se spesso non possono essere le figure chiave perche’ per mancanza di tempo non potrebbero dedicarsi in modo efficace all’attività di mantenimento del wiki.

Concludono questa carrellata sulle figure coinvolte per la buona riuscita del wiki, i cosiddetti “abbellitori” del wiki, attori coinvolti nel processo di gestione degli aspetti grafici ma anche ipertestuali il cui lavoro è volto al miglioramento della fruizione (lettura e navigazione) del wiki stesso. Si tratta dei WikiGnome (colui che costantemente apporta piccole migliorie sui contenuti) o del WikiGardner (che lavora invece più sugli aspetti di confezionamento, impaginazione, grafica ed editing dei link); hanno potere di revisione e spesso sono gli stessi che svolgono il lavoro di Maintainer.

Le dolenti note: errori tipici

Dopo aver introdotto le figure pro-wiki e le azioni per promuoverne l’evoluzione, vediamo adesso quali sono le figure che possono ostacolare il wiki (i detrattori) e quali sono gli errori tipici (antipattern) che possono compromettere il successo del wiki.

L’esempio più evidente di antipattern è il Bully (qui nel senso di prepotente,  prevaricatore, oppositore) che in genere fa di tutto per spingere le persone a non usare il wiki in favore di altri strumenti di comunicazione (da lui ritenuti migliori o comunque di pari funzione e potenza, ma che invece hanno una connotazione, scopo e funzionalità di tutt’altra natura). Il Bully è la figura antagonista per antonomasia del Champion, verso il quale a volte cela la sua vera natura mostrando un atteggiamento eccessivamente favorevole (rispetto agli altri elementi  del gruppo) tale da suscitare qualche sospetto. Spesso pubblicamente ha un atteggiamento di grande (troppa) stima del wiki mentre nelle conversazioni private non perde occasione per criticarlo duramente. Ha alle volte un atteggiamento sarcastico.

Il modo migliore per “bloccare un bullo” è quello di cercare un dialogo diretto, evidenziandone il comportamento e facendo comprendere le differenze fra un wiki rispetto ad altri strumenti di comunicazione (che sono in genere preferiti dal Bully); evidenziare che per il passaggio al wiki non è necessario alcun extra effort è un modo per convincere un bullo; da tenere presente che spesso queste persone non sono consapevoli che stanno mostrando un atteggiamento ostile nei confronti del wiki e dei colleghi.

Strettamente legato al Champion e all’Ambassador troviamo l’antipattern All wiki all the time, uno schema tipico che si presenta quando vi è una eccessiva spinta verso il wiki (“il troppo stroppia” anche in questo contesto). Il wiki infatti deve essere presentato in modo graduale così come gradualmente deve essere introdotto ai membri del gruppo; non deve esserci fretta nell’accelerare il processo di adozione (evitate la reazione “oh no! ancora un altro wiki” oppure “no, anche questo va sul wiki?”). Il wiki deve essere vissuto come uno strumento di uso confortevole e del quale il gruppo percepisce l’effettiva utilità. Si deve quindi cercare di evitare di promuoverlo sempre e comunque (specialmente se ci sono resistenze all’interno del gruppo), così come di variarne troppo spesso la struttura o le istanze, proprio per ridurre lo spaesamento all’interno di un mondo che cambia troppo spesso.

Una difficoltà che molti utenti incontrano (specialmente quelli poco avvezzi allo scrivere e al condividere contenuti con gli altri) deriva proprio dalla natura pubblica e condivisa dei contenuti del wiki: la sindrome da foglio bianco si associa sovente con la paura che altri possano criticare o deridere quanto da noi scritto, o addirittura modificarlo,  con lo scopo di alterarne il contenuto o lo spirito; questa paura per questa forma di sabotaggio culturale prende il nome di anti pattern Vandal.

Per risolvere questi problemi si può agire in modo da tranquillizzare gli ansiosi: nel primo caso può essere utile che il Champion (o di altri attori leader del wiki) si metta in gioco scrivendo e pubblicando contenuti, cosa che può aiutare gli altri utenti a superare la paura di mostrare i propri scritti; un gesto altrettanto utile è quello in cui utenti esperti richiedano l’aiuto dei nuovi o dei più “timidi” per effettuare la revisione o la semplice rilettura dei contenuti, un po’ per dimostrare che nessuno è al di sopra degli altri e che l’attività di scrivere è una attività che necessita del contributo di tutti.

Nel caso in cui il timore dei vandali sia forte, si può fra credere che solo alcune persone “fidate” abbiano diritto di editing dei contenuti (al limite si può “barare” dando possibilità di edit a tutti tranne che a chi teme i vandali); in alternativa se si ritiene che il rischio di attività di vandalismo sia reale, si può irrobustire il processo di validazione in modo da migliorare la resistenza agli “attacchi” di disturbatori e vandali. È chiaro che questa opzione deve essere considerata una sorta di extrema ratio, dato che va contro la natura stessa del wiki (condivisione, libertà, flessibilità).

Al fine di facilitare l’accesso al wiki e indurre alla massima partecipazione di tutti, si devono semplificare le procedure di accesso: una procedura di registrazione complessa, l’uso di certificati di accesso, attivazione di canali criptati (come nel caso di wiki protetti da VPN), rappresentano talvolta impedimenti che possono disincentivare l’uso del wiki da parte dai meno motivati); questo è quello che viene descritto nell’antipattern Gate.

Può capitare che all’interno del gruppo di lavoro ci siano persone che agiscano per accelerare e incentivare il processo di popolamento del wiki;  queste persone a volte dispongono delle risorse (economiche o politiche) per mettere al lavoro attori che lavorano (pagati o comunque comandati) per produrre contenuti. È questo il caso del cosiddetto antipattern ContributorForHire: sebbene chi “paga” i contributori sia animato da buone intenzioni, gli effetti negativi di questo scenario si ripercuotono sul medio e lungo periodo: da un lato scoraggia gli altri (non pagati) a scrivere nel wiki (“perche’ dovrei farlo io? Tanto c’è lui che lo fa, ed è pure pagato”), dall’altro porta a un blocco delle pubblicazioni non appena il soggetto (o i soggetti) pagati interrompono il loro contributo.

Il primo problema può essere ridotto tenendo segreta l’informazione relativa al pagamento dell’onorario (ma i caso di pubblicazione della notizia gli effetti possono essere anche peggiori), mentre il secondo non ha soluzione e in genere è di difficile risoluzione. Si dice infatti che quando si verifica un ContributorForHire, il danno è permanente all’interno del gruppo e gli effetti si protraggono nel tempo anche per un lungo periodo. Per rimediare a questo scenario c’è chi suggerisce di “chiudere” il wiki, crearne uno nuovo con una grafica e struttura radicalmente diversa e con un alto tasso di innovazione per far capire a tutti che è in atto un nuovo corso e che gli errori del passato non verranno più ripetuti.

Scrivere contenuti in un wiki può essere spesso un processo costoso se non faticoso e la tendenza al copia e incolla è sempre dietro l’angolo: se il vincolo dell’originalità non è un requisito (in fondo nella maggior parte dei casi il wiki non deve dire qualcosa di nuovo, ma semplicemente formalizzare concetti, linee guida, indicazioni per il gruppo di lavoro), questo potrebbe non essere un fattore negativo.

Il problema insorge quando si portano nel wiki contenuti presi da fonti coperte da copyright, cosa che può avere gravi conseguenze se il wiki non è interno o privato ma pubblico; è questo il caso del cosiddetto Copyright Infringement, problema del quale ci si accorge se il tasso di nuovi inserimenti aumenta improvvisamente o comunque in modo non proporzionale alle risorse coinvolte (poche persone non possono scrivere come molte).

Passando al setaccio di un motore di ricerca alcuni dei passaggi sospetti (esempio quelli scritti con una forma migliore, più curata e dettagliata o comunque diversa dal resto del wiki), si metterà in luce la presenza e provenienza dei cloni. È bene agire nel più breve tempo possibile, limitando il fenomeno e rimuovendo quei contenuti che potrebbero dar luogo a ritorsioni legali. Sempre legato alla difficoltà di fornire contenuti e visto che la distrazione è sempre dietro l’angolo, si dovrebbe limitare la naturale tendenza di usare strumenti alternativi al wiki non appena possibile (anti pattern Leech); si tratta i questo caso di combattere la convinzione che per passare un contenuto a un collega sia più comodo allegare un documento alla mail, piuttosto che pubblicare il documento nel wiki e passare l’URL ai colleghi per la discussione comune (discussione che dovrebbe essere ospitata dal wiki sotto forma di commenti alla pagina). Il Champion, il Maintainer sono tipicamente le persone che hanno la responsabilità di combattere tali deviazioni limitando l’uso di strumenti di comunicazione e di discussione alternativi al wiki.

Concludiamo questa lunga carrellata con una figura nota nelle comunità virtuali e quindi nel contesto di gestione di un wiki. Stiamo parlando del WikiTroll persona che agisce con spirito critico non costruttivo e non utile alla crescita del wiki o della comunità che lo usa.

Il troll è una persona che interviene spesso nelle discussioni con asserzioni filosofiche negative spesso fini a se stesse o più orientate a mettere in luce la presunta superiorità dell’autore. Il suo contributo finisce spesso per creare disarmonia, ansia, nervovismo nel gruppo; può capitare che un WikiTroll agisca (più o meno volontariamente) per generare adepti che sposano la sua causa finendo per criticare l’utilità del wiki, la qualità dei contenuti o dei contributori. Per fortuna il WikiTroll non si trova di frequente nelle comunità, specialmente se a fianco della comunità virtuale si trova quella reale (es. per un wiki aziendale); in questi casi infatti gli eventuali attriti o discussioni possono essere risolti faccia a faccia. In ogni caso è bene tener presente che il troll è una figura pericolosa, tale da bloccare il processo editoriale in toto e quindi vanificare il wiki stesso. È in genere l’antagonista del Champion.

Un buon modo di limitare i danni prodotti da un WikiTroll è quello di organizzare un incontro in cui si cerchi di comprendere le ragioni del suo operato e analizzando le conseguenze delle sue azioni (spesso il troll è ignaro dei reali effetti delle sue parole).  Il troll che sia ragionevolmente aperto al confronto è probabile che sia in grado di comprendere i suoi errori e di agire di conseguenza. Se ciò non è possibile, si rende necessario ricorrere a soluzioni drastiche come il blocco al wiki imponendo un login al sito (e quindi impedendo l’accesso ai soggetti indesiderati).

Conclusioni

Come si può notare, la gestione dei vari attori che collaborano per promuovere il wiki è un lavoro corale che deve preoccuparsi di svariati aspetti: da quelli legati al processo organizzativo a quelli più propriamente psicologici. Le persone coinvolte si schiereranno normalmente in due gruppi: da una parte avremo i “fautori” (in contrapposizione ai cosiddetti detrattori), ovvero coloro che sono favorevoli e promotori del wiki e del suo successo all’interno del gruppo di lavoro. Gli antagonisti invece sono coloro che per predisposizione, per fattori ambientali o a volte per pura coincidenza di fattori non spiegabili razionalmente (“mi ha detto mio cugggino che una volta una tipa…”), si schierano contro il wiki e cercano di banalizzarne ogni successo o vantaggio.

In entrambi i casi (fautori e detrattori o antagonisti) si tratta di figure astratte che non è detto che siano impersonate da singoli attori; ad esempio fra i ruoli associati ai fautori potranno essere accorpati quelli con responsabilità di editing, di coordinamento o di promozione.  In entrambi i casi il successo del wiki è reso possibile grazie alla gestione di entrambe le tipologie di persone: se appare infatti ovvio che sia necessario contrastare i detrattori, un po’ meno ovvio è capire come e quando sia opportuno gestire i fautori che sono a favore del wiki e che quindi non dovrebbero agire per ostacolarne l’evoluzione e la crescita. Nonostante essi abbiano infatti un atteggiamento positivo, devono essere comunque gestiti per evitare che per un eccesso di entusiasmo non rispettino le elementari regole di gestione e di popolamento del wiki. Il compito di gestire i fautori non è difficile, anche se a volte può dare qualche complicazione in più del previsto. L’antipattern All Wiki All The Time è la tipica dimostrazione di questo fenomeno.

Riferimenti

[WP] Wiki Patterns
wikipatterns.com

[ASW] F. Saliola – G. Puliti, “Aspetti sociali del web – I parte: Tecnologie e comportamenti”, MokaByte 149, marzo 2010
https://www.mokabyte.it/cms/article.run?articleId=1XJ-SFX-Y22-RCV_7f000001_30087332_532365df