버그 추적기에 사용자를 유도

17

내가 만든 앱의 문제를 추적하기 위해 완전히 구성된 사마귀 버그 추적기가 있습니다. 사용자가 훈련을 받고 문제 보고서를 작성하기 위해 사마귀에게 직접 갈 때, 사용자는 가장 빠른 반응을 보이며 문제와 관련된 모든 것을 매우 쉽게 추적 할 수 있습니다.

그러나 모든 사람이 그렇게하고 싶어하는 것은 아닙니다. 그들은 전화, 이메일을 통해 문제를보고하고 전혀보고하지 않습니다.

버그 추적기 시스템을 사용하는 데 가장 좋은 방법은 무엇입니까? 분명히, 그들은 즉각적인 혜택을보고 더 많은 혜택을 찾을 수 있도록해야합니다.

편집하다:

ISV로 판매하는 제품에 대한 지원에 대해 이야기하고 있습니다.

issue-tracking

— 다니엘 모스 몬 도르
소스

2

버그보고를 제품에 직접 통합하는 것은 어떻습니까?

— JoelFan

22

버그 추적기는 고객이 아닌 편의를 위한 것 입니다. 전화 나 이메일로 문제를 겪지 않고 직접 입력 할 수 없다면 기분이 어떻습니까?

이슈를 입력하고이를 클라이언트에 수동으로 할당 할 수 있어야합니다. 그런 다음 문제가 발생하면 "고맙습니다. 문제를 Google의 문제 관리 시스템에 입력하겠습니다. 문제를 처리 할 때 이메일 (또는 기타)을 받기 시작할 것입니다. 미래에, 당신이 편한 경우, 당신은 바로 거기에 그런 종류의 것을 입력 할 수 있습니다.

내가 고객으로 일한 최고의 시스템 중 하나는 내가 재판매하는 호스팅 제공 업체의 시스템입니다. support @에게 보내는 전자 메일은 제목 줄에서 도메인 이름을 파싱하고 보낸 사람 주소를 기반으로 클라이언트 계정에 할당되며 티켓 시스템에 자동 입력됩니다. 꽤 매끄러운.

— 댄 레이
소스

2

동의-고객이 버그 추적 시스템을 사용하지 않을 것으로 예상됩니다.

— tcrosley

4

@tcrosley-더 나은 버그 추적 시스템이 필요합니다. 여기서 핵심은 사용자 가 추적 시스템 을 사용 해야하는지 여부가 아니라 추적 시스템 을 사용 하기 위해 사용자 가 추적 시스템을 더 잘 (더 쉽고 빠르며, 원하는 결과를 달성 할 가능성이 높음) 설득하는 방법입니다.

— Murph

1

나는 이것에 정말로 동의 할 수 없다. 프로그래머는 전화, 전자 메일 또는 그와 관련된 다른 장소를 통해 사용자로부터 직접 버그 보고서를받지 않아야합니다. 사용자가 버그를 "개인적으로"보고하려면 지원 담당자를 통해 버그를보고해야합니다. 만약 그들이 그것을 거부한다면 그들의 유일한 선택은 UI를 통해 직접 또는 트래커로 전달되는 전용 이메일받은 편지함을 통해 실제 버그 보고서를 제출하는 것입니다. ISV이고 지원 담당자 가없는 경우 이는 또 다른 문제입니다.

— Aaronaught

1

ISV 스타트 업 으로서는 실제로 지원 담당자가 없습니다. 그리고 명백한 이유가 아니라 비용입니다. 그러나 사용자의 요구와 필요에 따라 올바른 방향으로 제품을 조종하기 위해 가능한 한 사용자에게 가까이 있기를 원합니다. 중년은 그것을 어느 정도 희석시킬 것입니다.

— Daniel Mošmondor

이 대답은 전적으로 사실이 아닙니다. programmers.stackexchange.com/questions/191961/… 에서 논의한 것처럼 최소한 오픈 소스 개발의 맥락에서 버그 추적기는 사용자에게 매우 유익 할 수 있습니다. 알려진 문제점에 대한 지원 지식 데이터베이스 역할을하며 해결 방법을 제공 할 수 있습니다. 존재하는 경우 이를 통해 사용자는 자신의 문제가 얼마나 빨리 해결되고 있는지 평가하여 다른 솔루션으로 이동할 것인지 결정할 수 있습니다. 또한 잠재적 인 기여자들에게 팀 운영 방식과 도움이 필요한 위치에 도움을줍니다.

— naught101

8

불평하는 사용자는 경쟁 업체를 포기하고 포기하고 전화하는 것보다 낫습니다. 따라서 가능한 한 쉽게 불만을 제기 할 수 있습니다. 나는 그들이 계속 전화를 걸거나 이메일을 보내도록하고 버그를 제기하도록 요구하지 않을 것이다.

이메일을 작성 / 작성하는 데 시간을 들일 필요가없고 다른 사람의 이상한 버그 추적 시스템을 배워야하는 경우 불만을 제기하지 않을 가능성이 높습니다.

필요한 경우 고객 서비스 담당자를 고용하여 개발자가 방해받지 않도록하십시오. 그들은 고객의 불만을 접수하고 개발자 팀에 버그를 만들 수 있습니다.

— 더그 티
소스

Daniel은 사용자가 동료 직원 (내 대답에 사용한 압정) 인 사내 개발자인지 아니면 유료 고객을 지원하는지에 대해서는 언급하지 않습니다.

— Frank Shearar

나는 내 제품에 대한 고객 지불을 지원하고 있습니다. 내 질문에, thx

— Daniel Mošmondor

3

불만을 제기하는 사용자가 PERIOD를 사용하지 않는 사용자보다 낫습니다. 내가 가장 싫어하는 것이 있다면 소프트웨어를 잘못 사용하는 사용자는 아무것도보고하지 않고 슬픔을 쌓는 것입니다.

— Daniel Mošmondor

6

Mantis를 구체적으로 알지 못하지만 전자 메일 주소를 모니터링하고 자동으로 보고서를 생성하도록 구성 할 수 있습니까? 다른 시스템을 알고 있습니다 (예 : JIRA와 같은).

문제는 그들이 올바른 이메일 주소를 사용하게하는 것입니다!

— 크리스프
소스

1

+1-이메일은 고객이 버그 추적기와 상호 작용하도록하는 유일한 방법입니다. Mantis UI는 사용자에게 친숙하지 않지만 더 매끄러운 솔루션을 사용하더라도 고객은 자신을 위해 일하는 것처럼 느끼게됩니다 .

— grossvogel

FogBugz를 사용하는 동일한 시스템.

— FinnNk

1

" http : // your / url / 의 버그 추적기에이를보고 하십시오 . 버그를보고하지 않으면 추적 할 수 없습니다."

아마도 메일 클라이언트 용 플러그인을 작성하여 이메일을 버그 보고서로 바꾸거나 전용 메일 함 (bugs @ foo)을 사용하여 버그 보고서를 작성할 수 있습니다. (그러나 후자는 사용자 교육이 필요합니다 ...)

— 프랭크 시어
소스

1

전자 메일에서 버그 리포트를 수집하기위한 mantis 용 플러그인이 있습니다.

— Daniel Mošmondor

1

+1 .. 전화 통화가 산만하고 비생산적이며 비공식적이므로. 또한 누가 무엇을 왜 말했는지에 대한 흔적도 남기지 않습니다. 나중에 사람들이 왜 당신이 무언가를했는지 물어 보면 #xxxxxx를 발행하도록 지시하는 대신 스스로 설명해야합니다. 전화는 금지되어 있어야합니다. 사용자가 버그 추적기를 사용하는 방법을 모른다면 교육 할 수 있습니다.

— Dr Hannibal Lecter

1

내부적으로 우리는 코너에 피드백 링크를 포함하는 웹 애플리케이션을위한 사이트 템플릿을 가지고 있습니다. 이 피드백 링크는 버그, 새로운 기능 또는 기타 발생한 문제에 대한 설명을 묻는 jQuery UI 대화 상자를 사용자에게 제공하고보고하는 페이지 및 시간에 대한 세부 정보를 캡처합니다. 이 모든 것은 장면 뒤에서 JIRA로 직접 푸시되며 사용자는 문제 상태에 대한 업데이트를 얻을 수 있습니다.

작업을 수행하는 가장 좋은 방법은 일반적으로 사용자가 가능한 한 간단하게 만드는 것입니다. 메뉴에 정보가 필요한 곳으로 정보를 보내는 것을 처리하는 피드백 링크가 있으면 정보를 사용할 가능성이 훨씬 높습니다.

— rjzii
소스

1

전역 예외 처리기를 사용하려면 많은 옵션이 있습니다. 델파이의 경우 MadExcept를 사용하지만 Eureka Log도 사용했습니다.이 둘은 (사용자가 계속해서 이메일을 보내거나) 버그 보고서 인 HTTP를 통해 업로드합니다.

앱에 예외를 던지고이 버그 추적 항목을 시작하는 버튼이있을 수 있습니다. MadExcept는 앱의 스크린 샷을 가져 와서 버그와 함께 업로드하기 때문에 매우 멋집니다. 사용자가 수행 한 작업을 올바르게 설명 할 수 없어도 꽤 잘 손질 할 수 있습니다.

다른 생각은 버그가 어디에서 왔는지 분명하게 코딩하는 것입니다. 베타 사용자가 있다면 앱에 디버그 정보를 포함시켜 충돌이 발생할 때 추가 데이터를 얻을 수 있습니다.

이 중 어느 것도 구현 버그 (예 : 버튼이 잘못된 위치에 있음)에 도움이되지 않으므로 희망적으로는 버그가 없습니다.

— 피터 터너
소스

물론 전자 메일 예외 처리기가 있지만 실제로 최후의 수단입니다. 내가 캡처하고 싶은 것은 시스템의 새로운 기능과 개선에 대한 사용자의 소망에서 비롯됩니다.

— Daniel Mošmondor

좋아, 그럼 기준선을 얻었 어 따라서 더 많은 사용자 보이스 포럼을 원한다면 "버그 추적기"라고 부르지 않습니다. 현재 버그 추적기가 스크린 샷을 캡처하는 경우 MS 페인트를 열어 메시지를 보내기 전에 개선 사항을 제안하도록 할 수 있습니다.

— 피터 터너

1

주소에서 이메일을 받아 자동으로 문제로 기록하도록 서비스를 구성하여 채택률이 가장 크게 증가했습니다. 이 시스템의 좋은 부작용은 주제에 특수 구문 (예 : TeamITNo : 12345)을 포함하여 문제에 대화를 쉽게 추가 할 수 있다는 것입니다. 또한이 시스템을 통해 모든 전자 메일 통신을 보내고 응답을 받으면 문제가 업데이트 된 상태로 버그 추적기로 회신을 받게됩니다.

사용자가 편안하게 사용할 수있는 기술을 사용하고 모든 문제를 한 곳에서 얻을 수 있다는 점에서 가장 큰 긍정적 인 효과를 얻었습니다.

— 톰 모건
소스