การคัดกรองบั๊กที่พร้อมตัดสินใจ
เทมเพลตคัดกรองบั๊กสำหรับลำดับความสำคัญและผู้รับผิดชอบ
ทำให้ผลลัพธ์การคัดกรองแต่ละแบบชัดเจน: ขอข้อมูล รับและมอบหมาย รวมเป็นรายการซ้ำ เลื่อนพร้อมวันที่ทบทวน หรือปฏิเสธพร้อมเหตุผล
ลงชื่อเข้าใช้เพื่อตรวจมุมมองที่มีข้อมูลนี้ จากนั้นติดตั้ง App พร้อมข้อมูลตัวอย่างเพื่อทดสอบเรคคอร์ด การตัดสินใจ และแดชบอร์ดที่เชื่อมกัน
การตัดสินใจที่การคัดกรองต้องให้ได้
การคัดกรองบั๊กเปลี่ยนรายงานให้เป็นการดำเนินการถัดไปที่ควบคุมได้ การตัดสินใจควรอิงความสามารถในการทำซ้ำ ผลกระทบต่อผู้ใช้ และความเร่งด่วน ไม่ใช่คำขอที่เสียงดังที่สุด และควรทิ้งผู้รับผิดชอบรุ่นเป้าหมายหรือวันที่ทบทวนไว้
- ระดับความรุนแรงและลำดับความสำคัญต้องแยกกัน
- ผลลัพธ์รายการซ้ำและต้องการข้อมูลยังเก็บบริบทไว้
- บั๊กที่รับแล้วต้องมีผู้รับผิดชอบและรุ่นเป้าหมาย
กฎการคัดกรอง
ใช้คำถามเดียวกันตามลำดับเดียวกัน
การคัดกรองที่สม่ำเสมอทำให้การตัดสินใจเกี่ยวกับงานค้างอธิบายได้ และลดการเร่งลำดับความสำคัญโดยไม่มีหลักเกณฑ์
เราทำซ้ำได้ไหม
ยืนยันเส้นทางหรือส่งคำขอข้อมูลที่เฉพาะเจาะจงกลับไป
เป็นปัญหาที่รู้แล้วหรือไม่
รวมรายการซ้ำเข้ากับปัญหาหลักหนึ่งรายการและเก็บบริบทรายงานไว้
ผลกระทบคืออะไร
กำหนดระดับความรุนแรงจากผลต่อผู้ใช้ ข้อมูล ความปลอดภัย และการปฏิบัติงาน
ต้องดำเนินการเมื่อไร
กำหนดลำดับความสำคัญจากความเร่งด่วนวิธีแก้ชั่วคราวและจังหวะการปล่อยรุ่น
ใครรับผิดชอบการดำเนินการถัดไป
มอบหมายเจ้าขององค์ประกอบและรุ่นเป้าหมายหรือวันที่ทบทวน
อย่ารวมสองการตัดสินใจเข้าด้วยกัน
ระดับความรุนแรงอธิบายผลกระทบ ลำดับความสำคัญอธิบายลำดับการทำงาน
สองอย่างนี้มักสัมพันธ์กัน แต่ข้อบกพร่องที่มีผลกระทบสูงอาจเลื่อนได้หากมีวิธีแก้ชั่วคราวที่ปลอดภัย ขณะที่ประเด็นเล็กกว่าอาจเร่งด่วนสำหรับการเปิดตัวที่ใกล้ถึง
| มิติ | Question | ตัวอย่าง |
|---|---|---|
| ระดับความรุนแรง | ข้อบกพร่องกระทบผู้ใช้หรือธุรกิจหนักแค่ไหน | รับชำระเงินแล้วแต่ไม่ยืนยันผลถือว่าร้ายแรง |
| ลำดับความสำคัญ | ทีมควรลงมือเร็วแค่ไหนเมื่อเทียบกับงานอื่น | ข้อขัดขวางการปล่อยรุ่นเป็น P0 แม้ก่อนมีผู้ใช้วงกว้างเจอ |
| วิธีแก้ชั่วคราว | ผู้ใช้ทำงานให้เสร็จอย่างปลอดภัยด้วยวิธีอื่นได้ไหม | การกระทบยอดด้วยมือช่วยลดความเร่งด่วนทันที แต่ไม่ลดผลกระทบ |
| รุ่นเป้าหมาย | รุ่นทดสอบใดควรมีการแก้ไขนี้ | Web 4.28.0 ถูกพักไว้จนกว่าการตรวจยืนยันจะผ่าน |
ทุกแถวต้องมีทางออก
บันทึกว่าทำไมบั๊กจึงถูกเลื่อนสถานะ หรือไม่ถูกเลื่อน
งานค้างจะมีประโยชน์เมื่อการตัดสินใจคงทนและกลับมาทบทวนได้
ต้องการข้อมูล
ส่งคำขอที่ชัดเจนกลับไปยังผู้รายงาน
รับแล้ว
มอบหมายผู้รับผิดชอบ ลำดับความสำคัญ และรุ่นเป้าหมาย
รายการซ้ำ
ลิงก์ไปยังประเด็นหลักและเก็บหลักฐานใหม่ไว้
เลื่อน
บันทึกเหตุผลและวันที่หรือเงื่อนไขสำหรับพิจารณาใหม่
ปฏิเสธ
อธิบายขอบเขต พฤติกรรมที่คาดหวัง หรือกรณีที่ไม่รองรับ
คำถามและขอบเขต
คำถามเรื่องการคัดกรองบั๊ก
แนวทางปฏิบัติสำหรับมอบหมายผลกระทบ ความเร่งด่วน และผู้รับผิดชอบ
ทีมควรคัดกรองบั๊กบ่อยแค่ไหน
กำหนดรอบคัดกรองให้สอดคล้องกับปริมาณและความเสี่ยง รายงานร้ายแรงจากระบบจริงต้องถูกส่งต่อทันที ส่วนทีมผลิตภัณฑ์อาจทบทวนรายงานทั่วไปทุกวันหรือหลายครั้งต่อสัปดาห์
ใครควรอยู่ในการคัดกรอง
รวมคนที่เข้าใจผลกระทบต่อผู้ใช้ คนที่เข้าใจองค์ประกอบที่ได้รับผลกระทบ และคนที่ยืนยันผู้รับผิดชอบหรือจังหวะการปล่อยรุ่นได้
ควรปิดรายการซ้ำหรือไม่
ทำเครื่องหมายว่าเป็นรายการซ้ำได้ แต่ต้องเก็บผู้รายงาน บริบท และหลักฐานไว้ แล้วลิงก์กับประเด็นหลัก ปริมาณรายการซ้ำอาจเผยให้เห็นผลกระทบ
บั๊กที่ถูกเลื่อนจะเกิดอะไรขึ้น
ระบุเหตุผลและเงื่อนไขสำหรับทบทวน สถานะ "ไว้ทีหลัง" ที่ไม่มีผู้รับผิดชอบเป็นเพียงงานค้างที่เพิ่มขึ้นโดยมองไม่เห็น
ทำให้การตัดสินใจงานค้างอธิบายได้
เริ่มจากผลลัพธ์การคัดกรองที่มีข้อมูลตัวอย่าง
ตรวจตัวอย่างที่รับแล้ว ต้องการข้อมูล รายการซ้ำ เลื่อน และเปิดซ้ำ ก่อนปรับกฎ



