Muda — ความสูญเปล่า 7 ชนิด#

Ohno แบ่ง waste ในระบบการผลิตเป็น 7 ชนิด:

Key insight: waste พวกนี้ไม่สร้าง value ให้ลูกค้าเลย ลบทิ้งได้ ไม่ใช่ไป optimize ซึ่งส่วนใหญ่ที่เจอ บริษัทมักไปจ้างที่ปรึกษามา “speed up” ขั้นตอนที่ตัวมันเองคือ waste อยู่แล้ว อ้าว…

Genchi Genbutsu — “ไปดูที่หน้างานเอง”#

現地現物 — Go and see for yourself

ผู้บริหาร Toyota ห้ามตัดสินใจจาก report อย่างเดียว ต้องลงไปดูสายพานเอง

ในบริบท PM ก็เหมือนกัน PM ที่ตัดสินใจจากห้องประชุม + dashboard อย่างเดียวเนี่ย พลาดแน่ ต้องไปดู developer ทำงานจริง ดู user ใช้ระบบจริง ดูลูกค้าใช้ product จริง

Kaizen — improvement เล็กๆ ต่อเนื่อง#

ไม่ต้องรอ “transformation ครั้งใหญ่” ครับ ทุกวัน ทุกคนในทีมเสนอ improvement เล็กๆ ได้ 1% ดีขึ้นทุกวัน × 365 วัน = 37x

Counter: บริษัทไทยส่วนมากเลือก big bang ครับ แบบ “เปลี่ยน CRM ใหม่ทั้งหมด” “เปลี่ยน ERP ทั้งบริษัท” ใช้เงินเยอะ ทีม resist (EP.06) success rate ก็ต่ำ Kaizen สลับด้านเลย เริ่มจากปัญหาเล็กๆ ที่ทีมแก้ได้เอง

Jidoka — “หยุดเมื่อมีปัญหา”#

Toyota มี Andon cord ทุกสายพาน operator ทุกคนดึงได้ ถ้าเห็นปัญหาปุ๊บ ทั้งสายพานหยุด ทีมรุมแก้

ในบริบท software ก็คือ Stop-the-line principle ถ้า build แตก deploy พัง ทั้งทีมหยุดงานอื่นมาแก้ก่อน ไม่ใช่ปล่อยให้ “เดี๋ยวมีคนทำ”

5 Focusing Steps#

graph LR
  A["1. Identify<br/>หา bottleneck"] --> B["2. Exploit<br/>รีด bottleneck สูงสุด"]
  B --> C["3. Subordinate<br/>ทุกอย่างปรับให้ bottleneck"]
  C --> D["4. Elevate<br/>ลงทุนขยาย bottleneck"]
  D --> E["5. Repeat<br/>bottleneck ใหม่จะโผล่"]
  E --> A
  style A fill:#fbbf24,color:#000

ตัวอย่าง software team:

• ทีม 10 คน เขียน feature เร็วมาก (10 feature/sprint)
• แต่ QA มีคนเดียว test ได้แค่ 3 feature/sprint
• เห็นมั้ย QA คือ bottleneck

ถ้าใช้ TOC:

1. Identify: QA คือคอขวด
2. Exploit: เลิกให้ QA ทำงาน admin, automate test ที่ทำซ้ำ
3. Subordinate: dev หยุดเขียน feature ใหม่ถ้า backlog QA เกิน 5 ticket แล้วมาช่วย QA แทน
4. Elevate: จ้าง QA เพิ่ม หรือลงทุน test automation framework
5. Repeat: หา bottleneck ใหม่ (อาจกลายเป็น deployment ก็ได้)

Anti-pattern ที่เจอบ่อย: จ้าง developer เพิ่ม → QA ยังคนเดียว → backlog ยาวขึ้น → ช้ากว่าเดิม นี่คือสิ่งที่ TOC บอกว่าห้ามทำเลยครับ

โยงกลับ EP.07 — CCM คือ TOC applied to PM#

Critical Chain Method ที่เพิ่งเรียนใน EP.07 เป็นการเอา TOC มาใช้กับ schedule:

• Bottleneck ของ project = critical chain (resource-constrained path)
• Project Buffer = ป้องกัน bottleneck
• Feeding Buffer = ไม่ให้สาย non-critical กระเด็นไปโดน critical

5 Steps (ตามลำดับเป๊ะ — ห้ามสลับ)#

graph LR
  Q["1. Question<br/>requirement"] --> D["2. Delete<br/>parts/process"]
  D --> S["3. Simplify<br/>optimize"]
  S --> A["4. Accelerate<br/>cycle time"]
  A --> AU["5. Automate"]
  style Q fill:#fca5a5,color:#000
  style D fill:#fca5a5,color:#000
  style AU fill:#86efac,color:#000

1. Question every requirement — ทุก requirement ต้องโยงไปถึง “คน” ที่สั่ง ไม่ใช่ “department” เพราะ department ไม่มีปัญหา คนมี ถามคนนั้นว่า “ทำไม”

2. Delete parts/processes — ลบทิ้งเลยครับ กฎทองคือ ถ้าไม่ต้องเอากลับมาซัก 10% = ตัดน้อยไป ถ้าลบแล้วไม่เห็นปัญหาเกิดทันที แสดงว่ามันไม่จำเป็น

3. Simplify and optimize — เฉพาะที่เหลือหลัง delete นะ อันนี้ผิดบ่อย คนชอบไป optimize ของที่ควรลบทิ้งตั้งแต่แรก

4. Accelerate cycle time — เร่งเฉพาะหลัง simplify ถ้ายังไม่ simplify แล้วเร่ง ก็คือผิดเร็วขึ้น 555+

5. Automate last — สุดท้ายเท่านั้น automate process ที่ flawed อยู่ เท่ากับติดคุกกับ flaw นั้นไปอีก 10 ปี + จ่ายค่า license แพงๆ ด้วย

Anti-pattern ของบริษัทไทย — สลับลำดับ#

ส่วนใหญ่จะทำ Step 5 ก่อน Step 1 ซะอย่างนั้น:

• ซื้อ ERP มา → automate process เดิมที่ควรลบ
• ซื้อ RPA bot → automate การคีย์ข้อมูลซ้ำซ้อนที่ไม่ควรมีตั้งแต่แรก
• เซ็น contract Salesforce → ใช้ feature แค่ 10% ของที่จ่ายเงิน 100%

ค่าเสียโอกาสคือ ตอนนี้ติด vendor contract 3-5 ปี ทีมต้องคอยดูแล tool แล้ว process ที่ flawed ก็ยังอยู่เหมือนเดิม 555+

Build → Measure → Learn loop#

graph LR
  I["Idea<br/>(สมมติฐาน)"] --> B["Build<br/>MVP"]
  B --> M["Measure<br/>data"]
  M --> L["Learn<br/>validated insight"]
  L --> I
  style I fill:#fbbf24,color:#000

หัวใจคือ ทุก feature ที่จะสร้าง = สมมติฐาน ว่าลูกค้าจะใช้ ต้อง validate ก่อน build ใหญ่

MVP — Minimum Viable Product#

ไม่ใช่ “version 1.0 ที่ห่วยกว่าปกติ” นะครับ มันคือ experiment ที่ตอบคำถามเชิงสมมติฐาน เล็กที่สุด

ตัวอย่างเช่น:

• Wrong MVP: สร้างแอป e-commerce ครบทุก feature เวอร์ชั่นแรก แต่ “feature น้อยกว่าคู่แข่ง”
• Right MVP: สร้าง landing page + form pre-order ดูก่อนว่ามีคนสมัครไหม ค่อยเขียนโค้ดแอป

Pivot vs Persevere#

ทุก iteration ถามตัวเอง 2 คำถาม:

1. Persevere: สมมติฐาน validate แล้ว ทำต่อ
2. Pivot: สมมติฐานผิด เปลี่ยนทิศเลย (เปลี่ยนลูกค้า เปลี่ยน feature เปลี่ยน business model)

Counter ที่บริษัทใหญ่ชอบบ่น: “เราลงทุนไปแล้ว 100M จะ pivot ได้ไง” อันนี้คือ sunk cost fallacy ครับ ของที่ลงทุนไปแล้วเอาคืนไม่ได้แล้ว ตัดสินใจจาก expected value ข้างหน้าสิ ไม่ใช่จากเงินที่จ่ายไปแล้ว

Innovation Accounting — Vanity vs Actionable#

โยงกลับ EP.12 metrics:

• Vanity: Total users, page views ขึ้นเสมอ ไม่บอกว่าทำดีหรือไม่ดี
• Actionable: Cohort retention, conversion rate, MAU/DAU ratio บอก behavior change จริงๆ

Brooks’s Law — 1975#

Origin: Fred Brooks, The Mythical Man-Month (1975) — จากประสบการณ์ทำ IBM System/360

“Adding manpower to a late software project makes it later.”

ทำไม “เพิ่มคน” ไม่ใช่คำตอบ#

1. Communication overhead = O(n²)

• 5 คน → 10 communication channels
• 10 คน → 45 channels
• 20 คน → 190 channels
• 50 คน → 1,225 channels

graph LR
  N5["5 คน<br/>10 channels"] --> N10["10 คน<br/>45 channels"] --> N20["20 คน<br/>190 channels"] --> N50["50 คน<br/>1225 channels"]
  style N50 fill:#fca5a5,color:#000

2. Onboarding cost — คนใหม่ต้องอ่านโค้ด เข้าใจระบบ สร้าง context ขึ้นมาเอง ระหว่างนั้น คนเก่าก็ต้องเสียเวลาสอน ความเร็วทีมเดิมลดอีก

3. Sequential constraint — บางงาน split ไม่ได้ครับ “เลี้ยงเด็ก 9 เดือนใช้แม่ 1 คน จะใช้แม่ 9 คนเลี้ยงใน 1 เดือนไม่ได้” 555+

Bezos’s Two-Pizza Team — Amazon 1990s#

Counter-narrative ของ scaled framework (EP.10):

“If a team can’t be fed with two pizzas, it’s too big.”

หลักการ:

• ทีม 6-8 คน
• Own end-to-end (เขียน, deploy, ดูแล, on-call)
• Two-way door decisions ทีมตัดสินเอง — ไม่ต้องขอ approval
• One-way door เท่านั้นที่ต้องขึ้นบน

ทำไม Amazon scale ได้ทั้งที่ทีมเล็ก:

• 100 ทีม × 8 คน = 800 คน ทำงานขนานกันได้หมด
• ไม่ต้องประชุม cross-team บ่อย เพราะ team own everything อยู่แล้ว
• ใช้ API contracts ระหว่างทีมแทน meetings

Brooks + Bezos รวมกัน ก็คือ อย่าเพิ่มคนในทีมเดิม ให้ไปตั้งทีมใหม่เล็กๆ ที่ own piece อื่นแทน

4 + 1 Domains#

quadrantChart
  title Cynefin Framework
  x-axis "Cause-effect ไม่ชัด" --> "Cause-effect ชัด"
  y-axis "Unordered" --> "Ordered"
  quadrant-1 "Clear (Best practice)"
  quadrant-2 "Complicated (Good practice)"
  quadrant-3 "Chaotic (Novel)"
  quadrant-4 "Complex (Emergent)"
  "ทำตามคู่มือ": [0.85, 0.85]
  "ออกแบบสะพาน": [0.7, 0.65]
  "สร้าง product ใหม่": [0.3, 0.3]
  "Crisis response": [0.15, 0.15]

ทำไมเรื่องนี้สำคัญสำหรับ PM#

Mismatch ที่เจอบ่อย:

• บริษัทใช้ Waterfall (เหมาะ Clear/Complicated) กับ product development (จริงๆ Complex) → กำหนด spec ครบ → 12 เดือนต่อมา feature ออกมาไม่มีใครใช้
• บริษัทใช้ Agile (เหมาะ Complex) กับ compliance project (จริงๆ Complicated) → ไม่มี spec ชัด → audit fail

กฎทอง: ก่อนเลือก methodology ให้ identify domain ก่อนครับ ถ้าโปรเจคอยู่ใน Complex domain Waterfall ผิด ไม่ใช่เพราะ Waterfall ห่วย แต่เพราะใช้ผิดประเภทปัญหาต่างหาก

Concept#

• Post-mortem: project ล้มแล้ว ค่อยมาถามว่าทำไมล้ม
• Pre-mortem: project ยังไม่เริ่มเลย แต่ imagine ว่ามันล้มไปแล้ว แล้วถามว่าทำไมล้ม

How to run (1 ชั่วโมง ก่อน kickoff)#

1. Set the stage: “สมมติว่า 12 เดือนผ่านไป project นี้ล้มอย่างสมบูรณ์ ใช้เงินหมด ไม่ส่งของ”
2. Silent writing (10 นาที): ทุกคนเขียน reason ที่ project ล้ม ห้ามคุย ห้าม influence กัน
3. Round-robin (20 นาที): แต่ละคนแชร์ 1 reason ทีละรอบ จนหมด
4. Cluster + rank (20 นาที): จัดกลุ่ม risk แล้ว ranking ตาม likelihood × impact
5. Mitigation plan (10 นาที): top 5 risk ใครรับผิดชอบ วิธีลดยังไง

ทำไม effective#

Optimism bias — ทุกคนตอน kickoff อยากให้ project สำเร็จ เลยมองไม่เห็น risk ที่ชัดเจน

Prospective hindsight (Mitchell, Russo, Pennington 1989) — พอ assume ว่า “ล้มไปแล้ว” + ต้อง imagine สาเหตุ ความสามารถระบุ risk จะเพิ่มขึ้น 30%

ปลดล็อก dissent — ที่ kickoff คนที่เห็น risk ไม่กล้าพูด เพราะดูเหมือน negative ใช่มั้ยครับ Pre-mortem ทำให้การพูด risk = norm ของวง