การคัดกรองบั๊กที่พร้อมตัดสินใจ

เทมเพลตคัดกรองบั๊กสำหรับลำดับความสำคัญและผู้รับผิดชอบ

ทำให้ผลลัพธ์การคัดกรองแต่ละแบบชัดเจน: ขอข้อมูล รับและมอบหมาย รวมเป็นรายการซ้ำ เลื่อนพร้อมวันที่ทบทวน หรือปฏิเสธพร้อมเหตุผล

การตัดสินใจที่การคัดกรองต้องให้ได้

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

  • ระดับความรุนแรงและลำดับความสำคัญต้องแยกกัน
  • ผลลัพธ์รายการซ้ำและต้องการข้อมูลยังเก็บบริบทไว้
  • บั๊กที่รับแล้วต้องมีผู้รับผิดชอบและรุ่นเป้าหมาย

กฎการคัดกรอง

ใช้คำถามเดียวกันตามลำดับเดียวกัน

การคัดกรองที่สม่ำเสมอทำให้การตัดสินใจเกี่ยวกับงานค้างอธิบายได้ และลดการเร่งลำดับความสำคัญโดยไม่มีหลักเกณฑ์

01

เราทำซ้ำได้ไหม

ยืนยันเส้นทางหรือส่งคำขอข้อมูลที่เฉพาะเจาะจงกลับไป

02

เป็นปัญหาที่รู้แล้วหรือไม่

รวมรายการซ้ำเข้ากับปัญหาหลักหนึ่งรายการและเก็บบริบทรายงานไว้

03

ผลกระทบคืออะไร

กำหนดระดับความรุนแรงจากผลต่อผู้ใช้ ข้อมูล ความปลอดภัย และการปฏิบัติงาน

04

ต้องดำเนินการเมื่อไร

กำหนดลำดับความสำคัญจากความเร่งด่วนวิธีแก้ชั่วคราวและจังหวะการปล่อยรุ่น

05

ใครรับผิดชอบการดำเนินการถัดไป

มอบหมายเจ้าขององค์ประกอบและรุ่นเป้าหมายหรือวันที่ทบทวน

อย่ารวมสองการตัดสินใจเข้าด้วยกัน

ระดับความรุนแรงอธิบายผลกระทบ ลำดับความสำคัญอธิบายลำดับการทำงาน

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

มิติQuestionตัวอย่าง
ระดับความรุนแรงข้อบกพร่องกระทบผู้ใช้หรือธุรกิจหนักแค่ไหนรับชำระเงินแล้วแต่ไม่ยืนยันผลถือว่าร้ายแรง
ลำดับความสำคัญทีมควรลงมือเร็วแค่ไหนเมื่อเทียบกับงานอื่นข้อขัดขวางการปล่อยรุ่นเป็น P0 แม้ก่อนมีผู้ใช้วงกว้างเจอ
วิธีแก้ชั่วคราวผู้ใช้ทำงานให้เสร็จอย่างปลอดภัยด้วยวิธีอื่นได้ไหมการกระทบยอดด้วยมือช่วยลดความเร่งด่วนทันที แต่ไม่ลดผลกระทบ
รุ่นเป้าหมายรุ่นทดสอบใดควรมีการแก้ไขนี้Web 4.28.0 ถูกพักไว้จนกว่าการตรวจยืนยันจะผ่าน

ทุกแถวต้องมีทางออก

บันทึกว่าทำไมบั๊กจึงถูกเลื่อนสถานะ หรือไม่ถูกเลื่อน

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

01

ต้องการข้อมูล

ส่งคำขอที่ชัดเจนกลับไปยังผู้รายงาน

02

รับแล้ว

มอบหมายผู้รับผิดชอบ ลำดับความสำคัญ และรุ่นเป้าหมาย

03

รายการซ้ำ

ลิงก์ไปยังประเด็นหลักและเก็บหลักฐานใหม่ไว้

04

เลื่อน

บันทึกเหตุผลและวันที่หรือเงื่อนไขสำหรับพิจารณาใหม่

05

ปฏิเสธ

อธิบายขอบเขต พฤติกรรมที่คาดหวัง หรือกรณีที่ไม่รองรับ

คำถามและขอบเขต

คำถามเรื่องการคัดกรองบั๊ก

แนวทางปฏิบัติสำหรับมอบหมายผลกระทบ ความเร่งด่วน และผู้รับผิดชอบ

ทีมควรคัดกรองบั๊กบ่อยแค่ไหน

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

ใครควรอยู่ในการคัดกรอง

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

ควรปิดรายการซ้ำหรือไม่

ทำเครื่องหมายว่าเป็นรายการซ้ำได้ แต่ต้องเก็บผู้รายงาน บริบท และหลักฐานไว้ แล้วลิงก์กับประเด็นหลัก ปริมาณรายการซ้ำอาจเผยให้เห็นผลกระทบ

บั๊กที่ถูกเลื่อนจะเกิดอะไรขึ้น

ระบุเหตุผลและเงื่อนไขสำหรับทบทวน สถานะ "ไว้ทีหลัง" ที่ไม่มีผู้รับผิดชอบเป็นเพียงงานค้างที่เพิ่มขึ้นโดยมองไม่เห็น

ทำให้การตัดสินใจงานค้างอธิบายได้

เริ่มจากผลลัพธ์การคัดกรองที่มีข้อมูลตัวอย่าง

ตรวจตัวอย่างที่รับแล้ว ต้องการข้อมูล รายการซ้ำ เลื่อน และเปิดซ้ำ ก่อนปรับกฎ

ใช้ App คัดกรองบั๊ก