Tickets e Feature Requests: o diálogo como parte do produto
Como abrir um ticket no Narraya, como propor uma funcionalidade, e porque o diálogo com os autores é parte integrante do produto. Tempos honestos, respostas humanas.
Há duas experiências opostas, quando algo num software deixa de funcionar. A primeira: abre um ticket, recebe um email automático, depois o silêncio, depois — ao fim de cinco dias — uma resposta vaga a pedir-lhe para "reiniciar o browser". A segunda: abre um ticket, recebe uma resposta humana em um ou dois dias, o problema é levado a sério, e por vezes até resolvido. A diferença entre as duas experiências não é técnica: é de cultura.
O Narraya é um projecto jovem, pequeno, construído por poucas mãos. Não podemos dar-nos ao luxo da primeira experiência. E, para dizer a verdade, também não a queremos.
O canal de Tickets, para quando algo corre mal
Os tickets, no Narraya, servem para duas coisas: reportar um bug (algo que não funciona como devia) e pedir ajuda (algo que não percebe ou não consegue fazer). Abrem-se a partir de um botão presente em quase todas as páginas da aplicação, no menu "Ajuda". A resposta chega por email, com o registo interno do ticket sempre acessível a partir da sua conta.
Sem chatbot treinado para o fazer ricochete. Sem FAQs para percorrer antes de chegar ao formulário. O primeiro contacto é humano — pelo menos enquanto a dimensão do projecto o permita, e comprometemo-nos a fazer com que o permita o mais tempo possível.
Como abrir um ticket que recebe uma resposta útil
-
Descreva o que estava a fazer.
"Estava a escrever um capítulo" não chega. "Estava a exportar o terceiro capítulo em DOCX" é melhor. Uma frase sobre o contexto.
-
Conte o que aconteceu.
O comportamento observado: mensagem de erro exacta, passo que não acontece, funcionalidade que responde de forma estranha. O que viu, não o que deduziu.
-
Diga o que esperava em vez disso.
Simplesmente: "esperava receber o ficheiro DOCX para transferência, recebi uma página de erro". Ajuda-nos a perceber se é um bug ou um mal-entendido.
-
Se puder, anexe uma captura de ecrã.
Vale mil palavras. O botão de anexo está no formulário do ticket. Ficheiros até 10 MB.
-
Verifique o email.
A resposta chega aí, e pode pedir-lhe mais detalhes. Responda a partir do mesmo email: o fio fica arrumado.
Não prometemos respostas em 24 horas. Um projecto pequeno não pode sustentar esse nível de serviço sem sacrificar outras coisas — como o desenvolvimento do produto que todos estão a pedir. Respondemos, em média, em 2-4 dias úteis para tickets não urgentes, e muito mais rapidamente para bugs que bloqueiam por completo uma funcionalidade. É uma promessa realista, que podemos cumprir. As promessas que não podemos cumprir, evitamo-las, porque são uma forma de engano.
Os Feature Requests: a voz dos autores
Há outro canal, distinto e importante: os Feature Requests. São propostas públicas de novas funcionalidades — ou melhorias das existentes — que qualquer utilizador pode abrir. Cada feature request é visível a todos os utilizadores do Narraya e votável: um "+1" se a ideia lhe serve, um comentário se quer acrescentar o seu ponto de vista.
Não é uma democracia directa — no fim somos nós a escolher o que desenvolver, equilibrando prioridades, esforço, coerência do produto. Mas também não é um teatro: lemos cada pedido, os votos pesam de verdade, e muitas funcionalidades lançadas nos últimos meses nasceram precisamente aí.
Três tipos de feedback que realmente nos ajudam
Um bug reprodutível
"Quando clico aqui acontece isto, mas deveria acontecer aquilo." Com passos que qualquer um possa repetir. É o tipo que resolvemos mais depressa, porque é o menos ambíguo.
Uma funcionalidade em falta bem fundamentada
Não "seria bom ter X", mas "quando faço Y sou obrigado a fazer um passo externo e perco trinta minutos". A motivação torna o pedido avaliável. Sem motivação, torna-se um desejo abstracto.
Uma melhoria de UX
"A ficha de personagem está a três cliques de onde estou a escrever — poderia ser um botão ao lado do capítulo?". Pequenas sugestões operacionais que melhoram os dias de trabalho real. Muitas vezes as mais preciosas, porque nascem do uso verdadeiro.
O que NÃO é um feature request útil
Digamo-lo claramente: "façam como [outro software]" não é um feature request. Cada produto tem uma filosofia, e o Narraya tem a sua. Se lhe falta algo, interessa-nos saber porquê lhe falta — o problema real que resolveria — e não uma referência genérica a uma ferramenta concorrente. A mesma funcionalidade, pensada dentro de uma filosofia diferente, pode tornar-se outra coisa.
E outro esclarecimento: os pedidos que contradizem a nossa filosofia de fundo — por exemplo "quero que a IA escreva o capítulo por mim" — lemo-los com respeito mas não os vamos concretizar. Não por teimosia: porque o Narraya tomou uma posição explícita sobre o que quer e o que não quer ser, e trair essa posição para agradar a pedidos isolados seria trair quem nos escolheu precisamente por ela.
O diálogo como parte do produto
Recebemos tickets e pedidos todos os dias. Alguns fazem-nos rir (no bom sentido), alguns fazem-nos pensar, alguns assinalam problemas de cuja existência nunca teríamos percebido sem o utilizador que os viveu. Esta troca não é um "extra" do produto: é parte do produto. Sem vós, o Narraya seria um software menos bom.
Para abrir um ticket ou propor uma funcionalidade, entre no Narraya e procure o menu "Ajuda" no canto inferior esquerdo. A primeira resposta chega à mão — em todos os sentidos.