Agrupando seus usuários ao seu bugtracker

17

Eu tenho um rastreador de erros de mantis totalmente configurado para rastrear problemas nos aplicativos criados por mim. Quando um usuário é disciplinado e vai direto ao mantis para redigir um relatório de problemas, ele terá uma resposta mais rápida e tudo sobre o problema será muito fácil de rastrear.

No entanto, nem todo mundo quer fazer isso. Eles relatam seus problemas por telefone, e-mail, não os relatam.

Qual seria a melhor maneira de incentivá-los a usar um sistema de rastreamento de bugs? Claramente, eles precisam ver alguns benefícios imediatos para poder voltar e procurar mais benefícios.

EDITAR:

Estou falando de suporte aos produtos que vendo como ISV.

issue-tracking

— Daniel Mošmondor
fonte

2

Que tal integrar relatórios de erros diretamente no seu produto?

— JoelFan

22

Seu rastreador de erros é para sua conveniência, não para os clientes. Se você não pode se incomodar em pegar o problema por telefone ou e-mail e inseri-lo, como acha que eles se sentem?

Você precisa inserir problemas e atribuí-los manualmente a um cliente. Então, quando eles ligarem para um problema, você poderá dizer: "Obrigado por informar isso! Vou inseri-lo em nosso sistema de gerenciamento de problemas e você começará a receber e-mails (ou o que for) enquanto lidamos com isso. No futuro, se for fácil para você, você pode entrar nesse tipo de coisa. Ou fique à vontade para me ligar, tudo bem também. "

Um dos melhores sistemas com os quais trabalhei como cliente é o do provedor de hospedagem que revendo. O email para support @ é analisado em busca de um nome de domínio na linha de assunto, atribuído a uma conta de cliente com base no endereço de origem e inserido automaticamente no sistema de tickets. Muito liso.

— Dan Ray
fonte

2

Concordo - eu não esperaria que os clientes usassem um sistema de rastreamento de bugs.

— tcrosley

4

@ tcrosley - então você precisa de um melhor sistema de rastreamento de bugs. A chave aqui não é se os usuários precisam usar o sistema de rastreamento, mas como convencê-los de que é melhor (mais fácil, mais rápido, mais propenso a alcançar o resultado desejado) usar o sistema de rastreamento.

— Murph

1

Eu realmente não posso concordar com isso. Os programadores nunca devem receber relatórios de erros diretamente dos usuários por telefone, email ou qualquer outro local para esse assunto. Se os usuários desejam relatar erros "pessoalmente", devem fazê-lo através da equipe de suporte. Se eles se recusarem a fazer isso, sua única opção deve ser enviar um relatório de erro real, diretamente através da interface do usuário ou através de uma caixa de entrada de email dedicada que encaminha para o rastreador. E se você é um ISV e não tem pessoal de suporte, bem, isso é outra questão.

— Aaronaught

1

Como uma startup ISV, eu realmente não posso ter pessoal de suporte. E não pela razão óbvia - isso é despesa, mas a razão pela qual eu quero estar o mais próximo possível do usuário para orientar o produto na direção certa, de acordo com as necessidades e desejos. O homem do meio diluiria até certo ponto.

— Daniel Mošmondor 29/10/10

Esta resposta não é totalmente verdadeira. Conforme discutido em programmers.stackexchange.com/questions/191961/… , pelo menos no contexto do desenvolvimento de código aberto, um rastreador de erros pode ser bastante benéfico para os usuários: ele atua como um banco de dados de conhecimento de suporte de problemas conhecidos e pode fornecer soluções alternativas. , se eles existirem. Ele permite que o usuário avalie a rapidez com que o problema está sendo solucionado, ajudando-o a decidir se deseja mudar para uma solução diferente. Também ajuda colaboradores potenciais como a equipe opera e onde a ajuda é necessária.

— precisa saber é o seguinte

8

Um usuário que reclama é melhor do que aquele que não, desiste e liga para o seu concorrente. Por esse motivo, facilitaria o máximo possível o envio de uma reclamação. Eu os deixaria continuar ligando e / ou enviando e-mails e não pedir que eles arquivassem bugs.

Olhe para o ponto de vista deles - se você não apenas tivesse tempo para ligar / escrever um e-mail, mas também fosse forçado a aprender o sistema de rastreamento de bugs de alguém - é provável que você não vá reclamar.

Se necessário, contrate uma pessoa de atendimento ao cliente para que os desenvolvedores não sejam interrompidos. Eles podem receber as reclamações dos clientes e fazer bugs para a equipe de desenvolvimento.

— Doug T.
fonte

Daniel não menciona se ele é um desenvolvedor interno cujos usuários são seus colegas de trabalho (que foi o caminho que tomei na minha resposta) ou se apoia clientes pagantes.

— Frank Shearar

Eu estou dando suporte a clientes pagantes pelos meus produtos, vou esclarecer que, na minha pergunta, thx

— Daniel Mošmondor

3

Eu gostaria que o usuário que reclama fosse melhor do que aquele que não PERIOD. Se há algo que eu mais não gosto é o usuário que usa o software com defeito, não relata nada e acumula pesar.

— Daniel Mošmondor

6

Não conheço o Mantis especificamente, mas ele pode ser configurado para monitorar um endereço de email e gerar automaticamente relatórios a partir deles? Conheço outros sistemas (como o JIRA, por exemplo, pode).

O problema então é fazê-los usar o endereço de email correto!

— ChrisF
fonte

1

+1 - O e-mail é a única maneira que quero que meus clientes interajam com meu rastreador de erros. A interface do usuário do Mantis está longe de ser fácil de usar, mas mesmo com uma solução mais simples, os clientes sentirão que estão fazendo seu trabalho por você.

— grossvogel

Mesmo sistema em minha casa, usando o FogBugz.

— FinnNk

1

"Por favor, reporte isso no rastreador de erros em http: // your / url / . Eu não posso acompanhar os erros se você não os informar lá."

Talvez seja possível escrever um plug-in para o seu cliente de email transformar um email em um relatório de erro ou usar uma caixa de correio dedicada - bugs @ foo - para obter relatórios de erros. (Mas o último, é claro, requer treinar seus usuários ...)

— Frank Shearar
fonte

1

Existe um plugin para o mantis para coletar relatórios de erros de email.

— Daniel Mošmondor

1

+ 1 .. porque falar ao telefone é perturbador, improdutivo e não oficial. Também não deixa rastros de quem disse o quê e por quê. Mais tarde, quando as pessoas perguntam por que você fez algo, você precisa se explicar, em vez de apontá-las para o número #xxxxxx. O telefone deve ser banido. Se seus usuários não souberem usar seu rastreador de erros, você poderá educá-los.

— dr Hannibal Lecter

1

Internamente, temos um modelo de site para aplicativos da web que inclui um link de feedback no canto. Esse link de feedback fornece ao usuário uma caixa de diálogo da interface do usuário do jQuery que solicita uma descrição do bug, novo recurso ou outro que eles encontraram e também captura alguns detalhes sobre a página e a hora em que estão reportando. Tudo isso é enviado diretamente para o JIRA nos bastidores e o usuário pode receber atualizações com o status do problema.

Em geral, a melhor maneira de fazer as coisas é simplificando-a o máximo possível para os usuários; se houver um link de feedback em um menu que lide com o envio das informações para onde elas precisam ir, é muito mais provável que sejam usadas.

— rjzii
fonte

1

Bem, se você quiser usar um manipulador de exceção global, terá muitas opções. Para o Delphi, usamos o MadExcept, mas também o Eureka Log, que enviará um e-mail (com o avanço do usuário) ou fará o upload via HTTP, um relatório de bug para você.

Você pode ter um botão no seu aplicativo que apenas lança uma exceção e lança esse material de rastreamento de erros. O MadExcept é muito legal porque pega uma captura de tela do aplicativo e a carrega junto com o bug, dessa forma, mesmo que o usuário não possa explicar adequadamente o que estava fazendo, você pode ter um desejo muito bom.

Outra coisa em que pensar é a codificação, para tornar óbvio a origem dos erros. Se você possui usuários beta, talvez inclua informações de depuração no aplicativo para poder obter dados extras quando ocorrerem falhas.

Nada disso ajuda a erros de implementação (ou seja, o botão está no lugar errado), embora esperemos que você não tenha nenhum deles.

— Peter Turner
fonte

É claro que tenho um manipulador de exceções por email, mas esse é realmente o último recurso. Mais coisas que eu gostaria de capturar vêm dos desejos do usuário por novos recursos e melhorias no sistema.

— Daniel Mošmondor

OK bom, tenho uma linha de base então. Então, eu começaria chamando-o de "Rastreador de erros" se você quiser mais um fórum sobre a uservoice! Se o seu rastreador de erros atual captura capturas de tela, talvez você possa abrir o MS paint e deixá-lo sugerir melhorias para você antes de enviar a mensagem.

— Peter Turner

1

Obtivemos o maior aumento de aceitação ao configurar um serviço para coletar email de um endereço e registrá-lo automaticamente como um problema. O bom efeito colateral desse sistema é que você também pode adicionar facilmente conversas a um problema, incluindo uma sintaxe especial no assunto (por exemplo, TeamITNo: 12345). Além disso, se você enviar toda a sua comunicação por e-mail através deste sistema, e eles responderem, você receberá a resposta de volta no rastreador de erros, com o problema atualizado.

Isso teve o maior efeito positivo, pois usa os usuários de tecnologia que são confortáveis e também significa que você obtém todos os seus problemas em um só lugar.

— Tom Morgan
fonte