สารบัญ
📚 EP นี้เป็นตอนที่ 12 ของ mini-series Project Management 101 — สารบัญรวม อยู่ที่นี่
ตอนนี้เรื่องที่ใหญ่ที่สุดของ PM modern: วัดยังไง
มี 3 มุม:
- Classic measurement — EVM (SPI/CPI) — สำหรับ deliverable-based project
- Modern software measurement — DORA metrics — สำหรับ continuous delivery
- Project vs Product mindset — shift ที่บริษัทใหญ่กำลังเดิน
ส่วนที่ 1: EVM Recap
(ละเอียดอยู่ใน EP.07)
3 numbers:
- PV = Planned Value
- EV = Earned Value
- AC = Actual Cost
2 indices:
- SPI = EV / PV — schedule
- CPI = EV / AC — cost
Forecast: EAC = BAC / CPI
EVM ถูกออกแบบสำหรับ:
- Project ที่ scope fixed
- Deliverable ที่ measure ได้ชัด
- Long-running project ที่ต้อง track quarterly
ใช้ใน defense, construction, large IT — แต่ไม่เหมาะกับ continuous delivery (next section)
ส่วนที่ 2: DORA Metrics
Origin: Accelerate (Forsgren / Humble / Kim, 2018) — research จาก State of DevOps reports
คำเต็ม: DevOps Research and Assessment (acquired by Google 2018)
ทำไม DORA สำคัญ
ก่อน DORA — software industry ไม่มี metric มาตรฐานวัด “team performant แค่ไหน”
แต่ละบริษัทใช้ของตัวเอง:
- Velocity (story points/sprint) — game ได้
- Lines of code — ไร้สาระ
- Bugs filed — ยิ่งเขียนเยอะยิ่งบั๊กเยอะ
DORA หา 4 metrics ที่ predictive ของ business outcome (revenue, profitability, market share)
4 Key Metrics
Metric 1: Deployment Frequency
คำถาม: ทีม deploy production บ่อยแค่ไหน?
ทำไมสำคัญ: Deploy บ่อย = batch เล็ก = blast radius เล็ก = quality สูง
Metric 2: Lead Time for Changes
คำถาม: จาก commit code → run production ใช้เวลาแค่ไหน?
ทำไมสำคัญ: Lead time สั้น = feedback loop เร็ว = response ต่อ market เร็ว
Metric 3: Change Failure Rate
คำถาม: % ของ deployment ที่ทำให้เกิด incident / hotfix?
ทำไมสำคัญ: ต่ำ = quality ดี + process ดี
Metric 4: Mean Time to Restore (MTTR)
คำถาม: Production fail แล้ว ใช้เวลาแค่ไหนถึงกู้ได้?
ทำไมสำคัญ: ผิดพลาดเป็นเรื่องปกติ — กู้คืนเร็วสำคัญกว่า “ไม่ผิด”
Performance Levels (จาก State of DevOps 2023)
| Level | Deploy Freq | Lead Time | Change Fail | MTTR |
|---|---|---|---|---|
| Elite | Multiple/day | < 1 hour | 0-15% | < 1 hour |
| High | Weekly–Monthly | 1 day – 1 week | 16-30% | < 1 day |
| Medium | Monthly – 6 mo | 1 week – 1 month | 16-30% | < 1 week |
| Low | < 6 months | > 6 months | 46-60% | > 6 months |
Elite vs Low gap: 200x deployment frequency, 100x lead time
ทำไม Elite ทำได้ขนาดนี้
Tech ที่จำเป็น:
- CI/CD pipeline — automated build + test + deploy
- Trunk-based development — short-lived branches
- Test automation — unit + integration + e2e
- Feature flags — deploy ≠ release
- Observability — logging + monitoring + tracing
Practice ที่จำเป็น:
- Small batch size — deploy 1 feature ที่จบ ไม่ใช่ 50 feature รวม
- Blameless postmortem — เรียนจาก incident ไม่หาคนผิด
- Continuous improvement
Reliability — DORA metric ที่ 5 (เพิ่ม 2021)
คำถาม: ระบบ available + reliable แค่ไหน?
- SLO (Service Level Objective) compliance
- Customer-facing reliability
DORA vs EVM — เมื่อไหร่ใช้อะไร
| EVM | DORA | |
|---|---|---|
| For | Deliverable-based project | Continuous delivery (software) |
| Time horizon | Project lifecycle | Ongoing |
| Granularity | Project-level | Team / system level |
| Best for | Construction, hardware, regulated IT | Modern software product |
| Frequency | Monthly, quarterly | Daily, weekly |
ใน enterprise ที่ run ทั้ง project + product — ใช้ทั้งคู่
- EVM สำหรับ project ที่มี scope fixed
- DORA สำหรับ ongoing product team
ส่วนที่ 3: Project vs Product Mindset
นี่คือ paradigm shift ที่บริษัทใหญ่กำลังเดิน — สำคัญพอๆ กับ Agile Manifesto
ความต่างพื้นฐาน
| Project Mindset | Product Mindset | |
|---|---|---|
| Lifespan | Temporary (เริ่ม-จบ) | Persistent (ตลอดอายุ product) |
| Success | On time, on budget, on scope | Outcome (revenue, retention, NPS) |
| Funding | Project budget (one-shot) | Persistent team budget |
| Team | Form for project, disband at end | Stable, long-running |
| Optimize | Output (deliver what was planned) | Outcome (improve what matters) |
| Customer | ”stakeholder" | "user” |
| Question | ”ส่งมอบตามแผนไหม?" | "ผู้ใช้ดีขึ้นไหม?” |
Quote ของ Marty Cagan (Inspired, 2008)
“Build the right thing” matters more than “build the thing right.”
Project mindset: focus build the thing right (on time, on budget) Product mindset: focus build the right thing (outcome)
Mik Kersten — Project to Product (2018)
หนังสือสำคัญ — argument หลัก:
- Software industry ใช้ project model (ที่มาจาก construction) — model ผิดสำหรับ software
- Software คือ product — ต้อง treat แบบ product
- ตัดสินจาก flow of value ไม่ใช่ completion of project
Implication ของ Product Mindset
1. Funding model เปลี่ยน
- Old: Approve project budget per project
- New: Persistent team funded long-term + objectives quarterly
2. Team structure เปลี่ยน
- Old: Project team form-disband
- New: Long-running product team
3. KPI เปลี่ยน
- Old: Schedule, budget, scope
- New: Adoption, retention, revenue, NPS
4. Mindset เปลี่ยน
- Old: “เสร็จ”
- New: “ดีขึ้น” — never done
Spotify, Amazon, Google = native product mindset
ไม่มี “project” ใน Spotify — มี “squad” + “tribe” ที่ดูแล product พื้นที่ของตัวเอง ไม่จบ
Banking + healthcare กำลังเดิน slow transition
- Old: Mortgage IT project (12 เดือน, fixed budget)
- New: Mortgage product team (long-running) + quarterly OKR
ต้องการ:
- Persistent funding model (ยาก — finance ต่อต้าน)
- Career path ที่ไม่ใช่ project-based
- Skill ใน product management
OKR — Objectives + Key Results
หลายบริษัท adopt OKR คู่กับ Product mindset
Origin: Andy Grove (Intel) → John Doerr → Google + Amazon + ทั่วโลก
Concept
Objective = qualitative goal — motivating, ambitious Key Results = quantitative metric — 3-5 ตัวต่อ objective
ตัวอย่าง
Objective: เพิ่ม customer retention
- KR1: Monthly churn จาก 5% → 3%
- KR2: NPS จาก 30 → 50
- KR3: 80% of users return within 30 days
Cadence
- Annual OKR (company)
- Quarterly OKR (team)
- Review weekly / monthly
OKR vs Project KPI
| Project KPI | OKR | |
|---|---|---|
| Time | Project lifecycle | Quarter / annual |
| What | Deliver scope | Improve outcome |
| Specific | Output | Metric (input → metric) |
| Stretch | Not really | Yes (60-70% achievement = good) |
Vanity metrics vs Actionable metrics
Eric Ries ใน The Lean Startup (2011):
Vanity metric = ดูดี แต่ไม่ inform decision
- Total users (always grows!)
- Total page views
- Lines of code
Actionable metric = inform decision
- Daily/Monthly Active Users (DAU/MAU ratio)
- Conversion rate
- Cohort retention
กฎ: ถ้า metric ขยับ — เปลี่ยน behavior ของทีมไหม? ถ้าไม่ → vanity
Goodhart’s Law — กับดักของ measurement
“When a measure becomes a target, it ceases to be a good measure.”
ตัวอย่าง:
- KPI = bug fixed → engineer ไป fix bug ที่ไม่สำคัญ ละเลย important work
- KPI = lines of code → engineer เขียน verbose code
- KPI = sprint velocity → ทีมขยาย story point inflate
Solution:
- ไม่ใช้ metric เดียว — ใช้ basket
- ไม่ tie to bonus โดยตรง
- ทบทวน metric ทุกไตรมาส
- Combine quantitative + qualitative
CHAOS Report — บริบทของ project failure
Standish Group CHAOS Report (1994 onwards):
| ปี | Successful | Challenged | Failed |
|---|---|---|---|
| 1994 | 16% | 53% | 31% |
| 2015 | 29% | 52% | 19% |
| 2020 (CHAOS Beyond Infinity) | Agile 2x more likely to succeed than Waterfall on small projects |
McKinsey + Oxford 2012:
- 17% ของ large IT project (>$15M) failures threaten company existence
- Average overrun: 45% over budget, 56% less value than predicted
Bent Flyvbjerg — “Iron Law of Megaprojects”
“Over budget, over time, under benefits, over and over again.”
สรุป EP นี้
Classic measurement:
- EVM (SPI/CPI) — สำหรับ deliverable-based project — ตอบ “on track ไหม”
Modern software:
- DORA 4 metrics (deploy frequency, lead time, change fail, MTTR) + reliability
- Elite vs Low = 100-200x gap
- Predictor ของ business outcome
Mindset shift:
- Project mindset — temporary, output-focused, on time/on budget
- Product mindset — persistent, outcome-focused, never done
- Banking + healthcare กำลัง slow transition
Watch out:
- Goodhart’s Law — metric ที่กลายเป็น target = no longer a good measure
- Vanity metrics ≠ actionable metrics
EP ต่อไปคือเคสล้มจริง — Denver Airport, NHS NPfIT, Boeing 737 MAX — bottlenecks ที่ใช้ pattern recognize ในชีวิตจริง
