Die Risiken zu spät vs. zu früh zu skalieren

Es ist nie zu früh, um mit der Planung für zukünftiges Wachstum zu beginnen. Sobald Sie festgestellt haben, ob Sie eine Bibliothek oder ein Café aufbauen, können Sie mit der Entwicklung adaptiver Strategien beginnen.

Wir haben einige Recherchen zu unserer Kundenbasis durchgeführt und dabei drei frühe Signale entdeckt, die bei Kunden mit Communities, die Schwierigkeiten haben, konsistent auftreten:

  • Kein klarer Anwendungsfall / keine grundlegende Startausrichtung
  • Fehlende Abstimmung der Interessengruppen / keine klare Verantwortungszuweisung
  • Fehlende frühe Fortschritte (Dinge stocken nach dem Start)

Wenn diese wichtigsten Aspekte nicht von Anfang an berücksichtigt werden, werden sie zu einem führenden Indikator für nachgelagerte Misserfolge.

Wenn Sie sie zu spät angehen, wird die Community zunehmend anfällig und ist von früher Fragmentierung bedroht. Siehe Community-Fragmentierung: Wenn Wachstum zum Hindernis wird.

Die Risiken, zu früh vorzugehen, sind nicht so hoch und äußern sich tendenziell wie folgt:

  • Prozesse, die komplexer sind als notwendig
  • Mitglieder erleben unnötige Reibungsverluste
  • hohe Arbeitsbelastung des Personals
  • Geisterstädte
  • Mangel an aussagekräftigen Daten für Berichte

Weiterführende Literatur
Der Community-Lebenszyklus: Vom Start zum Vermächtnis

Die Community, auf die ich im oben genannten Artikel verweise, ist ein gutes Beispiel für eine Community, deren Prozesse aufgrund unzureichender Skalierbarkeit zusammenbrachen. Unsere Moderationsprotokolle waren nicht skalierbar, daher nutzten wir die Gelegenheit beim Umstieg von vB auf Discourse, um sie zu überarbeiten. Es war der richtige Schritt.

Hat jemand anderes eine Geschichte zu erzählen?

6 „Gefällt mir“

Vielen Dank, dass du diese Art von Forschungsergebnissen teilst. Offensichtlich ist dieses Forum ein großartiges Beispiel für eine lebendige Foren-Community und ein hervorragendes Beispiel dafür, wie die Discourse-Forumsoftware richtig eingesetzt werden kann. Als Manager einer kleinen und noch wachsenden Community kann man viel von dem hier vorgelebten Beispiel lernen.

Deine Bereitschaft, Erfahrungen aus deiner Kundenbasis zu teilen, ist besonders nützlich und geschätzt.

4 „Gefällt mir“

Ich habe eine kleine, amüsante Geschichte darüber, wie ich eine meiner Communities mit 1,2 Millionen Mitgliedern viel zu spät skaliert habe.

SkyscraperCity ist eine der größten, wenn nicht die größte Community der Welt, die sich Architektur, städtischem Umfeld und metropolitanen Strukturen widmet. Jede Region der Welt mit einem signifikanten Maß an städtischer Entwicklung und zugehörigen größeren Bauwerken hat ihren eigenen Bereich. Natürlich werden dort unzählige Bilder geteilt, denn die Mitglieder dieser Community lieben es, die diskutierten Wolkenkratzer zu zeigen und zu beschreiben.

Das Problem trat nicht dort auf, wo man es vermutet hätte.

Es ging nicht darum, das Handling von Bildern und Anhängen zu spät zu skalieren. Das war ein bekannter Faktor, und die Plattform war darauf ausgelegt, damit umzugehen.

Das Problem entstand, als die Anzahl der verschiedenen Metropolen wuchs. Mit jeder neuen Kategorie, Unterkategorie, Unter-Unter-Unterkategorie – basierend auf Kontinent, Nation, Bundesland und schließlich Stadt, wobei es beliebig viele Stadtviertel geben konnte – wuchs die Komplexität. Die Informationsarchitektur der Community hatte sich so stark erweitert, dass die Plattform nicht mehr damit zurechtkam, wenn all diese Bereiche aktiv wurden. Sie buckelte unter der Last all dieser Kategorien, und die Performance verlangsamte sich auf ein absolutes Krückenlaufen. Es war schmerzhaft, von Seite zu Seite zu navigieren, geschweige denn einen Beitrag zu verfassen!

Die spezifische Plattform war ein älterer, benutzerdefinierter XenForo-Aufbau, der auf Knotenbäumen für Kategorien basierte. Sie war nicht dafür konzipiert, Hunderte oder Tausende einzelner Kategorien als Teil der Struktur zu handhaben. Durch den Aufbau beansprucht jeder Knoten eine beträchtliche Menge an Ressourcen, und je mehr Knoten an einer bestimmten Stelle vorhanden waren, desto instabiler wurde die Plattform. Als Nerd, wie ich bin, habe ich das der Community zur Veranschaulichung mit einer bestimmten Folge von Star Trek: The Next Generation verglichen, in der entdeckt wird, dass Warp-Antriebe zu häufig Löcher in den Raumzeit-Gewebe reißen und den Raum in einem stark frequentierten Gebiet schwächen.

Die unzähligen Kategorien (Unter-Unter-Unter-Unterkategorien und so weiter) verursachten „Schäden“ an der Stabilität der Plattform, genau so, wie Hunderte von Warp-Antrieben, die in und um ein beliebtes Raumgebiet aktiviert wurden, dazu führten, dass dieses Gebiet kollabierte.

Die Lösung unterschied sich nicht viel von der der Föderation, indem man zurückfuhrt und die Durchschläge begrenzt. Also führten wir eine umfassende Überarbeitung der Informationsarchitektur durch, verschmolzen eine Reihe der untergeordneten Kategorien und sogar einige der übergeordneten, und das System stabilisierte sich.

Natürlich tritt dieses Problem bei Discourse nicht auf, da Discourse Kategorien viel besser als erstklassige Container behandelt, anstatt als einen großen, monolithischen Strukturbaum. Ein Myzelnetzwerk oder Transwarp-Leitungen, wenn man so will. Aber dies ist definitiv eines der besten Beispiele, die ich habe, für ein zu frühes Skalieren – und zwar nicht genau dort, wo man den Engpass vermuten würde.

1 „Gefällt mir“

Großartiges Beispiel! Vielen Dank, dass du es geteilt hast.

Ich habe ähnliche Fälle gesehen – nicht in Communities, die ich selbst verwaltet habe, sondern in unserer Kundenbasis. Eine riesige Marke, die ich nicht nennen werde, kam zu uns, um ihre Community nach Discourse zu migrieren. Sie bieten Navigationssoftware an und hatten Unterkategorien für jeden einzelnen geografischen Standort, den sie bedienten.

Zu der Zeit waren wir besorgt über die Belastung der Admin-Funktionen, wenn sie Tausende von Kategorien hätten. Wir lehnten es ab, tiefere Ebenen zu erstellen und versuchten, sie von der Kraft der Tags zu überzeugen, aber sie ließen sich nicht bewegen. Wir haben den Deal abgebrochen, weil er auf keine Weise funktionieren würde, die wir für nachhaltig hielten.

Das Design einer skalierbaren IA ist so wichtig.

1 „Gefällt mir“