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

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

ขอบเขตการศึกษา: วิเคราะห์ปัจจัยและรูปแบบความแปรปรวนของเวลาในรอบการทำงานจากผู้ร่วมงานเกือบ 12,000 คนในองค์กรกว่า 200 แห่ง

ตำนานของประสิทธิภาพนักพัฒนาที่สม่ำเสมอ

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

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

ปัจจัยสำคัญที่ส่งผลต่อระยะเวลาในการพัฒนา:

• การ merge PR มากขึ้น: ลดระยะเวลาในการพัฒนา (ขนาดผลกระทบ: -0.0083)
• จำนวนวันที่เขียนโค้ดต่อสัปดาห์มากขึ้น: ลดระยะเวลาในการพัฒนา
• การทำงานร่วมกันมากขึ้น: ลดระยะเวลาในการพัฒนา
• จำนวนความคิดเห็นต่อ PR มากขึ้น: เพิ่มระยะเวลาในการพัฒนา
• จำนวนข้อบกพร่องมากขึ้น: เพิ่มระยะเวลาในการพัฒนา

ปัญหาของการปฏิบัติต่อซอฟต์แวร์เหมือนการผลิต

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

ซอฟต์แวร์เป็นเรื่องที่ซับซ้อนเพราะวิศวกรซอฟต์แวร์เป็นทั้งสถาปนิก วิศวกร และช่างก่อสร้างในเวลาเดียวกัน

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

ปัจจัยด้านสถาปัตยกรรม

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

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

แนวทางระดับระบบ

การวิจัยแนะนำว่าการปรับปรุงความเร็วในการส่งมอบซอฟต์แวร์ต้องการการคิดระดับระบบมากกว่าการแทรกแซงที่เน้นบุคคล แทนที่จะพยายามวัดและเพิ่มประสิทธิภาพของประสิทธิภาพส่วนบุคคล องค์กรควรมุ่งเน้นไปที่แนวโน้มระดับทีมเป็นเดือนๆ ยอมรับว่าความแปรปรวนเป็นเรื่องปกติ และลงทุนในการปรับปรุงระบบที่เป็นประโยชน์ต่อทุกคน

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

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

อ้างอิง: Measuring Engineering