ความเร็วในการ delivery software นั้น เราสามารถวัดได้หลายมุม ขึ้นกับว่าอยากดู "เร็วแค่ไหน" ในมิติไหน

นี่ คือ metric หลักที่ใช้กันจริงในทีม engineering

1. Cycle Time (เวลาทำงานจริง)

วัดตั้งแต่ engineer เริ่มลงมือทำ จนถึง deploy/done

Cycle Time = วันที่ Done − วันที่เริ่ม In Progress

ซึ่งข้อมูลนี้ เราสามารถดึงข้อมูลได้จาก Jira/Linear/GitHub ตรง ๆ เราดูที่ timestamp ตอน ticket เปลี่ยน status เป็น "In Progress" กับ ตอนเปลี่ยนเป็น "Done"/merged ได้เลย

2. Lead Time (เวลาทั้งหมดที่ลูกค้า/ฝั่งธุรกิจรอ)

วัดตั้งแต่ request เข้ามา จนถึง ของจริงไปอยู่ในมือ user

Lead Time = วันที่ Released − วันที่ Ticket ถูกสร้าง/Request เข้ามา

สิ่งนี้ คือ ตัวเลขที่ฝั่ง business รู้สึกจริงๆ ซึ่งต่างจาก Cycle Time เพราะรวมเวลาที่ ticket ค้างอยู่ใน backlog ก่อนมีคนหยิบขึ้นมาทำด้วย

3. Deployment Frequency

นับว่า deploy ขึ้น production บ่อยแค่ไหน (ต่อวัน/สัปดาห์) ยิ่งถี่ มักแปลว่า batch size เล็ก ความเสี่ยงต่อ release ต่ำ

4. Throughput / Velocity

  • Throughput = จำนวน items ที่ทำเสร็จต่อ sprint/เดือน (นับจำนวนตรง ๆ ไม่สน point)
  • Velocity = sum of story points ที่ทำเสร็จต่อ sprint (ใช้เทียบ trend ภายในทีมเดียวกันเท่านั้น ห้ามเอาไปเทียบข้ามทีม เพราะแต่ละทีม estimate point ไม่เหมือนกัน)

5. % Sprint Commitment Met

(จำนวน items ที่ทำเสร็จตามที่ commit) ÷ (จำนวน items ที่ commit ไว้ตอนต้น sprint) × 100

วัด "ความแม่นยำในการคาดการณ์" มากกว่าความเร็ว แต่สำคัญพอ ๆ กัน เพราะ predictability คือสิ่งที่ stakeholder ต้องการจริง ๆ

ข้อแนะนำการนำไปใช้งาน

  • ใช้ Median (มัธยฐาน) หรือ p85 ไม่ใช่ average cycle time มัก skew จาก outlier (ticket ที่ค้าง 3 สัปดาห์) ทำให้ average หลอกตา
  • แยกตาม squad ไม่รวมทั้งองค์กรเป็นตัวเลขเดียว เพราะแต่ละทีมงานต่างกัน เทียบรวมจะไม่มีความหมาย
  • ถ้าอยากได้ framework ที่ครอบคลุมและเป็นมาตรฐานที่คนในอุตสาหกรรมรู้จัก ลองดู DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Restore) — มันคือ 4 ตัวที่ Google ใช้วัด elite vs low-performing team

p85 คืออะไร

มัน คือ เปอร์เซ็นไทล์ที่ 85 หมายความว่า ถ้าเอาข้อมูลทั้งหมดมาเรียงจากน้อยไปมาก แล้วดูว่าตัวเลขไหนที่ "85% ของข้อมูลทั้งหมดอยู่ต่ำกว่าหรือเท่ากับมัน"

ตัวอย่าง

สมมติเรามี cycle time ของ 20 tickets ที่ทำเสร็จในเดือนนี้ (หน่วย: วัน) เรียงจากน้อยไปมากแล้ว:

1,1,1,2,2,2,2,3,3,3,3,4,4,4,5,5,6,8,12,21
  • Median (p50) = ตัวกลาง (อันดับที่ 10-11) = 3-4 วัน
  • p85 = ตัวที่อยู่ตำแหน่งที่ 85% ของ 20 ตัว = ประมาณอันดับที่ 17 = 8 วัน

ความหมายคือ: 85% ของ ticket ทำเสร็จภายใน 8 วัน ส่วนอีก 15% (พวก outlier ที่ใช้เวลา 12, 21 วัน) คือตัวที่ฉุดค่าเฉลี่ยให้ผิดเพี้ยน

ทำไมต้องใช้ p85 แทน Average

ลองคิดดูจากตัวอย่างเดียวกัน:

  • Average = รวมทั้งหมด ÷ 20 = ประมาณ 4.2 วัน → ดูดีเกินจริง เพราะถูกถ่วงด้วยตัวเลขกลาง ๆ ส่วนใหญ่
  • p85 = 8 วัน → สะท้อนภาพ "เคสที่แย่แต่ไม่ใช่ outlier สุดขั้ว" ได้ตรงกว่า

Average จะโกหกเราได้ง่าย เพราะ ticket ส่วนใหญ่ (เช่น bug fix เล็ก ๆ) เสร็จเร็ว แต่มี ticket ไม่กี่ตัวที่ค้างนานมาก (ติด dependency, รอ review, scope บวม) ตัวพวกนี้จะถ่วง average ให้ดูแย่ลงแบบไม่สมเหตุสมผล หรือบางทีกลับกัน — ทำให้ average ดูดีเกินจริงถ้า outlier น้อย ในขณะที่ p85/p90 จะบอกเราตรง ๆ ว่า "เคสส่วนใหญ่ที่แย่กว่าค่ากลาง" หน้าตาเป็นยังไง