วิธีสอนผู้ใช้ / ลูกค้าให้ส่งคำอธิบายข้อผิดพลาดที่ดีขึ้น

ฉันมักจะต้องจัดการกับลูกค้าหรือผู้ใช้ที่รายงานข้อผิดพลาดในแอปพลิเคชัน ส่วนใหญ่เนื้อหาของพวกเขาเป็นสิ่งที่ไร้ประโยชน์เช่น

• ข้อผิดพลาด !!!
• 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, C, ... ก่อนที่คุณจะพูดกับตัวแทนของเรา" สิ่งนี้จะขึ้นอยู่กับว่าคุณควบคุมแอพได้มากแค่ไหนดังนั้นมันอาจไม่สามารถทำได้ทั้งหมด นี่ไม่ใช่วิธีที่แน่นอนเช่นกัน แต่หวังว่ามันจะได้แนวคิดในหัวลูกค้าที่กรีดร้องว่า "ERRORZ PLZ HLP !!!" ไม่พอ.

ปัญหาเกี่ยวกับข้อความแสดงข้อผิดพลาดในแอปพลิเคชันที่ทันสมัยคือแทบจะเป็นไปไม่ได้ที่จะรวมบริบททั้งหมดที่อาจเกี่ยวข้อง อะไรก็ได้ตั้งแต่สถาปัตยกรรมของโปรเซสเซอร์จนถึงเวลาของวันนั้นอาจเกี่ยวข้องกันด้วยเหตุนี้ทั้งการรายงานข้อผิดพลาดและการจัดการข้อผิดพลาดจึงมีความทันสมัยมากกว่าวิทยาศาสตร์ ระบบเช่นapport-bugนั้นมีประโยชน์ในการรวบรวมข้อมูลที่เกี่ยวข้องและส่งให้คุณ โชคไม่ดีที่จนกระทั่งถึงวันที่มีผู้ลอกเลียนแบบการเดินทางข้ามเวลาและผู้ชดเชยไฮเซนเบิร์กก็ไม่มีทางที่จะแน่ใจได้ว่าข้อมูลที่คุณได้รับจากผู้ใช้จะเพียงพอที่จะทำการดีบักหรือทำให้ปัญหาเกิดซ้ำ

ทุกสิ่งที่คุณจำเป็นต้องเข้าสู่ระบบ เรามีไฟล์บันทึกการหมุนของ x mb หากมีสิ่งใดไม่ดีเกิดขึ้นผู้ใช้จะส่งล็อกไฟล์และบ่อยครั้งก็เพียงพอที่จะแก้ไขปัญหาได้

อีกตัวเลือกหนึ่งคือใช้ไคลเอนต์เดสก์ท็อประยะไกลเพื่อดูว่ามีอะไรผิดปกติ วันนี้เป็นเรื่องง่ายเหมือนให้ไคลเอนต์ดาวน์โหลด exe

คุณจะต้องถามคำถามที่ตรงประเด็นและต้องการให้พวกเขาตอบคำถามทุกข้อ บางครั้งการร้องเรียนปัญหาของพวกเขาจะสลับกับแผนของพวกเขาสำหรับวันหยุดสุดสัปดาห์การร้องเรียนเกี่ยวกับเรื่องสำคัญอื่น ๆ หรือสภาพอากาศ พยายามทำให้พวกเขาทำงานและถามพวกเขาว่า "โอเคเมื่อคุณทำ X แต่อย่าทำ Y จะเกิดอะไรขึ้น?" อธิบายการตอบสนองของพวกเขาเพื่อให้คุณเริ่มสร้างไดอะแกรมลำดับเหตุการณ์ที่คุณสามารถย้อนกลับและดีบักได้ในภายหลัง

คุณสามารถลงทุนสักครู่และเพิ่มปุ่มสีแดง 'รายงานข้อบกพร่อง' ที่มุมบนขวาของแอพ เมื่อผู้ใช้กดปุ่มพยายามถ่ายภาพหน้าจอให้รวบรวมบันทึกที่มีอยู่ทั้งหมดสำหรับเซสชัน (อาจคุ้มค่า) เปิดการแชร์หน้าจอโดยตรงไปยังหน้าจอผู้ใช้แสดงแบบฟอร์มง่าย ๆ และส่งข้อมูลไปยังเซิร์ฟเวอร์ของคุณโดยอัตโนมัติ

- ลองถามผู้ใช้ให้น้อยที่สุดถ้าแอปของคุณสามารถรับข้อมูลได้ ความละเอียดหน้าจอ, เวอร์ชั่นของระบบปฏิบัติการ, ชื่อผู้ใช้, ล็อกอิน, การกระทำล่าสุดและบันทึก

- ลงชื่อตั๋วให้กับผู้ใช้และให้ลิงก์แก่เขาเพื่อให้เขารู้ว่าเขามีหมายเลขข้อผิดพลาด 1234 ที่ www.yoursite.issues / 1234

- ถามผู้ใช้ในสิ่งที่เขาพยายามทำ

ฉันคิดว่าทั้งหมดนี้เข้าด้วยกันหรือแม้แต่บางส่วนสามารถช่วยให้คุณได้รับข้อมูลที่เพียงพอและแสดงให้ผู้ใช้เห็นว่าเขาสามารถช่วยคุณในการทำให้ซอฟต์แวร์ของคุณดียิ่งขึ้น

วิธีที่ง่ายที่สุดคือการใช้เครื่องมือที่สามารถ "เข้าใจ" สิ่งที่ลูกค้าต้องการ มีเครื่องมือมากมาย แต่อาจดีที่สุดคือ Usersnap ดูเรื่องนี้ที่นี่