{"id":633,"date":"2016-06-27T19:13:11","date_gmt":"2016-06-27T17:13:11","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/scegliere-cms-amato-dalla-vostra-azienda\/"},"modified":"2016-06-27T19:13:11","modified_gmt":"2016-06-27T17:13:11","slug":"scegliere-cms-amato-dalla-vostra-azienda","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/scegliere-cms-amato-dalla-vostra-azienda\/","title":{"rendered":"Scegliere un CMS che sar\u00e0 amato dalla vostra azienda"},"content":{"rendered":"
\n

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\u00f9 impressionante. Considerate i costi di propriet\u00e0, 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 \u00e8 tanto efficace quanto studiare i dati di un censimento per migliorare le proprie capacit\u00e0 di scrittura.<\/p>\n

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\u00f2, \u00e8 di cruciale importanza comprendere i vari interessi dei dipartimenti, i compromessi psicologici e le realt\u00e0 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<\/em> CMS e cominciate a preoccuparvi di avere un CMS utilizzabile<\/em>.<\/p>\n<\/div>\n

\n

La maledizione del software aziendale<\/h2>\n

Una executive survey<\/a> del 2012 ha rivelato che \u00e8 sette volte pi\u00f9 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\u00f2 accomodare il modo di lavorare dell’organizzazione.<\/p>\n

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

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.<\/p>\n<\/div>\n

\n

I tools fanno lo sviluppatore<\/h2>\n

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\u00f9 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\u00e9 il codice architettato male rallenta, rende frustrati e demoralizza anche gli sviluppatori pi\u00f9 esperti, rendendo ogni promettente nuova iniziativa una sfacchinata senza fine.<\/p>\n

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’\u00e8 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’\u00e8 una pletora di temi, plugin ed estensioni per completare la funzionalit\u00e0 standard e non mancano mai dei consulenti tecnici da assumere.<\/p>\n

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\u00e0 dietro a un layer API. Tutto quello che deve fare uno sviluppatore per andare a prendere il contenuto \u00e8 fare una API call che, dopo qualche millisecondo, gli ritorna una risposta formattata ordinatamente. Finch\u00e9 uno sviluppatore lavora con uno dei popolari linguaggi di programmazione, i costi per integrare il contenuto inviato in questo modo sono irrilevanti.<\/p>\n

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’\u00e8 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.<\/p>\n

Ecco alcune domande per aiutarvi a valutare i pro e i contro di queste opzioni:<\/p>\n