Bắt người dùng viết báo cáo lỗi hữu ích

Có ai biết một cách tốt để khiến người dùng viết một báo cáo lỗi bán khá (đọc: hữu ích ) không?

Chúng tôi muốn đưa ra một cái gì đó có ý nghĩa với hầu hết người dùng (dễ đọc và dễ hiểu), nhưng cũng cung cấp thông tin hữu ích cho các nhà phát triển.

Nó không hoạt động khi tôi nhấp vào nút màu xanh! Ahhh, tôi vừa mất một tuần làm việc ... làm cho nó hoạt động.

không phải là rất hữu ích, vì nó là.

Tôi bắt đầu sửa về một danh sách, nhưng nghĩ rằng hãy kiểm tra với các bạn, liệu một phương pháp tương tự đã tồn tại chưa.

Cách hiệu quả nhất để khiến người dùng viết báo cáo lỗi hữu ích và tốt là

1. để cho họ xem báo cáo của họ trực tuyến ...
   ^{[Hệ thống] Cảm ơn bạn đã báo cáo, bạn có thể tìm thấy trạng thái yêu cầu của mình tại đây: ...}
2. ... cùng với đánh giá và nhận xét từ kỹ sư được chỉ định ...
   ^{[Kỹ sư] Yêu cầu bị từ chối, vì các chi tiết sau bị thiếu: ...}
3. ... Với một tùy chọn để chỉnh sửa / cải thiện báo cáo của họ.
   ^{[Người dùng] Chi tiết được yêu cầu được thêm vào, vui lòng đánh giá lại: ...}

Tôi sẽ đi xa hơn để tuyên bố rằng đó là cách hiệu quả duy nhất.

Hãy đối mặt với nó, kỹ năng viết báo cáo lỗi hiệu quả chỉ đến với kinh nghiệm. Một người cần học hỏi để có được kinh nghiệm. Học tập bao gồm thực hành, nhận thông tin phản hồi và cải thiện.

Báo cáo lỗi trực tuyến có thể chỉnh sửa của người dùng là cách hiệu quả nhất để dạy người dùng cải thiện .

• ^{Các lựa chọn thay thế ở trên là 1) để sắp xếp các buổi học trực tiếp với người dùng (vâng chắc chắn, đặc biệt là khi có hàng ngàn người trong số họ trải rộng trên toàn cầu). Hoặc 2) giải thích cho họ mọi thứ qua điện thoại ("hãy nhìn xem, nếu bạn chỉ có thể nhìn thấy những thứ nhảm nhí mà bạn đã viết ở dòng 225 ..."). Còn gì nữa không Ồ 3) qua email, chắc chắn "trong thư bạn đã gửi cho chúng tôi hai tháng trước, bạn đã đề cập ... không phải email đó, bạn đã gửi cho chúng tôi năm email trong ngày hôm nay, ba trong số đó có chủ đề Re: nhấp vào nút màu xanh , nhìn vào cái thứ hai, cái có màn hình 10Mb được gắn vào nó ... cái gì? bạn không thể tìm thấy nó? "}

Theo tôi, điều quan trọng hơn là sử dụng lỗi để thiết lập ý nghĩa khi tiếp xúc với người dùng. Viết và hiểu các báo cáo lỗi là một kỹ năng, và lời khuyên của tôi là làm cho người dùng dễ dàng nhất có thể thực hiện liên hệ đầu tiên, sau đó dần dần đưa ra phản hồi của họ có giá trị hơn khi cần.

Ví dụ: chỉ cần nhận email của người dùng và cung cấp cho họ trường văn bản thuần với văn bản sau để hoàn thành:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Sau khi bạn nhận được email, hãy tự động trả lời để có một lựa chọn kép để xác nhận rằng họ đã gửi lỗi, bạn đã nhận được nó và theo dõi lỗi này là ổn.

Bạn có thể cân nhắc lấy một số ý tưởng từ Mozilla và Sun về chủ đề này:

• Hướng dẫn viết lỗi - bài viết Mozilla MDN
• Cách viết một lỗi thích hợp - Bài viết Mozilla QMO
• Cách viết Báo cáo lỗi hữu ích - Bài viết của Sun SDN

Đặc biệt (từ trang "Cách viết lỗi đúng" của Mozilla):

Đề cương chung của báo cáo lỗi

Tóm tắt : Làm thế nào bạn sẽ mô tả lỗi trong ít hơn 60 ký tự? Nó sẽ nhanh chóng và xác định một báo cáo lỗi cũng như giải thích vấn đề, không phải là giải pháp được đề xuất của bạn.

Tốt : Từ chối Hủy hộp thoại Sao chép tệp Trình quản lý tệp

Xấu : Phần mềm bị sập

Xấu : Trình duyệt có thể hoạt động với trang web của tôi

Thành phần : Phần phụ của phần mềm tồn tại trong trường nào? Trường này là một yêu cầu để gửi bất kỳ báo cáo lỗi. Nhấp vào từ Thành phần trực tuyến để xem mô tả của từng thành phần. Nếu không có gì phù hợp, hãy làm nổi bật thành phần của General General.

HĐH : Bạn đã tìm thấy hệ điều hành (HĐH) nào? (ví dụ: Linux, Windows XP, Mac OS X.) Ví dụ: Triệu Nếu bạn biết lỗi xảy ra trên nhiều loại hệ điều hành, hãy chọn Đây là tất cả. Nếu hệ điều hành của bạn không được liệt kê, hãy chọn Khác.

Mô tả : Các chi tiết của báo cáo vấn đề của bạn, bao gồm:

- Tổng quan : Đây là một bản tóm tắt chi tiết lớn hơn của bản tóm tắt. Một ví dụ sẽ là: Chọn kéo bất kỳ trang nào gặp sự cố Mac xây dựng trong hàm NSGetFactory.

- Build Id : Để tìm trang này, hãy truy cập trang Giới thiệu về: Giới tính thông qua thanh vị trí hoặc, nếu bạn có tiện ích mở rộng Công cụ kiểm tra hàng đêm của MozQA, sau đó truy cập Công cụ | Công cụ kiểm tra hàng đêm và chọn tùy chọn chứa đầu ra của Id xây dựng. Nó sẽ trông giống như thế này: Phần cứng Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3.

- Các bản dựng và nền tảng bổ sung : Có hay không xảy ra lỗi trên các nền tảng khác (hoặc trình duyệt, nếu có). Nó sẽ trông giống như thế này: Ngôi sao không xuất hiện trên Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2.

Các bước để tái sản xuất : Các bước được tối thiểu hóa, dễ thực hiện sẽ gây ra lỗi. Nếu cần thiết, hãy đảm bảo bao gồm bất kỳ bước thiết lập đặc biệt nào. Ví dụ hay về điều này sẽ giống như sau: 1) Xem bất kỳ trang web nào. (Tôi đã sử dụng trang mẫu mặc định, http://www.google.com/ ). 2) Kéo-chọn trang. Cụ thể, trong khi giữ nút chuột, kéo con trỏ chuột xuống từ bất kỳ điểm nào trong vùng nội dung của trình duyệt đến cuối vùng nội dung của trình duyệt.

Kết quả thực tế : Ứng dụng đã làm gì sau khi thực hiện các bước trên. Ví dụ sẽ là: Ứng dụng bị sập.

Kết quả dự kiến : Những gì ứng dụng nên làm, là lỗi không xuất hiện. Ví dụ sẽ là: Cửa sổ sẽ cuộn xuống dưới. Nội dung cuộn nên được chọn. Hoặc, ít nhất, ứng dụng không nên sập.

Có cách báo cáo lỗi hiệu quả của Simon Tatham. Nó giải thích mọi thứ độc đáo, để dễ hiểu cho người dùng ít kinh nghiệm. Tuy nhiên nhược điểm là nó khá nhiều văn bản. Khi bạn có một người dùng đang cố gắng báo cáo một vấn đề nhưng không giải thích được nó, bạn thường sẽ không thể thuyết phục anh ta đọc tất cả điều này.

Bạn có thể hỏi dễ hiểu và dễ trả lời câu hỏi cho người dùng để mong đợi các báo cáo hữu ích.

Ví dụ: "Hành động cuối cùng của bạn trước lỗi này là gì?", "Bạn đã cố gắng ... ngay trước lỗi này chưa?".

Không người dùng nào sẽ viết cho bạn một báo cáo lỗi như: "Trình điều khiển video của tôi không cải tiến. Thư viện đồ họa của bạn có thể không tương thích với trình điều khiển đồ họa cũ."

Giả sử cơ sở người dùng là người dùng cuối đã gặp sự cố với phần mềm bạn đã viết ....

Đây không phải là công việc người dùng của bạn để trở thành một Kỹ sư phần mềm thành thạo hoặc Kiểm tra chuyên nghiệp và bạn không nên mong đợi họ. Người dùng của bạn là những người bình thường, những người mong đợi phần mềm "chỉ hoạt động". Khi không, họ sẽ báo cáo bất cứ điều gì họ nghĩ rằng họ chú ý để thu hút sự chú ý của bạn. Bạn không thể thay đổi điều đó, và không nên cố gắng. Bất kỳ nỗ lực nào để nhấn mạnh vào loại báo cáo mà chuyên gia dự kiến ​​sẽ thực hiện sẽ dẫn đến việc mất báo cáo lỗi và khách hàng - "Tôi gặp vấn đề với phần mềm đó, nhưng thay vì giúp tôi, họ đã điền vào tất cả các dạng vô dụng không có nghĩa gì và không có giá trị đối với tôi. Tôi sẽ đi tìm một số phần mềm thực sự hoạt động. "

tức là không phải việc của họ .....

Nếu bạn muốn báo cáo lỗi tốt, sử dụng các chuyên gia để tìm lỗi của bạn. Nếu bạn, là một nhà phát triển phần mềm, không thể bận tâm giao dịch với khách hàng, hãy thuê một người có thể.