더 나은 오류 설명을 보내도록 사용자 / 고객에게 가르치는 방법

종종 응용 프로그램에서 오류를보고하는 고객이나 사용자를 처리해야합니다. 대부분의 경우 그들의 내용은 쓸모없는 것입니다

• 오류!!!
• x가 작동하지 않습니다

더 많은 정보없이.

문제를 해결하려면 모든 세부 사항을 요청해야하는데, 종종 문제 자체를 수정하는 것보다 시간이 많이 걸립니다. 스크린 샷과 같은 (데이터 레코드의 적합하지 않은 형식의 다른 전송 정보, 하지 가 링크를 보낼 수 있지만 오류) (우리가 시스템에 액세스 할 수 있습니다) 등등.

전체 프로세스가 양쪽에서 더 쉬울 수 있도록 사용자 / 고객에게 더 자세한 문제를 설명하도록 어떻게 지시합니까?

편집하다

이 질문은 로그와 오류 정보를 프로그래밍 방식으로 수집하는 방법보다 사회적 기술에 관한 것입니다. 이것이 좋은 소프트웨어 디자인의 일부라는 사실을 알고 있습니다.

좋은 버그 보고서에 대해 사용자에게 보상하고 나쁜 버그에 대해 처벌하십시오 (적어도 조금은 좋습니다).

사용자는 문제를 신속하게 해결하기 위해서는 좋은 버그 보고서가 필수적이므로 솔루션도 훨씬 빨리 얻을 수 있기 때문에 그에게도 유리하다는 점을 이해해야합니다.

첫 번째 응답은 "알겠습니다. 보고서를 읽었지만 어디서부터 시작해야할지 모르겠습니다.이 문제가 한 번 발생 했습니까? 반복되는 현상입니까? X를 시도해 보시겠습니까? 그 다음에 Y? 등등.

사람들이 이런 종류의 피드백을 받았을 때, 무엇을해야하는지, 직접적으로 또는 간접적으로 그들이 배우게 될 첫 번째 장소에서하지 않은 것을 말하는 경우가 종종 있습니다. 어쩌면 즉시는 아니지만 더 많은 보고서를 제출할수록 요청하는 내용을 더 많이 예상하고 (직관적으로 부정확하게) 답변을 직접 제공 할 수 있습니다.

예, 이것은 단계별 프로세스이며 내일 아침까지 모든 통신 문제를 해결하지는 못하지만 그럼에도 불구하고 시작입니다.

여러 오픈 소스 프로젝트에서 보았던 것 중 하나는 버그 정보를위한 표준 "양식"을 작성하는 것입니다. 여기에는 일반적으로 필요한 정보 섹션이 있습니다.

고객이 액세스 할 수있는 버그보고 사이트 또는 응용 프로그램이있는 경우 빈 버전으로 버그 설명 필드의 기본 텍스트를 만들 수 있는지 확인하십시오. 그렇지 않으면 사이트 나 제품의 설치 디렉토리와 같이 찾을 수있는 위치 (또는 가리킬 수있는 위치)에 두십시오.

귀하의 경우 다음과 같습니다.

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

(여기서 "귀하"는 고객을 말합니다)

아이디어는 가장 유용한 정보 목록을 제공하여 유용한 정보를 제공하도록 장려하는 것입니다.

일반적으로 매번 오류의 스크린 샷을 요청하고 결국 요청한다는 것을 알고 있기 때문에 오류 요청과 함께 스크린 샷을 보내기 시작합니다.

나는 때때로 더 많은 정보를 얻기 위해 그것들을 불러야하지만, 종종 스크린 샷을 보면서 문제를 볼 수 있습니다.

그러나 @Mahmoud의 의견에 동의하는 가장 좋은 방법은 응용 프로그램이 사용자에게 의존하는 대신 오류를 보내도록하는 것입니다.

비관적 인 견해 : 당신은 할 수 없습니다. 더 많은 사용자, 더 많은 시스템, 더 많은 응용 프로그램이 있다는 점을 제외하면 40 년 전과 같은 상황입니다.

(비관론자는 경험이있는 낙관론자 일뿐입니다.)

그들이 쉽게 할 수 있도록하십시오.

필요한 정보를 제공하는 방식으로 오류를보고 할 수있는 가장 쉬운 방법을 만드는 것이 좋습니다. 이것은 소프트웨어에서 오류보고 프로세스를 자동화한다는 것을 의미합니다.

자세한 로그 파일을 유지하고 오류 보고서를 첨부하는 것이 시작입니다.

고객과 대화를 마치면 "다음에 이런 일이 발생하면 데이터 항목 A, B, C 등을 준비하십시오"라고 말하십시오. 물론 이것은 동일한 고객이 반복해서 전화를 거는 경우에만 작동합니다. 사용자가 a) 통화 속도를 높이고 b) 전체 해상도를 훨씬 빠르게 만드는 특정 주요 사항을 알게 된이 방법으로 성공했습니다.

대부분이 일회성 발신자 인 경우 "ERROR!"를 업데이트하는 것이 가장 좋습니다. "대리인에게 문의하기 전에 데이터 항목 A, B, C, ...을 수집해야합니다"라는 텍스트가있는 화면. 이것은 실제로 앱에 대한 제어 능력에 달려 있으므로 전혀 가능하지 않을 수 있습니다. 이것은 확실한 방법은 아니지만 "ERRORZ PLZ HLP !!!"라는 비명을 지르는 아이디어를 고객의 머리에 담을 수 있기를 바랍니다. 충분하지 않다.

최신 응용 프로그램의 오류 메시지 문제는 관련이있는 모든 컨텍스트 를 포함하는 것이 사실상 불가능하다는 것입니다 . 프로세서 아키텍처에서 시간에 이르기까지 모든 것이 관련 될 수 있으므로 오류보고 및 오류 처리가 과학보다 예술적인 이유입니다. 이와 같은 시스템 apport-bug은 관련 정보를 수집하여 귀하에게 제출한다는 점에서 유용합니다. 불행히도, 복제본, 시간 여행 및 Heisenberg 보상기 시절까지는 사용자로부터 얻은 정보가 문제를 디버그하거나 재현하기에 충분할 것이라고 확신 할 수있는 방법이 없습니다.

필요한 모든 것을 기록하십시오 . x mb의 롤링 로그 파일이 있습니다. 문제가 발생하면 사용자는 로그 파일을 보내며 종종 문제를 해결하기에 충분합니다.

또 다른 옵션은 원격 데스크톱 클라이언트 를 사용하여 무엇이 잘못되었는지 직접 확인하는 것입니다. 요즘에는 클라이언트가 exe를 다운로드하는 것만 큼 쉽습니다.

당신은 뾰족한 질문을하고 당신에게 모든 답을주기 위해 매우 요구해야합니다. 때로는 문제에 대한 불만이 주말 계획, 중요한 다른 사람에 대한 불만 또는 날씨에 산재합니다. 작업을 계속하고 "좋아, X를하되 Y를하지 않으면 어떻게됩니까?"라고 물어보십시오. 응답에 주석을 달아서 나중에 돌아가서 디버깅 할 수있는 이벤트 시퀀스 다이어그램을 작성하십시오.

시간을 투자하고 앱의 오른쪽 상단에 '버그 신고'빨간색 버튼을 추가 할 수 있습니다. 사용자가 버튼을 누르면 스크린 샷을 찍으려고 할 때 세션에 사용할 수있는 모든 로그를 수집하여 사용자 화면에 직접 화면 공유를 열고 간단한 양식을 표시하고 자동으로 서버에 데이터를 보냅니다.

-앱이 데이터 자체를 가져올 수 있으면 사용자에게 가능한 한 적게 물어보십시오. 화면 해상도, OS 버전, 사용자 이름, 로그인, 마지막 작업 및 로그

-티켓을 사용자에게 할당하고 링크를 제공하면 www.yoursite.issues / 1234에 버그 번호 1234가 있음을 알 수 있습니다.

-사용자에게 달성하려는 것을 물어보십시오.

이 모든 것을 함께 또는 부분적으로 사용하면 충분한 데이터를 수신하고 사용자에게 소프트웨어를 개선하는 데 도움을 줄 수 있음을 보여줄 수 있다고 생각합니다.

가장 쉬운 방법은 실제로 고객이 원하는 것을 "이해"할 수있는 도구를 사용하는 것입니다. 많은 도구가 있지만 아마도 가장 좋은 것은 Usersnap입니다. 이 이야기를 여기에서보십시오.