วิธีส่งผลกระทบต่อลำดับความสำคัญของข้อบกพร่องให้กับนักพัฒนาและปฏิบัติต่อพวกเขาอย่างไร

เรามีกระบวนการบั๊กที่ใช้งานอยู่ในปัจจุบัน

เรามีบั๊ก 3 ระดับ:

• ข้อผิดพลาด P1: ข้อบกพร่องที่ทำให้ผู้ใช้ไม่สามารถทำงานได้ พวกเขาจะต้องแก้ไขทันที
• ข้อผิดพลาด P2: ข้อบกพร่องที่ส่งผลกระทบ แต่ผู้ใช้สามารถทำงานได้
• ข้อผิดพลาด P3: ข้อบกพร่องที่ไม่ส่งผลกระทบและผู้ใช้สามารถทำงานได้

P1 เป็นข้อบังคับและต้องได้รับการจัดการทันที แต่สำหรับ P2 และ P3 เราจะตัดสินเป็นกรณีไป

ด้วย 3 ระดับที่เรามีทีมมีแนวโน้มที่จะทำงานในการพัฒนาที่เร่งรีบมากกว่าที่ลูกค้าถามแทนการติดต่อกับ P2 และ P3 ซึ่งเกือบจะไม่เร่งด่วน

คำถามดังต่อไปนี้:

ฉันควรเพิ่มระดับความสำคัญอีกระดับเช่นมี P4 หรือไม่

ฉันควรกำหนดเป้าหมายให้พวกเขาสำหรับจัดการกับตั๋วที่ไม่เร่งด่วนเหมือนในสัปดาห์นี้หรือไม่เมื่อไม่ได้มอบหมายงานการเขียนโค้ดคุณควรปฏิบัติต่ออย่างน้อย 1 P2 หรือไม่

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

ปรับปรุง:

ฉันถูกเสนอคำถามนี้ในแง่ของความคล้ายคลึงกัน อย่างไรก็ตามมันไม่เหมือนกันเลย

คำถามของฉันคือทำอย่างไรถึงจะมีคนจัดการกับข้อผิดพลาดโดยไม่มีการกำหนดวาระที่เข้มงวดและยังไม่ได้รับการแก้ไข ดังนั้นไม่คำถามที่บอกเป็นนัย ๆ ไม่ได้ช่วยฉัน ยังขอบคุณ

โดยทั่วไปคุณมีสองแกนสำหรับข้อบกพร่อง: แรงโน้มถ่วงและความถี่

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

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

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

ส่วนใหญ่เป็นอัตนัยเกี่ยวกับสิ่งที่ถือเป็นบั๊กที่มีแรงโน้มถ่วง 3 หรือบั๊กที่มีความถี่ 3 แต่ใช้สามัญสำนึกของคุณ บั๊กที่มีแรงโน้มถ่วง 1 ความถี่ 2 อาจเป็นป้ายกำกับที่สะกดผิด บั๊กที่มีแรงโน้มถ่วง 2 ความถี่ 1 อาจเป็นการจัดการข้อผิดพลาดที่เหมาะสมเมื่อการเชื่อมต่อฐานข้อมูลไม่ทำงาน

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

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

โชคดี!

สิ่งนี้สำคัญมากสำหรับสิ่งที่คุณคิดว่าสำคัญกว่า ข้อผิดพลาด P2 หรือคุณสมบัติใหม่

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

นักพัฒนาซอฟต์แวร์ไม่ได้รับอนุญาตให้เลือกงานที่พวกเขาทำ นั่นคือหน้าที่ของผู้จัดการโครงการ ใครจะต้องตรวจสอบให้แน่ใจว่าโครงการมีจำนวนคุณลักษณะที่สำคัญที่สุดเท่าที่จะเป็นไปได้ก่อนที่งบประมาณจะหมด

นั่นคือสิ่งที่สำคัญที่สุดจริงๆ กฎง่ายๆเช่น "แก้ไขอย่างน้อย 1 P2 ต่อสัปดาห์" ไม่ได้ช่วยให้บรรลุเป้าหมายนี้จริงๆ

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

คุณอยู่ใน บริษัท ที่ดีถ้า devs ของคุณปล่อยให้พวกเขาเลื่อน แน่นอนคุณสามารถเล่นปาหี่ด้วย "กฎ" ตามที่คุณพูดถึง ("หากคุณไม่ได้ทำงานกับคุณสมบัติใหม่คุณต้องทำงานอย่างน้อย P2 ต่อสัปดาห์") แต่นั่นอาจทำให้คุณไม่เป็นที่นิยม

คำถามของฉันคือทำอย่างไรถึงจะมีคนจัดการกับข้อผิดพลาดโดยไม่มีการกำหนดวาระที่เข้มงวดและยังไม่ได้รับการแก้ไข

แต่ฉันขอแนะนำให้เปลี่ยนความคิดโดยรวมเล็กน้อยและทำข้อบกพร่องเพิ่มเติมเช่นคุณลักษณะในแง่ที่ว่าพวกเขาเป็นพลเมืองชั้นหนึ่งในงานในมือของคุณ ใช่คุณสมบัติใหม่ยอดเยี่ยม ใช่การจัดการและการขายดึงคุณสมบัติใหม่ ๆ อย่างหนัก แต่การมีแอพพลิเคชั่นที่เสถียรและใช้งานได้ดีแทนที่จะเป็นกองแมลงขนาดใหญ่ก็มีความสำคัญเช่นกัน

อย่าบอก devs ของคุณว่าพวกเขาต้องทำงานที่ไม่ชอบ แต่พยายามเปลี่ยนบรรยากาศเพื่อให้พวกเขาชอบทำงานกับแมลง พยายามปลูกฝังความภาคภูมิใจในแอปพลิเคชันที่ไม่มีข้อบกพร่อง ทำให้สนุกมากขึ้น (sic) ในการทำงานกับข้อผิดพลาดโดยอนุญาตให้พวกเขาแก้ไขปัญหาพื้นฐานที่ทำให้เกิดรายการข้อผิดพลาดนั้น (เช่นไม่ใช่เพียงแค่การแก้ไขปัญหาด่วน / แฮ็ก) หากมี การแตกโครงสร้างชั้นเรียนที่แตกออกและแทนที่ด้วยสิ่งที่เหมาะสมกว่านั้นสามารถสร้างความบันเทิงให้กับผู้พัฒนาได้มาก หากคุณมีชิ้นส่วนกลางที่หักซึ่งทำให้เกิดข้อบกพร่องเป็นประจำที่อื่นให้แก้ไขส่วนกลาง

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