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