Os riscos de escalar tarde demais vs. cedo demais

Comunidade Empresa
1

Nunca é cedo demais para começar a planejar o crescimento futuro. Depois de determinar se você está construindo uma biblioteca ou uma cafeteria, você pode começar a projetar estratégias adaptativas.

Realizamos algumas pesquisas sobre nossa base de clientes e descobrimos três sinais iniciais que parecem aparecer consistentemente em clientes cujas comunidades enfrentam dificuldades:

  • Nenhum caso de uso claro / direção básica de lançamento
  • Falta de alinhamento entre as partes interessadas / propriedade clara
  • Falta de progresso inicial (as coisas estagnam após o kickoff)

Se essas questões fundamentais não forem abordadas desde o início, elas se tornam um indicador principal de falhas posteriores.

Se você as abordar tarde demais, a comunidade se torna cada vez mais frágil e corre o risco de fragmentação precoce. Veja Fragmentação da Comunidade: Quando o Crescimento se Torna Seu Obstáculo.

Os riscos de agir muito cedo não são tão altos e tendem a se manifestar como:

  • processos mais complexos do que o necessário
  • membros enfrentando atritos desnecessários
  • carga de trabalho pesada para a equipe
  • cidades fantasma
  • falta de dados significativos para relatórios

Leitura adicional
Ciclo de Vida da Comunidade: Do Lançamento ao Legado

A comunidade que eu menciono no artigo acima é um bom exemplo de uma comunidade que teve processos quebrados devido à escalabilidade insuficiente. Nossos protocolos de moderação não eram escaláveis, então aproveitamos a oportunidade quando migramos do vB para o Discourse para revisá-los. Foi a decisão certa.

Alguém mais tem uma história para contar?

6 curtidas
2

Obrigado por compartilhar esse tipo de resultado de pesquisa. Obviamente, este fórum é um ótimo exemplo de uma comunidade de fórum vibrante e um excelente exemplo de uso adequado do software de fórum Discourse. Como gestor de uma comunidade pequena e ainda em crescimento, há muito a aprender com o exemplo estabelecido aqui.

Sua disposição para compartilhar experiências obtidas com sua base de clientes é especialmente útil e apreciada

4 curtidas
3

Tenho uma historinha divertida sobre ter escalado tarde demais uma das minhas comunidades, que tinha 1,2 milhão de membros.

O SkyscraperCity é uma das maiores, senão a maior comunidade dedicada à arquitetura, ao ambiente urbano e às estruturas metropolitanas do mundo. Cada região do mundo com um nível significativo de desenvolvimento urbano e estruturas maiores associadas tem sua própria seção. Naturalmente, há uma quantidade massiva de fotos compartilhadas, porque, bem, os membros dessa comunidade realmente, realmente adoram mostrar e contar sobre os arranha-céus que estão sendo discutidos.

O problema não surgiu no lugar em que você esperaria.

O problema não foi atrasar a escalabilidade do processamento de imagens e anexos. Isso seria um fator conhecido, e a plataforma foi construída para lidar com isso.

O problema aconteceu à medida que o número de áreas metropolitanas distintas crescia, e com cada nova categoria, subcategoria, sub-sub-subcategoria baseada em continente, nação, estado e, finalmente, cidade, das quais poderia haver qualquer número de bairros. A arquitetura de informações da comunidade havia crescido além da capacidade da plataforma de lidar com cada uma dessas áreas tornando-se ativa. Ela estava se curvando sob o peso de todas aquelas categorias, e o desempenho havia desacelerado a um rastejar completo. Era simplesmente doloroso navegar de uma página para outra, quanto mais fazer uma postagem!

A plataforma específica era uma versão personalizada mais antiga do XenForo, construída com árvores de nós para categorias; ela não foi projetada para lidar com centenas e milhares de categorias individuais como parte da estrutura. Da maneira como foi construída, cada nó ocupa uma boa quantidade de recursos, e quanto mais nós em um determinado ponto, menos estável a plataforma. Sendo um nerd, como eu sou, a maneira como descrevi isso à comunidade para visualização foi compará-la a um episódio específico de Star Trek: The Next Generation, quando descobriram que os motores de dobra estavam abrindo buracos no tecido do espaço/tempo um pouco frequentemente demais, enfraquecendo o espaço em uma área altamente transitada.

As zilionésimas categorias (sub-sub-sub-subcategorias e assim por diante) estavam causando “danos” à estabilidade da plataforma da mesma maneira que centenas de motores de dobra sendo ativados em e ao redor de uma área popular do espaço estavam fazendo essa área colapsar.

A solução não foi muito diferente da da Federação, no sentido de que você reduz a velocidade e limita as perfurações. Então, fizemos uma revisão completa da arquitetura de informações, fundimos várias das categorias de nível inferior e até algumas das superiores, e o sistema se estabilizou.

Claro, esse problema não aparece com o Discourse, já que o Discourse trata as categorias muito melhor como contêineres de primeira classe, em vez de uma grande árvore estrutural. Uma rede micelial ou condutos de transdobra, se preferir. Mas este é definitivamente um dos melhores exemplos que tenho de escalar muito cedo, e não exatamente no lugar em que você pensaria que o impacto viria.

1 curtida
4

Ótimo exemplo! Obrigado por compartilhar.

Já vi casos semelhantes — não em comunidades que gerenciei, mas em nossa base de clientes. Uma grande marca, que não nomearei, procurou-nos querendo migrar sua comunidade para o Discourse. Eles fornecem software de navegação e tinham subcategorias para cada localização geográfica que atendiam.

Na época, estávamos preocupados com a carga nas funções administrativas se eles tivessem milhares de categorias. Recusamo-nos a criar camadas mais profundas e tentamos convencê-los do poder das tags, mas eles não cederam. Desistimos do negócio porque nunca funcionaria de uma forma que acreditávamos ser sustentável.

Projetar uma IA escalável é tão importante.

1 curtida