Sponsor — คนจ่ายเงิน#

ใคร: Executive (มัก C-level หรือ VP) ที่เป็นคน push project เข้ามา + รับผิดชอบ business outcome

ทำอะไร:

• ตั้ง goal ของโปรเจค + อนุมัติ business case
• Approve budget + scope ที่สำคัญ
• Escalation point เมื่อ PM ติด
• Accountable ต่อ result — ถ้าโปรเจคล้ม คนแรกที่โดน

Sponsor ที่ดี:

• พร้อมเสีย political capital ให้ project
• มีอำนาจอนุมัติจริง (ไม่ใช่แค่ “ผู้ประสานงาน”)
• มีเวลาดู progress รายเดือน

Sponsor ที่แย่ = โปรเจคตายตั้งแต่ phase 1 — เพราะไม่มีใครเคลียร์ blocker ระดับองค์กรได้

Steering Committee — กลุ่มอนุมัติ#

ใคร: กลุ่มผู้บริหาร 5-10 คนที่ project กระทบ — Sponsor + executive จากทุก department ที่เกี่ยว

ทำอะไร:

• ประชุมรายเดือน/รายไตรมาส
• รับ status report จาก PM
• ตัดสินใจระดับ strategic — change scope ใหญ่, ขอ budget เพิ่ม, accept risk ระดับสูง
• ตั้ง direction รวม

ขนาด: ปกติ 5-10 คน — ใหญ่กว่านี้ตัดสินใจช้า เล็กกว่านี้ขาด representation

PMO — Project Management Office#

ใคร: หน่วยงานในบริษัทที่ดูแล PM practice ทั่วทั้ง portfolio

3 ประเภท (ตาม PMI):

1. Supportive PMO — ให้ template + training + best practice (ไม่บังคับ) — เหมือนห้องสมุด
2. Controlling PMO — บังคับใช้ framework + audit project + รายงาน — มีอำนาจกลาง
3. Directive PMO — เป็นเจ้าของ project เอง — PM report ตรงเข้า PMO

ใครใช้แบบไหน:

• Startup / มีน้อย project: Supportive ก็พอ
• Mid-size: Controlling
• Enterprise + regulated: Directive

💡 Connect to CISA D3-24: CISA Domain 3 อ้างถึง PMO ทั้ง 3 แบบนี้ — แต่ไม่อธิบายว่าต่างกันยังไง ตอนนี้น่าจะ map ได้แล้ว

PM — Project Manager#

ใคร: หัวหน้า project ที่ดูทุกอย่างรายวัน

ทำอะไร:

• Plan + execute + monitor + close (วน lifecycle ของ EP.02)
• Manage scope, time, cost, quality, risk, stakeholder, communication
• Coordinate ทีม — ไม่ได้ทำงาน technical เอง
• Status report ขึ้น Sponsor + Steering

Skill ที่ต้องการ:

• Communication (60% ของงาน)
• Risk management
• Negotiation
• Domain knowledge ระดับเข้าใจ — ไม่ต้องลึกเท่า expert

PM ใน Waterfall = หัวหน้าโปรเจคเต็มรูปแบบ มีอำนาจสูง

PM ใน Agile = ตำแหน่งนี้ไม่ค่อยมี — งานแยกเป็น Product Owner + Scrum Master (ดูข้างล่าง)

Program Manager#

ใคร: หัวหน้าโครงการระดับ program (กลุ่ม projects)

ทำอะไร:

• ดู benefit รวมข้าม projects
• Manage cross-project dependency
• Resolve conflict ระหว่าง PM
• Report ขึ้น Steering / Portfolio Manager

Differ จาก PM ยังไง:

• PM ดู 1 project, ส่งมอบ deliverable
• Program Manager ดูหลาย project, ส่งมอบ benefit รวม

Product Owner (PO)#

ใคร: คน “เป็นเจ้าของ product” — ตัดสินใจว่าจะ build อะไรก่อน

ทำอะไร:

• Maintain backlog (รายการงานที่ต้องทำ)
• Prioritize — เรียงลำดับ
• Accept/reject งานที่ทีมส่งมอบ
• คุยกับ stakeholder + customer

PO ที่ดี: ตัดสินใจเร็ว + รู้ business deep + อยู่ใกล้ทีม

PO ที่แย่: ตัดสินใจไม่ได้ (ต้อง “ขอผู้บริหาร” ทุกครั้ง) → ทีม block

Scrum Master (SM)#

ใคร: Coach + facilitator ของทีม Scrum

ทำอะไร:

• จัด ceremonies (standup, planning, review, retro)
• Remove impediment (อะไร block ทีมอยู่ — แก้ให้)
• Coach ทีมให้ทำ Scrum ดี
• Protect ทีมจาก distraction

ไม่ได้ทำ:

• ❌ ไม่ได้สั่งงานทีม
• ❌ ไม่ได้รายงาน status (PO ทำ)
• ❌ ไม่ได้ assign task

Scrum Master ≠ PM — Scrum Master ไม่มีอำนาจสั่ง — เป็น servant leader

Developer (Scrum Team Member)#

ใคร: คนที่ build product จริง — engineer, designer, QA

ทำอะไร:

• Self-organize — จัดการตัวเองว่าทำอะไรก่อน
• ส่งมอบ increment ทุก sprint
• Estimate งาน

Scrum Guide: ทีม Scrum ควร 3-9 คน (ไม่รวม PO + SM)

BA — Business Analyst#

ใคร: คนกลางระหว่าง business กับ tech

ทำอะไร:

• Capture requirement จาก business stakeholder
• Translate เป็น user story / spec
• Validate solution กับ business
• Help PO ใน Agile setup

ทำไมสำคัญ: Business + Tech พูดคนละภาษา — BA แปล

Tech Lead#

ใคร: Senior engineer ที่ดูทาง technical

ทำอะไร:

• Technical decision (architecture, library, pattern)
• Code review
• Mentor junior
• เป็น escalation point ของปัญหา technical

ในทีมเล็ก: Tech Lead + Architect รวมเป็นคนเดียว

Architect#

ใคร: คนวาด architecture ระดับสูง — system design, integration, technology stack

ระดับ:

• Solution Architect — ระดับ project
• Enterprise Architect — ระดับบริษัท

💡 Connect to CISA D2-16B: CISA Domain 2 พูดถึง Enterprise Architecture — บทบาทของ EA ก็คือคน design ภาพ tech ของทั้งบริษัทให้ align กับ business strategy

QA — Quality Assurance#

ใคร: คนตรวจคุณภาพ

Difference QA vs QC:

• QA = preventive — process ที่ทำให้ของมีคุณภาพตั้งแต่แรก
• QC = detective — test/inspect หลัง build แล้ว

(EP.08 จะลงลึก)

DevOps / SRE#

ใคร: คนดูระบบ deploy + run + monitor production

ทำอะไร:

• CI/CD pipeline
• Infrastructure (cloud, kubernetes, network)
• Monitoring + on-call
• Incident response

ตัวอย่าง RACI: Project ติดตั้ง CRM#

กฎทอง:

• ทุก row ต้องมี A เพียง 1 ตัว — ไม่งั้นไม่มีคนรับผิดชอบ
• ถ้ามี A 2 ตัว = blame game ตอนล้ม
• R มีหลายคนได้

Two-Pizza Team (Amazon)#

กฎของ Bezos: ถ้าใช้ pizza 2 ถาดเลี้ยงทีมไม่พอ — ทีมใหญ่เกินไป

ขนาด: 6-10 คน

ทำไมใช้ได้: Communication overhead = n*(n-1)/2 — ทีม 8 คน = 28 channels, ทีม 16 คน = 120 channels — overhead เพิ่ม exponential

Feature Team vs Component Team#

Feature Team:

• ทำ feature ที่ลูกค้าเห็น (end-to-end ผ่าน frontend → backend → DB)
• Full-stack — ทีมเดียวรับผิดชอบทั้ง stack
• ✅ ส่งมอบ value เร็ว
• ❌ ต้องการ skill diverse

Component Team:

• ทำ component เฉพาะ (frontend team / backend team / DB team แยก)
• ✅ Specialization ลึก
• ❌ Feature 1 ตัวต้องผ่าน 3-4 ทีม — ส่งมอบช้า + dependency เยอะ

Modern preference: Feature Team — เพราะ Conway’s Law (EP.09 ลึก) บอกว่าโครงสร้างทีมจะกลายเป็นโครงสร้างระบบ

Squad / Tribe / Chapter / Guild (Spotify Model)#

Squad = team 6-12 คน (เหมือน Scrum team) Tribe = กลุ่ม squads ที่ทำ product family เดียวกัน (40-150 คน) Chapter = กลุ่มคน specialty เดียวกัน (เช่น all backend engineers across squads) — meet เป็นระยะ Guild = community ที่สนใจเรื่องเดียวกัน — เปิดให้คนเข้าร่วม voluntary

หมายเหตุ: Spotify เองไม่ใช้แบบนี้แล้ว — แต่บริษัทอื่นเอาไปใช้ ผลลัพธ์ผสม