Priorização do feedback da comunidade

O produtor Vincent Malley traz algumas dicas sobre o processo de priorização do feedback da comunidade! Para discussões sobre este tópico, visite os fóruns!


Quanto à priorização:
 
Não há um sistema que cobre totalmente como priorizamos as coisas. Geralmente, daremos a máxima atenção a questões que impedem as pessoas de jogarem o jogo (incluindo obter recompensas) ou problemas que possam afetar nossa capacidade de manter o jogo em execução (por exemplo, o Mercado Zen não funciona - o que é desagradável como algumas pessoas podem sentir É, o jogo precisa para permitir que os jogadores para comprar e gastar Zen, a fim de permanecer em desenvolvimento ativo). Então é uma questão de uma pessoa encarregada da triagem de bugs fazendo perguntas como essas:

Impacto
 

    Como jogador, como isso me afeta?

    Gostaria de deixar o jogo por causa disso?

    Mesmo se eu não deixasse o jogo para esta edição específica, causaria a insatisfação a longo prazo?


Viabilidade
 

    Compreendemos a questão num nível técnico, e é possível reproduzir isso em um ambiente controlado para que possamos provar que está corrigido?

    Qual parcela da base do jogador é afetada, e existe uma solução alternativa conhecida pelo jogador?

    É possível corrigir de uma boa maneira, ou precisamos fazer uma mudança mais rápida, menos abrangente que pode causar mais problemas na linha?

    A correção corre o risco de ser pior do que a questão em si?

    A correção se encaixa dentro de um novo ciclo de teste de compilação? Podemos mesmo obtê-lo nas atualizações do módulo atual?

    Temos uma correção melhor e mais abrangente em um futuro módulo? Se assim for, é logo o suficiente que podemos deixar este problema deslizar por enquanto?


Basicamente, se houver uma pergunta que afete a forma como você priorizaria um problema se estivesse no nosso lugar, provavelmente é uma pergunta que nos fazemos ou que pode contribuir para a priorização de um bug, recurso ou pedaço de feedback.

Há um elemento humano na triagem destas questões, também. Essas perguntas podem ter peso diferente para pessoas diferentes - todos nós temos nossas diferentes maneiras de jogar e perceber o jogo, e alguns de nós são mais conhecedores do que outros sobre certos conteúdos, certos sistemas de recompensa, certos fluxos de UI, etc Se tivermos perguntas Nós não podemos responder, vamos falar com um membro da equipe que sabe - mas às vezes os membros da equipe estão doentes, de férias, ou só conhecem parte de um problema.

Mesmo uma diferença na redação pode afetar como algumas dessas perguntas são respondidas. Como um exemplo disso, veja "Great Weapon Fighter: Unstoppable pode tornar-se temporariamente inutilizável durante o combate" vs. "Great Weapon Fighter: Ao ativar imparável direito antes de ganhar determinação, jogador fica bloqueado de usá-lo novamente. Um mistério aberto pode afundar dias de tempo de desenvolvimento, mas o tidbit direito da informação pode mudar uma edição de "eu não tenho nenhum indício onde começar mesmo" a "oh, mim poderia tentar esta mudança, e se que falha então eu ' Pelo menos, descartou uma boa hipótese ".

Há também o aspecto divertido de: Não importa o quão bem podemos saber o jogo, os jogadores sabem que é melhor. Nosso conhecimento do jogo é inatamente afetado por nós vendo como ele funciona no back-end, e nossa percepção é tendenciosa em direção ao conhecimento de como ele "deve" trabalhar, ao invés de potenciais fatores emergentes.



Sobre como obter / escalar relatórios e comentários:
 
Nossa informação pode vir de muitas fontes. Muitas vezes, antes do lançamento de um módulo, ele vem de nossa equipe de garantia de qualidade (conhecida como QA ou testadores), playtests em toda a equipe ou tópicos de comentários no fórum de visualização. Após o lançamento de um módulo, ele vem mais frequentemente das tendências identificadas pelo Suporte ao Cliente, da nossa equipe da Comunidade (muitas vezes escalada pelo Nitocris83 / Julia e vários outros) e dos próprios fóruns, onde eles podem ser vistos e escalados por mim ou por outros desenvolvedores Que procuram (se Julia não tinha chegado a eles primeiro).

Se eu vejo um relatório de bug publicado nos fóruns, eu mesmo, muitas vezes escrevo um resumo rápido e um potencial primeiro tiro em etapas de reprodução para nossa equipe de controle de qualidade, e depois de verificá-lo, ele é escrito oficialmente em nosso banco de dados de bug. Este é o lugar onde a formulação dos posts do jogador entra em jogo - eu tenho um "jack of all trades" conhecimento de trabalho do jogo e ter uma compreensão solta de como a maioria dos sistemas de trabalho nos bastidores, por isso, se um jogador relata para mim, Como exemplo, "Ao usar qualquer Artifact Off-Hand, se eu classificar o Aspect of the Pack para Rank 4, o efeito Class Feature deixa de funcionar no poder", é relativamente fácil para mim dizer: "Oh, isso é Provavelmente uma questão com algum pré-requisito em um segmento de configuração do poder ", e é então uma tarefa viável para traduzir isso em termos de nossos desenvolvedores serão capazes de agir fora de sem investigação extra significativa. Se, em vez disso, um relatório de bugs for usado, para usar um exemplo hiperbólico, eu realmente não vi, "AotP está quebrado", então não está claro por onde começar a procurar, supondo que eu mesmo saiba o que esse acrônimo é - e se nossa equipe de QA já está inundada , Eu não vou ser capaz de escalar isso para eles em boa consciência.


Ainda assim, muitas vezes estou disposto a fazer algumas pesquisas, dependendo da gravidade percebida da questão (ou, desde que eu sou humano, o fascínio de um mistério se eu tiver o suficiente de um palpite de como descobrir). Só depende muito de quanto tempo eu tenho disponível entre outras coisas que eu preciso para fazer.

Feedback é muito o mesmo, embora causa e efeito são um pouco mais squishier. "Eu não gosto de X" e "Eu gosto de Y" são importantes para nós ouvir, mas torna-se muito mais fácil se concentrar no que está funcionando eo que não é quando compreendemos as partes individuais envolvidas. "Eu não gosto do Arcanic Focus grind agora, porque parece que o jogo está me dizendo que eu preciso moer sites de escavação por 12 horas por dia para fazer o progresso da campanha padrão" é um grande pedaço de feedback, porque nos diz a Perspectiva a partir da qual as pessoas estão falando, a meta para a qual eles querem o foco Arcanic (progressão da campanha), e alude a potenciais erros ou falhas de design em taxas de queda.

Haverá sempre mais relatórios do que nós podemos campo, mas nós poderia sempre fazer melhor e melhorar em nossa comunicação e respostas para estes. Eu sei que, pessoalmente, tenho algumas semanas onde eu estou na bola para as respostas aos relatórios de bugs, e algumas semanas em que eu mal posso encontrar o tempo para rever o fórum em tudo.



TL; DR prioridade: A priorização é difícil e não uma ciência. Se ele mantém as pessoas de jogar o jogo ou nos apoiar, que provavelmente vai ver mais atenção. O resto é um julgamento baseado em perguntas que nos fazemos, e risco / tempo contra recompensa.

TL; DR para escalonamento: ao relatar bugs e comentários, torna-se muito mais fácil para mim escalar quando há uma causa e efeito claros - mas não deixe que isso impedi-lo de relatar problemas para os quais você não tem essas informações, Se você acha que a gravidade é ruim o suficiente. Lembre-se também que os desenvolvedores nem sempre estão atualizados sobre as abreviações padrão.