Engineering OKR ที่เห็นในหลายองค์กร สุดท้ายกลายเป็น Jira backlog ที่เขียนใหม่อีกรอบ — “ship feature X”, “fix bug Y”, “deploy service Z” — แทนที่จะเป็น outcome ที่ business วัดได้ ปัญหาคือ tech leadership ส่วนใหญ่ตั้ง Key Result เป็น output (สิ่งที่ทีมทำ) ไม่ใช่ outcome (ผลลัพธ์ที่ระบบหรือผู้ใช้ได้รับ) เมื่อสิ้นไตรมาส ทีมบอกว่า “ship ครบ” แต่ระบบยัง down บ่อย, p95 latency ยังสูง, lead time ยังเป็นสัปดาห์ บทความนี้สำหรับ VP Engineering, Engineering Manager, Tech Lead และ CTO ที่ต้องการตั้ง OKR Engineering Team แบบ outcome-based ที่เชื่อมกับ DORA metrics และ SLI/SLO ไม่ใช่นับ ticket ที่ ship
ทำไม OKR ของ Engineering Team มักล้มเหลว
Engineering OKR มี failure pattern ที่ชัดเจนกว่าทีมอื่น เพราะ engineer ถนัด measure สิ่งที่ตัวเองทำได้ ไม่ใช่สิ่งที่ business ต้องการ ทำให้ KR ที่ออกมาเป็น vanity metric ที่ไม่มีคนนอกทีมสนใจ
1. Feature delivery as Key Result — KR ที่เขียนว่า “ship feature A, B, C ภายใน Q3” คือ roadmap ไม่ใช่ OKR ปัญหาคือถ้า feature ออกครบแต่ไม่มีคนใช้ หรือทำให้ระบบ down ก็ยังนับว่า 1.0 ทั้งที่ outcome แย่ลง
2. ไม่มี link กับ reliability หรือ SLO — Engineering team ที่ไม่ได้ track uptime, error rate, p95 latency เป็น KR จะไม่มีแรงต้านเวลา product team push feature เข้ามาเรื่อย ๆ ผลคือ tech debt สะสม, incident เพิ่ม, ทีมหมดไฟ
3. Velocity = vanity metric — Story point ต่อ sprint เป็นตัวเลขที่ engineer ปรับได้เอง ไม่ได้สะท้อนว่า user ได้ value มากขึ้นจริง KR ที่บอกว่า “เพิ่ม velocity จาก 40 → 60 points” คือการวัด output ของทีม ไม่ใช่ outcome ของระบบ
4. ไม่มี trade-off framing — OKR ที่ดีต้องบอกว่า “เร็วขึ้นแต่ไม่พังลง” หรือ “คุณภาพสูงขึ้นแต่ไม่ช้าลง” ถ้า KR มีแต่ speed (deploy frequency, lead time) โดยไม่มี quality counter (change failure rate, MTTR) ทีมจะ optimize ทางเดียวจน reliability พัง
5. Engineer วัดเองโดยไม่ link business — KR เช่น “refactor module X เสร็จ 80%” หรือ “migrate to microservices” — ไม่มีใครนอกทีมเข้าใจหรือสนใจ ทำให้ engineering OKR ไม่ถูกพูดถึงใน leadership meeting และไม่ได้รับ resource จริง อยากเข้าใจ pattern เพิ่มเติม อ่าน ตั้งและติดตาม OKRs อย่างมีประสิทธิภาพ
ตัวอย่าง OKR สำหรับ Engineering Team
ตัวอย่าง 4 ทีมด้านล่างเขียนแบบ outcome-based อ้างอิง DORA metrics (deploy frequency, lead time, change failure rate, MTTR) และ SLI/SLO ที่ engineering organization ระดับ mature ใช้จริง
1. Platform / Infrastructure Engineering
Objective: สร้าง platform ที่ทีม product สามารถ ship ได้เร็วและปลอดภัยโดยไม่ต้องพึ่ง infra team ทุกครั้ง
| Key Result | Baseline | Target |
|---|---|---|
| Self-service deployment coverage ของ product team | 40% | 90% |
| p95 build + deploy time จาก commit ถึง production | 32 นาที | ≤ 12 นาที |
| Platform uptime (control plane SLO) | 99.5% | 99.95% |
2. Product Engineering (Delivery)
Objective: ส่งมอบ feature ที่ผู้ใช้รับไปใช้จริงและไม่ทำให้ระบบเสื่อม
| Key Result | Baseline | Target |
|---|---|---|
| Feature adoption rate ภายใน 30 วันหลัง launch | 22% | ≥ 50% |
| Change failure rate (DORA) | 18% | ≤ 8% |
| Lead time for changes (commit → prod, p75) | 4.2 วัน | ≤ 1 วัน |
3. DevEx / Developer Tooling
Objective: ลด friction ของ developer ในการ ship code ให้ทีมโฟกัสกับ business problem ไม่ใช่ tooling
| Key Result | Baseline | Target |
|---|---|---|
| CI build time (median) | 14 นาที | ≤ 5 นาที |
| Developer satisfaction (DevEx survey, scale 1–5) | 3.1 | ≥ 4.2 |
| Local environment setup time สำหรับ engineer ใหม่ | 2 วัน | ≤ 2 ชั่วโมง |
4. SRE / Reliability
Objective: รักษา reliability ให้ตรง SLO ที่สัญญาไว้กับ business โดยไม่ block velocity ของ product team
| Key Result | Baseline | Target |
|---|---|---|
| Service availability (user-facing SLO) | 99.82% | ≥ 99.95% |
| MTTR (mean time to recovery) สำหรับ Sev1/Sev2 | 78 นาที | ≤ 25 นาที |
| Error budget burn rate ต่อเดือน | 1.4× | ≤ 1.0× |
หลายทีมใน Thailand ตั้ง OKR แบบ “deploy 12 features” หรือ “close 200 tickets” — output ทั้งหมด ลองเทียบกับตารางด้านบนแล้วจะเห็นว่า outcome-based KR มี baseline + target + unit ที่ business เถียงไม่ได้ ดูตัวอย่างทีมอื่นเทียบได้ใน ตั้งและติดตาม OKRs อย่างมีประสิทธิภาพ
วิธีให้คะแนน OKR ของ Engineering Team
Engineering KR เกือบทั้งหมดเป็นตัวเลขที่ instrument ได้จาก monitoring / CI / git provider — ทำให้ scoring ตรงไปตรงมากว่าทีมอื่น ใช้ scale 0.0–1.0 และวาง stretch target ให้ 0.7 = success, 1.0 = exceptional
ตัวอย่าง scoring — Service availability KR (SRE)
| ผลลัพธ์จริง | Score | การตีความ |
|---|---|---|
| 99.82% (เท่า baseline) | 0.0 | ไม่มี progress |
| 99.88% | 0.4 | ดีขึ้นแต่ยังไม่ถึง commitment |
| 99.92% | 0.7 | ผ่าน commit level (success) |
| 99.95% (target) | 1.0 | ถึง stretch — exceptional |
| 99.97%+ | 1.0 (cap) | เกินเป้า แต่ไม่ให้คะแนน > 1.0 |
หลักสำคัญสำหรับ engineering:
- วัดจาก telemetry ไม่ใช่ self-report — uptime อ่านจาก monitoring, deploy frequency อ่านจาก CI, lead time อ่านจาก git อย่าให้ engineer มา input ตัวเลขเอง
- 0.7 = on-track, 1.0 = stretch — ถ้าทีมได้ 1.0 ทุก KR ติดต่อกัน 2 ไตรมาส แปลว่า target ตั้งง่ายเกินไป
- Score รายเดือน ไม่ใช่ปลายไตรมาส — เพื่อปรับ trade-off ระหว่าง speed กับ reliability ทันเวลา
วิธีให้คะแนนละเอียดเพิ่มเติม อ่าน OKR Scoring Method — ใช้ logic เดียวกันแต่ปรับ unit ให้เข้ากับ engineering metric
Weekly Check-in สำหรับทีม Engineering
Engineering check-in ที่ทำงานได้จริงต้อง integrate กับ ritual ที่ทีมมีอยู่แล้ว — sprint review, incident review, retro — ไม่ใช่ meeting ใหม่ที่เพิ่มเข้ามา cadence ที่แนะนำ
- Weekly: 15 นาที ใน sprint sync — update KR number จาก dashboard
- Bi-weekly: 30 นาที ระหว่าง EM ↔ Tech Lead — discuss trade-off speed vs reliability
- Monthly: 45 นาที กับ leadership — review error budget, DORA trend
5 คำถามที่ต้องถามทุก weekly check-in:
- Incident หรือ Sev1/Sev2 สัปดาห์นี้กระทบ reliability KR หรือไม่ และ error budget เหลือเท่าไหร่?
- Deploy frequency สัปดาห์นี้เปลี่ยนยังไงเทียบ baseline และมี blocker อะไรใน CI?
- p95 latency / change failure rate เคลื่อนทิศทางไหน — ดีขึ้นหรือแย่ลง?
- มี feature ที่กำลัง ship แล้ว trade-off กับ reliability KR หรือไม่ — ถ้ามี ใครเป็นคนตัดสินใจ?
- Adoption ของ feature ที่ ship 2 สัปดาห์ก่อน เป็นยังไงเทียบ target?
ถ้าทีมตอบคำถามพวกนี้ไม่ได้ในเวลา 15 นาที แปลว่า dashboard ยังไม่พร้อม หรือ KR ยัง instrument ไม่ครบ template check-in ที่ใช้กับ engineering ได้ ดูใน Weekly OKR Check-in Template
5 ข้อผิดพลาดที่เจอบ่อยใน Engineering OKR
1. ใช้ feature list เป็น OKR — “ship feature A, B, C” ไม่ใช่ Key Result นั่นคือ roadmap KR ต้องบอกว่าฟีเจอร์เหล่านั้นทำให้ตัวเลขอะไรขยับ — adoption, retention, latency, conversion
2. ไม่มี SLI/SLO เลย — ถ้าทีม engineering ไม่มี Service Level Indicator ที่ track ต่อเนื่อง การตั้ง reliability KR คือการเดา ต้อง define SLI ก่อน (uptime, latency, error rate) แล้วค่อยตั้ง SLO เป็น KR
3. Velocity worship — “เพิ่ม story point ต่อ sprint 50%” คือ KR ที่ engineer ปรับเองได้ทันที (estimate ใหญ่ขึ้น) DORA metrics เช่น deploy frequency กับ lead time วัด outcome จริงกว่า velocity
4. ไม่มี error budget — ถ้าตั้ง reliability target 99.95% โดยไม่มี policy ว่า “เมื่อ error budget หมดให้หยุด ship feature” ทีมจะ trade reliability เพื่อ speed ทุกครั้งที่มี deadline และ KR reliability จะไม่มีวันถึง
5. KR ที่ engineer วัดเองโดยไม่ link business — “refactor service X เสร็จ”, “migrate to Kubernetes” — สิ่งเหล่านี้คือ initiative ไม่ใช่ KR ต้องตอบให้ได้ว่า refactor แล้ว latency ลดลงเท่าไหร่ หรือ migration ทำให้ deploy frequency เพิ่มขึ้นเท่าไหร่ failure pattern อื่น ๆ ในการเลือก tool ดู OKR ด้วย Excel หรือ Software
สรุป: outcome ก่อน output เสมอ
Engineering OKR ที่ใช้งานได้จริง ไม่ใช่ list ของ feature ที่ ship แต่เป็น contract กับ business ว่าระบบจะเร็วขึ้น เสถียรขึ้น และ developer ship ได้เร็วขึ้น โดยมี DORA metrics + SLI/SLO เป็นตัววัด ขั้นตอนถัดไปคือทำให้ตัวเลขพวกนี้เห็นใน real-time ผ่าน engineering dashboard ที่ทุกคนเปิดดูได้ ไม่ใช่ slide รายเดือน
คำถามชวนคิด: Engineering team ของคุณตั้ง OKR เป็น outcome (reliability, velocity) หรือ output (tickets ที่ ship)?