- ข้อผิดพลาดที่มักเกิดขึ้นเมื่อวัดผลิตภาพของนักพัฒนา
- ปัญหาของการวัดสิ่งที่ป้อนเข้า
- การพึ่งพาสิ่งที่ป้อนเข้าหรือความพยายาม เช่น ‘ชั่วโมงการทำงาน’ จะกระตุ้นพฤติกรรมที่ผิดเพี้ยน
- ตัวอย่างเช่น หากวัฒนธรรมองค์กรให้คุณค่าและให้รางวัลกับเวลาที่ใช้ไปหน้าจอ นักพัฒนาอาจทุ่มเวลาไปกับสิ่งนี้ได้ แต่ก็ยากจะรับประกันคุณภาพของงาน
- ในสภาพแวดล้อมที่หนักข้อกว่าเดิม อาจบิดเบือนไปเป็นการแข่งขันแบบ ‘ใครมาถึงที่ทำงานเช้าที่สุดและกลับช้าที่สุด’
- ปัญหาของการวัดผลลัพธ์
- ตัวชี้วัดที่แย่ที่สุด เช่น จำนวนบรรทัดโค้ดหรือจำนวนคอมมิต อยู่ในหมวดหมู่นี้
- นักพัฒนาสามารถเขียนโค้ดจำนวนมากได้อย่างรวดเร็วมาก จึงทำให้การวัดสิ่งนี้เป็นเรื่องง่าย
- ตัวชี้วัดผลลัพธ์ทั้งหมดต้องทำความเข้าใจตามบริบท
- ปัญหาของการวัดผลลัพธ์และผลกระทบ
- ความท้าทายของตัวชี้วัดสองประเภทนี้คือการระบุว่า ‘ทีม DevOps ต้องรับผิดชอบมากน้อยเพียงใด’
- เมื่อต้องวัดการเพิ่มขึ้นของรายได้ทางธุรกิจ เป็นไปไม่ได้ที่จะยกให้เป็นความรับผิดชอบของนักพัฒนาเพียงฝ่ายเดียว
12 ความคิดเห็น
น่าหวาดเสียวเหมือนกันนะ คิดว่ามุมมองของผู้จัดการกับมุมมองของคนทำงานหน้างานน่าจะต่างกัน,,
น่าจะเป็นส่วนที่ต้องใช้ llm พอดีเลยนะ
บทความนี้ไม่มีทางเลือกอื่นเสนอไว้ จึงมีแง่มุมที่ทำให้ความหมายที่ต้องการสื่อจางลงไป ผมเห็นด้วยกับข้อโต้แย้งที่ว่าควรตัดปริมาณผลลัพธ์ออกจากการวัดผลลัพธ์ แต่ไม่อาจเห็นด้วยกับการตัดชั่วโมงทำงานออกจากการวัดปัจจัยนำเข้าโดยสิ้นเชิง เพราะไม่สอดคล้องกับความเป็นจริง ไม่ว่าอย่างไร ในระหว่างที่ทำงานเชิงความรู้นั้นเวลาก็เดินไปเรื่อย ๆ จึงคิดว่าจำเป็นต้องพิจารณาเรื่องเวลาในการตัดสินใจเสมอ
ผมคิดว่าการพูดถึงผลิตภาพของนักพัฒนาหลังจากวัดตัวชี้วัดนำอย่างเช่น ความคืบหน้าโดยรวม = (จำนวนข้อกำหนดที่ตอบสนองได้ / ชั่วโมงทำงาน) จะเข้าใจได้ง่ายและมีประสิทธิภาพกว่า
ช่วงหลังมานี้ผมค่อนข้างมองบทความประเภทนี้อย่างวิพากษ์มากขึ้น เพราะคิดว่าสุดท้ายแล้วข้อสรุปที่ผู้คนได้จากการอ่านบทความเหล่านี้คือการเลือกที่จะไม่บริหารจัดการอะไรเลย ไม่ว่าจะบริหารด้วยตัวชี้วัดแบบไหน สุดท้ายก็มีปัญหาคล้ายกันอยู่ดี อีกทั้งเมื่อเอาตัวชี้วัดใด ๆ ไปใช้เพื่อการแข่งขันหรือการเปรียบเทียบระหว่างคนหรือทีม ก็จะเกิดผลข้างเคียงตามมา ดังนั้นจึงไม่ควรบริหารด้วยตัวชี้วัดเพียงตัวเดียว แต่จำเป็นต้องใช้ตัวชี้วัดที่เสริมกันหลาย ๆ ตัวร่วมกัน และควรใช้ตัวชี้วัดเพื่อช่วยให้ทีมพัฒนาปรับปรุงตัวเองได้ด้วย
แล้วถ้าวัดจากจำนวน PR ที่มีขนาดเหมาะสมและมีความหมายที่ส่งขึ้นไปล่ะ คิดว่าเป็นอย่างไร?
จริง ๆ แล้วมีบริษัทยักษ์ใหญ่ในประเทศแห่งหนึ่งที่วัดผลงานจากจำนวนบรรทัดโค้ดที่เขียนด้วยครับ/ค่ะ ฮือฮือ
ฮ่า ผมก็เคยเห็นเหมือนกันครับ
เขาอัปคอมมิตที่เปลี่ยนชื่อของตัวแปรไปเรื่อย ๆ เลย..ฮะ
ดูเหมือนว่าเป็นสภาพแวดล้อมที่ไม่ได้มีการทำโค้ดรีวิวเลยสินะ?
ฮ่าๆ แม้แต่คนรีวิวโค้ดก็ต้องได้รับการรีวิวโค้ดเหมือนกันนะครับ
เลยกลายเป็นว่าต่างคนต่างช่วยเหลือเกื้อกูลกันอยู่..
55555 โอ๊ย...
hello hell world ;)
นี่คือการวัดประสิทธิภาพการทำงานด้วย LOC ที่เคยได้ยินแต่ในชื่อใช่ไหมเนี่ย ฮ่าๆๆ