/ blog
A dualidade do feedback, amargodon't
Uma das minhas lutas diárias costuma ser decidir o que fazer com meus múltiplos interesses. É impossível abarcar todos eles, a tal ponto que focar em um termina “esgotando” essa cota diária, então vivo num switch focus-mind constante. Coisa que não me incomoda, aliás, já me acostumei.
No entanto, não posso negar o aumento de eficiência quando o foco é mais concreto, mas essa parte prefiro deixar para o horário de trabalho.
Para mim, meus interesses, meus hobbies… prefiro fazer as coisas do meu jeito.
Foi aí que encontrei no homelab, primeiro, o abismo. Depois, a salvação. Algo quase tão poético quanto bíblico.
Por pura nostalgia, ressuscitei um jogo de Dragon Ball online. Começou self-hosted, para hoje viver numa VPS, deixando meu lab como algo puramente experimental. Porém, esse período me permitiu algo que até então minhas tentativas fracassadas com produtos diferentes não tinham conseguido.
Usuários reais, dando feedback constante.
Os números do Grafana aumentavam pouco a pouco. Eu conseguia ver como alguns mapas eram mais frequentados que outros, onde preferiam subir de nível, onde farmar loot, onde se divertiam mais em geral. Era a primeira vez que eu tinha dados reais sobre pessoas usando algo construído por mim, e, também pela primeira vez, deixei de pensar só no que eu queria fazer para começar a me perguntar o que eles precisavam.
E aí, com esses dados, entendi algo triste. O jogo, tendo muita coisa para fazer, muito para explorar, um mapa adequado ao universo Dragon Ball… tinha um problema enorme.
O mundo não estava vivo.
Comecei a me conectar com a conta de GM a toda hora. Cada vez que via um jogador online, ia até ele. Pedia feedback. Todos pediam coisas diferentes: coisas que sentiam falta de outros jogos, coisas que gostariam de ter, coisas que eles fariam diferente.
Comecei a analisar cada pedido e me deparei com um choque de realidade. Eu estava trabalhando sobre uma base 8.60, popular no seu nicho, mas muito old-school para os dias de hoje. Não permitia sistema de montarias, nem voar, nem pescar, nem… nem… nem…
Resolver isso exigia migrar. Algo tão óbvio quanto dizer que faço amanhã. Mas, como toda migração, implicava mudar completamente minha estrutura.
Para dar uma dimensão, a versão 8.60 é do ano 2010, e está sendo migrada para o OTClient Redemption (Canary) 1525. Isso significa 16 anos de otimizações, correções e uma comunidade que continuou evoluindo enquanto esse projeto ficava congelado no tempo.
E ótimo, posso ir fazendo isso enquanto aprendo esse novo ecossistema. Leva tempo, mas é possível.
Mas havia algo que continuava incomodando.
Mesmo fazendo tudo isso, eu continuaria com um problema muito mais radical.
O mapa.
Que, embora tenha uma boa aparência, tem um design que favorece os portais, zonas seguras em todo lugar, fazendo com que a interação entre os jogadores fosse baixa demais. Fazendo com que o jogo, mesmo com jogadores online, parecesse mais morto do que vivo.
E aí entendi outra coisa.
O problema já não era só técnico.
Era de design.
Entre os issues reportados pelo portal, tinha de tudo. Gente sendo agressiva, enquanto outros escreviam o passo a passo para reproduzir um problema com todo o detalhe.
No começo, era inevitável valorizar muito mais os segundos. Era fácil agradecer um relatório bem escrito, estruturado, quase pronto para se transformar numa tarefa.
Mas, com o tempo, comecei a notar um padrão.
Muitos dos relatos agressivos apontavam problemas reais. Estavam escritos da pior forma possível, sim, mas ainda assim apontavam para algo que merecia atenção.
A esses últimos, obrigado.
Aos primeiros… também.
Porque até a falta de educação deles continuava me dando um input útil.
Se essa experiência me deixou alguma coisa, foi entender que escutar feedback não significa escutar só quem sabe se comunicar bem.
Significa tentar entender qual problema existe atrás das palavras.
E acho que isso vale bem além de um servidor de Dragon Ball.
No trabalho.
Num projeto pessoal.
Numa startup.
Até na vida.
As pessoas são outras por trás da cortina.
E aprender a separar o tom da mensagem é provavelmente uma das habilidades mais incômodas, mas também uma das mais úteis que terminei desenvolvendo.
