Los riesgos de escalar demasiado tarde vs. demasiado pronto

Comunidad Empresa
1

Nunca es demasiado pronto para empezar a planificar el crecimiento futuro. Una vez que hayas determinado si estás construyendo una biblioteca o una cafetería, puedes comenzar a diseñar estrategias adaptativas.

Realizamos algunas investigaciones sobre nuestra base de clientes y descubrimos tres señales tempranas que parecen aparecer consistentemente en clientes con comunidades que luchan:

  • Sin un caso de uso claro / dirección básica de lanzamiento
  • Falta de alineación de las partes interesadas / propiedad clara
  • Falta de progreso temprano (las cosas se estancan después del inicio)

Si estas cosas clave no se abordan desde el principio, se convierten en un indicador principal de fracaso posterior.

Si los abordas demasiado tarde, la comunidad se vuelve cada vez más frágil y corre el riesgo de fragmentarse prematuramente. Ver Fragmentación de la comunidad: cuando el crecimiento se convierte en tu obstáculo.

Los riesgos de actuar demasiado pronto no son tan altos y tienden a manifestarse como:

  • procesos más complejos de lo necesario
  • los miembros experimentan fricciones innecesarias
  • una carga de trabajo pesada para el personal
  • pueblos fantasma
  • la falta de datos significativos para informes

Lectura adicional
El ciclo de vida de la comunidad: del lanzamiento al legado

La comunidad a la que me refiero en el artículo anterior es un buen ejemplo de una comunidad que tenía procesos defectuosos debido a una escalabilidad insuficiente. Nuestros protocolos de moderación no eran escalables, así que aprovechamos la oportunidad cuando nos mudamos de vB a Discourse para revisarlos. Fue la decisión correcta.

¿Alguien más tiene una historia?

6 Me gusta
2

Gracias por compartir este tipo de resultados de investigación. Obviamente, este foro es un gran ejemplo de una comunidad de foros vibrante y un excelente ejemplo de cómo utilizar adecuadamente el software de foros Discourse. Como administrador de una comunidad pequeña y aún en crecimiento, hay mucho que aprender del ejemplo establecido aquí.

Su disposición para compartir experiencias obtenidas de su base de clientes es especialmente útil y apreciada

4 Me gusta
3

Tengo una divertida anécdota sobre escalar demasiado tarde una de mis comunidades de 1,2 millones de miembros.

SkyscraperCity es una de las comunidades más grandes, si no la más grande, dedicada a la arquitectura, el entorno urbano y las estructuras metropolitanas en el mundo. Cada área del mundo con un nivel significativo de desarrollo urbano y estructuras asociadas más grandes tiene su propia sección. Naturalmente, tiene una cantidad masiva de imágenes compartidas dentro de ella, porque, bueno, los miembros de esa comunidad realmente, realmente les gusta mostrar y contar sobre los rascacielos que se están discutiendo.

El problema no surgió en el lugar donde uno pensaría que lo haría.

El problema no fue escalar el manejo de imágenes y adjuntos tarde. Eso iba a ser un factor conocido, y la plataforma estaba construida para manejarlo.

El problema ocurrió a medida que crecía el número de áreas metropolitanas distintas, y con cada nueva categoría individual, subcategoría, sub-sub-subcategoría basada en continente, nación, estado y finalmente ciudad, de las cuales podría haber cualquier número de barrios. La arquitectura de información de la comunidad había escalado más allá de la capacidad de la plataforma para hacer frente a cada una de esas áreas volviéndose activas. Se estaba doblando bajo el peso de todas esas categorías, y el rendimiento se había ralentizado hasta un arrastre total. Era directamente doloroso navegar de página en página, ¡digamos nada de hacer una publicación!

La plataforma específica era una construcción personalizada más antigua de XenForo construida sobre árboles de nodos para categorías, no estaba diseñada para manejar cientos y miles de categorías individuales como parte de la estructura. La forma en que estaba construida, cada nodo ocupa una buena cantidad de recursos, y por lo tanto, cuantos más nodos en un cierto punto, menos estable la plataforma. Como nerd que soy, la forma en que lo describí a la comunidad para visualizarlo fue comparándolo con un episodio particular de Star Trek: La Nueva Generación, cuando descubrieron que los motores de salto estaban haciendo agujeros en la tela del espacio/tiempo un poco demasiado frecuentemente, debilitando el espacio en un área que era altamente transitada.

Las zillion categorías (sub-sub-sub-subcategorías y así sucesivamente) estaban causando “daño” a la estabilidad de la plataforma de la misma manera que cientos de motores de salto siendo activados en y alrededor de un área popular del espacio estaban causando que esa área colapsara.

La solución no fue disimilar a la de la Federación, en que reduces y limitas los pinchazos. Así que ejecutamos una revisión completa de la arquitectura de información, fusionamos un montón de las categorías de nivel inferior e incluso algunas de las superiores, y el sistema se estabilizó.

Por supuesto, este problema no aparece con Discourse, ya que Discourse trata las categorías mucho mejor como contenedores de primera clase, en lugar de un gran árbol estructural. Red micelial o conductos de transvelocidad, si lo prefieres. Pero esto es definitivamente uno de los ejemplos más claros que tengo de escalar demasiado pronto, y no exactamente donde uno pensaría que vendría el golpe.

1 me gusta
4

¡Gran ejemplo! Gracias por compartirlo.

He visto casos similares, no en comunidades que he gestionado, sino en nuestra base de clientes. Una gran marca, que no nombraré, se acercó a nosotros buscando migrar su comunidad a Discourse. Proporcionan software de navegación y tenían subcategorías para cada ubicación geográfica que servían.

En ese momento, estábamos preocupados por la carga en las funciones de administración si tenían miles de categorías. Nos negamos a crear capas más profundas e intentamos convencerlos del poder de las etiquetas, pero no cedieron. Nos retiramos del acuerdo porque nunca iba a funcionar de una manera que creyéramos sostenible.

Diseñar una IA escalable es muy importante.

1 me gusta