เกือบทุกข้อบกพร่องที่รายงานเป็นข้อบกพร่องที่มีลำดับความสำคัญสูง [ปิด]

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

ดังนั้นฉันอยากรู้ว่าปัญหานี้เป็นเรื่องปกติหรือไม่ถ้าฉันโชคร้าย ฉันทำการค้นหาโดย Google อย่างรวดเร็วและพบว่าบางทีมใช้แนวทางการรายงานข้อผิดพลาดหรือมีทีม "Bug Triage" แยกต่างหาก หากคุณเผชิญและแก้ไขปัญหานี้อะไรคือวิธีการที่เหมาะกับคุณ

คำถามนี้โดยเฉพาะเกี่ยวกับปัญหา "อัตราเงินเฟ้อสำคัญ": หากคุณเผชิญกับสถานการณ์และสิ่งที่ meassures ส่งผลให้เกิดปัญหานี้

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

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

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

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

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

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

หลังจากการต่อรองเรามีรายการที่ต้องทำของสัปดาห์ซึ่งแบ่งออกเป็น "จะทำ", "อาจทำ" และ "ไม่สามารถทำ" ที่ถูกชนไปสัปดาห์ถัดไป นี่คือที่ต่อรองราคาเพิ่มเติมบางอย่างเข้ามา: เราบอกว่าห้าสิบชั่วโมงเพื่อจัดสรรให้กับข้อบกพร่องและเราแน่ใจว่า 95% ที่จะแก้ไขยี่สิบแรก ฝ่ายบริหารต้องการอย่างยิ่งที่จะแก้ไขข้อผิดพลาดที่ยี่สิบเอ็ดและไม่มีเครดิตเหลืออยู่ จากนั้นเราจะเสนอให้แลกเปลี่ยนข้อผิดพลาดนั้นด้วยรายการ "Will do" หรือมีคนพูดว่า "พาฉันออกจากกลุ่มย่อย FooBazFeature สองสามวันแล้วฉันจะทำ" หรือเราจะพูดว่า "เราต้องการมากกว่านี้ กำลังคน"

ระบบไม่พอใจใครจริง ๆ แต่นี่เป็นความเชื่อ (อย่างน้อยก็ในกลุ่มผู้พัฒนา) จะเป็นสัญญาณที่ดี

รูปแบบเชิงลบเพิ่มเติมที่ปรากฏขึ้นคือ "ความคิดที่ปรารถนา" ในส่วนของผู้จัดการ ("คุณระบุข้อผิดพลาด 57212 ต้องใช้เวลาแปดชั่วโมงนั่นเป็นที่ยอมรับไม่ได้ทำให้มันเป็นสี่") และ "Debug by Fiat" ("ทำทุกสิ่งที่คุณต้องการ แต่ข้อผิดพลาดสี่สิบเหล่านี้จะต้องได้รับการแก้ไขก่อนการสาธิตครั้งใหญ่ในสัปดาห์หน้าคุณไม่สามารถมีเวลาได้มากขึ้น นอกจากนี้Boxer Syndrome ("ฉันจะทำงานหนักขึ้น") ซึ่งมีแนวโน้มที่จะทำงานได้ดีมากในช่วงเวลาสั้น ๆแต่มักจะนำไปสู่นักพัฒนาที่ออกนอกบ้านหรือออกจากทุ่งหญ้าสีเขียว

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

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

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

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

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

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

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

1. โปรแกรมใช้ไม่ได้หรือล้มเหลวเมื่อฉันทำบางสิ่ง
2. โปรแกรมมีข้อบกพร่องกราฟิกที่มีผลต่อการทำงาน
3. โปรแกรมไม่อนุญาตให้ฉันทำสิ่งที่ฉันควรจะทำ
   โปรแกรมอนุญาตให้ฉันทำสิ่งที่ฉันไม่ควรทำ
4. โปรแกรมให้ผลที่ผิดเมื่อฉันทำอะไร
5. โปรแกรมใช้เวลาในการทำอะไรนานเกินไป
6. โปรแกรมมีข้อบกพร่องกราฟิกที่ไม่มีผลต่อฟังก์ชันการทำงาน
7. โปรแกรมมีข้อบกพร่องที่ไม่สอดคล้องกับหมวดหมู่ข้างต้นอย่างใดอย่างหนึ่ง

เพื่อให้ตัวอย่าง:

1. iPhone ของฉันทำงานล้มเหลวเมื่อฉันได้รับข้อความที่มีสัญลักษณ์ภาษาฮิบรู
2. หน้าจอล็อค Android ของฉันหมุนไปครึ่งทางครึ่งหนึ่งของหน้าจอ
3. บางครั้งโทรศัพท์ Android ของฉันไม่ยอมรับรหัส lockscreen ของฉันแม้ว่าฉันจะป้อนรหัสที่ถูกต้องก็ตาม
4. เมื่อฉันพยายามนำทางไปยัง PhoneHub.net โทรศัพท์ของฉันจะเปลี่ยนเส้นทางฉันไปที่ไซต์สำหรับผู้ใหญ่
5. เมื่อฉันเปิดแอพ Facebook มันต้องใช้เวลาสักครู่ในการเปิดแม้ในการเชื่อมต่อที่รวดเร็วและไม่มีแอพอื่นทำงานอยู่
6. แอปของคุณมีข้อผิดพลาดในการสะกดคำ
7. ฉันพบข้อบกพร่องด้านความปลอดภัยในโปรแกรมของคุณและต้องการรายงาน

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

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

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

คุณสามารถเห็นบางส่วนของระบบนี้ในสถานการณ์ที่รองรับการรับส่งข้อมูลสูง: บริษัท เทคโนโลยียักษ์ใหญ่เช่น Microsoft, Facebook, Google, บริษัท เกมที่มีผู้ใช้จำนวนมากเช่น Valve และ Blizzard รัฐบาลบางประเทศ ... ในขณะที่ฉันไม่แน่ใจ ในการทำงานเบื้องหลังคุณสังเกตเห็นว่าระบบรองรับผู้ใช้ของพวกเขามีอินเทอร์เฟซคล้ายกับสิ่งที่ฉันแนะนำที่นี่ด้วยระบบหมวดหมู่ที่เข้มงวด

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

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

1. สูญเสียการทำงานอย่างสมบูรณ์
2. สูญเสียฟังก์ชันการทำงานบางส่วน
3. การลดประสิทธิภาพอย่างกว้างขวาง
4. ลดประสิทธิภาพในการแปล
5. ความรำคาญหรือสิ่งกีดขวาง (มีวิธีแก้ไข)
6. ประทิ่น
7. ไม่มีใครสังเกตเห็นจริงพบในระหว่างการทดสอบเชิงสำรวจที่คลุมเครือ

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

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

มันจะเป็นแบบนี้:

Mgr: คุณกำลังทำงานอะไรอยู่? Dev: งานที่มีลำดับความสำคัญต่ำ Mgr: คุณไม่ควรทำงานกับงานที่มีลำดับความสำคัญสูงหรือไม่

ลูกค้า: ข้อผิดพลาดของฉันจะได้รับการแก้ไขเมื่อไหร่? Dev: มันมีลำดับความสำคัญต่ำเรามีงานที่มีลำดับความสำคัญสูง ลูกค้า: โอ้งั้นตั้งค่าสถานะบั๊กของฉันเป็นลำดับความสำคัญสูง

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

1. ลำดับความสำคัญสูงมาก
2. ลำดับความสำคัญสูงเป็นพิเศษ
3. จัดลำดับความสำคัญสูงมากเป็นพิเศษ
4. จัดลำดับความสำคัญสูงมากเป็นพิเศษ

ฯลฯ

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

โดยทั่วไปมี 2 วิธีในการตอบโต้เรื่องนี้:

1. ควบคุมจากลูกค้าเกี่ยวกับระดับความสำคัญ
2. เชื่อมโยงต้นทุนกับลูกค้าสำหรับระดับความสำคัญที่สูงขึ้น

หนึ่งสามารถเพิ่มระดับความสำคัญสูงกว่าและสูงกว่าให้กับระบบโดยเฉพาะอย่างยิ่งถ้าเป็นจิรา การให้ลำดับความสำคัญสูงขึ้นใหม่ ๆ นั้นจะยิ่งเพิ่มความงี่เง่า แต่ชื่อที่น่าสยดสยองก็สามารถเพิ่มเอฟเฟ็กต์ Hawthorneในคุณภาพของตัวเลือกลำดับความสำคัญที่จัดทำโดยทุกฝ่าย หากลำดับความสำคัญสูงสุดมีชื่อต่างชาติจริง ๆ ผลอาจเป็นแบบถาวร ในที่สุดเมื่อใครบางคนเลือกลำดับความสำคัญพวกเขาต้องชั่งน้ำหนักผลกระทบทางสังคมจากการเลือกลำดับความสำคัญ "ข้อผิดพลาดของการเสียชีวิต" กับการได้รับความสนใจ ดังนั้นลำดับความสำคัญสูงสุดคือพฤตินัยสงวนไว้สำหรับสิ่งที่เกิดขึ้นกับ CTO ที่บ้านต่อหน้าแขกของเขาหรือเหตุการณ์อื่น ๆ ที่มีทัศนวิสัยเทียบเท่า

แนะนำค่าใช้จ่ายในการสนับสนุนคำขอ คุณสามารถอนุญาตให้ผู้ใช้รายงานรายการ X ลำดับความสำคัญสูงในช่วงเวลาที่กำหนดจำนวน Y ของรายการลำดับความสำคัญปานกลางและระดับความสำคัญต่ำ Z

แน่นอนว่ายังหมายถึงทีมผู้พัฒนาและผู้บริหารจะต้องรับประกันว่าจำนวนของสิ่งเหล่านี้จะได้รับการแก้ไข - รายการที่มีลำดับความสำคัญสูงส่วนใหญ่ของรายการที่มีลำดับความสำคัญปานกลางและ (อาจ) บางรายการ รายการที่มีลำดับความสำคัญต่ำภายในกรอบเวลาที่กำหนด

แต่ถ้ามันเป็นไปได้การจัดการจะต้องซื้อจริง ๆ ไม่เช่นนั้นการฝึกทั้งหมดจะเสียเวลา

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

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

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

นี่คือการจัดการที่เลวร้ายโดยเฉพาะอย่างยิ่งผู้จัดการที่ไม่ใช่ด้านไอทีที่ไม่สามารถพูดว่า "ไม่" หรือที่ปล่อยให้นักธุรกิจตั้งความสำคัญข้อบกพร่อง (ไม่ว่าในกรณีใดผู้จัดการกล่าวว่าไม่ได้ทำงานของเขา / เธอ) ผู้จัดการส่วนใหญ่จะจัดลำดับความสำคัญข้อผิดพลาดที่พวกเขาได้รับการติดต่อครั้งสุดท้ายเพราะ "มันเป็นเรื่องเร่งด่วน"; ผลลัพธ์สุทธิคือนักพัฒนาท้ายสุดกระโดดจากบั๊กไปยังบั๊กดังนั้นการแก้ไขบั๊กเดี่ยวใช้เวลานานขึ้น (การสลับบริบท) และในตอนท้ายของวันที่ทุกคนไม่มีความสุข "เมื่อทุกบั๊กเป็นบั๊กที่มีลำดับความสำคัญสูงจะไม่มีบั๊กที่มีลำดับความสำคัญสูง"

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

โดยทั่วไปหากนักพัฒนาไม่มีการควบคุมลำดับความสำคัญแสดงว่าคุณเสียไปแล้ว

ในฐานะ บริษัท คุณต้องการแก้ไขปัญหาด้วยอัตราส่วนความสำคัญ / ต้นทุนสูงสุด ผู้ใช้เป็นผู้ตัดสินใจที่สำคัญวิศวกรรมตัดสินใจต้นทุน หากผู้ใช้กำหนดความสำคัญแบบเดียวกันให้กับบั๊กทั้งหมดแสดงว่ามีค่าใช้จ่ายเพียงอย่างเดียว

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

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

ปัจจัยบางประการ ...

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

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

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

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

ส่วนใหญ่ได้รับการกล่าวถึงแล้ว แต่ฉันจะกลั่นรายการ "สวนสัตว์บั๊ก" ลงไปเป็นบางสิ่งที่ละเอียดน้อยลง:

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

B: ทุกอย่างอื่น เหล่านี้เป็นข้อบกพร่อง "ต่อรองได้"

ข้อบกพร่องของการเจรจาต่อรองตกอยู่ภายใต้ความกังวลที่หลากหลาย

1: ข้อบกพร่องที่ส่งผลกระทบต่อความปลอดภัย

2: ข้อบกพร่องที่ส่งผลกระทบต่อการใช้งาน (ความเหมาะสมสำหรับวัตถุประสงค์);

3: ข้อบกพร่องที่ส่งผลกระทบต่อความสวยงาม;

4: ข้อบกพร่องที่ส่งผลกระทบต่อประสิทธิภาพ (อาจเป็นส่วนหนึ่งของการใช้งาน?);

5: ข้อบกพร่องที่ทำให้คุณอ่อนไหวในฐานะโปรแกรมเมอร์มืออาชีพ

6: ข้อบกพร่องที่ลดความน่าเชื่อถือของผู้ใช้;

นั่นคือโลกแห่งอุดมคติที่ไม่มีพวกเราอยู่ ถอนหายใจ เพื่อที่จะตอบคำถามของ OP ให้สมบูรณ์ในอุตสาหกรรมซอฟต์แวร์ทั้งหมดมันเป็นเรื่องธรรมดาที่สุดสำหรับความพยายามในการพัฒนาที่จะอยู่ในสถานะที่ทุกข้อบกพร่องสำคัญ - หนึ่งในซุปเปอร์ไส้กรอกพิเศษ และคุณรู้ว่าสิ่งที่พวกเขาพูดเกี่ยวกับ "พิเศษ": เมื่อทุกคนมีความพิเศษไม่มีใครเป็นพิเศษ

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

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

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

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

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

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

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

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

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

หากความยากลำบากเกิดขึ้นจากการไม่สามารถสร้างเกณฑ์วัตถุประสงค์คุณสามารถใช้เกณฑ์ที่เกี่ยวข้อง:

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

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