เขียนข้อเสนอแนะเกี่ยวกับเครื่องมืออ่านและตีความอย่างไรให้มีประโยชน์
ข้อเสนอแนะที่มีประโยชน์ให้ข้อมูลเพียงพอที่ผู้ดูแลจะเข้าใจปัญหาและตัดสินใจทำขั้นต่อไป สำหรับเครื่องมืออ่านและตีความ มักต้องแยกปัญหาการคำนวณหรืออินเทอร์เฟซออกจากการไม่เห็นด้วยกับคำตีความ ทั้งสองเรื่องอาจควรได้รับความสนใจ แต่ต้องใช้หลักฐานต่างกัน
เริ่มจากงานที่คุณพยายามทำให้เสร็จ “ฉันต้องการเปรียบเทียบไพ่ที่จั่วเสร็จแล้วกับคำตอบ” ระบุขั้นตอนการทำงานได้ ส่วน “คำอ่านไม่ดี” ยังไม่บอกว่าปัญหาเกิดจากข้อมูลขาด ลำดับไพ่ผิด หรือข้อความที่ผู้อ่านไม่เชื่อ
เมื่อทำได้ ให้ใช้ข้อมูลสมมติสร้างปัญหาซ้ำ ข้อเสนอแนะสาธารณะไม่ควรต้องอาศัยข้อมูลการเกิด ประวัติความสัมพันธ์ หรือบันทึกบทสนทนาทั้งหมดของคนจริง
ระบุประเภทของปัญหา
ปัญหาข้อมูลนำเข้าเกี่ยวกับสิ่งที่เข้าสู่ระบบ เช่น วันที่เปลี่ยน ฟิลด์ประวัติที่หายไป หรือลำดับไพ่ที่ไม่ตรงกับที่ให้ ปัญหาการแสดงผลเกี่ยวกับสิ่งที่อินเทอร์เฟซแสดง ส่วนปัญหาการให้เหตุผลเกี่ยวกับวิธีที่คำตอบใช้ข้อมูลซึ่งเดิมถูกต้องอยู่แล้ว
เช่น รายงานปัญหาทาโรต์สมมติอาจบอกว่า ผลจั่วแสดงไพ่ใบหนึ่งในตำแหน่งสุดท้าย แต่คำตอบกลับอธิบายไว้ในตำแหน่งแรก ผู้ดูแลตรวจได้ว่าความคลาดเคลื่อนมาจากผลที่เก็บไว้ การแสดงผล หรือคำตอบ AI หากเรียกเพียงว่าเป็นบั๊กการจั่วไพ่ ก็เท่ากับระบุสาเหตุเร็วเกินไป
คำขอฟีเจอร์ต้องเขียนอีกแบบ หากต้องการเทียบสองคำตอบข้างกัน ให้บอกว่าปัจจุบันทำอย่างไร และการเทียบจะช่วยตัดสินใจเรื่องใด อย่าอธิบายอินเทอร์เฟซที่เพิ่งเสนอว่าเป็นตัวควบคุมที่มีอยู่แล้วแต่ทำงานผิด
สร้างขั้นตอนทำซ้ำที่เล็กที่สุด
ลองทำปัญหาซ้ำในเซสชันที่ทิ้งได้ โดยใช้เนื้อหาสังเคราะห์ เอาไฟล์แนบและบริบทที่ไม่เกี่ยวข้องออกทีละอย่าง เป้าหมายคือขั้นตอนสั้น ๆ ที่ยังคงทำให้เกิดปัญหา หากเอาบางอย่างออกแล้วปัญหาหายไป ก็ควรบันทึกข้อสังเกตนั้นในรายงาน
ซอร์สทาโรต์เดสก์ท็อปของ Mystilink ที่ตรวจดูรับตัวระบุสเปรด one, three, five, cross และ decision และบันทึกสถานะจั่วเสร็จหรือข้าม รายงานที่เกี่ยวกับเส้นทางนี้ควรบอกว่าใช้สเปรดใด และผู้ใช้ทำการสอบถามจนเสร็จหรือปิดไปก่อน เพื่อให้ผู้ดูแลมีแขนงการทำงานที่ชัดเจนให้ตรวจ
หากเป็นปัญหาประวัติ ให้ระบุฟิลด์ที่ได้รับผลและใช้ค่าสมมติแทน README ของประวัติการเกิดที่ตรวจดูแยกฟิลด์อัตลักษณ์จากค่าคำนวณดวง หากความคลาดเคลื่อนเกี่ยวข้องกับสองส่วนนี้ ให้ระบุทั้งสองป้ายและผลที่สังเกต อย่าเปิดเผยประวัติจริงเพื่อแสดงความต่าง
บันทึกความคาดหวังโดยไม่ด่วนสรุปสาเหตุ
บอกว่าคาดหวังอะไรและเพราะอะไร ป้ายที่เห็น ข้อความในเอกสาร หรือการทำงานครั้งก่อนที่สำเร็จ อธิบายความคาดหวังได้ จากนั้นบอกให้ตรงว่าเกิดอะไรขึ้นจริง แยกคำอธิบายที่คาดไว้เป็นอีกประโยค เช่น “อาจเกี่ยวกับการจับคู่ตำแหน่ง แต่ฉันยังไม่ได้ยืนยันสาเหตุ”
ใส่รุ่นแอปและระบบปฏิบัติการเมื่อมีข้อมูล หากรายงานเกี่ยวกับพฤติกรรมโมเดล ให้ระบุโมเดลที่เลือกและเส้นทางเชื่อมต่อโดยไม่ใส่ข้อมูลรับรอง เอกสารแพลตฟอร์มที่ตรวจดูแยกเส้นทางเกตเวย์ Newton จาก BYOK ที่ตรงถึงผู้ให้บริการ ข้อมูลเส้นทางจึงอาจช่วยจำกัดวงปัญหาเกี่ยวกับพฤติกรรมคำขอ
หลีกเลี่ยงการวางโทเคน คีย์ผู้ให้บริการ หรือส่วนหัวคำขอที่ยังไม่ปกปิด หากตัวอย่างทำซ้ำขนาดเล็กยังไม่พอ ผู้ดูแลสามารถขอข้อมูลวินิจฉัยในรูปแบบที่ปลอดภัยกว่าได้ ใส่ข้อความผิดพลาดหลังจากตรวจรายละเอียดที่ระบุตัวบุคคลแล้วเท่านั้น
ให้ประวัติพอที่จะอธิบายการเปลี่ยนสถานะ
บางปัญหาเกิดหลังการแก้ไขหรือการขัดจังหวะ จดลำดับที่เกี่ยวข้อง เช่น จั่วไพ่เสร็จ ส่งคำแก้ไข เปิดเซสชันใหม่ แล้วพบความคลาดเคลื่อน ภาพหน้าจอสถานะสุดท้ายเพียงภาพเดียวอาจซ่อนขั้นที่กระตุ้นปัญหา
เอกสารเซสชันที่ตรวจดูอธิบายบันทึกบทสนทนาที่เก็บถาวรและการดำเนินต่อจากบันทึก หากปัญหาเกี่ยวกับการกู้คืน ให้แยกบทสนทนาที่เสร็จแล้วจากการสอบถามที่ยังค้าง ระบุว่าปัญหาเกิดเมื่อเปิดเซสชันเดิมอีกครั้ง หรือเริ่มเซสชันใหม่ ความต่างเหล่านี้อาจสำคัญกว่าความยาวรายงาน
ใช้ข้อความตัดตอนสั้น ๆ พร้อมป้ายบทบาท ข้อความผู้ใช้ ผลจากเครื่องมือ และคำตอบ AI เป็นหลักฐานคนละชนิด การคงป้ายไว้ช่วยไม่ให้รายงานทำให้ข้อความที่เดาดูเหมือนข้อมูลที่ผู้ใช้ให้มา
อธิบายผลกระทบของปัญหา
บอกว่าคุณทำอะไรต่อไม่ได้ เช่น ต้องประกอบสเปรดใหม่เอง ไม่รู้ว่าใช้ประวัติไหน หรือต้องแนบบริบทต้นทางใหม่ก่อนแชร์โน้ต สิ่งนี้ช่วยให้ผู้ดูแลประเมินผลกระทบจริงโดยไม่ต้องใช้คำเกินจริง
สำหรับข้อเสนอปรับปรุง ให้ยกหนึ่งตัวอย่างของการทำงานที่สำเร็จ คำขอให้การส่งออกมีคำถามเดิม อาจแสดงคำถามสมมติสั้น ๆ และอธิบายว่ามันหายไปตรงไหนในขั้นตอนปัจจุบัน ผู้ดูแลจึงพิจารณาวิธีแก้ได้หลายแบบ
จบรายงานด้วยข้อมูลที่ยังไม่ทราบและคุณยังให้เพิ่มได้อย่างปลอดภัย ให้การติดตามสาธารณะเน้นวิธีทำซ้ำและผลลัพธ์ หากรุ่นหลังแก้ได้แล้ว ให้จดรุ่นที่ทดสอบและขั้นตอน ผู้อ่านในอนาคตจะมีหลักฐานที่ใช้ได้ และกระทู้สนับสนุนจะไม่กลายเป็นข้ออ้างไร้หลักฐานเกี่ยวกับผลิตภัณฑ์ทุกเวอร์ชัน