Agradeço a equipe do Discourse por estar aberta a sugestões de novas pessoas, lá e em outros lugares também.
Tenho visto esse problema acontecer com frequência no Meta ao longo dos anos, mas isso me motivou a também oferecer minhas opiniões em geral. Também me frustrava ver isso, mas eu realmente não sabia como levantar a questão. Então, tentarei escrever sobre isso agora:
Contexto
Às vezes, no Meta, tenho visto uma tendência de criticar as sugestões de novas pessoas para recursos ou mudanças no Discourse. Em vez de ouvir e entender a experiência de pessoas mais novas no software – cujas percepções podem ser úteis até mesmo para aqueles de nós que usam o Discourse há mais de 10 anos – às vezes, pessoas da comunidade desqualificam a ideia preventivamente.
Muitas vezes, isso acontece se uma ideia foi rejeitada no passado pela equipe do Discourse, ou se uma configuração padrão específica foi escolhida em detrimento de outras configurações pela equipe do Discourse, e assim por diante.
Mesmo que seja o caso, gostaria de oferecer minhas opiniões sobre por que não devemos descartar preventivamente ideias ou reclamações sobre o software, mesmo que já tenham sido discutidas no passado.
A equipe do Discourse tem a palavra final. Muita coisa mudou. Coisas de antigamente podem não se aplicar agora.
Primeiro, nós, como membros da comunidade, não somos os gerentes de produto do Discourse. Se formos dizer a alguém que sua ideia foi rejeitada no passado e por quê, isso pode não refletir necessariamente as decisões atuais da equipe de produto do Discourse.
Às vezes, até mesmo a própria equipe do Discourse pode decidir trabalhar em um recurso que foi previamente descartado no passado. Por muito tempo, o chat foi um desses recursos.
Portanto, nunca há uma garantia de 100% de que as decisões passadas serão as mesmas que as decisões presentes.
Mesmo as pessoas da equipe do Discourse podem ter opiniões diferentes umas das outras sobre o que deve ser uma prioridade para o Discourse.
Por exemplo, eu costumava acompanhar o blog de @erlend_sh e ele discute como tinha uma visão diferente do resto da equipe sobre como o chat deveria ser no Discourse – ênfase em negrito é minha:
A maioria dos projetos de código aberto não tem um fórum dedicado, mas os que têm quase certamente também têm um chat em grupo. Minha última passagem pelo Discourse foi uma tentativa de mesclar os dois modos, com a introdução do Discourse Chat.
Tenho muito orgulho desse MVP (que desde então graduou-se para o núcleo), mas a direção que eu queria seguir a partir daí era compreensivelmente incompatível com o DNA do projeto Discourse como um fórum tradicional: propus que fizéssemos do chat o líder de nossa experiência comunitária. A comunidade começa nas salas de chat, pensei. O Discourse não pensou assim, então nos separamos amigavelmente.
Anos depois, minha posição permanece inalterada. ‘Chat em grupo’ e ‘fórum’ deveriam significar praticamente a mesma coisa. Essa é, de fato, a direção em que parecemos estar indo, já que o Discord, o governante de nossas terras comunitárias, agora suporta uma variedade de recursos de threads e quadros que se encaixam perfeitamente no paradigma do fórum.
Portanto, não cabe a nós decidir prematuramente o que não deve entrar no Discourse, pois isso também pode mudar com o tempo.
Aqueles de nós dos primeiros dias do Discourse se lembrarão de quando a CDCK tinha menos de 10 pessoas e o gerenciamento de produtos era frequentemente muito impulsionado pelos cofundadores do Discourse. Mas hoje a CDCK tem 100 pessoas e a CDCK tem uma equipe de produto inteira!
O próprio Discourse tem uma base de usuários muito, muito maior, cujas necessidades e uso do software cresceram além dos primeiros adotantes iniciais do Discourse. De forma mais ampla, o cenário das plataformas sociais mudou (o momentum mudou do Facebook para o Discord e mais, e assim por diante), e as expectativas gerais das pessoas mudaram.
Como a equipe é muito maior do que nos primeiros dias do Discourse, eles têm mais capacidade para trabalhar em outros recursos que podem ter sido de prioridade muito menor durante os primeiros dias de desenvolvimento de produto, no passado.
Portanto, como eles revisam as solicitações de recursos agora, provavelmente será bem diferente do início. A equipe de produto terá seu próprio processo para tomada de decisões e para decidir o que finalmente será trabalhado e quando.
Mais pontos de dados são melhores
Segundo, geralmente é útil para a equipe do Discourse ouvir mais pontos de dados em vez de menos.
Havia algo amplamente popularizado no Meta como uma Regra de 3 (um mínimo de 3 pessoas reclamam de algo antes que essa solicitação de recurso seja considerada). Mesmo com isso, você tem que deixar as pessoas compartilharem suas experiências e reclamarem, para poder ouvir 3 pessoas diferentes encontrarem um problema com algo.
Além disso, outra ideia popularizada foi o Desenvolvimento Orientado por Reclamações. E com isso, você também tem que ouvir as opiniões das pessoas:
A única coisa que já vi funcionar é mergulhar fundo e sujar as mãos nas trincheiras com seus usuários, comunicando-se com eles e cultivando relacionamentos.
Depois de reler isso, também insisto fortemente que a premissa original por trás dessa “regra de 3” na verdade NÃO é que sua opinião não importa se mais ninguém está reclamando sobre isso.
O cerne da questão era que (especialmente se você é uma equipe com poucos recursos) encontrar as coisas sobre as quais as pessoas mais reclamam é uma maneira eficiente de encontrar os problemas que mais incomodam seus usuários – para que você possa corrigi-los primeiro.
Como Steve Krug diz em Don’t Make Me Think:
Você sempre encontrará mais problemas do que tem recursos para corrigir, então é muito importante que você se concentre em corrigir os mais sérios primeiro. E três usuários provavelmente encontrarão muitos dos problemas mais significativos relacionados às tarefas que você está testando.
Portanto, só porque não muitas outras pessoas reclamaram sobre a mesma coisa, não significa que não importa. Mais pontos de dados ainda são úteis para a equipe do Discourse ao considerar quais são os atuais pontos problemáticos principais/secundários para os usuários.
É possível apreciar o feedback das pessoas, mesmo que você não o implemente
Terceiro, ainda é possível agradecer o feedback das pessoas, mesmo que você não possa implementar todas as suas sugestões ou se decidiu não fazê-lo.
Fiquei mais experiente em lidar com feedback dessa maneira, depois que estudei design de jogos, onde dar e receber feedback era uma parte enorme do processo. Em iterações de cada nível de jogo, documento de design ou qualquer outra coisa, daríamos feedback sobre o trabalho de pelo menos 3 outras pessoas e receberíamos feedback de pelo menos 3 outras. Eu costumava tentar dar feedback para 4 ou 5 pessoas para ajudar a compensar outras pessoas que estavam ausentes / entregando seus trabalhos atrasados, etc.
Muitas vezes, o feedback das pessoas é muito perspicaz e útil, mas há mais de 10 pontos importantes e, no momento, você só tem tempo para implementar 1-3 coisas.
Este também foi o caso quando trabalhei profissionalmente como engenheiro de software, interagindo frequentemente com a comunidade, como parte de uma pequena startup. Pode haver mais de 10 relatórios de bugs importantes, mas na próxima atualização, você tem tempo para corrigir 1-3 deles.
Em qualquer caso, ainda me sinto muito obrigado a agradecer às pessoas por suas observações, agradecer por compartilharem suas opiniões, agradecer por dedicarem tempo para escrever os passos para reproduzir um bug e pedir desculpas pelo inconveniente.
Na maioria das vezes, os usuários/jogadores não dizem nada a menos que estejam realmente incomodados. Portanto, a maioria dos feedbacks escritos/solicitações de recursos/relatórios de bugs vêm de alguém que dedicou tempo para compartilhar suas opiniões sobre algo – coisas que muitas outras pessoas podem ter pensado, mas ainda não identificaram ou disseram nada sobre, coisas que você provavelmente perdeu, e assim por diante.
Portanto, mesmo que você não possa implementar tudo o que todos dizem — o que pode ser até 90% das vezes — isso não significa que você tenha que aceitar todo esse feedback e segui-lo. O feedback ainda é importante, mesmo que você não tenha os recursos para agir sobre ele no momento ou mesmo que tenha decidido não agir sobre ele.
Enfim, é por isso que acho que vale a pena, para nós como membros da comunidade, deixar outras pessoas mais novas compartilharem suas opiniões e não criticar imediatamente as sugestões das pessoas para o Discourse. Isso ocorre porque a posição da equipe do Discourse sobre recursos pode mudar com o tempo, e o feedback ainda é útil como pontos de dados para a equipe do Discourse, mesmo que eles possam não implementá-lo no momento.