Management for Developers

Management
for Developers

เมื่อ Dev เข้าใจ Management — ทีมทำงานได้เร็วขึ้น ปัญหาลดลง และ Career เติบโตแบบก้าวกระโดด

By DevNest

Methodologies

Roles

Sprint

Documents

Digital Product

02 / 37

Product คืออะไร?

Product ไม่ใช่แค่แอปพลิเคชัน แต่คือ "ทุกสิ่ง" ที่สร้างขึ้นมาเพื่อแก้ปัญหา (Pain Point)

→

→

→

ล้างจานคราบมันไม่ออก

ปัญหาที่ทุกคนเคยเจอ ความหงุดหงิดนี้ทำให้เกิด 'น้ำยาล้างจาน' ขึ้นมา

Pain Point → Product

หิวแต่ขี้เกียจทำอาหาร

ไม่อยากเสียเวลาทำกับข้าว จึงเกิด 'ไมโครเวฟ' ที่อุ่นอาหารได้ในไม่กี่นาที

Pain Point → Product

หลงทาง จำทางไม่ได้

ต้องถามทางตลอด เลยเกิด 'Google Maps' ที่นำทางได้ทุกที่ทุกเวลา

Pain Point → Product

Digital Product

03 / 37

Digital Product — ข้อได้เปรียบ & จุดเด่น

ทำไมยุคนี้บริษัทถึงฮิตสร้าง Digital Product? และมี "พลังวิเศษ" อะไรที่ Physical Product ทำไม่ได้

กระจายสินค้าง่าย

ไม่ต้องมีหน้าร้าน ไม่ต้องจ้างรถขนส่ง แค่อัปโหลดขึ้น Store ก็เข้าถึงคนได้ทั่วโลกทันที

Distribution

อัปเดตง่าย ต้นทุนต่ำ

ไม่ต้องรื้อสายพานผลิตใหม่ แค่กดปล่อยอัปเดต ผู้ใช้ทุกคนก็ได้ฟีเจอร์ใหม่ทันที

Fast Updates

Scalability

ต้นทุนดูแลลูกค้า 10 คน กับ 1 ล้านคน แทบไม่ต่างกัน

Data-Driven

เก็บข้อมูลพฤติกรรมผู้ใช้ได้ละเอียดยิบ รู้ว่าคนกดปุ่มไหนเยอะสุด

Continuous Improvement

มี Data + อัปเดตง่าย = ปรับปรุงได้ตลอดเวลา (Iterative)

Digital Product

04 / 37

ทีมสร้าง Digital Product — 3 ทหารเสือ

Digital Product ที่ดี ต้องเกิดจากความสมดุลของ 3 ฝ่าย — ขาดฟันเฟืองตัวใดตัวหนึ่งไม่ได้

Business

Product Manager / Product Owner /
Business Analyst
ตอบคำถาม: จะทำอะไร? ทำไมต้องทำ?
โฟกัส: หาปัญหาที่แท้จริง กำหนดทิศทาง
ดูแลเป้าหมายธุรกิจ & รายได้

What & Why

Design

UX/UI Designer
ตอบคำถาม: ออกแบบอย่างไรให้ใช้งานง่าย?
โฟกัส: User Experience & ความสวยงาม
จัดวางหน้าจอให้เข้าใจง่าย

How — Usable

Tech

Software Engineer / Developer
ตอบคำถาม: สร้างมันขึ้นมาได้จริงอย่างไร?
โฟกัส: เขียนโค้ด สถาปัตยกรรมระบบ
ทำให้ระบบใช้งานได้จริง & ไม่ล่ม

How — Build

Opening

05 / 37

ทำไม Dev ต้องรู้เรื่อง Management?

ปัญหาที่เกิดขึ้นเมื่อ Dev ไม่เข้าใจ Process — และโอกาสที่เปิดกว้างเมื่อเข้าใจ

ปัญหาที่เจอ

Requirement เปลี่ยนบ่อย ไม่รู้จะถามใคร ทำงานซ้ำซ้อน Deadline พลาดเพราะ Scope บาน

Pain Points

เมื่อเข้าใจ Process

สื่อสารกับทีมได้ตรงจุด เข้าใจ Priority Estimate งานได้แม่นยำ ลดการทำงานซ้ำ

Benefits

Career Path

Tech Lead, Engineering Manager, CTO — ทุกตำแหน่งต้องการทั้ง Technical + Management Skills

Growth

Module 1 · Methodologies

06 / 37

Waterfall vs Agile

สองแนวคิดหลักในการบริหารโปรเจค — แบบไหนเหมาะกับงานแบบไหน?

Waterfall

Sequential

✓ เหมาะกับ: Requirement ชัดเจน ไม่เปลี่ยนบ่อย
✗ ไม่เหมาะ: โปรเจคที่ต้อง flexible ปรับเปลี่ยนได้

Agile

Iterative

✓ เหมาะกับ: Requirement เปลี่ยนได้ ต้องการ feedback เร็ว
✓ ส่งมอบงานทีละ increment — เห็นผลลัพธ์เร็ว

Module 1 · Methodologies

07 / 37

Scrum คืออะไร? — ภาพรวมทั้งหมด

จาก Mindset สู่ Framework สู่ตำแหน่งในทีม — ทุกอย่างเชื่อมกัน

Waterfall
วางแผนจบก่อน แล้วค่อยทำ

←→

Agile
ทำทีละนิด ปรับไปเรื่อยๆ

2 ปรัชญาการทำงานที่ต่างกัน

↓

Scrum
Framework ที่ทำตามแนวคิด Agile
แบ่งงานเป็นรอบ Sprint ทุก 2 สัปดาห์

Framework ยอดนิยมของ Agile

↓

Product Owner
ตัดสินใจว่าทำอะไร

Dev Team
ลงมือทำ

Scrum Master
ดูแล process ให้ราบรื่น

3 ตำแหน่งภายใน Scrum

3

Roles

PO · Dev · SM

·

3

Artifacts

Backlog · Sprint · Increment

·

5

Events

Sprint · Plan · Daily · Review · Retro

Module 2 · Roles

08 / 37

บทบาทในทีม — ใครทำอะไร?

PM, PO, BA, Scrum Master — แต่ละคนรับผิดชอบอะไร และ Dev ควรคุยกับใครเมื่อไหร่

Project Manager

วางแผน Timeline & Budget
บริหาร Risk & Resource
ติดตาม Progress ภาพรวม
สื่อสารกับ Stakeholder

PM

Product Owner

กำหนด Product Vision
จัดลำดับ Backlog Priority
ตัดสินใจ Feature ไหนทำก่อน
Accept / Reject Sprint Result

PO

Business Analyst

วิเคราะห์ Requirements
เขียน User Story & AC
แปลภาษา Business → Tech
ทำ User Flow & Wireframe

BA

Scrum Master

ดูแล Scrum Process
แก้ไข Impediments
Facilitate ทุก Ceremony
Coach ทีมให้ดีขึ้น

SM

Module 2 · Roles

09 / 37

PM · PO · BA — สามบทบาทที่ทำให้โปรเจกต์เดินได้

"เสร็จ · ตรงจุด · แก้ปัญหาได้จริง" — คนละหน้าที่ ไม่ใช่คนละตำแหน่งเสมอไป

PM PROJECT MANAGER

ทำให้ เสร็จ

บริหารเวลา คน และการสื่อสาร ให้ทีมวิ่งไปทางเดียวกันโดยไม่ต้องคอยจี้

สิ่งที่ PM ทำ

• วางแผน Timeline / Milestone
• บริหาร Resource / Dependency
• ติดตาม Progress ภาพรวม
• จัดการ Risk / Blocker
• Assign owner ให้แต่ละงาน
• สื่อสารกับ Stakeholder

PO PRODUCT OWNER

ทำให้ คุ้ม

เลือกทำสิ่งที่ให้คุณค่าสูงสุดก่อน และกล้าปฏิเสธสิ่งที่ยังไม่จำเป็น

สิ่งที่ PO ทำ

• กำหนด Product Vision
• ตัดสินใจ feature "เอา / ไม่เอา"
• จัดลำดับ Priority (Backlog)
• วาง Roadmap ระดับ product
• สร้าง Epic / Feature
• Approve ว่าตรง product goal ไหม

BA BUSINESS ANALYST

ทำให้ ถูก

แปลโจทย์ธุรกิจเป็นข้อกำหนดที่ Dev / QA อ่านแล้วเข้าใจตรงกัน

สิ่งที่ BA ทำ

• รวบรวม Requirement
• เขียน User Flow / Process Flow
• กำหนด Business Rules / Edge Cases
• เขียน Functional Spec
• แตก Epic → Task ที่ Dev ทำได้
• วิเคราะห์ Impact Analysis

สรุป: PO บอก "ทำอะไร" → BA แตกรายละเอียด "ทำยังไง" → PM ดูแล "เสร็จเมื่อไหร่"

หลายองค์กรคนเดียวสวมทั้ง 3 หมวก — สิ่งสำคัญคือรู้ว่าตอนนี้กำลังคิดด้วยหมวกใบไหน

Module 2 · Roles · PM

10 / 37

PM — Execution & Team Alignment

สั่งงานให้ชัด สื่อสารให้ทีมคิดต่อเองได้

Goal: บริหารงานให้เสร็จตามเวลา ทีมทำงานร่วมกันอย่างมีเป้าหมาย — ไม่ต้องคอยจี้

KEY FRAMEWORKS & TRICKS

1 3W + Self-Commitment Deadline

สั่งงานต้องระบุ Who + What + When เสมอ ถ้าไม่กล้ากำหนดวันเอง ให้ย้ายเดดไลน์ไปเป็นคำมั่นของทีม ด้วยคำถามเดียว

"ทำได้เร็วที่สุดวันไหน?"

2 Content + Intent (What + Why)

บอกเนื้องาน (Content) พร้อมเหตุผล/เป้าหมายภาพใหญ่ (Intent) เพื่อให้ทีม ตัดสินใจแก้ปัญหาหน้างานเองได้ เมื่อเกิดเหตุไม่คาดคิด

สั่งงาน ≠ สั่งให้ทำตาม

3 Outcome-Driven Meeting

ตั้งเป้าผลลัพธ์ของที่ประชุมล่วงหน้า → ส่ง Agenda ก่อน 2–5 วัน → กัน Buffer Time เผื่อตกปัญหา → ปิดด้วย Visual สรุปภาพรวม

ประชุมเพื่อ "ได้ข้อสรุป" ไม่ใช่ "ได้อัปเดต"

🎬 Example Scenario — โจทย์: สั่งทีมทำหน้าเว็บแคมเปญเปิดตัวสินค้าใหม่

● สั่งแบบทั่วไป

"ช่วยทำหน้าเว็บแคมเปญให้หน่อย"

• ใครทำ? เสร็จเมื่อไหร่? ทำไปทำไม?
• ทีมงง ต้องกลับมาถาม หรือเดาเอง
• พอเจอปัญหา = หยุดรอคำสั่ง

● สั่งแบบ PM มือโปร

              "พี่บอส ช่วยทำ หน้าเว็บแคมเปญเปิดตัวสินค้า ให้เสร็จ วันพุธบ่าย 3 นะ เพราะเราต้องใช้ เก็บยอดลงทะเบียนล่วงหน้าก่อนวันเปิดตัวจริงวันศุกร์นี้"
            

              • Who / What / When ครบในประโยคเดียว + Intent ต่อท้าย
            

ผลลัพธ์: ถ้าวันพุธระบบเชื่อมฐานข้อมูลมีปัญหา (Accident) ทีมจะไม่หยุดทำ แต่จะช่วยคิดวิธีแก้เฉพาะหน้า เช่น ทำฟอร์มสำรอง เพื่อให้บรรลุเป้าหมาย "เก็บยอดลงทะเบียนให้ทันวันศุกร์"

Module 2 · Roles · PO

11 / 37

PO — Value Maximization & Prioritization

เลือกทำสิ่งที่ใช่ ในเวลาที่เหมาะสม

Goal: ส่งมอบงานที่มีคุณค่าสูงสุดแก่ผู้ใช้และธุรกิจ — ไม่ใช่ส่งมอบให้ครบทุกอย่างที่มีคนขอ

KEY FRAMEWORKS & TRICKS

1 Value vs Effort Prioritization

ไม่ทำทุกอย่างที่คนขอ แต่หยิบฟีเจอร์ที่ Value สูง / Effort ต่ำ ขึ้นมาทำก่อนเสมอ

Quick Win มาก่อน

2 MVP First

ปล่อยฟีเจอร์หลักออกไปทดสอบตลาดก่อน ไม่ต้องรอสมบูรณ์ 100% แล้วค่อยเก็บ Feedback มาพัฒนาต่อ

เสร็จ 60% ที่ใช้ได้ > 100% ที่ยังไม่ปล่อย

3 The Art of Saying "No"

ปฏิเสธความต้องการที่ยังไม่จำเป็นของ Stakeholder ด้วย ข้อมูลและลำดับความสำคัญที่ชัดเจน ไม่ใช่ด้วยความรู้สึก

"ยังไม่ใช่ตอนนี้" ≠ "ไม่ทำ"

🎬 Example Scenario — โจทย์: ทำระบบชำระเงินของเว็บขายสินค้าออนไลน์

● โจทย์ที่ได้รับจาก Stakeholder

• จ่ายผ่านบัตรเครดิต • สแกน QR
• ผ่อนชำระ • จ่ายด้วย Crypto
• ระบบห่อของขวัญ

ถ้าทำทั้งหมดพร้อมกัน = รอ 6 เดือน กว่าจะขายของได้ชิ้นแรก

● วิธีแบบ PO มือโปร

• แยกทุกฟีเจอร์ลง Value / Effort Matrix
• เลือก MVP = สแกน QR + จ่ายบัตร ปล่อยใน 2 สัปดาห์แรก ให้ลูกค้าเริ่มซื้อได้ทันที
• ผ่อนชำระ → รอบถัดไปตาม Demand จริง
• Crypto + ห่อของขวัญ → Backlog พร้อมเหตุผลที่อธิบายได้

ผลลัพธ์: สร้าง Revenue ให้ธุรกิจได้ทันที ไม่ต้องเสียเวลา 6 เดือนรอทำทุกฟีเจอร์ให้เสร็จพร้อมกัน — และ Feedback จากผู้ใช้จริงจะเป็นตัวบอกเองว่าฟีเจอร์ถัดไปควรเป็นอะไร

Module 2 · Roles · BA

12 / 37

BA — Deep Problem Solving & Requirement Clarity

อย่าเป็น Order Taker จงเป็นคนหาปัญหาที่แท้จริง

Goal: เคลียร์โจทย์ธุรกิจให้กลายเป็นข้อกำหนดทางเทคนิคที่ชัดเจน — ลด Gap ความเข้าใจระหว่าง Business และ Dev / QA

KEY FRAMEWORKS & TRICKS

1 5 Whys — Want vs Need

ถาม "ทำไม" ซ้ำลงไปทีละชั้นราวๆ 5 รอบ เพื่อขุดจากสิ่งที่เขาขอ (Want) ลงไปเจอปัญหาจริง (Need) แทนที่จะรับมาทำตามแบบ Order Taker

"5" คือค่าเฉลี่ยที่มักขุดถึงต้นตอ ไม่ใช่กฎตายตัว — ถึงรากเมื่อไหร่ก็หยุดได้

เขาขอ "ปุ่ม" แต่เขาต้องการ "เวลาที่หายไป"

2 User Story + Acceptance Criteria

เขียนความต้องการให้มีขอบเขตการตรวจรับงานชัดเจน — "ทำอะไร + แค่ไหนถึงเรียกว่าเสร็จ"

ไม่มี AC = เถียงกันตอน UAT

3 Visual Diagram Over Prose

ใช้ Flowchart / Wireframe คุยงานแทนเอกสารตัวหนังสือยาวๆ ดักจับ Logic ที่ตกหล่นได้ตั้งแต่แรก

ภาพ 1 รูป = ประชุมที่หายไป 1 รอบ

🎬 Example Scenario — โจทย์: ฝ่ายบริการลูกค้า (Call Center) เดินมาบอกว่า…

● สิ่งที่เขาขอ (Want)

"อยากได้ปุ่มค้นหาข้อมูลด้วยเลขบัตรประชาชน 13 หลัก"

• BA แบบ Order Taker: รับมา เขียนสเปก ส่ง Dev ทำ
• ได้ปุ่มตามขอ แต่ Call Center ยังต้องพิมพ์ 13 หลักอยู่ดี
• ปัญหาเดิมไม่ถูกแก้ → มี Request ใหม่ตามมาอีก

● วิธีแบบ BA มือโปร (Need)

• ขุดทีละชั้น: Why 1 "ทำไมถึงต้องค้นหา?" → Why 2 "ค้นหาตอนไหน?" → Why 3 "ตอนนี้เสียเวลาตรงไหน?"
• พบปัญหาจริง: Call Center เสียเวลาพิมพ์เลข 13 หลักของลูกค้าทุกครั้งที่รับสาย
• เสนอโซลูชัน: Auto-Pop Up สรุปข้อมูลลูกค้าขึ้นมาทันทีที่รับสาย

ผลลัพธ์: ได้ระบบที่แก้ปัญหาการทำงานของ Call Center ได้จริง ลดเวลาคุยต่อสาย และไม่ต้องเสียเวลาทำปุ่มค้นหาแบบ Manual ตามที่ขอมาตอนแรก

Module 2 · Roles

13 / 37

Dev ควรคุยกับใคร เมื่อไหร่?

Role Matching Guide — เจอสถานการณ์แบบนี้ ให้หาคนที่ใช่

สถานการณ์ที่พบบ่อย → คุยกับใคร

Requirement ไม่ชัดเจน

→

BA

แปลง Business Need → User Story

Feature ไหนทำก่อน?

→

PO

เป็นคนตัดสินใจ Priority

Deadline / Timeline เลื่อน

→

PM

บริหาร Timeline & สื่อสาร Stakeholder

ติดปัญหา / Blocker

→

Scrum Master

แก้ไข Impediment ให้ทีม

งานเสร็จ ใครต้อง Accept?

→

PO

Review & Accept/Reject ใน Sprint Review

Process มีปัญหา

→

Scrum Master

หยิบขึ้นมาคุยใน Retrospective

Module 2 · Wrap-up

14 / 37

สรุป 3 หมวด · 3 คำถามที่ต้องถามตัวเอง

แผ่นเดียวสำหรับแปะไว้ข้างจอ

บทบาท

โฟกัส

คำถามประจำตัว

ถ้าขาดไป จะพังแบบไหน

PM

Execution & Alignment

"ใครทำ เสร็จเมื่อไหร่ และทำไปทำไม?"

งานเสร็จช้า ต้องคอยตามจี้ และทีมหยุดรอคำสั่งทุกครั้งที่เจอปัญหา

PO

Value & Prioritization

"สิ่งนี้คุ้มที่จะทำตอนนี้ไหม?"

ทำครบทุกอย่าง แต่ปล่อยช้า และของที่ปล่อยออกไปไม่มีใครใช้

BA

Problem & Clarity

"นี่คือปัญหาจริง หรือแค่วิธีแก้ที่เขานึกออก?"

สร้างตามที่ขอเป๊ะ แต่ไม่ได้แก้ปัญหา และเถียงกันตอนตรวจรับงาน

Key Takeaway: ทั้ง 3 บทบาทใช้ทักษะเดียวกันคือ "การถามคำถามที่ถูก ก่อนลงมือ" — PM ถามเรื่องเวลาและเป้าหมาย, PO ถามเรื่องคุณค่าและลำดับ, BA ถามเรื่องปัญหาที่แท้จริง

เริ่มพรุ่งนี้ด้วยข้อเดียว: งานถัดไปที่คุณสั่งหรือรับมา ลองเติม Intent เข้าไป แล้วดูว่าบทสนทนาเปลี่ยนไปแค่ไหน

Module 3 · Sprint

15 / 37

Sprint Overview

กรอบเวลา 1-4 สัปดาห์ที่ทีมทำงานจนได้ผลลัพธ์ที่ส่งมอบได้ (Increment)

SPRINT LIFECYCLE

 Planning
Day 1

→

 Development
Day 1-10

→

 Review
Last Day

→

 Retro
Last Day

DAILY STANDUP (ทุกวัน ~15 นาที)

เมื่อวาน

ทำอะไรเสร็จ?

วันนี้

จะทำอะไร?

Blocker

ติดปัญหาอะไร?

Module 3 · Sprint

16 / 37

Sprint Ceremonies

Review, Demo & Retrospective — ปิด Sprint ให้สมบูรณ์

Sprint Review / Demo

จุดประสงค์

โชว์ผลงานที่ทำเสร็จในรอบ Sprint
รับ Feedback จาก Stakeholder
PO Accept / Reject แต่ละ Story

ใครเข้าร่วม

Dev Team — Demo ผลงาน
PO — Accept/Reject
Stakeholder — ดู & Feedback

Retrospective

😊 What went well?

อะไรทำได้ดีใน Sprint นี้
ทีมร่วมมือกันดีตรงไหน

😟 What went wrong?

ปัญหาที่เจอ / สิ่งที่ไม่เวิร์ค
Blocker หรือ Communication gap

What to improve?

Action Item สำหรับ Sprint หน้า
ปรับ Process อย่างไร

Module 4 · Documents

17 / 37

User Flow & User Story

แปลงความต้องการของผู้ใช้ให้เป็นเอกสารที่ทีมเข้าใจตรงกัน

USER FLOW EXAMPLE — Login

เปิด App

→

กรอก Email

→

กรอก Password

→

กด Login

→

หน้า Home

USER STORY FORMAT

As a [ประเภทผู้ใช้]
I want to [สิ่งที่ต้องการทำ]
So that [ผลลัพธ์ที่คาดหวัง]

ตัวอย่าง: As a new user, I want to register with email, so that I can access the platform

Module 4 · Documents

18 / 37

Acceptance Criteria

Given / When / Then — เงื่อนไขที่ชัดเจนว่า "เสร็จ" คืออะไร

FORMAT: GIVEN / WHEN / THEN

Given สถานการณ์เริ่มต้น (Context)
When ผู้ใช้ทำ Action อะไร
Then ผลลัพธ์ที่คาดหวัง

EXAMPLES — 1 STORY ต้องเขียนให้ครบทั้ง 2 ทาง

Case 1 · Login สำเร็จ (Happy Path)

Given ผู้ใช้อยู่หน้า Login When กรอก email & password ที่ถูกต้อง แล้วกด Login Then ระบบพาไปหน้า Dashboard + แสดงชื่อผู้ใช้

Case 2 · Login ไม่สำเร็จ (Error Path)

Given ผู้ใช้อยู่หน้า Login When กรอก password ผิด แล้วกด Login Then แสดง error "Invalid credentials" + ไม่เปลี่ยนหน้า

AC ที่แย่ ❌ → AC ที่ดี ✅

"ระบบต้องเร็ว"

วัดไม่ได้ — เร็วแค่ไหนถึงเรียกว่าเร็ว?

→

"หน้าค้นหาแสดงผลภายใน 2 วินาที เมื่อมีข้อมูล 10,000 รายการ"

มีตัวเลข + มีเงื่อนไข = QA กดผ่าน/ไม่ผ่านได้

"ทำระบบล็อกบัญชีเวลากรอกรหัสผิดบ่อยๆ"

บอก "งานที่ต้องทำ" ไม่ได้บอก "เกณฑ์ตรวจรับ"

→

Given กรอกรหัสผิดครบ 5 ครั้ง When กด Login ครั้งที่ 6 Then ล็อกบัญชี 15 นาที + ส่งอีเมลแจ้งเจ้าของบัญชี

ระบุตัวเลขและผลลัพธ์ครบ ไม่ต้องเดา

"หน้าจอต้องใช้งานง่าย สวยงาม"

เป็นความรู้สึก — แต่ละคนตัดสินไม่เหมือนกัน

→

"ผู้ใช้จองห้องประชุมสำเร็จได้ภายใน 3 คลิก จากหน้าแรก"

เปลี่ยนความรู้สึกเป็นพฤติกรรมที่นับได้

เช็คด้วยคำถามเดียว: "ถ้า Dev ส่งงานมาพรุ่งนี้ เราจะกด ผ่าน / ไม่ผ่าน ด้วยอะไร?" — ถ้าตอบไม่ได้ แปลว่า AC ข้อนั้นยังไม่ดีพอ

Example

19 / 37

ตัวอย่าง: ระบบจองห้องประชุม

Meeting Room Booking — ลองดูตัวอย่างการเขียน Objective, User Story, User Flow และ AC จากโปรเจคจริง

PROJECT OVERVIEW

ระบบให้พนักงานค้นหาและจองห้องประชุมในออฟฟิศ รองรับการดูห้องว่าง จอง ยกเลิก/แก้ไข และ Admin จัดการห้อง

FEATURES

F1: ค้นหาห้องประชุม

ค้นหาห้องว่างตามวันที่ เวลา จำนวนคน อุปกรณ์

F2: จองห้องประชุม

จองห้อง กรอกรายละเอียด เพิ่มผู้เข้าร่วม ส่ง Email แจ้งเตือน

F3: ยกเลิก/แก้ไขการจอง

ยกเลิกหรือแก้ไขรายละเอียดการจอง มีเงื่อนไขเวลา

Example · F1

20 / 37

F1: ค้นหาห้องประชุม

Search Meeting Room — ค้นหาห้องว่างตามเงื่อนไข

OBJECTIVE

ให้พนักงานค้นหาห้องประชุมที่ว่างตามวันที่ เวลา และเงื่อนไขที่ต้องการ เพื่อเลือกห้องที่เหมาะสมก่อนทำการจอง

USER STORIES

• ค้นหาห้องว่างตามวันที่และเวลา เพื่อดูว่ามีห้องไหนใช้ได้
• กรองห้องตามจำนวนคนและอุปกรณ์ เพื่อเลือกห้องที่เหมาะสม
• เห็นเวลาแนะนำเมื่อไม่มีห้องว่าง เพื่อเลือกช่วงเวลาอื่นได้

USER FLOW

กดปุ่ม "ค้นหาห้องว่าง" │ ▼ กรอกเงื่อนไข ├─ วันที่ (required) ├─ เวลาเริ่ม - สิ้นสุด (required) ├─ จำนวนคน (optional) └─ อุปกรณ์ (optional) │ ▼ กดค้นหา ├─ พบห้องว่าง → แสดงรายการ → เลือก → ไป F2 └─ ไม่พบ → แนะนำเวลาใกล้เคียง

ACCEPTANCE CRITERIA — เปรียบเทียบ 2 รูปแบบ

แบบตาราง (Checklist)

1. วันที่ และ เวลา เป็น required ถ้าไม่กรอกแสดง error
2. ไม่สามารถเลือกวันที่ย้อนหลังได้
3. เวลาสิ้นสุด ต้อง > เวลาเริ่มต้น
4. ผลลัพธ์แสดงเฉพาะห้องว่าง + เปิดใช้งาน
5. ไม่มีห้องว่าง → แนะนำเวลาใกล้เคียง

แบบ Given / When / Then

Given ผู้ใช้อยู่หน้าค้นหา
When เลือกเวลาเริ่ม 14:00 สิ้นสุด 13:00
Then แสดง error "เวลาสิ้นสุดต้อง > เวลาเริ่ม"

Given ผู้ใช้เลือกวันที่ + เวลาที่ทุกห้องเต็ม
When กดค้นหา
Then แสดง "ไม่มีห้องว่าง" + แนะนำเวลาใกล้เคียง

📝 เปรียบเทียบ: ตาราง — สั้น อ่านเร็ว เหมาะ Sprint Planning & overview | แต่อาจตีความไม่ตรงกัน
Given/When/Then — ละเอียด QA นำไปทดสอบได้เลย รองรับ BDD automation | แต่เขียนนาน ยาวกว่า 3-5 เท่า
💡 ใช้ร่วมกันได้ — ตารางสำหรับ overview, Given/When/Then สำหรับ feature ที่ซับซ้อนหรือต้อง automate test

Example · F2

21 / 37

F2: จองห้องประชุม

Book Meeting Room — จองห้อง กรอกรายละเอียด แจ้งเตือนผู้เข้าร่วม

OBJECTIVE

ให้พนักงานจองห้องประชุมที่ว่าง พร้อมระบุรายละเอียดและผู้เข้าร่วม เพื่อสำรองห้องและแจ้งเตือนทุกคน

USER STORIES

• จองห้องที่ว่างพร้อมระบุหัวข้อและจำนวนคน เพื่อสำรองห้องไว้ใช้
• เพิ่มผู้เข้าร่วมประชุม เพื่อให้ทุกคนได้รับแจ้งเตือน
• ตรวจสอบรายละเอียดก่อนยืนยัน เพื่อป้องกันการจองผิด

USER FLOW

(จาก F1) เลือกห้องแล้ว │ ▼ กรอกรายละเอียด ├─ หัวข้อประชุม (required) ├─ จำนวนคน (required) ├─ เพิ่มผู้เข้าร่วม (optional) └─ หมายเหตุ (optional) │ ▼ Preview → ยืนยัน ├─ สำเร็จ → Booking ID + Email └─ ห้องถูกจอง → เลือกห้อง/เวลาอื่น

ACCEPTANCE CRITERIA — เปรียบเทียบ 2 รูปแบบ

แบบตาราง (Checklist)

1. หัวข้อประชุม + จำนวนคน เป็น required
2. แสดง Preview ก่อนยืนยัน
3. จองสำเร็จ → แสดง Booking ID + ส่ง Email
4. ห้องถูกจองไปแล้ว (race condition) → error + เสนอทางเลือก
5. คนเกินความจุ → warning แต่ยังจองได้

แบบ Given / When / Then

Given เลือกห้อง A ที่ว่าง
When กรอกหัวข้อ "Weekly Standup" + กดยืนยัน
Then จองสำเร็จ แสดง Booking ID + ส่ง Email

Given มีคนจองห้องเดียวกันไปก่อน
When กดยืนยัน
Then แสดง "ห้องถูกจองแล้ว" + เสนอห้อง/เวลาอื่น

📝 เปรียบเทียบ: ตาราง — สั้น อ่านเร็ว เหมาะ Sprint Planning & overview | แต่อาจตีความไม่ตรงกัน
Given/When/Then — ละเอียด QA นำไปทดสอบได้เลย รองรับ BDD automation | แต่เขียนนาน ยาวกว่า 3-5 เท่า
💡 ใช้ร่วมกันได้ — ตารางสำหรับ overview, Given/When/Then สำหรับ feature ที่ซับซ้อนหรือต้อง automate test

Example · F3

22 / 37

F3: ยกเลิก/แก้ไขการจอง

Cancel & Edit Booking — ยกเลิกหรือแก้ไขรายละเอียดที่จองไว้

OBJECTIVE

ให้พนักงานยกเลิกหรือแก้ไขการจองที่มีอยู่ เพื่อปล่อยห้องว่างให้คนอื่นหรืออัปเดตข้อมูลเมื่อแผนเปลี่ยน

USER STORIES

• ยกเลิกการจองที่ไม่ต้องการ เพื่อปล่อยห้องว่างให้คนอื่น
• แก้ไขรายละเอียดการจอง เพื่ออัปเดตเมื่อแผนเปลี่ยน
• เปลี่ยนเวลา/ห้อง เพื่อย้ายไปเวลาที่สะดวกกว่า

USER FLOW

หน้า "การจองของฉัน" → เลือกรายการ │ ├─ กดยกเลิก │ ├─ ≥ 30 นาที → ยืนยัน → ยกเลิก → Email │ └─ < 30 นาที → ไม่ได้ → ติดต่อ Admin │ └─ กดแก้ไข ├─ ≥ 30 นาที → แก้ได้ทุก field │ └─ เปลี่ยนห้อง/เวลา → เช็คว่าง └─ < 30 นาที → แก้ได้เฉพาะหัวข้อ

ACCEPTANCE CRITERIA — เปรียบเทียบ 2 รูปแบบ

แบบตาราง (Checklist)

1. ยกเลิกได้เฉพาะก่อนเริ่ม ≥ 30 นาที
2. < 30 นาที → error + แนะนำติดต่อ Admin
3. ยกเลิกสำเร็จ → ห้องว่างทันที + Email แจ้ง
4. แก้ไข ≥ 30 นาที → แก้ได้ทุก field
5. แก้ไข < 30 นาที → แก้ได้เฉพาะหัวข้อ + หมายเหตุ

แบบ Given / When / Then

Given จองห้อง A เวลา 14:00 ปัจจุบัน 12:00
When กดยกเลิก + ยืนยัน
Then ยกเลิกสำเร็จ ห้องว่างทันที + Email

Given จองห้อง A เวลา 14:00 ปัจจุบัน 13:45
When กดยกเลิก
Then error "เหลือน้อยกว่า 30 นาที" + แนะนำ Admin

📝 เปรียบเทียบ: ตาราง — สั้น อ่านเร็ว เหมาะ Sprint Planning & overview | แต่อาจตีความไม่ตรงกัน
Given/When/Then — ละเอียด QA นำไปทดสอบได้เลย รองรับ BDD automation | แต่เขียนนาน ยาวกว่า 3-5 เท่า
💡 ใช้ร่วมกันได้ — ตารางสำหรับ overview, Given/When/Then สำหรับ feature ที่ซับซ้อนหรือต้อง automate test

Mini Workshop

23 / 37

Mini Workshop: เขียน User Flow & AC

แบ่งกลุ่ม กลุ่มละ 3 คน ทำทั้ง 3 ฟีเจอร์ เขียน Objective / User Story / User Flow / AC ใน FigJam

โจทย์ — ทำทั้ง 3 ข้อ

1. เข้าสู่ระบบ (Login)

ผู้ใช้ Login ด้วย Email + Password
เงื่อนไข:
• มีปุ่ม "ลืมรหัสผ่าน"
• รองรับ Remember Me

2. สมัครสมาชิก (Register)

ผู้ใช้สมัครสมาชิกใหม่
เงื่อนไข:
• กรอก ชื่อ, Email, Password
• ยืนยันตัวตนผ่าน OTP 6 หลัก ส่งไปทาง Email
• OTP หมดอายุใน 5 นาที กดส่งซ้ำได้

3. ออกจากระบบ (Logout)

ผู้ใช้ Logout ออกจากระบบ
เงื่อนไข:
• มี Confirmation dialog ก่อน Logout
• Logout แล้ว clear session ทุก device
• Session หมดอายุอัตโนมัติหลัง 30 นาที

สิ่งที่ต้องเขียน

1. Objective — เป้าหมายของฟีเจอร์ (1-2 ประโยค)
2. User Stories — ผู้ใช้ต้องการทำอะไร เพื่ออะไร
3. User Flow — วาด flow ตั้งแต่ต้นจนจบ
4. Acceptance Criteria — เลือก format ที่ถนัด (ตาราง หรือ Given/When/Then)

FigJam Board

ทำงานใน FigJam ที่ลิงก์นี้:

figma.com/board/.../Management-for-Developers

Checklist

☐ แบ่งกลุ่ม 3 คน ทำทั้ง 3 ฟีเจอร์
☐ เขียน Objective + User Stories
☐ วาด User Flow ครบทุก step
☐ เขียน AC อย่างน้อย 3 ข้อ

Module 4 · Documents

24 / 37

Definition of Ready & Done

DoR = พร้อมเริ่มทำ · DoD = ทำเสร็จจริงๆ — สองด่านที่ทีมต้องตกลงกัน

Definition of Ready (DoR)

☐ User Story เขียนตาม format
☐ Acceptance Criteria ครบ
☐ ผ่าน INVEST Criteria
☐ Estimate แล้ว (Story Points)
☐ ไม่มี dependency ที่ยังไม่ resolve
☐ UI/UX Design พร้อม (ถ้ามี)

ถ้ายังไม่ Ready → ห้ามเข้า Sprint

Definition of Done (DoD)

☐ Code เขียนเสร็จ + Review แล้ว
☐ Unit Test ผ่าน
☐ AC ทุกข้อผ่าน
☐ Deploy ขึ้น staging ได้
☐ Document อัพเดตแล้ว
☐ PO Accepted

ถ้ายังไม่ Done → ห้ามนับว่าเสร็จ

Module 5 · Scope & Prioritization

25 / 37

PRD — Product Requirements Document

เอกสารหลักที่รวมทุกอย่าง: ปัญหา, Solution, Scope, Timeline

Problem & Goal

ปัญหาคืออะไร? ทำไมต้องทำ? KPI วัดความสำเร็จอย่างไร? Target Users คือใคร?

Solution & Scope

Feature ที่ต้องทำ (In-Scope) สิ่งที่ไม่ทำ (Out-of-Scope) User Stories ทั้งหมด

ช่องนี้เติมได้หลังจัดลำดับเสร็จ

Timeline & Release

Milestone แต่ละ Phase Release Plan ว่า Sprint ไหน Dependencies & Risks

PRD FLOW

Research

→

Draft PRD

→

Review

→

Approved

→

Sprint Planning

Module 5 · Scope & Prioritization

26 / 37

โครงสร้าง PRD — เขียนยังไงให้ครบ?

8 ส่วนหลักของ PRD ที่ดี — แต่ละส่วนมีอะไร และ Dev ต้องเช็คอะไร

1 Problem Statement / บทนำ

ปัญหาคืออะไร? ทำไมต้องทำ? สถานการณ์ปัจจุบันเป็นอย่างไร?

Dev เช็ค: เข้าใจ "ทำไม" ก่อน "ทำอะไร"

2 Vision & Goals / เป้าหมาย

วิสัยทัศน์ผลิตภัณฑ์ เป้าหมาย Phase 1 และ Success Metrics ที่วัดได้

Dev เช็ค: มี KPI ที่วัดได้จริงไหม?

3 Scope & Phases / ขอบเขต

ทำอะไรใน Phase นี้ / ไม่ทำอะไร (Out of Scope) / แผนเฟสถัดไป

Dev เช็ค: Out of Scope ชัดเจนไหม?

4 Target Users / กลุ่มเป้าหมาย

ใครใช้? มี Role อะไรบ้าง? แต่ละ Role ต้องการอะไร?

Dev เช็ค: User persona ชัดพอให้ออกแบบ UI ไหม?

5 Functional Requirements

FR-XX แต่ละตัว: วัตถุประสงค์ / ขอบเขต / นอกขอบเขต / Acceptance Criteria

Dev เช็ค: AC ครบไหม? มี Edge Case ไหม?

6 Non-Functional Requirements

Performance / Security / Scalability / Availability / Compliance (PDPA)

Dev เช็ค: มีตัวเลขวัดได้ไหม? ไม่ใช่แค่ "ต้องเร็ว"

7 Technical Architecture

Tech stack / Infrastructure / External Integration / Legacy systems

Dev เช็ค: เข้ากับระบบเดิมไหม? มี constraint ด้าน infra?

8 Constraints & Notes

ข้อจำกัด / Dependencies / Risks / สิ่งที่ต้องตัดสินใจเพิ่ม

Dev เช็ค: มี dependency ที่จะ block งานไหม?

⚠️ ถ้า PRD ขาดส่วนไหน — Dev ต้องถาม PO/BA ก่อนเริ่ม code

Module 5 · Scope & Prioritization

27 / 37

MoSCoW Prioritization

จัดลำดับความสำคัญของ Feature — Must, Should, Could, Won't

M

Must Have

ขาดไม่ได้เด็ดขาด
ถ้าไม่มีคือ product ใช้งานไม่ได้
~60% ของ effort

S

Should Have

สำคัญแต่ไม่ใช่ critical
ถ้าเลื่อนได้ก็เลื่อน แต่ควรมี
~20% ของ effort

C

Could Have

Nice-to-have
ถ้ามีเวลาก็ทำ ถ้าไม่มีก็ไม่เป็นไร
~20% ของ effort

W

Won't Have

ตกลงแล้วว่า ไม่ทำ ใน release นี้
อาจพิจารณาในอนาคต

Workshop 1

28 / 37

Workshop: MoSCoW — โปรเจคกลุ่มของคุณ

ลิสต์ Feature ทั้งหมด แล้วจัดลำดับว่าอะไรจะได้ทำใน Release นี้

โจทย์

ใช้ โปรเจคกลุ่มของตัวเอง โดยอิง Problem & Goal ที่เขียนไว้ใน PRD

1. List feature ทั้งหมดที่กลุ่มคิดออก
2. จัดแต่ละ Feature เข้า M / S / C / W
3. อธิบายเหตุผล — ทำไมจัดแบบนี้?
4. ตรวจสอบ: Must ≤ 60% หรือเปล่า?
5. นำเสนอต่อ "PO" (อาจารย์)

📤 ผลลัพธ์ที่ต้องได้

Feature ชุด Must / Should ที่ตกลงกันแล้วว่าจะทำใน Release นี้
→ เก็บไว้ใช้ต่อใน Workshop 2 ห้ามทิ้ง

เวลา

25 นาที — จัดลำดับ + เตรียมนำเสนอ
15 นาที — นำเสนอ + PO Feedback
5 นาที — สรุป & Debrief

Tips

Must ≤ 60% ของ effort ทั้งหมด
Won't ≠ ไม่สำคัญ แค่ "ยังไม่ใช่ตอนนี้"
ถ้าทุกอย่าง Must → ลองคิดใหม่!

Workshop 2

29 / 37

Workshop: แบ่ง Feature & เขียน User Story

45 นาที — หยิบ Feature ที่ตกลงจะทำจาก Workshop 1 มาแบ่งงาน แล้วลงรายละเอียด

โจทย์

📥 ใช้ของจาก Workshop 1: Feature ชุด Must / Should ที่ตกลงกันแล้ว

1. หยิบเฉพาะ Feature ที่เป็น Must / Should ออกมา (Could / Won't พักไว้ก่อน)
2. แบ่ง assign ว่าใครรับผิดชอบฟีเจอร์ไหน
3. แต่ละคนเขียน User Story + AC ในฟีเจอร์ที่ตัวเองได้รับ
4. วาด User Flow ของฟีเจอร์ที่รับผิดชอบ

✅ Checklist

☐ หยิบมาเฉพาะ Must / Should — ไม่เขียน Story ให้ของที่ไม่ได้ทำ
☐ ฟีเจอร์ที่หยิบมาถูก assign ครบทุกคน
☐ User Story ตาม As a / I want / So that
☐ AC ตาม Given / When / Then
☐ User Flow ครบทุก step ของฟีเจอร์

📤 ผลลัพธ์ที่ต้องได้

Backlog ที่พร้อมลง Jira — Story + AC + Flow ของทุก Feature ที่จะทำ
→ ใช้ต่อใน Workshop 3 Sprint Planning

Module 6 · Jira Guide

30 / 37

โครงสร้างงานใน Jira

จัดระเบียบงานเป็น 3 ระดับ — จากใหญ่ไปเล็ก

📦

Epic

ฟีเจอร์ใหญ่ ใช้เวลาหลายสัปดาห์

เช่น ระบบ Login

📋

Story (User Story)

งานมองจากมุมผู้ใช้ ทำเสร็จใน 1 Sprint

ในฐานะ... ฉันต้องการ...

✅

Subtask

ขั้นตอนย่อยที่ต้องทำให้ Story เสร็จ

เช่น สร้าง UI, เขียน API

Module 6 · Jira Guide

31 / 37

ตัวอย่างโครงสร้าง — ระบบจองห้องประชุม

Epic → Story → Subtask จากตัวอย่างที่เรียนมา

📦 Epic: ค้นหาและจองห้องประชุม
📋 Story: พนักงานค้นหาห้องว่าง
✅ Subtask: สร้าง UI หน้าค้นหา + filter
✅ Subtask: เขียน API search rooms
✅ Subtask: เขียน unit test
📋 Story: พนักงานจองห้องที่ว่าง
✅ Subtask: สร้าง UI ฟอร์มจอง
✅ Subtask: เขียน API create booking
✅ Subtask: จัดการ race condition
✅ Subtask: ส่ง email ยืนยัน

📦 Epic: จัดการการจอง
📋 Story: พนักงานยกเลิกการจอง
✅ Subtask: สร้าง UI รายการจองของฉัน
✅ Subtask: เขียน API cancel booking
✅ Subtask: เช็คเงื่อนไข ≥30 นาที
📋 Story: พนักงานแก้ไขการจอง
✅ Subtask: สร้าง UI แก้ไขข้อมูล
✅ Subtask: เขียน API update booking
✅ Subtask: แยก logic ≥30 นาที vs <30 นาที

Module 6 · Jira Guide

32 / 37

กฎพื้นฐานสำหรับทีม

5 ข้อตกลงที่ทุกคนต้องทำตาม

1

ทุกคนต้องเขียน Story เอง

ห้ามรอ PO เขียนให้

2

อัปเดต Board ทุกวัน

ย้ายสถานะให้ตรงจริง

3

ไม่มีงานนอก Board

ทำอะไรต้องมี task

4

Comment แทนแชท

เก็บ log ใน Jira

5

Story ต้องมี AC

เพื่อให้รู้ว่า "เสร็จ" คืออะไร

Workshop 3

33 / 37

Workshop: Sprint Planning Simulation

60 นาที — ใช้ Backlog จาก Workshop 2 จำลอง Sprint Planning จริงบน Jira / Asana

SIMULATION FLOW

Review Backlog

→

Set Sprint Goal

→

Estimate (Poker)

→

Commit Stories

บทบาท

PO — 1 คน (อาจารย์ / เพื่อน)
SM — 1 คน (facilitate)
Dev — 3-4 คน (estimate & commit)

กติกา

Sprint = 2 สัปดาห์
Team Velocity = 30 SP
ห้ามเอางานเกิน Velocity!

เวลา

10 นาที — PO อธิบาย Backlog
25 นาที — Planning Poker
15 นาที — Commit + สร้าง Board
10 นาที — Debrief

Closing

34 / 37

Key Takeaways

6 สิ่งสำคัญที่ Dev ควรจำกลับไป

Digital Product ต้อง Balance 3 ฝ่าย

Business + Design + Tech — ขาดฟันเฟืองตัวใดตัวหนึ่ง Product ก็ไม่สำเร็จ

เลือก Methodology ให้เหมาะกับบริบท

Scrum ≠ ดีที่สุดเสมอ — Waterfall ก็มีที่ทาง Kanban ก็เหมาะกับงานบางอย่าง

รู้จัก Role = สื่อสารได้ตรงจุด

PM ≠ PO ≠ BA — คุยกับคนที่ถูกต้อง ได้คำตอบที่ถูกต้อง

User Story + AC = ภาษากลาง

เขียนดี = ทีมเข้าใจตรงกัน ลด miscommunication ลดงานซ้ำซ้อน

Estimate ≠ Commitment

Story Points วัด "ความซับซ้อน" ไม่ใช่ "จำนวนชั่วโมง" — เป็นเครื่องมือช่วย plan

Retro = ทีมดีขึ้นได้ทุก Sprint

ไม่มีทีมไหน perfect ตั้งแต่แรก — Retrospective ช่วยให้ดีขึ้นทีละนิด

Closing

35 / 37

Action Items

สิ่งที่ควรทำหลังจบคอร์ส เพื่อนำไปใช้ได้จริง

สัปดาห์นี้

☐ ลอง Sprint Planning กับทีมจริง
☐ เขียน User Story 1 Feature ตาม format
☐ ตั้ง DoR / DoD กับทีม

เดือนนี้

☐ ทำ Retrospective หลังจบ Sprint
☐ ลอง MoSCoW กับ Backlog จริง
☐ ใช้ Planning Poker ใน Sprint Planning

เรียนรู้เพิ่ม

☐ อ่าน Scrum Guide (scrumguides.org)
☐ ลอง Jira / Asana / Linear
☐ ศึกษา Agile Manifesto

เป้าหมาย

☐ สื่อสารกับ PM/PO ได้ดีขึ้น
☐ เข้าใจ Sprint Ceremony ทุกขั้นตอน
☐ เขียน User Story ได้ด้วยตัวเอง

Bonus · Career Toolkit

36 / 37

AI Prompts Strategy — แปลงประสบการณ์เป็น HTML Resume

วิธีใช้: ยิงทีละ Prompt ตามลำดับ ในแชทเดียวกัน — 1 เกลาประสบการณ์ → 2 เพิ่มโปรเจกต์ → 3 แปลงเป็นไฟล์เว็บ

Prompt 1 · Content Transformation

งานเดิม → Transferable Skills (X-Y-Z)

คุณคือ Career Coach ที่เชี่ยวชาญการเขียนเรซูเม่สายเทคสำหรับคนย้ายสายงาน

ตำแหน่งเป้าหมายของฉัน: [Junior Project Manager]
สายงานเดิมของฉัน: [เช่น Sales / Call Center / บัญชี]

ประสบการณ์เดิมแบบดิบ (ยังไม่ได้เรียบเรียง):
"""
[วางประวัติงานเดิมของคุณตรงนี้]
"""

สิ่งที่ต้องการ:
1) วิเคราะห์ Transferable Skills ที่ตรงกับตำแหน่งเป้าหมาย
   (เช่น การประสานงานหลายฝ่าย การจัดลำดับความสำคัญ
    การสื่อสารกับ Stakeholder การวิเคราะห์ข้อมูล)
2) เขียนใหม่เป็น bullet 4-6 ข้อ ด้วยสูตร X-Y-Z:
   "Accomplished [X] as measured by [Y], by doing [Z]"
   - ขึ้นต้นด้วย Action Verb
   - ใส่ตัวเลขให้ได้มากที่สุด
   - หลีกเลี่ยงคำลอย เช่น "มีความรับผิดชอบสูง"
3) ถ้าข้อมูลไม่พอจะใส่ตัวเลข ให้ถามฉันกลับเป็นคำถาม
   ห้ามแต่งตัวเลขขึ้นมาเองเด็ดขาด
4) เขียน Professional Summary 3 บรรทัด อธิบายว่าทำไม
   คนจากสายเดิมถึงเหมาะกับตำแหน่งนี้

ภาษา: ไทยเป็นหลัก คงศัพท์เทคนิคเป็นภาษาอังกฤษ

Prompt 2 · Class Project Integration

งานในคลาส → Key Projects

ต่อจากเดิม ช่วยเพิ่มโปรเจกต์ที่ฉันทำในคลาสเรียน
ให้กลายเป็นหัวข้อ "Key Projects" ในเรซูเม่

รายละเอียดโปรเจกต์ (ดิบ):
"""
ชื่อโปรเจกต์ / โจทย์ที่ได้รับ:
บทบาทของฉัน:
กระบวนการและเครื่องมือที่ใช้:
ชิ้นงานที่ทำออกมา:
ผลลัพธ์หรือสิ่งที่ค้นพบ:
"""

ข้อกำหนด:
1) ตั้งชื่อโปรเจกต์ให้ดูเป็นมืออาชีพ + ระบุ Role และระยะเวลา
2) เขียน 3-4 bullet ตามลำดับ:
   Problem (โจทย์ธุรกิจ) → Action (สิ่งที่ฉันลงมือทำ /
   framework ที่ใช้) → Result / Insight
3) ระบุ Deliverable ที่จับต้องได้ เช่น User Story +
   Acceptance Criteria, Product Backlog, Flowchart,
   Wireframe, Prioritization Matrix
4) ห้ามเขียนให้เข้าใจผิดว่าเป็นงานให้ลูกค้าจริง
   ให้ใช้คำตรงไปตรงมา เช่น "Course Project" หรือ
   "Simulated Business Case" แต่เรียบเรียงอย่างมืออาชีพ
5) แนะนำ Keyword สำหรับระบบ ATS ของตำแหน่ง [PM/PO/BA]
   ที่ควรแทรกเพิ่มในเรซูเม่

Prompt 3 · HTML Generator

เนื้อหาทั้งหมด → index.html

ช่วยสร้างเรซูเม่แบบ Single-Page HTML จากเนื้อหาทั้งหมด
ที่เราเรียบเรียงกันไว้ด้านบน

ข้อกำหนดทางเทคนิค:
1) ไฟล์เดียวจบ ชื่อ index.html เขียน CSS ไว้ใน <style>
   ห้ามใช้ไฟล์ภายนอกหรือ framework ใด ๆ
2) ดีไซน์: สะอาด อ่านง่าย โทนมืออาชีพ
   ใช้สีหลัก 1 สี + โทนเทา ฟอนต์รองรับภาษาไทย
   เว้นวรรคโปร่ง อ่านสบายตา
3) Responsive อ่านได้ทั้งบนมือถือและจอคอมพิวเตอร์
4) ใส่ @media print ให้พิมพ์ลงกระดาษ A4 ได้พอดี
   และ Save as PDF ออกมาสวย
5) โครงสร้างหัวข้อตามลำดับ:
   - ชื่อ + ตำแหน่งเป้าหมาย + ช่องทางติดต่อ + LinkedIn
   - Professional Summary
   - Key Projects
   - Work Experience
   - Skills & Tools
   - Education & Certificates
6) ใส่ <title> และ meta description ให้เหมาะกับการแชร์ลิงก์
7) ส่งออกมาเป็นโค้ดเต็มไฟล์เดียว ที่ก็อปวางแล้วใช้ได้ทันที

Thank You!

ขอบคุณทุกคนที่เข้าร่วม — หวังว่าจะนำไปใช้ในการทำงานจริงได้

Q&A

Feedback