Knowledge Base, parte 2: Progettazione

Nel post precedente di questa serie dedicata alle KB, abbiamo dato una definizione di KB identificando alcuni degli usi più comuni di questo strumento. In questo post iniziamo a guardare alla fase di progettazione di una KB, analizzandone i rischi e le opportunità.

Due vettori di progettazione

Come per altri progetti digitali, la progettazione di una KB parte da due vettori principali:

• le persone, e
• i contenuti.

Le informazioni che raccogliamo lungo questi due vettori ci permettono di definire i principi di progettazione della nostra KB.

Le persone

Per parlare delle persone coinvolte in un progetto si usa l'espressione "stake holder". Uno stake holder è chiunque abbia un ruolo, attivo o passivo, o anche solo un interesse, per il progetto.

La prima parte del nostro progetto quindi si concentra sul coinvolgere gli stake holders. È importante ricordarsi che il numero dei nostri stake holders è sempre maggiore di uno e inferiore a "tutti". Anche se il progetto è fortemente voluto da una sola persona (per esempio, un direttore, un CTO, o uno sviluppatore), solitamente avrà un impatto su un gruppo di persone, fatta eccezione per il caso limite di KB fatte per uso strettamente personale.

Allo stesso modo, è importante definire l'ambito della nostra KB. Anche se la facessimo per "tutti", potremmo pensare che in particolare potrebbe essere più utile a un certo gruppo di persone con determinate caratteristiche.

Di seguito alcune domande che ci possono aiutare a capire quali persone dovrebbero essere considerate degli stake holders:

• Chi ha richiesto la KB? oppure,
• Chi manifesta il bisogno di una KB?
• Chi paga per il progetto?
• Chi crea i contenuti?
• Chi userà la KB?
• Chi svilupperà e manterrà l'infrastruttura della KB?

Rispondere a queste domande ci aiuta a identificare le persone che dovrebbero essere coinvolte nel processo di progettazione. Queste persone sono il nostro gruppo di lavoro. A seconda del loro ruolo e del contributo che possono dare, entreranno a far parte del nostro processo di progettazione in diverse fasi.

Uno stake holder particolare

Se stai leggendo questa guida probabilmente sei il progettista della KB. Il progettista, inteso come "designer", è un tipo di stake holder un po' particolare. Il ruolo del progettista è quello di mettere insieme i bisogni di tutti gli altri stake holder e di portarli a lavorare insieme verso un obiettivo condiviso.

Questo non significa eseguire gli ordini di chi ha più potere nel gruppo o di limitarsi a sommare le richieste e accettarle con regola maggioritaria. Nel primo caso otterresti un progetto poco utile, perché si basa sui bisogni di una sola persona. Nel secondo caso otterresti quello che si chiama "progettazione per commissione", e come disse Alec Issigonis, "un cammello è un cavallo progettato da una commissione".

Sono convinto che un cammello direbbe che se mai è Alec ad essere stato progettato da una commissione.

Il progettista lavora per trovare la sinergia del gruppo e sintonizzarlo verso l'obiettivo comune. Lo fa andando a fondo di tutti i bisogni, le obiezioni e i comportamenti che vengono manifestati dagli stake holder. Per questo motivo, una delle responsabilità del progettista è creare un ambiente di lavoro trasparente e supportare la fiducia che il gruppo di lavoro ha verso di sé e verso il progetto.

I contenuti

Il tipo di contenuti che metteremo nella nostra KB può avere un impatto sulle specifiche del nostro progetto. Di seguito alcune domande che possono aiutarci a capire meglio questo impatto:

• Che tipo di contenuti verranno caricati su una pagina normale? Per esempio: testo, immagini..
• Quali estensioni di file verranno usati? Per esempio: file 3d, video..
• Quali sono le interazioni che prevediamo? Per esempio: ricerca rapida, commenti, revisione dei contenuti..

Un altro aspetto da considerare è la visibilità di questi contenuti. Se i contenuti devono essere mantenuti riservati, sarà necessario prevedere un sistema di protezione con password. Magari vogliamo proteggere solo alcuni contenuti, oppure renderli visibili solo ad alcuni gruppi di utenti. In quest'ultimo caso per esempio lo sviluppatore dovrà implementare un controllo degli accessi di tipo diverso.

Se i nostri contenuti provengono da fonti esterne all'azienda o al gruppo di lavoro, dovremo anche verificarne eventuali limitazioni di uso dovute a copyright.

Diamo la giusta importanza alla fase di progettazione

La fase di progettazione è la radice del nostro progetto. Se affrontiamo questa fase con frettolosità, se trascuriamo qualche stake holder o se non consideriamo qualche limitazione, aumentiamo la probabilità che il nostro progetto non soddisfi i bisogni degli utenti o che addirittura non arrivi ad essere sviluppato.

In aziende abituate alla materialità del proprio prodotto (per esempio, aziende di meccanica) può essere difficile dimostrare il valore della fase di progettazione. Cosa sono tutti quei post-it, e dov'è il mio sito?

In altre aziende invece può succedere che la fase di progettazione si trasformi nell'unica fase possibile, perché il progetto non è mai pronto per essere sviluppato, oppure perché passa in secondo piano rispetto ad altre priorità.

Un altro compito fondamentale del progettista è quello di trovare il giusto compromesso per usare le risorse a sua disposizione entro un certo periodo di tempo. L'equilibrio tra esecuzione e preparazione dipende molto dal contesto. È una tensione tra il desiderio di "fare" e quello di "pensare", tra l'impulsività sconsiderata e la paura di sbagliare.

Così come è importante dare spazio alla progettazione, concludere la prima iterazione della nostra KB è un obiettivo fondamentale che porta molto valore. Dobbiamo tenere bene a mente che la pubblicazione della KB non sarà l'ultima fase del nostro progetto.

Alcuni rischi

Quando iniziamo a lavorare con i nostri stake holder è probabile che troveremo alcuni ostacoli. Di seguito alcuni dei rischi più comuni.

Il collo di bottiglia 🍼

In aziende prevalentemente arancioni, per dirla alla Laloux, c'è il rischio che un progetto di questo tipo sia voluto da un "capo" e gestito in modo gerarchico.

Se da un lato è conveniente che il progetto abbia una "sponsorizzazione" di un certo livello, dall'altro una gestione gerarchica spesso si trasforma in micro gestione e in lunghe attese per sbloccare le fasi di lavoro. Mai dovuto aspettare due mesi per una modifica insignificante?

Un modo per affrontare questo rischio è di parlarne con chi ha voluto, oppure sta finanziando il progetto, accettando anche che potrebbero non esserci soluzioni.

Il gate keeper 🔑

In molti contesti in cui il potere è considerato come qualcosa che separa e che si "ha" sugli altri, la conoscenza viene spesso vista come uno strumento di questo potere. Per questo motivo, rinunciare alla proprietà della conoscenza può equivalere a perdere potere. In alcune aziende questo problema è talmente importante da diventare il motivo per cui l'idea di una KB viene stroncata sul nascere.

Quando ci approcciamo alla conoscenza che risiede nella nostra azienda, dobbiamo essere consapevoli che rischiamo di entrare nella dinamica di come è distribuito il potere. Non tutti potrebbero essere pronti a rinunciare al proprio potere. Qualcuno invece potrebbe essere interessato a togliere potere a qualcun altro.

Un modo per affrontare questo problema è di disegnare come è distribuita la conoscenza che vogliamo mettere nella KB. Ci sono dei gruppi che potrebbero non voler collaborare? Chi sono i personaggi principali di questi gruppi? Chi sono i gate keeper?

Il tecnico factotum 💻

Tra gli stake holder abbiamo identificato anche le persone che svilupperanno la KB. In un team di lavoro poco strutturato che ha a disposizione una forte competenza tecnica può succedere che la parte tecnica prenda un po' il sopravvento e che si perda la parte di progettazione.

Durante la progettazione della nostra KB, è importante posticipare il più possibile le considerazioni tecniche. Nella progettazione "human-centered" ci dobbiamo ricordare che la parte più importante sono i bisogni e i problemi di partenza. La tecnologia deve essere una scelta secondaria, ovvero deve servire per risolvere il problema, non viceversa. Per dirla in un altro modo, a volte succede che un progetto nasce per cercare un problema ad una soluzione tecnica. Questo non serve ai nostri utenti. Se pensi che questo sia il caso del tuo progetto, forse dovresti riformulare il problema di partenza: invece di dire "come posso rendere accessibile la conoscenza nella mia azienda?", prova a dire "come faccio a mostrare l'uso di questa tecnologia nel modo più efficace possibile?"

In conclusione

La fase di progettazione è la fase più importante. Una parte fondamentale di questa fase è il dialogo con i nostri stake holder. Un progetto di successo si basa sulla capacità del progettista di ottenere la fiducia del gruppo di lavoro e di riuscire a usare le risorse a sua disposizione in tempi ragionevoli.

Nel prossimo post approfondiremo la fase di sviluppo.