Scegliere un CMS che sarà amato dalla vostra azienda

Su internet non mancano certo i suggerimenti su come scegliere una piattaforma CMS. Un esperto suggerisce di scegliere quella con l’insieme di feature più impressionante. Considerate i costi di proprietà, ribatte un altro. Assicuratevi che produca pagine ottimizzate per la SEO, segnala ovunque un qualsiasi consulente SEO. Sfortunatamente, scegliere il CMS giusto consultando dei criteri generici è tanto efficace quanto studiare i dati di un censimento per migliorare le proprie capacità di scrittura.

Gli esperti spesso ammettono prontamente l’importanza di considerare i bisogni organizzativi nel processo di selezione del CMS, ma raramente vogliono parlare di questi bisogni nello specifico. Però, è di cruciale importanza comprendere i vari interessi dei dipartimenti, i compromessi psicologici e le realtà politiche della vostra organizzazione: i criteri di selezione del CMS dovrebbero enfatizzare i fattori che avranno un impatto diretto sul successo delle persone che lo useranno. In altre parole, smettetela di preoccuparvi di avere un CMS e cominciate a preoccuparvi di avere un CMS utilizzabile.

La maledizione del software aziendale#section1

Una executive survey del 2012 ha rivelato che è sette volte più probabile che i progetti su CMS falliscano a causa di politica interna e mancanza di forma culturale piuttosto che per mancanza di feature. Prove aneddotiche suggeriscono ulteriormente che anche i progetti che inizialmente sembrano avere successo possono deragliare rapidamente se il CMS non può accomodare il modo di lavorare dell’organizzazione.

Come notoriamente hanno evidenziato Jason Fried e Karen McGrane, questi problemi saltano fuori dal fatto che chi acquista il software per l’azienda non coincide con chi poi lo utilizzerà. Però, cambiare il processo di vendite non è sufficiente per superare davvero questo problema: si devono anche comprendere le persone che useranno il CMS e i loro bisogni principali.

Queste tipologie di utenti ricadono tipicamente in tre categorie: sviluppatori che personalizzano e fanno girare il codice, editori che producono effettivamente il contenuto e manager che usano il contenuto online per raggiungere degli specifici obiettivi di business. Per scegliere un CMS che sia utile all’azienda, dovete capire che impatto ha il CMS sul loro lavoro quotidiano e che problematiche affrontano.

I tools fanno lo sviluppatore#section2

Tutti gli sviluppatori sanno che non ci sono due CMS uguali. Da un lato dello spettro, troverete delle piattaforme di publishing che separano attentamente i dati dell’applicazione, la presentazione e la business logic, rendendoli semplici da estendere e personalizzare. Dall’altro lato (il più affollato), vi imbatterete in CMS le cui viscere sono fatte di spaghetti code, inutilmente intricati e strutturati male. Cosa si nasconde sotto il rivestimento di un CMS ha molta importanza, perché il codice architettato male rallenta, rende frustrati e demoralizza anche gli sviluppatori più esperti, rendendo ogni promettente nuova iniziativa una sfacchinata senza fine.

Sfortunatamente, la differenza tra il software progettato a dovere e quello messo insieme a casaccio potrebbe apparire ovvia col senno di poi, ma non c’è modo di distinguere tra i due quando si sta ancora facendo shopping. Le aziende spesso limitano questo rischio scommettendo su produttori di CMS che vantano una grande community di sviluppatori. Infatti, una community vibrante gestisce molti difetti di un’architettura non buonissima: i misteri tecnici vengono risolti con una rapida sessione di ricerca su Google, c’è una pletora di temi, plugin ed estensioni per completare la funzionalità standard e non mancano mai dei consulenti tecnici da assumere.

Ma l’aumento di servizi incentrati sulle API e i nuovi approcci alla pubblicazione che generano, dai CMS headless al content-as-a-service fino ai mobile backend e agli static site generators, hanno aggiunto nuovo pepe a una vecchia storia. Piuttosto che richiedere agli sviluppatori di sgobbare tra le stranezze dell’architettura interna o di padroneggiare un miscuglio di tools e framework, questa nuova specie di CMS nasconde la complessità dietro a un layer API. Tutto quello che deve fare uno sviluppatore per andare a prendere il contenuto è fare una API call che, dopo qualche millisecondo, gli ritorna una risposta formattata ordinatamente. Finché uno sviluppatore lavora con uno dei popolari linguaggi di programmazione, i costi per integrare il contenuto inviato in questo modo sono irrilevanti.

Questo significa che gli stakeholder tecnici devono prendere una decisione architetturale strategica oltre che pensare alla sicurezza, al deploy e alla performance. I produttori tradizionali offrono software complesso che ha bisogno di mesi per essere imparato a dovere, ma c’è una grande community di developer a cui rivolgersi. I nuovi arrivati forniscono servizi leggeri senza overhead di programmazione, ma ci vorranno anni prima che recuperino in termini di community.

Ecco alcune domande per aiutarvi a valutare i pro e i contro di queste opzioni:

• Quanta specializzazione è richiesta per padroneggiare il CMS? Il CMS espone i dati in maniera standard? C’è una chiara separazione di interessi? Il codice è ben documentato? La personalizzazione del CMS è supportata di default? Che developer tools vengono messi a disposizione?
• Quanto è grande la community di sviluppatori? Ci sono molti consulenti tecnici specializzati in questo prodotto? Quanto è facile sistemare i bug e trovare risposte alle domande tecniche? C’è un mercato che fornisce extra?
• Il CMS ha una sua API nativa? Che tipo di dati sono accessibili in maniera programmatica? Quando è dettagliata e ben illustrata la documentazione dell’API? Quanto è difficile personalizzare gli endpoint della API? Com’è la performance dell’API rispetto ai benchmark?

La paura dei manuali dell’editore#section3

Di solito, gli sviluppatori interpretano la documentazione dettagliata del software come un segno di qualità. Gli editori indaffarati hanno esattamente la visione opposta: il publishing tool migliore non ha manuali ed è intuitivo da usare. Sfortunatamente, le interfacce generiche con cui devono misurarsi oggi sembrano sempre più spesso prodotti di una violenta eruzione del database piuttosto che di un design oculato. Alcuni produttori hanno cercato di gestire il problema migliorando stili e layout, aggiungendo etichette descrittive e migliorando le interazioni per ridurre al minimo le difficoltà di utilizzo di un CMS. Ma le interfacce migliori, da sole, non rendono un CMS intuitivo: abbiamo bisogno di authoring experiences (AX) migliori.

Capire bene l’AX richiede che i software developers progettino il CMS attorno al modo in cui editori e autori del contenuto eseguono i propri task: per esempio, preparare e caricare immagini responsive, identificare il vecchio contenuto che ha bisogno di una rinfrescata, personalizzare le etichette dei campi o aggiornare il testo di aiuto. Una buona AX deriva dal progettare attivamente e attentamente per questi workflow quotidiani, così che i team editoriali possano definire il proprio modello di contenuto e personalizzare le interfacce di authoring senza toccare il codice.

Questo focus sulla AX si incastra con le preoccupazioni sul modo in cui è strutturato il contenuto all’interno del CMS. Tradizionalmente, gli strumenti incentrati sulla pagina memorizzano le informazioni in grossi blob di dati, in cui il contenuto effettivo viene mischiato con gli stili di formattazione e gli elementi del layout. Karen McGrane ha illustrato la dolorosa lotta per adottare tale contenuto in nuovi medium in tutti i suoi sanguinosi dettagli. L’antidoto alla maggioranza di questi problemi è di disassemblare i blob di contenuto indifferenziato in piccoli chunk di dati riutilizzabili e di tenere questi dati strettamente separati dalla presentazione visuale.

L’organizzazione del contenuto ha un impatto drammatico sulla produttività del team perché fornisce strumenti molto distinti agli editori. I CMS page-centric permettono agli autori di assumere il ruolo di designer e di trafficare con il modo in cui appaiono le cose in un browser desktop. I CMS con contenuto strutturato aiutano gli autori ad agire come architetti, assemblando pezzi individuali per rientrare nei vincoli di un medium specifico. I team editoriali che si ossessionano sul look del proprio contenuto si sentirebbero sabotati senza un editor WYSIWYG, mentre i team che lavorano in più medium si aspettano che il contenuto arrivi in chunk come il LEGO. La domanda reale è: qual è lo use case critico per il vostro business?

Quando selezionate un CMS, esaminate i vostri casi d’uso e il vostro processo editoriale, poi prendete in considerazione questi fattori:

• Quanto è personalizzabile il CMS? I tipi di dati personalizzati possono essere definiti senza capacità di programmazione? Per quel che riguarda la UI? L’esperienza di authoring può essere aggiustata in modo da riflettere i workflow e la cultura del team? Il CMS può adattarsi ai bisogni di vari user group?
• Il CMS supporta le presentazioni ad alta fedeltà? Il CMS include i template del design? Gli editor possono selezionare i layout e assegnare stili a elementi singoli della pagina? Che opzioni di preview ci sono? Gli asset vengono ridimensionati automaticamente per le viewport target?
• Il CMS supporta contenuto strutturato? Il contenuto viene suddiviso in chunk riutilizzabili? Gli input vengono memorizzati come tipi di dati specifici? Viene impedito agli editor di formattare e assegnare stili alle voci immesse? È facile definire e mantenere più tipi di contenuto?

Aiutare i manager a vedere il quadro generale#section4

I manager vengono raramente menzionati nel contesto della selezione del CMS. Quando lo sono, è solitamente per raccontare una storia ammonitoria sulle disastrose conseguenze dell’ascoltare l’HiPPO (l’opinione della persona più pagata dell’ufficio). Questa linea di pensiero tende ad ignorare dubbi molto validi che ha chi prende decisioni, come i senior editor, i marketing VP o i product managers.

I manager orchestrano i singoli collaboratori esterni a produrre contenuti che soddisfino i bisogni dell’organizzazione. È un processo delicato che richiede forti doti di pianificazione, molta empatia ed attenzione ai dettagli. Mentre un CMS è un cattivo sostituto per l’empatia, ha la sua occasione di brillare aiutando manager indaffarati a vedere il quadro d’insieme: che contenuto c’è live, che pezzi sono programmati per la pubblicazione e chi, nel team, è rimasto indietro. L’informazione contestuale risulta anch’essa comoda quando si lavora con pezzi singoli, perché la possibilità di visualizzare i cambiamenti recenti aiuta a ottimizzare le discussioni interne, rafforzare le verifiche e tracciare chiunque abbia cancellato la cover image.

Un’altra fonte di ansia per i manager è la gestione dei ruoli e dei permessi, in gran parte perché la gestione degli accessi è spesso uno degli ultimi punti nel backlog dei produttori di CMS. La cultura dell’organizzazione detta bisogni molto vari in quest’area: i manager incaricati di coordinare una rete di collaboratori in continua evoluzione vogliono un approccio one-click all’onboarding dei nuovi collaboratori e per dire addio ai vecchi. Di contro, quelli che lavorano con team stabili sono più interessati a catturare informazioni approfondite sull’autore.

Lo stesso vale per i workflow: le organizzazioni piatte possono cavarsela senza pesi e contrappesi elaborati, mentre quelli in aziende regolamentate potrebbero cercare un modo per forzare un triplo sign-off prima che il nuovo materiale raggiunga la homepage. Tutto questo è solo per mostrare che gli obiettivi che persegue un team modificano profondamente le loro aspettative sul modo in cui funzioneranno varie parti del CMS. Anche quando i produttori di CMS rassicurano che i loro tool hanno ruoli e permessi, ricordatevi di investigare se il modo in cui funziona il controllo degli accessi vada davvero bene per i vostri bisogni o se richiede un genio del computer per gestirli nel quotidiano.

• Come si può tenere sotto controllo l’attività del CMS? In che modo si seguono le attività organizzative? Ci sono notifiche? Se sì, come funzionano? Che opzioni di filtering e reporting ci sono? L’informazione contestuale è disponibile sotto le singole entry?
• Come sono implementati i ruoli e i permessi? Che ruoli sono disponibili di default? Cosa ci vuole per aggiungere dei ruoli custom? Si possono rivedere i dettagli degli attuali accessi? È semplice aggiungere/rimuovere collaboratori?
• Il CMS supporta dei workflow specifici? Il processo di pubblicazione può essere automatizzato? Il CMS fornisce dei template per i workflow? Quanto è semplice aggiungere degli step e dei valori personalizzati? Ci sono le notifiche built-in?

Il collo di bottiglia umano#section5

I progetti CMS hanno successo o falliscono in larga parte a causa del fattore umano. Il CMS gioca un ruolo diverso giorno per giorno in dipartimenti diversi, rendendo necessari dei trade-off strategici. Alcuni trade-off sono correlati: un CMS API-powered è facile da combinare con le statistiche basate sul cloud e con i servizi di test A/B: concentrarsi sull’AX rende semplice per i manager impostare dei workflow personalizzati. Ma è probabile che sia così solo in alcune situazioni, la vostra organizzazione si troverà a un bivio, con gli stakeholder chiave che opteranno per produttori di CMS concorrenti. In che modo si gestiscono queste delicate situazioni?

Nel passato, un modo comune per risolvere queste divergenze di opinioni era di demandarle al dipartimento IT o di accettare con grazia l’accordo privato progettato dalle alte sfere del management. Questo approccio comporta molti costi e la cattiva usabilità è solo quello più ovvio.

Al contrario, è meglio affrontare questo problema guardando i propri processi di produzione. Pensate agli step fatti dai vostri vari team: gli sviluppatori fanno dello sviluppo personalizzato e forniscono supporto quotidiano; gli editori creano, aggiornano e mantengono il contenuto e i manager supervisionano i processi e misurano l’impatto sul business dei contenuti pubblicati.

Identificate gli anelli deboli nel processo, in cui i rischi abbondano e i programmi vengono continuamente ritardati. Questi sono i vostri colli di bottiglia: fermano i piani dell’azienda, abbassano il livello e mettono la gente sotto pressione.

Il collo di bottiglia è un concetto relativo: dipende sempre dalla configurazione di fattori individuali in una data situazione. Per un business appena creato, è spesso la dimensione del conto dell’IT che determina le limitazioni; per un dipartimento di un’università, si potrebbero ricondurre i vincoli al tempo a disposizione e alle capacità tecniche dei membri di facoltà e in una media company con contenuto sempreverde, il salto di produttività più grande potrebbe venire dalla rimozione degli ostacoli sul percorso del team del marketing.

Selezionare un CMS tenendo a mente questi ostacoli migliora la produttività degli utenti in molti modi diversi, dall’eliminazione degli errori alla velocizzazione della creazione del contenuto fino alla semplificazione dell’onboarding degli utenti e all’assicurare una reazione più entusiasta. Aiutare i team più deboli a sbloccare il proprio potenziale va ben oltre l’eliminazione dei colli di bottiglia immediati: rende anche più agile e più forte l’intera organizzazione.

Impostarsi per il successo#section6

Per molto tempo, la selezione di una piattaforma CMS è stata trattata come un problema tecnico, che doveva essere risolto dal dipartimento IT o da un consulente tecnico di fiducia. Resistete a questa visione. Come strumento che definisce la vostra presenza online, impone processi editoriali peculiari e influenza la produttività del vostro team, la scelta di una piattaforma CMS è troppo importante per essere decisa in base a criteri tecnici o imposta da un solo stakeholder.

D’altro canto, affrontare il problema della selezione del CMS come un problema organizzativo offre molti benefici: i criteri di selezione che scaturiscono dai requisiti funzionali, dai pattern di lavoro e dalle aspettative culturali dei futuri utenti assicurano di concentrarsi sul lavoro che deve essere fatto, non sulle feature che devono essere realizzate. Visualizzare la creazione di contenuto come un processo che comprende l’intera organizzazione aiuta ad evitare dispute territoriali interne e a dare la priorità a soluzioni di grande impatto.

Cominciate con l’identificare chi sarà impattato dal CMS nella vostra organizzazione: abbiamo parlato di developer, editori e manager, ma la lista degli stakeholder può includere anche altri ruoli. Poi, dovete capire i grandi compromessi che ci sono in ballo: la dimensione di una community di sviluppatori è un punto di rottura? Come dovrebbe essere strutturato il vostro contenuto? Qual è il ruolo dei manager? Rispondere a queste domande dovrebbe aiutarvi ad articolare i bisogni e le aspettative degli utenti futuri, che possono essere poi tradotti in una checklist di requisiti tecnici.

Forti di questa conoscenza, potete ora riprogettare la selezione dei produttori per mettere al centro di tutte le discussioni i veri bisogni della vostra azienda. E una volta fatto ciò, adottare nuovo software non sarà più foriero di incertezza, rischio e ansia, ma, al contrario, aiuterà la vostra organizzazione a diventare più agile, concentrata e resistente. Proprio come vi hanno sempre promesso i tizi delle vendite.

Illustrazioni: {carlok}