Wie sieht "Enterprise-Ready" für euch aus? (Hot takes willkommen!)

[jpishgar (Joe)]

Ich möchte hier eine Frage an die professionelle Community-Operator-Community stellen, die ich an anderen Orten bereits auf der Oberfläche diskutiert gesehen habe, aber noch nie wirklich in einer Weise vertieft, die der Definition gerecht würde.

Was ist für dich die Definition dessen, was als „enterprise-ready“ für deine Community gelten würde? Ich meine das sowohl in Bezug auf den Zustand und die Bereitschaft der Community-Plattform als auch auf etablierte Basisinhalte und -aktivitäten. Ich bin gespannt, zu beweisen, dass dies mehr Kunst als Wissenschaft ist, und dass es hier einige klare gemeinsame Muster gibt!

Aktivität ist wahrscheinlich einfacher zu messen – dafür gibt es zahlreiche Benchmarks.

Eine der häufig zitierten Definitionen von „aktiv“ in Foren ist Reddits Definition dessen, was ein „aktives“ Subreddit ausmacht, die ich in der Vergangenheit als Faustregel verwendet habe, um den Erfolg bei der Etablierung eines kritischen Kerns zu messen. Historisch gesehen ist dies „mindestens fünf Beiträge pro Tag“. Reddit hat eine aktive Community früher als ein Subreddit mit mindestens fünf Beiträgen oder Kommentaren an einem bestimmten Tag gezählt. Ich weiß, dass ich eine selbsttragende Aktivität in einer neuen Community erreicht habe, wenn es täglich so viele Beiträge oder Kommentare gibt, ohne dass Eingriffe oder Aufforderungen erforderlich sind. Es ist auch ein guter Test für einen neuen Bereich für Diskussionen oder eine Unterkategorie. Wenn du eine neue Kategorie erstellst und diese auf 5+ pro Tag steigern kannst, ohne dass du dich einmischen musst, hast du eine solide Kategorie.

Für „enterprise-ready“, insbesondere für B2B- oder Kundencommunities, würde ich dies dahingehend ändern, dass es 5+ Beiträge oder Kommentare pro Tag gibt, PLUS eine SLA-ähnliche garantierte Antwort auf 80% der Themen innerhalb von 48 Stunden. Ich finde es wichtig, sicherzustellen, dass neue Beiträge nie einsam und unbeantwortet bleiben, aber auch dem Thema etwas Zeit zum Atmen geben und die Möglichkeit für eine organische Antwort bieten.

Hast du eine Formel, die du bevorzugst? Liege ich mit dieser Antwortquote daneben?

Und um das Thema nicht zu stark zu unterteilen, aber wie sieht „enterprise-ready“ für dich auf Plattformebene aus? Meine Kurzliste wäre: eine solide Taxonomie/Informationsarchitektur für die ersten Kategorien, eine Funktion für gelöste oder beste Antworten, clevere Benachrichtigungen und Routing, um im Rahmen der erwarteten Antwortzeit für neue Themen zu bleiben, und mindestens ein paar Leute, die bereit sind, sich an der Moderation zu beteiligen. Ich bin auch sehr emphatisch dafür, ein Thema zu haben, das zur Organisation passt, für die die Community aufgebaut wird, aber das ist völlig Geschmackssache.

Was ist deine Meinung (heiß/umstritten/konträr oder nicht) darüber, wie eine „Enterprise-Ready“-Community für dich aussieht?

[fuse (Geoff Hughes)]

Wenn ich an „Enterprise-Ready“ denke, denke ich an Zuverlässigkeit, Verfügbarkeit und Leistung bei Skalierung – was vielleicht nicht genau die Frage ist, die du stellst.

Site-Uptime von vier Neunen (99,99 %), und je nachdem, wie man Verfügbarkeit betrachtet, bedeutet ein Service, der in einer Hochverfügbarkeits- oder Scale-Out-Architektur läuft, dass der Ausfall einer Komponente Kapazität kostet, aber nicht unbedingt die Verfügbarkeit beeinträchtigt.

Die nächste Ebene wäre, entweder globales Load Balancing, regionales Load Balancing oder Disaster-Recovery-Szenarien außerhalb der Region zu berücksichtigen.

Ich denke über die Größe der Benutzerpopulation und die Aktivitätslevel nach (die eingebauten DAU/MAU-Statistiken und andere Metriken liefern hier großartige Daten).

Kann deine Site 10.000 gleichzeitige aktive Benutzer verwalten, ohne dass beim Hochladen von Bildern oder bei der Nutzung von Chat-Funktionen Leistungsengpässe entstehen?

Ab wann beginnen Benutzer, Leistungsprobleme oder Verzögerungen/Latenz zu bemerken?

Beachte, dass ich zwei Dinge für wichtig halte: Die Architektur bestimmt die Kosten, und es ist entscheidend, bereits im Vorfeld zu verstehen, wie du das Community-Design betrachten möchtest, wenn es um Skalierung geht. Das ist schwierig, denn es sei denn, du startest sofort in Enterprise-Größe, kann das, was du für 100 Benutzer brauchst, völlig anders sein als das, was du für 1.000 oder 10.000 Benutzer benötigst.

Es gibt viel zu entschlüsseln bezüglich der Einfachheit von Monolith-Architekturen, den Risiken einzelner Ausfallpunkte im Vergleich zu Verfügbarkeitszielen und dafür, wo Ansätze wie Docker und Kubernetes Komplexität hinzufügen, während sie Scale-Out ermöglichen.

Ich bin ein großer Fan von Discourse, meine Community ist winzig, und ich habe keine nennenswerte Zeit damit verbracht zu evaluieren, wie ich Software wie Discourse zu einem SaaS-Produkt machen würde (was ich annehme, dass die coolen Leute bei Meta bereits gelöst und einfach aussehen lassen haben).

Ein kleiner Wechsel des Fokus: Was du vielleicht meinst, sind SLAs (Service Level Agreements, also Verträge) oder SLOs (Service Level Objectives, die zur Erwartungsmanagement dienen können). Das führt auch wieder zum Design zurück.

Wie viele Moderatoren oder Mitarbeiter hast du, wie ist das Verhältnis von Moderatoren zu Nutzern, und wie verhält sich das zum Posting-Volumen und zum Verhältnis von gemeldeten Beiträgen zu allen Beiträgen (als Beispiel)? Wenn du nur einen Admin und selbst nur 100 Benutzer hast, würde ich kaum ein SLO von einem Geschäftstag zusichern.

Die letzten beiden Punkte, die ich hinzufügen möchte, sind: Beginne mit dem Ziel im Blick und baue dein Design auf Basis klarer Anforderungen auf.

Hoffe, das war hilfreich! Viel Glück!

[jpishgar (Joe)]

@fuse

Wenn ich an „enterprise-ready“ denke, denke ich an Zuverlässigkeit, Verfügbarkeit und Leistung bei Skalierung, was nicht unbedingt die gleiche Frage ist, die du stellst.

Danke für die fantastische Antwort. Und es ist wirklich interessant, dass die Definition hier einen großen Fokus auf Leistung bei Skalierung, Uptime und Benutzererfahrung auf Server-Ebene legt.

Leistung ist eines dieser Themen, über die in Community-Management-Kreisen nicht viel gesprochen wird, aber Discourse hat darin definitiv einige enorme Vorteile.

Aber es ist auf jeden Fall ein wichtiger Faktor. Eines der drastischsten Beispiele, die ich nennen kann, ist, als ich Skyscraper City betrieb, das auf einer älteren Version von XenForo lief. Es ist eine riesige B2C-Enthusiast-Community, und aufgrund der gigantischen Anzahl von Kategorien und Unterkategorien mit einer Vielzahl von Diskussionsbereichen, die nach Region und Gebiet aufgeteilt waren, war es langsam und ziemlich unbrauchbar. Es hatte definitiv eine der höchsten Anzahl von Beschwerden bezüglich der Leistung, obwohl es eine Fülle einzigartiger Inhalte weltweit anzubieten hatte.

In Bezug auf das Community-Design selbst ist der Unterschied für „enterprise-ready“ infrastrukturell und nicht leistungsbezogen. Obwohl ich mir nicht sicher bin, ob es Studien zu Toleranzschwellen für Communities selbst gibt – wir haben ja die Core Web Vitals-Forschung. Chromium Blog: The Science Behind Web Vitals Ich habe immer so gedacht, dass die Toleranz und Geduld für geringere Leistung eine umgekehrte Funktion ist: Je engagierter die aktiven Mitglieder in einer Community sind, desto höher ist ihre Toleranz.

Ich würde mich freuen, wenn andere ihre Ansichten zu den Must-Haves für die Definition einer „enterprise-ready“ Community jenseits des oft vernachlässigten Gebots „Es muss schnell sein. Vroom vroom!“ teilen würden.