Риски масштабирования: слишком поздно против слишком рано

Создание сообщества Корпорация
1

Никогда не рано начать планировать будущий рост. Как только вы определитесь, строите ли вы библиотеку или кофейню, вы сможете приступить к разработке адаптивных стратегий.

Мы провели исследование нашей клиентской базы и обнаружили три ранних сигнала, которые стабильно проявляются у клиентов с сообществами, испытывающими трудности:

  • Отсутствие четкого сценария использования / базового направления запуска
  • Отсутствие согласованности между заинтересованными сторонами / четкого распределения ответственности
  • Отсутствие ранних успехов (процессы застывают после стартового этапа)

Если эти ключевые аспекты не будут решены с самого начала, они становятся ведущим индикатором последующих неудач.

Если вы займетесь ими слишком поздно, сообщество станет все более уязвимым и подвергнется риску ранней фрагментации. См. Фрагментация сообщества: когда рост становится препятствием.

Риски, связанные со слишком ранними действиями, не так велики и обычно проявляются в виде:

  • процессов, более сложных, чем необходимо
  • ненужных трудностей для участников
  • высокой нагрузки на сотрудников
  • «городов-призраков» (неактивных сообществ)
  • отсутствия значимых данных для отчетности

Дополнительные материалы
Жизненный цикл сообщества: от запуска до наследия

Сообщество, упомянутое в статье выше, является хорошим примером сообщества, чьи процессы дали сбой из-за недостаточной масштабируемости. Наши протоколы модерации не были масштабируемыми, поэтому, когда мы перешли с vB на Discourse, мы воспользовались возможностью пересмотреть их. Это было правильное решение.

У кого-нибудь еще есть похожая история?

6 лайков
2

Спасибо, что поделились результатами такого рода исследований. Очевидно, этот форум — прекрасный пример живой и активной форумного сообщества, а также отличный образец того, как следует правильно использовать программное обеспечение Discourse. Как менеджер небольшого, но растущего сообщества, я могу многому научиться на примере, показанном здесь.

Ваша готовность делиться опытом, полученным на основе работы с клиентской базой, особенно полезна и высоко ценится.

4 лайка
3

У меня есть забавная история о том, как я слишком поздно масштабировал одну из своих сообществ численностью 1,2 миллиона участников.

SkyscraperCity — одно из крупнейших, если не самое крупное сообщество в мире, посвященное архитектуре, городской среде и высотным зданиям. У каждого региона мира с существенным уровнем урбанизации и соответствующими крупными сооружениями есть свой раздел. Естественно, там публикуется огромное количество фотографий, потому что участники этого сообщества просто обожают показывать и рассказывать о обсуждаемых небоскребах.

Проблема возникла не там, где вы могли бы ожидать.

Проблемой не было позднее масштабирование обработки изображений и вложений. Это был известный фактор, и платформа была спроектирована с учетом этого.

Проблема возникла по мере роста количества отдельных метрополий, и с каждой новой категорией, подкатегорией, под-под-подкатегорией, основанной на континенте, стране, штате и, наконец, городе, в котором могло быть любое количество районов. Информационная архитектура сообщества вышла за пределы возможностей платформы справляться с активностью в каждом из этих разделов. Она начинала ломаться под тяжестью всех этих категорий, а производительность упала до ползущей скорости. Навигация со страницы на страницу была downright болезненной, не говоря уже о создании новых постов!

Используемая платформа была старой кастомной сборкой XenForo, построенной на древовидной структуре категорий, и она не была рассчитана на обработку сотен и тысяч отдельных категорий в рамках этой структуры. Из-за такого подхода каждый узел занимал значительное количество ресурсов, поэтому чем больше узлов было в определенной точке, тем менее стабильной становилась платформа. Как любитель технических деталей, я описал это сообществу для наглядности, сравнив с определенным эпизодом «Звездного пути: Следующее поколение», когда они обнаружили, что варп-двигатели слишком часто прорывают дыры в ткани пространства-времени, ослабляя пространство в районе с интенсивным движением.

Миллионы категорий (под-под-под-подкатегории и так далее) наносили «ущерб» стабильности платформы так же, как активация сотен варп-двигателей в популярном районе космоса приводила к его коллапсу.

Решение не сильно отличалось от решения Федерации: нужно было ограничить и контролировать количество «прорывов». Мы провели тщательный пересмотр информационной архитектуры, объединили множество нижних уровней категорий и даже некоторые из верхних, и система стабилизировалась.

Конечно, эта проблема не возникает в Discourse, поскольку Discourse относится к категориям гораздо лучше, как к первоклассным контейнерам, а не как к одному большому структурному дереву. Если хотите, это микоризная сеть или транзварп-каналы. Но это определенно один из самых ярких примеров, когда масштабирование происходит слишком рано и не там, где вы ожидаете удара.

1 лайк
4

Отличный пример! Спасибо, что поделились.

Я видел похожие случаи — не в сообществах, которыми я управлял, а среди нашей клиентской базы. Одна крупная компания, которую я не буду называть, обратилась к нам с просьбой перенести своё сообщество на Discourse. Они разрабатывают навигационное ПО и создавали подкатегории для каждого географического региона, где предоставляли свои услуги.

Тогда нас беспокоила нагрузка на административные функции, если бы у них было тысячи категорий. Мы отказались создавать более глубокие уровни вложенности и пытались убедить их в эффективности тегов, но они были непреклонны. Мы отказались от сделки, поскольку считали, что такое решение никогда не будет устойчивым.

Проектирование масштабируемой информационной архитектуры имеет огромное значение.

1 лайк