- บทความนี้อธิบายว่าความพยายามในการวัด ประสิทธิภาพของทีม ล้มเหลวได้อย่างไร
- มีการตัดสินใจนำ ตัวชี้วัดผลงานรายบุคคล มาใช้เพื่อการประเมินและการพัฒนานักพัฒนา
- ตัดตัวชี้วัดอย่างจำนวนบรรทัดโค้ดหรือจำนวนบั๊กออกไปเพราะมีโอกาสถูกปั่นตัวเลขได้สูง และเลือกวัดผลงานด้วย story point หรือ จำนวนสตอรี่ที่ส่งมอบ แทน
ผลงานของ Tim Mackinnon คือ ‘0’
- วัดผลงานของสมาชิกทุกคนในทีมผ่านเครื่องมือวัดประสิทธิภาพของทีม (Jira เป็นต้น)
- คะแนนผลงานของ Tim คือ 0 → เพราะไม่ได้บันทึก story point เลยแม้แต่รายการเดียว
- ผู้จัดการจึงเรียกร้องให้เปลี่ยนตัว Tim เพราะผลงานของ Tim เป็น 0
เหตุผลที่ Tim Mackinnon ไม่ได้สร้างผลงานตามตัวชี้วัด
- Tim ไม่ได้รับผิดชอบสตอรี่โดยตรง
- แต่หันไปโฟกัสกับ pair programming กับเพื่อนร่วมทีม
- ทำงานร่วมกับ นักพัฒนาที่มีประสบการณ์น้อยกว่า และช่วยชี้นำให้พวกเขาแก้ปัญหาได้
- ไม่ได้ลงมือแก้ให้เอง แต่ใช้คำถามเพื่อช่วยให้หาทางออกได้
- กับ นักพัฒนาระดับซีเนียร์ ก็ช่วยกันคิดปัญหาและปรับปรุงวิธีแก้ร่วมกัน
- แม้ Tim จะไม่ได้เขียนโค้ดด้วยตัวเองโดยตรง แต่กลับช่วยยกระดับผลงานโดยรวมของทีม
คุณูปการที่แท้จริงของ Tim Mackinnon
- สิ่งที่ Tim สร้างให้ทีมไม่สามารถวัดได้ด้วยคะแนนผลงานรายบุคคล
- ด้วย Tim ประสิทธิภาพการทำงานและคุณภาพโค้ดของทั้งทีมดีขึ้น
- เมื่อ Tim ทำงานร่วมด้วย ทีมจะได้ ผลลัพธ์ที่เร็วขึ้นและดีกว่าเดิม
เปลี่ยนวิธีประเมินเป็นผลงานของทีม
- อธิบายคุณูปการของ Tim ให้ผู้จัดการเข้าใจ และเปิดโอกาสให้สังเกตด้วยตัวเอง
- หลังจากยืนยันได้ว่าผลงานของทั้งทีมดีขึ้น ก็เลิกใช้วิธีวัดผลงานรายบุคคล
- เปลี่ยนมาใช้ ผลงานของทีมและผลกระทบทางธุรกิจ เป็นเกณฑ์ประเมินแทนผลงานรายบุคคล
สรุป (tl;dr)
- ควรวัดประสิทธิภาพจาก ผลลัพธ์ทางธุรกิจ (เช่น การลดต้นทุน การสร้างรายได้ ฯลฯ)
- ในระบบที่ซับซ้อน การวัดผลงานรายบุคคลไม่มีความหมาย
- DORA Metrics และตัวชี้วัดลักษณะเดียวกันเป็นเครื่องมือวัดประสิทธิภาพของระบบ ไม่ใช่เครื่องมือวัดการมีส่วนร่วมของรายบุคคล
- ถ้ามีโอกาสได้ร่วมงานกับ Tim Mackinnon อย่าปล่อยให้หลุดมือ
5 ความคิดเห็น
จริง ๆ แล้วพอข้ามระดับซีเนียร์ไปถึงประมาณสตาฟฟ์เอนจิเนียร์ ก็จะค่อย ๆ ห่างจากโค้ดที่ถูกดีพลอยลงสู่ภาคสนามมากขึ้นเรื่อย ๆ .... และแทนที่จะเขียนโค้ด ก็จะต้องไปโค้ชทั้งระดับซีเนียร์/จูเนียร์มากขึ้นเหมือนกัน ต้องคอยฟังผู้จัดการระบายด้วย.... พอมีปัญหาเกิดขึ้นก็ถูกเรียกไปทั่วทุกที่เพื่อเสนอทางแก้....
งานที่ทำมันเป็นแนวนี้ เลยเป็นไปไม่ได้ที่จะเอาตั๋ว Jira กับคะแนนมาวัดเชิงปริมาณ
ในฐานะ Tech Lead ผมทำงานลักษณะนี้ค่อนข้างบ่อยอยู่เหมือนกัน การพยายามวัดเชิงปริมาณโดยอิงจาก story point ก็คล้ายกัน แต่โชคดีที่บริษัทยังไม่ใหญ่ ทำให้ทั้งผู้บริหารและสมาชิกในทีมรับรู้ว่าผมมีบทบาทอะไรอยู่ ดังนั้นตอนนี้ก็ดูเหมือนว่ายังไม่เกิดปัญหาอะไร
ถ้าองค์กรใหญ่ขึ้น ก็คงต้องลองคิดเรื่องวิธีการวัดเชิงปริมาณด้วยเหมือนกัน
รู้สึกเหมือนเคยเห็นเรื่องนี้จากที่ไหนสักแห่ง.. ที่แท้ก็เป็นบทความปี 2023 นี่เอง
เมื่อ 2 ปีก่อนก็มีโพสต์เดียวกันนี้ขึ้นมาแล้ว https://th.news.hada.io/topic?id=10680
คงเป็นคนประเภทเดียวกับ GitHub Copilot สินะ....
ความคิดเห็นจาก Hacker News
การวัดผลิตภาพของนักพัฒนารายบุคคลเป็นเรื่องไร้สาระ การวัดด้วยจำนวนบรรทัดโค้ดหรือ story points เป็นสิ่งตรงข้ามกับผลิตภาพ สิ่งสำคัญคือนักพัฒนาสร้างคุณค่าได้มากขึ้นด้วยโค้ดที่น้อยลง
พบวิธีแก้ปัญหาโดยใส่ชื่อ Tim ลงในตั๋วงาน สมาชิกทีมจะเต็มใจเข้ามาช่วย
ดีใจที่ Tim ยังอยู่ในทีมและช่วยขับเคลื่อนกระบวนการไปในทิศทางที่ถูกต้อง จำเป็นต้องมีผู้จัดการที่รับฟัง
โมเดลที่มีโปรแกรมเมอร์คนหนึ่งคอยช่วยทุกอย่างโดยไม่มีงานส่วนตัวของตัวเองนั้นดูแปลก
การที่ Tim ไม่มีงานส่วนตัวเลยเป็นเรื่องแปลก เพื่อเพิ่มผลิตภาพของทีมให้สูงสุด จำเป็นต้องสร้างสมดุลระหว่างการมีส่วนร่วมรายบุคคลกับการทำงานร่วมกันในทีม
ถ้า Tim ไม่ได้มีส่วนร่วมกับทีม ก็จะให้เขาเริ่มงานและส่งมอบสตอรี Tim ช่วยคนอื่นได้ก็ดี แต่ก็ควรต้องทำงานของตัวเองด้วย
ไม่จำเป็นที่ทุกอย่างต้องเป็นกิจกรรมกลุ่มเสมอไป ถ้านักพัฒนาโดยเฉลี่ยไม่สามารถส่งมอบฟีเจอร์ได้โดยไม่มีความช่วยเหลืออย่างต่อเนื่องจาก Tim แสดงว่าทีมมีปัญหา
ทีมที่ดีที่สุดมักจะมีคนแบบ Tim อยู่เสมอ ความช่วยเหลือของ Tim จะถ่ายทอดต่อไปยังคนอื่น ทำให้ทั้งทีมเติบโต
การวัดผลิตภาพของนักพัฒนาด้วย story points ไม่ใช่เรื่องที่ดี มีนักพัฒนาคนหนึ่งชื่อ Zero ที่ไม่ได้รับมอบหมายสตอรี แต่คอยช่วยทีม
การหาค่าของงานสนับสนุนในเชิงปริมาณเป็นเรื่องยาก แต่การสนับสนุนนั้นจำเป็น จึงต้องเชื่อใจให้ผู้นำตัดสินได้อย่างถูกต้อง