Knowledge Base, parte 4: Mantenimento

Nel post precedente abbiamo guardato alcuni diversi approcci per sviluppare la nostra KB. Ora che l'abbiamo sviluppata, è il momento di farla vivere.

Creare i contenuti

Quando abbiamo steso le basi per la progettazione della nostra KB, abbiamo anche mappato i tipi di contenuti che vogliamo pubblicare. Inoltre, ci siamo confrontati con gli stake holder e abbiamo individuato le fonti di conoscenza principali.

Ma come facciamo a trasformare la conoscenza in contenuti?

Il valore della semplicità

Trasformare i concetti in parole chiare non è per nulla banale. Si tratta di creare dei modelli mentali lucidi e di trasmettere questi modelli usando un linguaggio accessibile e il meno ambiguo possibile.

Quando una persona legge il nostro contenuto, spesso si trova in una situazione di difficoltà. Ha un problema da risolvere, una risposta da dare a qualcun altro, oppure ha bisogno di capire come organizzare il proprio lavoro. In queste circostanze, una persona vuole avere il meno attrito possibile tra sé e la risoluzione del suo problema. In poche parole, vuole chiarezza e semplicità.

La semplicità non è sinonimo di facilità, perlomeno quando si tratta di creare qualcosa di semplice. John Maeda, autore del libro Laws of Simplicity, sostiene che la semplicità consiste nel sottrarre l'ovvio e aggiungere il significativo. Ma cosa è ovvio per i nostri utenti? Di cosa hanno bisogno per raggiungere i loro obiettivi?

Il ruolo del technical writer

Ragionando sull'importanza che la semplicità ha per gli utenti, ci rendiamo subito conto che creare i nostri contenuti richiede alcune competenze particolari. Tipicamente queste competenze fanno parte della formazione di un buon technical writer (l'espressione "redattore tecnico" suona vecchia).

In un post del blog di facile.it intitolato Technical Writers: the mystery unveiled, la technical writer Marta Gilberti presenta una lista nutrita di hard e soft skill che ci si aspetta da un technical writer. Strumenti per la scrittura, versionamento, editing di immagini... e poi collaborazione, ascolto attivo e gestione di un progetto di redazione legato a scadenze di prodotto e budget limitati. La nostra KB potrebbe non essere complessa come la documentazione tecnica di facile.it, ma sicuramente questa lista ci aiuta a capire alcuni vantaggi di avere una persona dedicata alla creazione dei contenuti.

Oltre a questi vantaggi pratici, c'è un altro motivo, più sottile ma più profondo. Spesso la semplicità si può raggiungere solo introducendo nel processo un "facilitatore di informazioni". Portare le informazioni fuori dalla testa di una persona (quella che Laloux definirebbe una "sorgente", la nostra fonte), e comunicare queste informazioni a un'altra persona, creano una realtà diversa, gettando luce su preconcetti, limitazioni e incoerenze. In questo caso con "realtà" intendo la nostra particolare percezione delle cose.

Joseph Jaworski, in Synchonicity: The Inner Path of Leadership, spiega l'importanza che il linguaggio ha nella creazione del nostro mondo:

Quindi, non descriviamo il mondo che vediamo, ma vediamo il mondo che descriviamo. Ma cosa significa per la nostra KB?

Per esempio, immaginiamo di essere in un ufficio tecnico di una qualunque PMI bresciana. Probabilmente il nostro vicino di scrivania è un ingegnere oppure un tecnico che conosce alla perfezione il prodotto che sta progettando. Se il prodotto è storico, può descriverne la storia degli ultimi anni; ricordare i momenti progettuali più significativi, e magari anche gli incidenti che hanno formato la sua esperienza, descrivendo i motivi che lo hanno portato a codificare un pezzo in un certo modo o a crearlo con una certa forma. Magari questo nostro collega negli anni ha anche fatto interventi sul campo e ha raccolto informazioni molto strategiche sull'uso del prodotto.

Se chiediamo a questa persona di creare i contenuti tecnici per la nostra KB, corriamo diversi rischi. Per prima cosa, come abbiamo visto la preparazione dei contenuti richiede alcuni hard skill su software e processi specializzati, che probabilmente un tecnico di prodotto non ha. Anche se in qualche modo eliminassimo questa difficoltà, rimane un secondo ostacolo, ben più importante: ovvero che il punto di vista della nostra sorgente di informazioni è "unico", cioè uno solo e specializzato, e quindi può rappresentare una sola porzione del mondo del prodotto. Tutte le conoscenze della nostra sorgente diventano così un ostacolo alla comunicazione. Abituato a descrivere il mondo con termini tecnici e di nicchia, conoscendo la storia e tutti i perché del nostro prodotto, il nostro collega vede il mondo che descrive.

Il technical writer è il facilitatore che permette alle informazioni di rompere questa barriera. Per farlo, intervista la sorgente, fa domande precise, concentra il fuoco del discorso. Registra tutto per poterlo studiare con accuratezza e portare avanti il processo. Crea strutture, chiarisce modelli mentali, e infine semplifica.

Misurare l'uso: analisi quantitativa e qualitativa

Quando seguiamo un processo chiaro e ci affidiamo a persone esperte per creare i contenuti, sicuramente stiamo creando valore per i nostri utenti. Ma aspetta: ne siamo davvero sicuri? A cosa serve un articolo scritto alla perfezione se nessuno lo legge?

Per capire se la nostra KB è efficace, è importante misurarne in qualche modo l'impatto. Un modo per farlo è raccogliere dati. Di seguito alcuni dati che potrebbero tornarci utili:

• quali pagine vengono consultate, e con quale frequenza?
• quanto tempo passano i nostri utenti su queste pagine?
• cosa viene inserito nella barra di ricerca? e di questo, cosa viene trovato e cosa no?

Per raccogliere questi dati possiamo usare diversi strumenti, lato client (più precisi, ma meno rispettosi della privacy) oppure lato server (richiedono più configurazione e rispettano l'anonimato delle persone).

Quando raccogliamo questi dati, dobbiamo ricordarci che sono, appunto, dati, e non informazioni. Senza una chiave di lettura, questi numeri ci dicono poco su come viene davvero usata la nostra KB. Per entrare nel dettaglio, dobbiamo parlare con i nostri utenti.

Nielsen e Norman parlano molto di come intervistare gli utenti. Quando lo facciamo, ricordiamoci che per noi conta quello che gli utenti fanno, non quello che dicono. Non è importante intervistare centinaia di utenti e registrare ore di conversazioni. Spesso basta condurre 3 o 4 interviste per ottenere risultati notevoli. Come in altre cose, possiamo applicare il principio di Pareto: con il primo 20% dello sforzo otteniamo l'80% del risultato.

Un altro modo per raccogliere informazioni è mantenere aperto un canale per il feedback spontaneo da parte degli utenti. Questo può darci un valore diverso a seconda del contesto. Per esempio, nel caso di un bacino di utenza molto grande potrebbe richiedere molto più lavoro di quanto immaginiamo. Addirittura potrebbe essere necessario trovare un modo per strutturare o analizzare questo feedback con tecniche di machine learning.

Contribuire e mantenere: un approccio organico

Per assicurarci che la nostra KB rimanga uno strumento utile alla nostra organizzazione, dobbiamo abbracciare un approccio più "organico" al progetto. Possiamo immaginarci quindi che sia una specie di albero da frutta.

La KB deve essere in grado di seguire i bisogni dei nostri utenti e adattarsi alle condizioni di lavoro. Nel tempo si ingrandirà, quindi probabilmente dovremo rivederne l'architettura e le funzionalità. Potrebbe essere necessario potare qualche ramo e supportarne altri dandogli maggiore visibilità ed energia.

Così come non guarderemmo un albero crescere istante per istante (anche se forse all'inizio potremmo esserne tentati), e nemmeno vorremmo che crescesse completamente da solo, per trovarci poi con un sacco di verde e pochi frutti, così dobbiamo pensare che la nostra KB ha bisogno di ritmo.

In questo caso ci viene utile lavorare "a sprint". All'inizio del progetto possiamo programmare di dedicarci all'analisi dei dati e dei feedback con una certa frequenza (per esempio, ogni due settimane). Questo ci permette di procedere a piccoli passi, invece che con grossi interventi di ristrutturazione. Così facendo possiamo adattarci velocemente alle modifiche del clima che ci circonda e ai bisogni dei nostri utenti. A volte ci sarà bisogno di dare da bere e a volte no. Col tempo capiremo se è necessario aumentare o ridurre la frequenza degli sprint, ma quello che conta è che ci sia un momento dedicato a questa attività.

Un pensiero su questa serie di post

Per completare questa serie di 4 puntate sulle KB ci sono voluti circa due mesi. Quando ho iniziato con il primo post, pensavo che mi sarei concentrato di più sugli aspetti tecnici. Scrivendo, mi sono accorto che ormai quelli sono gli aspetti più facili da affrontare anche per una persona che non ha competenze tecniche.

Penso che le vere difficoltà oggi si nascondano nel riuscire a individuare i veri obiettivi di un progetto e a collaborare con un team di persone. Queste difficoltà non sono tali per una mancanza di conoscenze, quanto piuttosto perché alcune domande mettono in discussione le strutture organizzative in cui siamo abituati a lavorare e vivere.