ฉันเปลี่ยนความคิดเกี่ยวกับตัวชี้วัดผลงานของพนักงานแล้ว

• ในอดีต (ราวปี 2004-2006) เคยสร้างเครื่องมือเพื่อวัด "ปริมาณผลงาน" ของพนักงานจากจำนวน commit จำนวนคอมเมนต์ ฯลฯ
• ไม่นานมานี้ได้รับข้อเสนอให้มีส่วนร่วมกับผลิตภัณฑ์ที่เกี่ยวกับ "ตัวชี้วัดพนักงาน" จึงกลายเป็นจุดเปลี่ยนที่ทำให้ตัดสินว่าสิ่งที่ฉันเคยทำนั้นผิด และตั้งใจว่าจะไม่แนะนำสิ่งนี้อีกต่อไป

เหตุผลที่เปลี่ยนจุดยืน

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

จุดยืนใหม่

• อย่าสร้างหรือช่วยสร้างเครื่องมือประเภทนั้น
• อย่าทดสอบว่าเพื่อนร่วมงานจัดการปัญหา "service hygiene" พื้นฐานหรือไม่
• อย่าพูดสิ่งที่เป็นเนื้อเป็นหนัง(substantive) ในการรีวิวผลงาน
• เรื่องพวกนี้ไม่ได้ทำให้สถานการณ์ดีขึ้นอย่างที่คุณคิด ตรงกันข้ามกลับทำให้ชีวิตยากขึ้น
• ความคิดที่ว่า "peer review ช่วยให้สถานการณ์ดีขึ้นจริง" เป็นความเข้าใจผิดครั้งใหญ่ของวงการเทคโนโลยี

คำแนะนำในมุมมองแบบเห็นแก่ตัว

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

ความเห็นของ GN⁺

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

[yangeok]

ตัวชี้วัดผลงานของตำแหน่ง k = ความรับผิดชอบร่วมกัน..??

[ndrgrd]

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

[GN⁺]

ความเห็นจาก Hacker News

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

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

• ฉากหนึ่งในซีรีส์ทีวี "Suits" แสดงให้เห็นว่าเมตริกผลงานอาจมองข้ามการมีส่วนร่วมที่สำคัญจริง ๆ ได้ พนักงานที่คอยช่วยเหลือผู้อื่นกลับได้อันดับต่ำในเมตริกผลงาน

• การวัดผลงานด้วยจำนวนบรรทัดของโค้ดนั้นไม่มีความหมาย เป้าหมายคือการลดความซับซ้อนและตอบสนองความต้องการของลูกค้าให้ดีขึ้น

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

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

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

• ในฐานะผู้จัดการฝ่ายวิศวกรรมของบริษัทขนาดใหญ่ เมตริกผลงานถูกใช้เพื่อเสริมการรับรู้ที่มีอยู่เดิม แต่ไม่ได้เปลี่ยนการรับรู้นั้นไปทั้งหมด

• ถ้าสามารถวัดผลงานของผู้บริหารได้ พนักงานก็คงไม่บ่นเรื่องการถูกวัดผลงานของตัวเอง จำเป็นต้องมีการประเมินที่เป็นธรรม

• เครื่องมืออัตโนมัติไม่ได้แสดงให้เห็นทุกอย่าง ผู้นำที่ดีต้องสามารถมองเห็นการมีส่วนร่วมที่เครื่องมืออัตโนมัติมองไม่เห็นได้