การวัดผลิตภาพของนักพัฒนา: กรณีศึกษาจริงจาก Google, Notion และอีกหลายบริษัท

• การวิเคราะห์เชิงลึกว่า 17 บริษัทเทคโนโลยี เช่น Google, LinkedIn, Peloton, Amplitude, Intercom, Notion และ Postman วัดผลิตภาพของนักพัฒนาอย่างไร

1. ตัวชี้วัดผลิตภาพของนักพัฒนาใน 17 บริษัทเทคโนโลยี

• การวัดผลิตภาพของนักพัฒนาเป็นปัญหาที่ซับซ้อน เพราะงานวิศวกรรมซอฟต์แวร์เป็นงานฐานความรู้ ทำให้ความหมายของคำว่า "มีผลิตภาพ" เองก็คลุมเครือ
• มีทีมที่เรียกว่า DevProd หรือ DevEx ซึ่งช่วยให้นักพัฒนาสามารถส่งมอบซอฟต์แวร์คุณภาพสูงได้ง่ายขึ้น
• ทีมเหล่านี้ต้องการ ตัวชี้วัดผลิตภาพของนักพัฒนา เพื่อวัดทั้งผลิตภาพและอุปสรรคของทีมวิศวกรรม รวมถึงติดตามว่างานของพวกเขาส่งผลกระทบจริงหรือไม่
• ตัวชี้วัดผลิตภาพของนักพัฒนาที่บริษัทเหล่านี้ใช้
  • ความง่ายในการส่งมอบ (Amplitude, GoodRx, Intercom, Postman, Lattice)
  • ความเร็วของการทดลอง (Etsy)
  • ความเสถียรของบริการ/แอป (DoorDash)
  • ตัวชี้วัด SPACE (Microsoft)
  • เวลาโฟกัสรายสัปดาห์ต่อวิศวกร (Uber)
• คัดเลือก 4 กลุ่มตามขนาดบริษัท
  • Google : พนักงานมากกว่า 100,000 คน
  • LinkedIn : มากกว่า 10,000 คน
  • Peloton : 1,000 คนขึ้นไปแต่ไม่ถึง 10,000 คน
  • กลุ่มสเกลอัป (วิศวกร 100 คนขึ้นไปแต่ไม่ถึง 1,000 คน): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. แนวทางของ Google

• Google มักถูกยกเป็นตัวอย่างแนวปฏิบัติที่ดีในการวัดผลิตภาพของนักพัฒนา แต่ก็มีข้อโต้แย้งว่าบริษัทส่วนใหญ่ไม่สามารถเลียนแบบระดับการลงทุนแบบ Google ได้
• ทีม Developer Intelligence ของ Google เป็นหน่วยงานเฉพาะทางที่วัดผลิตภาพของนักพัฒนาและส่งมอบอินไซต์ให้ผู้นำ
• Google เชื่อว่าไม่มีตัวชี้วัดเดี่ยวตัวใดจับผลิตภาพได้ครบถ้วน จึงมองผ่าน 3 มิติ คือ ความเร็ว ความง่าย และคุณภาพ
  • Speed ความเร็ว: ใช้เวลานานเท่าไรในการรีวิวโค้ดให้เสร็จ?
  • Ease ความง่าย: นักพัฒนารู้สึกว่าการผ่านกระบวนการ code review ง่ายหรือยากแค่ไหน?
  • Quality คุณภาพ: ฟีดแบ็กที่ได้รับจาก code review มีคุณภาพระดับใด?
• Google คำนวณตัวชี้วัดโดยผสมทั้งการวัดเชิงคุณภาพและเชิงปริมาณ

3. LinkedIn

• LinkedIn ดำเนินงานอย่างเป็นอิสระภายใน Microsoft และมีพนักงานมากกว่า 10,000 คน
• LinkedIn มีทีม Developer Insights ที่วัดผลิตภาพและความพึงพอใจของนักพัฒนา พร้อมส่งต่ออินไซต์ให้ทั้งองค์กร
• LinkedIn เก็บตัวชี้วัดผ่านแบบสำรวจรายไตรมาส ระบบฟีดแบ็กแบบเรียลไทม์ และตัวชี้วัดจากระบบ
  • แบบสำรวจรายไตรมาส:
    • ทีม Developer Insights ประเมินประสบการณ์นักพัฒนาครอบคลุมเครื่องมือ กระบวนการ และกิจกรรมต่าง ๆ ผ่านแบบสำรวจรายไตรมาส
    • แบบสำรวจมีคำถามราว 30 ข้อ และนักพัฒนาตอบได้ภายในประมาณ 10 นาที
    • แบบสำรวจถูกส่งผ่านแพลตฟอร์มเฉพาะที่ทีม Developer Insights พัฒนาและดูแลเอง โดยสามารถปรับแต่งและทำ personalization ของคำถามได้ขั้นสูงจากข้อมูลที่เก็บในระบบฟีดแบ็กแบบเรียลไทม์และระบบตัวชี้วัด
  • ระบบฟีดแบ็กแบบเรียลไทม์:
    • เพื่อเก็บฟีดแบ็กระหว่างรอบแบบสำรวจรายไตรมาส LinkedIn ได้พัฒนาระบบฟีดแบ็กแบบเรียลไทม์ที่ติดตามอีเวนต์และการกระทำของนักพัฒนาในเครื่องมือพัฒนา และส่งแบบสำรวจเฉพาะกลุ่มตาม trigger ที่กำหนด
    • ระบบนี้ใช้กลไก smart throttling เพื่อไม่ให้คำขอฟีดแบ็กถาโถมใส่นักพัฒนามากเกินไป
  • ตัวชี้วัดจากระบบ:
    • LinkedIn ยังใช้ข้อมูลจากระบบในการคำนวณตัวชี้วัด เพื่อให้ได้การวัดที่มีความแม่นยำสูงในเรื่องอย่างเวลา build และความถี่ในการ deploy
    • ทีม Developer Insights ดูแลระบบส่วนกลางสำหรับเก็บและวิเคราะห์ข้อมูลนี้ ซึ่งเรียกว่า Developer Insights Hub หรือ iHub
    • ระบบนี้ทำให้ทุกทีมใน LinkedIn สามารถสร้าง dashboard และ metric แบบปรับแต่งเองตามความต้องการได้
• LinkedIn พิจารณาทั้ง ตัวชี้วัดเชิงคุณภาพและเชิงปริมาณ
  • Developer Net User Satisfaction (NSAT): วัดว่าภาพรวมแล้วนักพัฒนาพึงพอใจกับระบบพัฒนาของ LinkedIn มากน้อยเพียงใด วัดทุกไตรมาส
  • Developer Build Time (P50 และ P90): วัดเป็นวินาทีว่าระหว่างการพัฒนา นักพัฒนาต้องรอให้ build เสร็จบนเครื่อง local นานเท่าใด
  • Code Reviewer Response Time (P50 และ P90): วัดเวลาตามชั่วโมงทำงานที่ผู้รีวิวโค้ดใช้ในการตอบสนองต่อแต่ละการอัปเดต code review ของผู้เขียน
  • Post-Commit CI Speed (P50 และ P90): วัดเป็นนาทีว่าแต่ละ commit ใช้เวลานานเท่าใดในการผ่าน pipeline ของ CI
  • CI Determinism: แนวคิดตรงข้ามกับ test flakiness หมายถึงความน่าจะเป็นที่ผลลัพธ์ของ test suite จะเป็นผลลัพธ์ที่ถูกต้อง ไม่ใช่ความผิดพลาด
  • Deployment Success Rate: วัดว่าการ deploy ไปยัง production สำเร็จบ่อยเพียงใด
  • Winsorized Means: วิธีรับรู้การปรับปรุงภายใน metric ที่มีค่าผิดปกติ โดยแทนที่ค่าสูงสุดและต่ำสุดด้วยตัวเลขที่ใกล้ค่ากลางมากขึ้นเพื่อใช้คำนวณ
  • The Developer Experience Index: ตัวชี้วัดพิเศษที่ LinkedIn มอบให้ทีมต่าง ๆ เป็นคะแนนรวมที่อิงจากหลายตัวชี้วัด เช่น ตัวที่กล่าวถึงข้างต้น

4. Peloton

• Peloton เป็นบริษัทขนาดใหญ่ที่มีพนักงานประมาณ 3,000-4,000 คน แต่ยังเล็กกว่า LinkedIn มาก
• แนวทางการวัดของ Peloton เริ่มจากการใช้แบบสำรวจประสบการณ์นักพัฒนาเพื่อเก็บอินไซต์เชิงคุณภาพ แล้วจึงนำมาใช้ร่วมกับตัวชี้วัดเชิงปริมาณในภายหลัง
• Peloton วัดผลิตภาพโดยมุ่งที่ 4 ด้านหลัก คือ การมีส่วนร่วม ความเร็ว คุณภาพ และความเสถียร
  • การมีส่วนร่วม (Engagement): คะแนนความพึงพอใจของนักพัฒนา
  • ความเร็ว (Velocity): เวลาจนถึง PR แรกและ PR ที่ 10 ของพนักงานใหม่ทุกคน, lead time, ความถี่ในการ deploy
  • คุณภาพ (Quality): สัดส่วนของ PR ที่มีน้อยกว่า 250 บรรทัด, line coverage, อัตราความล้มเหลวของการเปลี่ยนแปลง
  • ความเสถียร (Stability): เวลาในการกู้คืนบริการ
• แบบสำรวจประสบการณ์นักพัฒนาที่ใช้วัด metric จำนวนมากนี้ ขับเคลื่อนโดยทีม Tech Enablement and Developer Experience ของ Peloton ซึ่งเป็นส่วนหนึ่งขององค์กร Product Operations
• ทีม Tech Enablement and Developer Experience ยังมีหน้าที่วิเคราะห์ผลสำรวจและแบ่งปันกับผู้นำทั่วทั้งองค์กร

5. บริษัทสเกลอัปและบริษัทขนาดเล็ก

• บริษัทสเกลอัปหลายแห่ง เช่น Notion, Postman, Amplitude, GoodRx, Intercom และ Lattice มีวิศวกรตั้งแต่ 100 ถึง 1,000 คน
• บริษัทเหล่านี้มุ่งเน้นที่ "ตัวชี้วัดที่ขยับได้ (Moveable Metrics)"
  • ตัวชี้วัดที่ขยับได้ หมายถึงตัวชี้วัดที่ทีมผลิตภาพนักพัฒนาสามารถทำให้ "ขยับ" ได้ด้วยการส่งผลบวกหรือลบต่องานของตนเอง จึงมีประโยชน์ในการแสดงให้เห็นอิทธิพลของทีมผลิตภาพนักพัฒนา
• ตัวชี้วัดที่พบร่วมกัน
  • ความง่ายในการส่งมอบ (Ease of Delivery, moveable):
    • บริษัทส่วนใหญ่วัดความง่ายในการส่งมอบ ซึ่งเป็นมาตรวัดเชิงคุณภาพว่านักพัฒนารู้สึกว่าการทำงานของตนง่ายหรือยากเพียงใด
    • ผู้นำ DevProd หลายคนบอกว่า metric นี้คือ 'north star' ของงาน เพราะเป้าหมายของทีมคือทำให้ชีวิตนักพัฒนาสะดวกขึ้น
    • Metric นี้ยังมีประโยชน์ต่อการแสดงผลกระทบ เพราะเป็นสิ่งที่ขยับได้ค่อนข้างมาก
    • ในเชิงทฤษฎี metric นี้ยังสะท้อนแง่มุมสำคัญของประสบการณ์นักพัฒนา เช่น cognitive load และ feedback loop
  • การมีส่วนร่วม (Engagement)
    • มีการติดตาม engagement เพื่อวัดว่านักพัฒนารู้สึกสนใจและถูกกระตุ้นกับงานมากเพียงใด
    • โดยทั่วไป engagement มักวัดจากแบบสำรวจของ HR แต่ทีม DevProd ก็ให้ความสำคัญกับเรื่องนี้ด้วยเหตุผลเดียวกัน
    • engagement ของนักพัฒนาและผลิตภาพมีความสัมพันธ์กันอย่างใกล้ชิด หรืออย่างที่พูดกันว่า "นักพัฒนาที่มีความสุขคือนักพัฒนาที่มีผลิตภาพ" ดังนั้น engagement จึงมองได้ว่าเป็นตัวบ่งชี้ผลิตภาพ
    • ประโยชน์ที่แท้จริงของการวัด engagement คือช่วยถ่วงดุลกับตัวชี้วัดอื่นที่เน้นความเร็ว การส่งมอบซอฟต์แวร์ให้เร็วขึ้นเป็นเรื่องดี แต่ไม่ควรแลกกับความสุขของนักพัฒนาที่ลดลง
  • เวลาที่สูญเสีย (Time Loss, moveable)
    • GoodRx และ Postman ให้ความสำคัญกับปริมาณเวลาเฉลี่ยที่สูญเสียไป
    • สิ่งนี้วัดจากสัดส่วนเวลาของนักพัฒนาที่สูญเสียไปเพราะอุปสรรคในสภาพแวดล้อมการทำงาน
    • Metric นี้คล้ายกับความง่ายในการส่งมอบตรงที่เป็นตัวชี้วัดที่ขยับได้และทีมพัฒนาสามารถส่งผลโดยตรงต่อมันได้
    • ข้อดีสำคัญคือสามารถแปลงเป็นต้นทุนได้ จึงทำให้ผู้นำธุรกิจเข้าใจ time loss ได้ง่าย
    • ตัวอย่างเช่น หากองค์กรมีค่าแรงวิศวกรรม 10 ล้านดอลลาร์ และสามารถลด time loss จาก 20% เหลือ 10% ผ่าน initiative หนึ่ง ก็จะนำไปสู่การประหยัดต้นทุน 1 ล้านดอลลาร์
  • อัตราความล้มเหลวของการเปลี่ยนแปลง (Change Failure Rate)
    • นี่คือหนึ่งใน 4 ตัวชี้วัดหลักของโครงการวิจัย DORA (DevOps Research and Assessment)
    • เป็นตัวชี้วัดระดับบนที่หลายบริษัท เช่น Amplitude และ Lattice ติดตาม
    • ทีม DORA นิยามอัตราความล้มเหลวของการเปลี่ยนแปลงไว้ดังนี้:

    "สัดส่วนของการเปลี่ยนแปลงจากการปล่อยรีลีสไปยัง production หรือผู้ใช้ ที่ทำให้เกิดการเสื่อมถอยของบริการ (เช่น service impairment หรือ service outage) และต้องมีการแก้ไขตามมาในภายหลัง (เช่น hotfix, rollback, fix forward หรือ patch)"

6. ข้อค้นพบที่น่าสนใจ

• ตัวชี้วัด DORA และ SPACE ถูกใช้แบบเลือกสรร และทุกบริษัทต่างใช้ทั้งการวัดเชิงคุณภาพและเชิงปริมาณ
  • DORA : DevOps Research and Assessment
  • SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
• มีการเน้นอย่างมากกับ "เวลาโฟกัส" โดย Stripe และ Uber แชร์ metric เฉพาะอย่าง "จำนวนวันที่มีเวลาโฟกัสเพียงพอ" และ "เวลาโฟกัสรายสัปดาห์ต่อวิศวกร"
• ตัวชี้วัดที่มีเอกลักษณ์
  • Adoption Rate (DoorDash, GoodRx, Spotify)
  • Design Docs Generated per Engineer (Uber)
  • Experiment Velocity (Etsy)
  • Developer CSAT/NSAT (Chime, LinkedIn)

7. วิธีเลือกตัวชี้วัดของคุณเอง

• แนะนำให้ใช้ กรอบงาน Goals, Signals, Metrics (GSM) ของ Google เพื่อช่วยนำทางการเลือกตัวชี้วัด
• ให้เริ่มจากการกำหนดเป้าหมายของปัญหาที่ต้องการแก้ จากนั้นหาสัญญาณที่บอกว่าคุณบรรลุเป้าหมายนั้นแล้ว แล้วค่อยเลือกตัวชี้วัดที่เหมาะสม
  • กำหนดเป้าหมาย
    • Google: "ช่วยให้นักพัฒนาสามารถส่งมอบผลิตภัณฑ์ที่ยอดเยี่ยมได้อย่างรวดเร็วและง่ายดาย"
    • Slack: "มอบสภาพแวดล้อมการพัฒนาที่ลื่นไหลให้กับวิศวกรทุกคน"
    • Stripe: "ทำให้วิศวกรรมซอฟต์แวร์ง่ายขึ้น"
  • ย้อนจากเป้าหมายเพื่อกำหนดตัวชี้วัดระดับบน
    • นักพัฒนาส่งมอบซอฟต์แวร์ได้ง่ายแค่ไหน? (Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate
    • นักพัฒนาส่งมอบซอฟต์แวร์ได้เร็วแค่ไหน (Speed) : Perceived Delivery Speed, Perceived Productivity
    • คุณภาพของซอฟต์แวร์ที่ส่งมอบ (Quality) : Incident frequency, Perceived Software Quality
• หากคุณเป็น CTO, VPE หรือผู้นำสายวิศวกรรม
  • คำแนะนำที่ดีที่สุดคือ "ปรับกรอบปัญหาใหม่ (reframe the problem)"
  • ให้เลือกตัวชี้วัดจาก 3 บักเก็ต
    • ผลกระทบทางธุรกิจ
      • ทำไมจึงต้องสร้างสิ่งนี้ตอนนี้?
      • โปรเจ็กต์นี้สร้างรายได้หรือสนับสนุนเป้าหมายธุรกิจในทางใด?
      • โปรเจ็กต์นี้กำลังดำเนินไปอย่างราบรื่น หรือกำลังล่าช้า?
    • ประสิทธิภาพของระบบ
      • ระบบวิศวกรรมรวดเร็วและเสถียรหรือไม่?
      • โครงสร้างพื้นฐานปลอดภัยและได้รับการดูแลอย่างดีหรือไม่?
      • ผู้ใช้พึงพอใจกับบริการที่พวกเขาใช้งานหรือไม่?
    • ประสิทธิภาพของงานวิศวกรรม
• การวัดด้วยการผสมตัวชี้วัดเชิงคุณภาพและเชิงปริมาณเป็นสิ่งที่พบร่วมกันในทุกบริษัท
  • ควรนำแรงบันดาลใจจากรายการตัวชี้วัดที่หลากหลายที่แต่ละบริษัทใช้
  • สิ่งที่แต่ละบริษัทเลือกวัดเป็นพิเศษแตกต่างกันมากตามลำดับความสำคัญและวัฒนธรรมวิศวกรรมของตน

[demorier]

ฉันสนใจมาตั้งแต่บทความก่อนหน้านี้ที่เกี่ยวกับ McKinsey แล้ว และก็ดีที่มีการสรุปและช่วยย้ำเตือนอีกครั้ง