Knowledge Base, parte 3: Sviluppo

Pubblicato il 24-08-2021 | 7 min di lettura

Nel post precedente di questa serie dedicata alle KB, abbiamo affrontato la fase di progettazione. Una volta che abbiamo coinvolto tutti gli stake holder e raccolto i requisiti necessari è il momento di passare alla fase di sviluppo.

Ellipse

Soluzione custom vs proprietaria

La prima grande scelta che dobbiamo fare è decidere se questo progetto verrà sviluppato ad-hoc oppure se sarà necessario acquistare un prodotto "preconfezionato".

Entrambe le alternative possono essere soluzioni valide. Di seguito alcuni spunti che possono aiutarci a scegliere.

Disponibilità delle competenze di sviluppo

Per sviluppare una KB avremo bisogno di almeno uno sviluppatore che possa trasformare il nostro progetto in un sistema funzionante. Per farlo, questo membro del team deve avere competenze con lo sviluppo di progetti web, sia front-end che back-end (un cosiddetto "full-stack"). Deve saper impostare e gestire i sistemi che ospiteranno il nostro progetto e che ne regoleranno il rilascio online (sistemista / dev-ops) e, per un progetto di qualità, deve essere in grado di assicurare una buona esperienza utente.

In aziende che si occupano di software, ma non di web, talvolta succede che il team di sviluppo prenda in carico il progetto della KB per una sorta di affinità percepita da parte del management. Come per altri settori, anche il mondo dello sviluppo software è fatto di ambiti che richiedono una certa specializzazione. Il web è uno di questi ambiti. Ricordiamoci che una KB non è solo un sistema per organizzare le informazioni, ma anche per permettere agli utenti di creare e consumare queste informazioni. Uno sviluppatore web sa bene che, nella maggior parte dei casi, il valore di un progetto si crea proprio nell'interazione con gli utenti. È per questo motivo che nel web usiamo tecnologie all'avanguardia che ci permettono di massimizzare questo valore e di creare interfacce utenti usabili e intuitive.

Funzionalità speciali

Tipicamente una KB consiste in una serie di funzionalità di base, tra cui:

  • inserire contenuti
  • organizzare contenuti in modo gerarchico
  • fare una ricerca

Nel 2021, possiamo aspettarci che qualsiasi soluzione abbia queste funzionalità.

Le cose iniziano a complicarsi se abbiamo bisogno di qualche feature un po' particolare, per esempio:

  • estendere la ricerca all'interno di PDF
  • sincronizzare i dati con altri sistemi
  • gestire account e permessi.

Se scegliamo un prodotto "preconfezionato", è importante capire se queste funzionalità sono "nice-to-haves" oppure "deal-breakers". Prima ancora di procedere allo scouting dei prodotti che vogliamo valutare, ci conviene preparare una tabella in cui ci chiariamo le idee.

Per esempio, proviamo a fare ordine con le funzionalità che ho indicato sopra:

Nice to have Deal breaker
estendere la ricerca all'interno di PDF -
- sincronizzare i dati con altri sistemi
- gestire account e permessi

A seconda della quantità di funzionalità e della complessità del progetto, potremmo aggiungere un'altra colonna per gestire gli elementi che possiamo affrontare in una seconda fase oppure trattare con il rivenditore per plugin o funzionalità extra:

Nice to have Can wait Deal breaker
estendere la ricerca all'interno di PDF - -
- sincronizzare i dati con altri sistemi -
- - gestire account e permessi

Se invece scegliamo di sviluppare il progetto internamente, la questione diventa più fluida. Per decidere con quale priorità sviluppare le nostre funzionalità possiamo usare una matrice costi/benefici per mettere in relazione diversi aspetti del nostro progetto.

dithered camel

© Nielsen Norman Group, Using Prioritization Matrices to Inform UX Decisions

Integrazioni umane e digitali

Una delle funzionalità citate sopra è "sincronizzare i dati con altri sistemi". In realtà spesso quando parliamo di sistemi intendiamo anche reparti o gruppi di lavoro. Una KB si inserisce in un paesaggio digitale che è composto da tutti i sistemi e le informazioni che l'azienda usa e produce. Per aggiungere un nuovo componente a questo paesaggio bisogna considerare due aspetti principali.

In primo luogo, è importante capire quale cultura emerge dagli strumenti. Quali sono le politiche aziendali che vengono portate avanti? In che modo le persone sono abituate a relazionarsi con le informazioni e gli strumenti? La nostra KB può servire a supportare lo status quo, oppure a segnalare un cambio di rotta. Qualunque sia la direzione che prendiamo, è importante che sia una scelta consapevole.

L'altro aspetto fondamentale è il modo in cui l'informazione fluisce. Chi crea l'informazione in azienda? Dove viene salvata? Chi la mantiene? Per evitare informazioni duplicate dobbiamo assicurarci che la nostra KB possa collegarsi a sistemi pre-esistenti (per esempio per sincronizzare gli utenti con un database aziendale) e che sia in grado di condividere informazioni con altri CMS (per esempio per sincronizzare i contenuti con la documentazione che viene stampata).

Spesso l'argomento "integrazione" viene visto solo da un punto di vista tecnico. Ogni strumento però può generare valore solo se viene usato dalle persone. Nel considerare questo aspetto, cercate anche di immaginare che impatto ha un nuovo strumento sul lavoro e la vita delle persone coinvolte.

Protezione dei contenuti

Uno dei principali nodi di progettazione della KB è la disponibilità del contenuto. Se decidiamo di proteggere i contenuti, il nostro sviluppatore dovrà prevedere di far girare del codice lato server per gestire l'autenticazione degli utenti. Questo ha un impatto sui linguaggi e le piattaforme che possiamo usare, anche se più per una questione di semplicità che di limiti tecnologici. Detto questo, esistono anche diverse librerie per proteggere contenuti statici e gestirne la de-crittografia direttamente nel browser, ma forse è un percorso più avventuroso e con qualche limitazione in più sull'esperienza utente.

Questo è sicuramente l'ambito in cui soluzioni SAAS proprietarie possono apportare più vantaggi. Molte di queste piattaforme gestiscono gli accessi degli utenti e i rispettivi permessi. Inoltre alcuni di questi prodotti sono già integrati con servizi di autenticazione di terze parti, come Google o Facebook.

Orizzonte temporale del progetto

Una cosa a cui raramente si pensa in progetti di questo tipo è la durata nel tempo. In altri settori, il consumo dei materiali e l'usura dei meccanismi ci ricordano l'inesorabilità dell'entropia del mondo fisico. Quando calcoliamo il ritorno di investimento di un oggetto fisico ne teniamo sempre in considerazione la data di scadenza prevista, nonostante i macchinari possano essere riparati e perfino restaurati, e nonostante i beni di consumo vengano sostituiti periodicamente.

Sebbene un progetto digitale non si usuri a forza di click, e non venga consumato dai continui caricamenti, è buona norma considerarlo all'interno di una finestra temporale, e in qualche modo dargli una data di scadenza. Questo non per promuovere l'obsolescenza programmata all'interno del digitale, ma piuttosto per dare più valore a progetti sviluppati in modo da essere facilmente mantenibili ed espandibili.

Facciamo un esempio concreto. Se mettiamo a confronto un servizio SAAS che ci costa 50€ al mese con un progetto che richiede 20 giornate di sviluppo, troveremo che il primo anno il servizio ci costerà 600€, mentre lo sviluppo potrebbe arrivare a costarci circa 10 volte di più. Ma se estendiamo l'orizzonte temporale del progetto a 5 anni, notiamo che la differenza in termini di costi si è dimezzata. Inoltre, abbiamo a disposizione uno strumento proprietario potenzialmente molto più solido e che può facilmente essere adattato a nuove esigenze, senza incorrere in costi mensili aggiuntivi.

Per altri casi può valere il ragionamento opposto: alcuni servizi con orizzonti temporali più brevi hanno senso in cloud per questioni di miglioramenti tecnici, scalabilità e accesso da remoto.

Alcune soluzioni

Possiamo dividere le soluzioni tecniche per KB nelle seguenti 3 categorie.

Compilatori proprietari desktop (desktop CMS o publishers)

In alcuni casi, software dedicati alla comunicazione tecnica offrono anche soluzioni per compilare delle KB. In generale, questi software permettono di riusare il contenuto su piattaforme diverse, come per esempio per un PDF o appunto, una KB, e di cambiare l'aspetto e la struttura dei contenuti.

Solitamente però l'output di questi sistemi è un po' sovrastrutturato per permettere agli utenti di personalizzarlo. Aggiungere nuove funzionalità non previste può essere difficoltoso se non impossibile, perché raramente è possibile inserirsi all'interno del processo di compilazione. In pratica, quando optiamo per un compilatore desktop, dobbiamo accettare di avere una scatola nera tra i contenuti che creiamo e quelli che vengono compilati, avendo a disposizione i parametri che il rivenditore ha scelto per noi.

Inoltre abbiamo ancora l'onere di gestire l'hosting dell'output compilato e di curarne revisioni e rilascio.

Servizi cloud (SAAS)

Le soluzioni SAAS risolvono brillantemente una serie di problemi, tra cui:

  • hosting
  • gestione degli accessi
  • versionamento dei contenuti

Alcuni di questi servizi mettono anche a disposizione feature molto avanzate, come la ricerca estesa ai contenuti di documenti, il riconoscimento dei soggetti nelle immagini e l'analisi dell'uso da parte degli utenti.

Se però la soluzione compilatore era una sorta di scatola nera imperscrutabile, per certi versi la soluzione cloud è pure peggio: ora i contenuti non sono più sulle nostre macchine, e in più è necessario sostenere dei costi mensili o annuali.

Librerie open source

Esistono numerose librerie open source che permettono di generare KB. Alcune di queste librerie sono puramente dedicate a questo compito, come per esempio Vuepress, mentre altre sono dei generatori di siti statici che funzionano molto bene anche per questo scopo, come per esempio Nuxt.

Queste librerie permettono il completo controllo sul formato dei contenuti, sui flussi, sulle strutture e sulle funzionalità, mettendo però a disposizione una serie di strumenti per affrontare problemi tipici, rendendole la soluzione preferita dagli sviluppatori.

In conclusione

La fase di sviluppo è sicuramente quella più operativa. Le tecnologie a disposizione sono tantissime, e per questo è importante mettere bene a fuoco le nostre priorità, facendo tesoro delle informazioni raccolte durante la fase di progettazione.

Nel prossimo post ci sposteremo alla fase di mantenimento.

Questo post fa parte di una serie su come fare una KB. Leggi i post correlati: