Com'è fatto un prodotto "Enterprise-Ready"? (Parere netto benvenuto!)

[jpishgar (Joe)]

Vorrei porre una domanda alla comunità di operatori professionali presenti qui, una questione che ho visto trattare superficialmente in altri contesti, ma che non è mai stata approfondita in modo da soddisfare una definizione rigorosa.

Qual è, secondo voi, la definizione di ciò che considerereste “pronto per l’enterprise” come condizione per la vostra comunità? Intendo questo sia in termini di condizione e preparazione della piattaforma comunitaria, sia in termini di contenuti di base consolidati e attività. Sono ansioso di dimostrare che l’affermazione secondo cui si tratta più di arte che di scienza è errata, e che qui sono in gioco alcuni modelli condivisi e chiari!

L’attività è probabilmente più facile da misurare, dato che ci sono numerosi benchmark.

Una delle definizioni di “attivo” frequentemente citate nei forum è quella di Reddit per ciò che costituisce una subreddit “attiva”, che ho usato in passato come regola pratica per valutare il successo nel stabilire un nucleo critico. Storicamente, questa definizione è “almeno cinque post al giorno”. Reddit in precedenza considerava una comunità attiva una subreddit con almeno cinque post o commenti in un dato giorno. So di aver raggiunto un’attività autosufficiente in una nuova comunità se ho quel numero di post o commenti che avvengono quotidianamente, senza richiedere interventi o sollecitazioni. È anche un ottimo test per una nuova area di discussione o sottocategoria. Se crei una nuova categoria e riesci a portarla a 5+ post al giorno che avvengono senza il tuo intervento, hai una categoria solida.

Per quanto riguarda la prontezza per l’enterprise, specialmente per comunità B2B o di clienti, modificherei questa definizione dicendo 5+ post o commenti al giorno, PIÙ una risposta garantita in stile SLA all’80% degli argomenti entro 48 ore. Ritengo importante assicurarsi che i nuovi post non restino soli e senza risposta, ma anche dare all’argomento il tempo di respirare e l’opportunità che si verifichi una risposta organica.

Avete una formula che preferite? Sono fuori di testa riguardo a questo tasso di risposta?

E senza voler dividere troppo nettamente l’argomento, come appare la prontezza per l’enterprise a livello di piattaforma? Nella mia lista breve, direi avere una tassonomia/architettura dell’informazione solida per le prime categorie, una funzione di risposte risolte o migliori, notifiche intelligenti e instradamento per rimanere entro i tempi di risposta previsti per i nuovi argomenti, e almeno un po’ di persone pronte a occuparsi della moderazione. Sono anche molto insistenti sull’avere un tema che si integri con l’organizzazione per cui viene costruita la comunità, ma questo è totalmente una questione di preferenza.

Qual è la vostra opinione (calda/controversa/contraria o meno) su come appare una comunità “Pronta per l’Enterprise” secondo voi?

[fuse (Geoff Hughes)]

Quando penso a “pronto per l’enterprise”, penso ad affidabilità, disponibilità e prestazioni su larga scala, il che potrebbe non essere la stessa domanda che stai facendo.

Tempo di attività del sito al 99,99% (quattro nove), e a seconda di come si considera la disponibilità, si rende un servizio che funziona in un’architettura ad alta disponibilità o in modalità scale-out, dove la perdita di un componente potrebbe comportare una perdita di capacità e non di disponibilità.

Portare la questione al livello successivo implicherebbe considerare il bilanciamento del carico globale, o il bilanciamento del carico tra regioni, o scenari di disaster recovery fuori regione.

Penso alla dimensione della popolazione di utenti e ai livelli di attività (i dati integrati su DAU/MAU e altre statistiche offrono informazioni eccellenti).

Il tuo sito può gestire 10.000 utenti attivi simultanei senza alcun ritardo nelle prestazioni durante il caricamento di immagini o l’uso delle funzionalità di chat?

Quando gli utenti iniziano a percepire problemi di prestazioni, o lag/latenza?

Nota che credo in due cose: l’architettura determina i costi, e capire come intendi considerare la progettazione della comunità fin dall’inizio è importante su larga scala. Questo è difficile perché, a meno che non si sia già su scala enterprise dal primo giorno, ciò di cui hai bisogno per 100 utenti potrebbe essere molto diverso da ciò di cui hai bisogno per 1.000, o 10.000.

C’è molto da analizzare riguardo alla semplicità dell’architettura monolitica, ai rischi dei singoli punti di fallimento rispetto agli obiettivi di disponibilità, e a come approcci come Docker e Kubernetes aggiungono complessità mentre abilitano lo scale-out.

Sono un grande fan di Discourse, la mia comunità è minuscola, e non ho dedicato tempo significativo a valutare come trasformerei software come Discourse in SaaS (cosa che presumo i bravi ragazzi di Meta abbiano già risolto e reso sembrare facile).

Cambiando argomento, penso che ciò di cui potresti stare chiedendo siano gli SLA (accordi sul livello di servizio, che implicano contratti) o gli SLO (obiettivi sul livello di servizio, che possono essere usati per stabilire le aspettative). Questo torna alla progettazione.

Quanti moderatori o membri dello staff hai, qual è il rapporto tra moderatori e utenti, come si confronta questo con il volume di pubblicazioni e il rapporto tra post segnalati e post totali (come esempio). Se hai un solo amministratore, e anche solo 100 utenti, non sono sicuro che impegnerei nemmeno uno SLO di 1 giorno lavorativo.

Gli ultimi due punti che offro sono: inizia pensando all’obiettivo finale, e costruisci la tua progettazione basandoti su requisiti chiari.

Spero che sia stato utile! Buona fortuna!

[jpishgar (Joe)]

@fuse

Quando penso a “pronto per l’enterprise”, penso alla affidabilità, disponibilità e prestazioni su larga scala, il che potrebbe non essere la stessa domanda che stai facendo.

Grazie per la risposta fantastica. Ed è davvero interessante che la definizione qui abbia una forte concentrazione sulle prestazioni su larga scala, il tempo di attività e l’esperienza utente a livello di server.

Le prestazioni sono uno di quegli aspetti di cui non si parla molto nei circoli di Community Management, ma è sicuramente un punto in cui Discourse ha dei vantaggi supremi.

Ma è sicuramente un fattore importante. Uno degli esempi più eclatanti che posso citare è quando gestivo Skyscraper City, che era basato su una versione più vecchia di XenForo. È una comunità enorme B2C di livello entusiasta e, a causa dell’enorme numero di categorie e sotto-categorie con una moltitudine di aree di discussione suddivise per regione e zona, risentiva di lag ed era piuttosto insopportabile da usare. Certamente aveva uno dei numeri più alti di reclami sulle prestazioni, nonostante vantasse una ricchezza di contenuti unici al mondo.

In termini di design della comunità stessa, la differenza per “pronto per l’enterprise” è infrastrutturale piuttosto che prestazionale. Anche se non sono sicuro che ci siano studi fatti sulle soglie di tolleranza per le comunità stesse - abbiamo la ricerca sulle Core Web Vitals. Chromium Blog: The Science Behind Web Vitals Ho sempre pensato che la tolleranza e la pazienza per prestazioni inferiori siano una funzione inversa: più gli membri attivi all’interno di una comunità sono coinvolti, più alta è la loro tolleranza.

Sarei curioso di sapere se altri hanno opinioni sui requisiti indispensabili per la definizione di comunità “pronta per l’enterprise” oltre al requisito spesso trascurato “Deve essere veloce. Vroom vroom!”