Как по-вашему выглядит «готовность для корпоративного использования»? (Приветствуются смелые мнения!)

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

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

Какое, по вашему мнению, определение «готовности к корпоративному использованию» (enterprise-ready) применимо к вашему сообществу? Я имею в виду это и с точки зрения состояния и готовности платформы сообщества, и с точки зрения наличия устоявшейся базовой контента и активности. Мне бы очень хотелось опровергнуть мнение, что это скорее искусство, чем наука, и что здесь существуют четкие общие паттерны!

Активность, вероятно, легче измерить — для этого существует множество ориентиров.

Одним из часто упоминаемых определений «активности» в форумах является определение Reddit того, что составляет «активный» сабреддит, которое я в прошлом использовал как эвристику для оценки успеха в формировании критической массы. Исторически это означает «не менее пяти постов в день». Ранее Reddit считал сообщество активным, если в сабреддите было не менее пяти постов или комментариев за день. Я знаю, что достиг уровня самодостаточной активности в новом сообществе, если ежедневно появляется такое количество постов или комментариев без необходимости моего вмешательства или стимуляции. Это также отличный тест для новой ветви обсуждения или подкатегории. Если вы создаете новую категорию и можете развить её до 5 и более постов в день без вашего непосредственного участия, значит, у вас получилась крепкая категория.

Для «готовности к корпоративному использованию», особенно в B2B- или клиентских сообществах, я бы скорректировал это определение: 5 и более постов или комментариев в день, ПЛЮС гарантированный ответ на 80% тем в течение 48 часов по принципу SLA. Мне кажется важным обеспечить, чтобы новые посты не оставались без внимания и ответов, но при этом дать теме немного времени на «дыхание» и возможность для органичного ответа.

У вас есть какая-то предпочтительная формула? Неужели я сошел с ума, предлагая такой уровень отклика? :grin:

И не будем слишком жестко разделять тему, но как выглядит «готовность к корпоративному использованию» на уровне платформы? В моем кратком списке: наличие надежной таксономии/информационной архитектуры для первичных категорий, функция «решено» или «лучший ответ», продуманные уведомления и маршрутизация, чтобы удерживать время ответа на новые темы в рамках ожидаемых значений, и как минимум несколько человек, готовых заниматься модерацией. Я также очень настаиваю на наличии темы оформления, которая соответствует организации, для которой создается сообщество, но это, конечно, вопрос личных предпочтений.

Каково ваше мнение (будь оно популярным, спорным или неортодоксальным) о том, как выглядит «готовое к корпоративному использованию» сообщество?

7 лайков
What are some common breaking points as communities grow?
What are some signals that a community is moving beyond early-stage?
2

Когда я слышу «готовность для корпоративного использования», я думаю о надежности, доступности и производительности при масштабировании, что может не совпадать с тем, что вы имеете в виду.

Время безотказной работы сайта на уровне 99,99% (четыре девятки), и в зависимости от того, как вы трактуете доступность, запуск сервиса в архитектуре высокой доступности или масштабируемой архитектуры, где потеря компонента может привести к снижению емкости, а не к потере доступности.

На следующем уровне потребуется рассмотреть либо глобальную балансировку нагрузки, либо межрегиональную балансировку нагрузки, либо сценарии аварийного восстановления за пределами региона.

Я думаю о размере пользовательской базы и уровне активности (встроенные показатели DAU/MAU и другая статистика предоставляют отличные данные).

Сможет ли ваш сайт поддерживать 10 000 одновременных активных пользователей без задержек при загрузке изображений или использовании функций чата?

Когда пользователи начинают замечать проблемы с производительностью или задержки/латентность?

Обратите внимание, что я придерживаюсь нескольких убеждений: архитектура определяет стоимость, и понимание того, как вы хотите спроектировать сообщество на начальном этапе, имеет значение при масштабировании. Это сложно, потому что, если вы не начинаете с корпоративного масштаба, то, что вам нужно для 100 пользователей, может кардинально отличаться от того, что потребуется для 1000 или 10 000.

Здесь есть много аспектов для разбора: простота монолитной архитектуры, риски единичных точек отказа по сравнению с целевыми показателями доступности, и то, как подходы вроде Docker и Kubernetes добавляют сложности, но при этом обеспечивают возможность масштабирования.

Я большой поклонник Discourse, мое сообщество небольшое, и я не уделял сколько-нибудь значимого времени оценке того, как я мог бы превратить такое программное обеспечение, как Discourse, в SaaS (что, как я предполагаю, крутые ребята из Meta уже решили и сделали это выглядеть простым).

Сменив тему, думаю, что вы, возможно, спрашиваете о SLA (соглашениях об уровне сервиса, которые подразумевают контракты) или SLO (целях уровня сервиса, которые можно использовать для установления ожиданий). Это также возвращается к дизайну.

Сколько у вас модераторов или сотрудников, каково соотношение модераторов к пользователям, как это соотносится с объемом публикаций и соотношением помеченных постов к общему количеству постов (в качестве примера). Если у вас один администратор и даже 100 пользователей, я не уверен, что готов обязаться SLO в один рабочий день.

Последние два совета, которые я дам: начинайте с конца и создавайте свой дизайн на основе четких требований.

Надеюсь, это было полезно! Удачи!

3 лайка
3

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

Производительность — это один из тех аспектов, о которых не так часто говорят в кругах менеджеров сообществ, но в этом плане у Discourse действительно есть превосходные преимущества.

Но это, безусловно, важный фактор. Одним из самых ярких примеров, которые я могу привести, является Skyscraper City, который я управлял; он работал на старой версии XenForo. Это огромное B2C-сообщество энтузиастов, и из-за огромного количества категорий и подкатегорий, а также множества разделов обсуждений, разделенных по регионам и зонам, оно работало с задержками и было крайне неудобным в использовании. Несмотря на наличие уникального в мире контента, оно вызывало одно из самых больших количество жалоб на производительность.

Что касается самого дизайна сообщества, то разница в «готовности к работе в корпоративном сегменте» носит инфраструктурный, а не производительный характер. Хотя я не уверен, проводились ли какие-либо исследования порогов терпимости для самих сообществ, — у нас есть исследования Core Web Vitals. Chromium Blog: The Science Behind Web Vitals Я всегда склонен думать, что терпимость и готовность мириться с низкой производительностью обратно пропорциональны активности участников сообщества: чем выше их вовлеченность, тем выше их терпимость.

Мне было бы интересно узнать мнение других о необходимых требованиях для определения «готовности к работе в корпоративном сегменте» сообщества, помимо часто игнорируемого обязательного условия «Оно должно быть быстрым. Врум-врум!» :high_voltage:

3 лайка