เราก็ออกแบบปุ่มไว้กลางจอ
ทำไมเขาถึงไปจิ้มมุมล่างขวา? หรือกด “ย้อนกลับ” แทนที่จะ “บันทึก”!?

🧠 เพราะ “คนใช้จริง” ไม่ได้คิดเหมือน “คนออกแบบ”

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

🧩 เหตุผลที่ “เค้าไม่กดตามที่เราคิดไว้”

1. 👀 มองไม่เห็น

• อยู่ในจุดที่หลุดจากสายตา
• มุมล่างเกินไป / อยู่ล่าง banner

2. 🤔 ไม่เข้าใจว่าปุ่มนั้นทำอะไร

• ใช้คำไม่คุ้น เช่น “ยืนยันผลลัพธ์” = งง
• ไอคอนไม่สื่อ เช่น รูปแว่นขยาย = กดแล้วส่งข้อมูล?

3. 🧠 สมองเดาว่าต้องไปอีกที่

• ปุ่มบันทึกอยู่บนขวา แต่เค้าคิดว่าอยู่ข้างล่าง (เพราะทุกแอปก็เป็นแบบนั้น)

4. 💢 ประสบการณ์เก่าโดนหลอก

• เคยกด “ตกลง” ในแอปอื่น แล้วข้อมูลหาย
• เลยไม่กล้ากดอะไรง่าย ๆ

🛠 วิธี SA & UX ฟังเสียงคนใช้แบบไม่ต้องมโน

วิธี	ทำยังไง	ใช้เมื่อไหร่
👀 Observe	แอบดูเขาใช้งานจริง (หรือ screen record)	ตอนทำ UAT / ทดลองใช้จริง
❓ ถามเขาตรง ๆ	“พี่คิดว่าปุ่มนี้ทำอะไร?”	ตอนเขาเริ่มงง
🧪 A/B Testing	ลองเปลี่ยนสี / ตำแหน่ง แล้วดูคนคลิกอะไร	สำหรับฟีเจอร์สำคัญ
🧠 เดาแบบคนไม่รู้	ลองให้คนที่ไม่เคยใช้เลยมาเล่นดู	ก่อนปล่อยจริง

“ความเข้าใจผิด” ของผู้ใช้
ไม่ใช่ความผิดของผู้ใช้
แต่มันคือ “เบาะแส” ว่า flow ไหนยังต้องปรับ

สรุป

• อย่าคิดแทนผู้ใช้ว่าเค้าจะ “กดตรงนี้สิ!”
• ออกแบบ UI แล้ว “ลองให้แม่ใช้ดู” ถ้าแม่งง = คนอื่นก็งง
• SA ที่ดีต้องไม่แค่รู้ flow… แต่ต้อง “เดาใจคนใช้” ให้แม่นด้วย 🧠❤️

แต่มาจาก Flow ที่คนวางไว้แบบมีสติ!

เพราะ “รู้สึกใช้ง่าย” มันไม่ได้เกิดขึ้นเพราะเทพประทาน
แต่มันคือ “ดีไซน์ที่รู้ว่าคนคิดอะไรอยู่” ก่อนเขาจะคิด

🎯 UX คืออะไร (แบบไม่ UX-UX มาก)

UX (User Experience) = “ประสบการณ์ตอนใช้งาน”

เวลาคนใช้ระบบแล้วพูดว่า “อ๋อ เข้าใจเลย” หรือ “คลิกแล้วมันลื่น” → นั่นแหละ UX ดี

✋ SA ต้องสน UX ไหม?

ต้อง!
แม้ SA จะไม่ใช่ UX Designer
แต่ SA คือคนที่ “กำหนด flow ทุกอย่างตั้งแต่แรก”

ถ้า flow งง → UX ก็งง
ถ้า flow ลื่น → UX ก็ดีโดยไม่ต้องแต่งเพิ่ม

🔧 UX ที่ดี เริ่มจาก Flow ที่ดี

Flow งง ๆ	Flow ลื่นไหล
สมัคร = 5 ขั้นตอน, ไม่มีบอกว่าเสร็จเมื่อไหร่	สมัครง่ายใน 3 step พร้อม progress bar
ฟอร์มเด้ง error แบบไม่รู้ว่าผิดตรงไหน	ชี้จุดที่ผิด + ข้อความช่วยเข้าใจ
ปุ่มเยอะจนไม่รู้จะกดอันไหน	ปุ่มเดียว ชัดเจน ทำสิ่งเดียว

Flow ที่คิดดี = User ใช้แล้วไม่หงุดหงิด
Flow ที่คิดข้าม = Dev ต้องมาแก้ UI วุ่นวาย

🔍 เทคนิค “SA สาย UX” แบบง่าย ๆ

1. คิดแบบผู้ใช้ก่อนคิดแบบระบบ
   ถามตัวเองว่า “ตอนนั้นคนจะงงอะไร?”
2. ลองเดิน flow ด้วยตัวเอง (หรือหลอกเพื่อนให้ลอง)
   เช่น สมัคร, จ่ายเงิน, ยกเลิก แล้วจดว่าติดตรงไหน
3. ใส่ใจข้อความเล็ก ๆ
   UX ไม่ได้มาจากดีไซน์สวย แต่จากคำว่า “ยืนยัน”, “แก้ไข”, “สำเร็จ” ที่ชัดเจน
4. เขียน Flow พร้อม Scenario
   “ถ้าผู้ใช้ใส่ข้อมูลไม่ครบ → ระบบควรเตือนยังไง?”
   “ถ้ากดจ่ายเงินแล้วเน็ตหลุด → เกิดอะไรขึ้น?”

🍜 ยกตัวอย่างแบบร้านก๋วยเตี๋ยว

Flow งง	Flowดี
ลูกค้าต้องยืนรอคิว → สั่งเอง → จ่ายที่เคาน์เตอร์ → รับบัตรคิว → งง	ลูกค้าใช้แอป → เลือกเมนู → จ่ายเงิน → ได้แจ้งเตือนตอนอาหารใกล้เสร็จ

💬 สรุป

• UX ไม่ใช่เรื่องของโชค แต่คือ “การออกแบบประสบการณ์ที่คนใช้งานจะรู้สึกว่า ลื่น”
• SA ที่เก่ง UX ไม่ใช่แค่รู้ว่า “ทำอะไรได้” แต่รู้ว่า “คนจะคิดอะไรตอนกดสิ่งนั้น”
• ถ้าเริ่มจาก Flow ดี UX ก็แทบไม่ต้องแก้ทีหลัง

User:

“อยากให้ระบบมันแจ้งเตือนตอนมีของหมดนะ”

SA:

(คิดในใจ)
ถ้าจำนวนสินค้าในคลัง < 10 → ระบบส่ง Noti → ถึงผู้ดูแลคลัง → ผ่าน LINE และอีเมล

🧠 วิธีฟังแบบ SA: ไม่ใช่แค่ฟัง แต่ “ถอดรหัส”

สิ่งที่ User พูด	SA ควรถาม	เพื่อให้ได้ Flow
“อยากให้มันง่าย ๆ อะ”	ง่ายแบบไหน? ขั้นตอนไหน?	Step ที่ต้องลด / รวมปุ่ม / ตัดการยืนยัน
“อยากให้ระบบมันแจ้งเลย”	แจ้งเมื่อไหร่? ใครเห็น?	Trigger และ Target
“อยากให้มีประวัติย้อนหลัง”	ต้องเก็บอะไร? กี่วัน?	เงื่อนไขเก็บ log / แสดงข้อมูล
“อยากให้มันเร็ว ๆ”	ช้าเพราะอะไร? ช้าตรงไหน?	จุดที่ใช้เวลา / ปรับ logic

🛠️ เทคนิคแปลง “คำพูด” เป็น “Requirement Flow”

1. Highlight คำกริยา เช่น “กด”, “ส่ง”, “แจ้ง”, “ตรวจสอบ”
   → ใช้เป็น Step
2. หา Subject + Object
   เช่น “User กดปุ่ม → ระบบบันทึกข้อมูล”
   → พร้อมวาด Sequence / Flowchart ได้เลย
3. ถาม 3 คำถามทองคำ
   • • ใครทำ?
     • ทำอะไร?
     • ทำเมื่อไหร่?
4. เขียน Flow แบบใช้ได้จริงก่อนคิด UI

UI เปลี่ยนได้ Flow ต้องชัดก่อน

✏️ ตัวอย่าง

User:

“เวลาคนสมัครเข้ามา อยากให้มีคนอนุมัติด้วย ไม่ให้เข้าอัตโนมัติ”

SA เขียนเป็น Flow:

1. ผู้ใช้กรอกแบบฟอร์มสมัครสมาชิก
2. ระบบบันทึกสถานะ = “รออนุมัติ”
3. แอดมินเห็นรายการใหม่ → กดอนุมัติ / ปฏิเสธ
4. ถ้าอนุมัติ → ส่งอีเมลแจ้งผล

สรุป

User ไม่ผิดที่พูดลอย ๆ — มันคือธรรมชาติ

SA ไม่ต้องเป็นหมอดู — แต่ต้องเป็น “คนตีความที่ดี”

Requirement ที่ดี = ไม่ใช่แค่ตรง แต่ ต้องเป็น Flow ที่ Dev เขียนต่อได้ทันที

เขียนโค้ดไม่เป็น ไม่ใช่ปัญหา
ถ้ามองระบบเป็น เห็น flow ออก — คุณก็เป็น SA ได้!

🎯 แล้ว System Designer / SA ทำอะไร?

System Designer หรือ System Analyst คือ “คนออกแบบระบบ” ที่ทำให้ ไอเดียของลูกค้า กลายเป็น ภาพชัด ๆ ที่ Dev ทำต่อได้

📌 ไม่ใช่คนเขียนโค้ดเอง
📌 แต่เป็นคนแปล “ภาษาคน” ให้เป็น “ภาษาระบบ”

🔧 งานหลักของ SA มีอะไรบ้าง?

งาน	ตัวอย่าง
📋 เก็บ Requirement	คุยกับผู้ใช้: อยากได้ระบบอะไร? เจอปัญหาอะไร?
🎯 วิเคราะห์ความต้องการ	แยกให้ออกว่าอะไรจำเป็น, อะไรเป็นฟีเจอร์เสริม
🛠️ ออกแบบระบบ	วาด Flow, Use Case, ER Diagram, Wireframe
🗣️ สื่อสารกับทีม	อธิบาย requirement ให้ Dev, Tester เข้าใจตรงกัน
✅ ตรวจสอบผลลัพธ์	เช็คว่าสิ่งที่ Dev ทำ ตรงกับที่ออกแบบไว้หรือไม่

🤔 แล้วต้อง “เขียนโค้ดไม่เป็นเลย” ได้ไหม?

ได้!
แต่… ต้องเข้าใจโครงสร้างระบบคร่าว ๆ เช่น

• Client / Server คืออะไร
• API คืออะไร ใช้ตอนไหน
• Database เก็บข้อมูลยังไง
• การทำ Flow ที่มี condition, loop, validation

เพราะเป้าหมายของ SA ไม่ใช่เขียนโค้ด…
แต่คือ “ออกแบบให้คนอื่นเขียนได้ตรง”

ความสามารถสำคัญของ System Analyst

ทักษะ	ทำไมถึงสำคัญ
การตั้งคำถาม	เพื่อขุดลึกโจทย์ที่แท้จริง
การฟังอย่างเข้าใจ	เพื่อสื่อสารกับ User / Dev ให้ตรง
การคิดเป็นระบบ	เพื่อวาง flow ที่ไม่หลงทาง
การสื่อสารด้วยภาพ	เพราะภาพ 1 ภาพ = แทนคำอธิบาย 1 หน้า

📦 สรุปแบบเร็ว ๆ: ทั้งคู่คือ “มาตรฐานการพัฒนาซอฟต์แวร์”

มาตรฐาน	เหมาะกับใคร?
CMMI	องค์กรใหญ่ / โปรเจกต์ซับซ้อน / ต้องวัดผลคุณภาพเชิงลึก
ISO 29110	ทีมเล็ก / ฟรีแลนซ์ / สตาร์ทอัพ / ราชการ / SME

🧠 จุดตั้งต้นต่างกัน

หัวข้อ	CMMI	ISO 29110
🎯 เป้าหมาย	ยกระดับ “กระบวนการ” แบบต่อเนื่อง	วาง “ระบบทำงาน” สำหรับทีมขนาดเล็กให้เป็นมืออาชีพ
🧱 โครงสร้าง	แบ่งเป็น 5 ระดับ (Level 1–5)	แบ่งเป็น 2 กระบวนการ: PM (Project Management) + SI (Software Implementation)
🏢 เหมาะกับ	บริษัทขนาดกลาง-ใหญ่	ทีม ≤ 25 คน / โปรเจกต์ไม่ซับซ้อนมาก
📊 ความเข้มข้น	สูง – ต้องมีเอกสาร, ประเมิน, ตรวจสอบ, เก็บ Data	ปานกลาง – เน้นใช้งานจริง ไม่เน้นเอกสารเยอะ

🧪 ตัวอย่างเอกสารที่ทั้งสองมาตรฐานเน้น

หมวด	CMMI	ISO 29110
Requirement	ต้องมี Traceability Matrix / GAP Analysis	Use Case, Requirement List เข้าใจง่าย
การวางแผน	มี Project Plan, Risk Management Plan	มี Plan เบื้องต้น เช่น ตารางคน/เวลา/งาน
การพัฒนา	Document ทุก Phase: Design, Dev, Test	ทำ Flow, ERD, Test Plan ใช้งานจริง
การวัดผล	มี Metrics ชัดเจน เช่น Defect Rate, Cycle Time	ไม่บังคับวัดผลเชิงลึก แต่ควรมี Checklist
การปรับปรุง	Continuous Process Improvement	Lessons Learned หลังโปรเจกต์จบก็เพียงพอ

🧭 คำแนะนำสำหรับทีมที่ยังไม่เคยใช้มาตรฐาน

สถานการณ์	ควรเริ่มจาก…
ทีม ≤ 10 คน, ทำงาน agile	ISO 29110 จะเบาและเหมาะกับการปรับใช้
โปรเจกต์ภาครัฐ / ประมูล TOR	ดูว่าระบุ CMMI หรือไม่ (มักจะต้องมี Level 2 ขึ้นไป)
อยากมีมาตรฐานภายใน เริ่มง่าย ๆ	ISO 29110 เป็นจุดเริ่มที่ดี
ทีมโตขึ้น / มีหลายทีม / ต้องการวัดผล	ค่อยยกระดับสู่ CMMI ระดับ 2 หรือ 3

---

✅ สรุปสั้น ๆ

เรื่อง	CMMI	ISO 29110
ความซับซ้อน	สูง	กลาง-ต่ำ
ใช้กับทีมเล็ก	ไม่ค่อยเหมาะ	เหมาะมาก
เน้นปรับปรุงกระบวนการ	✅	✅
เน้นใช้งานจริง	บางส่วน	✅ มาก
ใช้เวลาปรับตัว	นาน	ไวกว่า
เริ่มต้นฟรีได้เลย	❌	✅ (มีเทมเพลตจากหลายประเทศ)

มาตรฐานที่ช่วยให้ “ทีมซอฟต์แวร์เล็ก” → เติบโตแบบ “องค์กรใหญ่”

💡 CMMI ย่อมาจาก…

Capability
Maturity
Model
Integration

คือกรอบแนวทาง (Framework) ที่ช่วยให้องค์กรพัฒนา “ความสามารถ” ในการ จัดการกระบวนการทำงานให้ดีขึ้นเรื่อย ๆ

🧭 เป้าหมายของ CMMI คืออะไร?

• ✅ ทำงานซ้ำได้ → มีมาตรฐาน
• ✅ ลดความผิดพลาด → ตรวจสอบได้
• ✅ พัฒนาระบบได้เร็วขึ้น → วางแผนดีกว่าเดิม
• ✅ ทีมโตขึ้น → กระบวนการไม่พัง

🪜 CMMI มีกี่ระดับ?

CMMI แบ่งระดับ “ความโตของกระบวนการ” ออกเป็น 5 ขั้น

ระดับ	ชื่อระดับ	ลักษณะทีม
1️⃣ Initial	ทำแบบตามใจ	งานสำเร็จเพราะคนเก่ง ไม่ใช่เพราะระบบ
2️⃣ Managed	วางแผน & จัดการได้	มีเอกสาร, จัดการ Requirement และ Project ได้ดี
3️⃣ Defined	กระบวนการชัดเจน	ใช้ขั้นตอนเดียวกันทั้งองค์กร มี standard
4️⃣ Quantitatively Managed	วัดผลได้	มี Data ในการวัด/ปรับกระบวนการ
5️⃣ Optimizing	ปรับปรุงต่อเนื่อง	ใช้ข้อมูลเพื่อพัฒนาอย่างสม่ำเสมอ

🎯 ส่วนใหญ่ทีมทั่วไปตั้งเป้าไปที่ระดับ 2 หรือ 3 ก็เพียงพอในการทำงานและผ่านงานประมูลหลายภาครัฐ

🛠️ CMMI ใช้กับใคร?

• 📌 Software Development
• 📌 IT Services
• 📌 Product & Process Development
• 📌 Government Project (TOR มักอ้างอิง CMMI Level)

🎯 แล้วเกี่ยวอะไรกับ SA/Dev/PM?

บทบาท	ต้องเข้าใจเรื่องนี้เพื่อ…
SA / BA	เขียน Requirement / Flow / Doc ให้เป็นระบบ
Dev	พัฒนาให้ตรง spec ที่วางตามกระบวนการ
Tester	มีแผน Test ที่สอดคล้องกับ Requirement
PM	วางแผน / ติดตามงานตามมาตรฐาน
Org Lead	พัฒนาทีมให้เข้าระบบ CMMI ได้จริง

✅ อยากเริ่มใช้ CMMI ต้องทำยังไง?

1. 🔍 ตรวจสอบว่าตอนนี้เราอยู่ “ระดับไหน”
2. 📋 วาง Process ที่จำเป็น: Requirement → Design → Dev → Test → Deploy
3. 🧪 เก็บ Evidence เช่น Document, Log, Test Plan
4. 👨‍🏫 อบรมทีมให้เข้าใจ และทำตามได้จริง
5. 📈 ประเมินซ้ำ + ปรับปรุงต่อเนื่อง

💡 คำจำกัดความแบบบ้าน ๆ

คำย่อ	ย่อมาจาก	คือใครในโปรเจกต์
BA	Business Analyst	“ล่ามธุรกิจ” ที่เข้าใจโจทย์จากฝั่ง User / ลูกค้า แล้วแปลงเป็น Requirement
SA	System Analyst	“นักออกแบบระบบ” ที่แปลง Requirement ให้กลายเป็น Flow, Data, Spec ที่ Dev สร้างได้จริง

🎯 เปรียบเทียบแบบเห็นภาพ

หัวข้อ	BA	SA
โฟกัสหลัก	ความต้องการของธุรกิจ	โครงสร้างของระบบ
ทำงานกับใคร	User, Stakeholder, PM	Dev, Tester, Architect
ผลลัพธ์หลัก	BRD, Use Case, Scope	Flow, DFD, ERD, SRS
ถนัดเรื่อง	การฟัง, ตั้งคำถาม, สื่อสาร	การคิดแบบระบบ, เชื่อมโยงข้อมูล
เครื่องมือ	Excel, Miro, Notion	Draw.io, DB Designer, Postman
คำถามที่เจอบ่อย	“ทำไมถึงต้องมีระบบนี้?”	“ข้อมูลวิ่งจากไหนไปไหน?”

🍜 ตัวอย่างแบบไทย ๆ: ระบบจองคิวโรงอาหาร

ขั้นตอน	BA ทำอะไร	SA ทำอะไร
1. สัมภาษณ์ User	คุยกับนักเรียน-พนักงาน: อยากให้ระบบช่วยอะไร	–
2. เก็บ Requirement	สรุปว่า “อยากจองล่วงหน้า”, “ไม่อยากรอคิว”	–
3. วาง Use Case	เขียนว่ามีผู้ใช้ “จองคิว”, “ดูสถานะ”, “ยกเลิก”	เริ่มออกแบบ Flow → ใครทำอะไร เมื่อไหร่
4. วางระบบ	–	วาด DFD, ออกแบบฐานข้อมูล, คุยกับ Dev
5. ส่งเอกสาร	สรุป BRD ส่งให้ทีม	สรุป SRS + Diagram ส่งให้ Dev

✅ แล้วใครสำคัญกว่า?

คำตอบคือ “ทั้งคู่ต้องมี” เพราะ…

• ถ้ามีแต่ BA → เข้าใจธุรกิจ แต่ระบบใช้ไม่ได้
• ถ้ามีแต่ SA → ระบบเทพ แต่ไม่ตอบโจทย์จริง

💡 ในบางทีม (เช่น โปรเจกต์เล็ก) → คนเดียวอาจรับบททั้ง BA + SA ก็ได้
แต่ต้อง “สลับหมวก” ให้เป็น!

เขียนดี = Dev ไม่ต้องเดา
Tester ไม่ต้องถาม
ลูกค้าไม่ต้องแก้!

💡 ก่อนอื่น: Requirement คืออะไร?

สิ่งที่ระบบ “ต้องทำ” หรือ “ต้องมี” เพื่อให้ตอบโจทย์ของผู้ใช้งาน
เขียนให้ชัดตั้งแต่ต้น = งานเร็ว ลดแก้ ลดบั๊ก!

📦 Requirement ที่ดีควรเป็นยังไง?

อักษร	ความหมาย	ตัวอย่างดี	ตัวอย่างไม่ดี
Specific	ชัดเจน ไม่คลุมเครือ	“ผู้ใช้สามารถกดปุ่มยืนยันเพื่อบันทึกข้อมูลได้”	“ทำให้มันเวิร์ก ๆ หน่อย”
Measurable	วัดได้	“ระบบต้องตอบสนองภายใน 3 วินาที”	“โหลดให้เร็ว”
Agreeable	ทุกฝ่ายเข้าใจตรงกัน	“แสดงชื่อผู้ใช้ตามชื่อในระบบ HR”	“ชื่อผู้ใช้จากระบบนู่นนั่นแหละ”
Realistic	ทำได้จริงในเวลาที่มี	“รองรับผู้ใช้ 100 คนพร้อมกัน”	“รองรับ 1 ล้านคนในงบ 2 วัน”
Testable	ทดสอบได้ มีเงื่อนไขชัด	“ถ้าไม่ได้กรอกอีเมล ระบบขึ้นข้อความ ‘กรุณากรอกอีเมล’”	“ป้องกัน error ทุกกรณี”

🔍 ตัวอย่าง Requirement ที่เขียนดี vs ไม่ดี

❌ เขียนไม่ดี	✅ เขียนใหม่ให้เข้าใจง่าย
ระบบแจ้งเตือนตอนมีปัญหา	“ระบบส่งอีเมลแจ้งผู้ดูแล หากเซิร์ฟเวอร์มี Error 500 ภายใน 1 นาที”
ทำระบบจองห้องให้ใช้ได้	“ผู้ใช้สามารถจองห้องประชุมผ่านฟอร์ม โดยเลือกวันที่, เวลา, และห้อง”
อยากให้หน้า UI ใช้ง่าย	“UI ต้องแสดงชื่อห้อง, ความจุ, และปุ่ม ‘จอง’ ชัดเจนบนจอมือถือ”

🧠 เทคนิคเขียน Requirement ให้เป๊ะ

• ✅ เริ่มด้วยคำว่า “ผู้ใช้สามารถ…” / “ระบบต้อง…“
• ✅ แยก Requirement เป็นข้อ ๆ (ไม่เขียนรวบ)
• ✅ ใช้ศัพท์กลาง ไม่ใช่คำเฉพาะที่แค่ Dev เข้าใจ
• ✅ ระบุเงื่อนไข, ข้อยกเว้น, ขอบเขตให้ครบ
• ✅ ถ้ามี flow ซับซ้อน → แนบ Diagram

---

🎯 Requirement ที่ดี = ประหยัดเวลา x3

ฝ่าย	ได้ประโยชน์อะไร
👩‍💻 Dev	เขียนโค้ดตรงเป้า ไม่ต้องเดา
🧪 Tester	เขียน Test Case ได้ทันที
🧑‍💼 ลูกค้า	ตรวจสอบว่า “ใช่สิ่งที่ต้องการ” หรือไม่

🧠 ก่อนอื่น… ทำไมต้องมีหลายเอกสาร?

เพราะ “1 ระบบ” = มีคนหลายบทบาท (ลูกค้า, Dev, Tester, ผู้บริหาร)
แต่ละคนต้องการ “ระดับความลึก” ที่ต่างกัน
เอกสารจึงต้อง แบ่งตามมุมมอง เพื่อสื่อสารได้เข้าใจง่ายสำหรับแต่ละฝ่าย

🔍 เปรียบเทียบ BRD vs FRD vs SRS

หัวข้อ	BRD (Business Requirement Document)	FRD (Functional Requirement Document)	SRS (Software Requirement Specification)
📌 คืออะไร	สรุปความต้องการของธุรกิจ	สรุปฟีเจอร์ที่ระบบต้องทำ	รวมทุก requirement เพื่อ Dev & QA
👥 ใช้กับใคร	ผู้บริหาร, ลูกค้า	SA, BA, Dev, Tester	Dev, Tester, SA, Architect
🧠 โฟกัสอะไร	“เราต้องการอะไร?”	“ระบบต้องทำอะไรให้ใครบ้าง?”	“ระบบจะทำสิ่งนั้นได้ยังไง?”
📄 มีอะไรในเอกสาร	เป้าหมายธุรกิจ, Stakeholder, KPI, ขอบเขต	Use Case, Flow, Business Rule, UI Mockup	Flow ละเอียด, Data Dictionary, Interface Spec
🧪 ระดับความลึก	พอเข้าใจแนวทาง	เห็นภาพการใช้งานจริง	พร้อมนำไปพัฒนาได้เลย
📝 ใครเขียน	BA / SA	BA / SA	SA / Tech Lead / System Architect

📌 สรุปจำง่าย ๆ

เอกสาร	คำจำกัดความจำง่าย
BRD	“ลูกค้าอยากได้อะไร”
FRD	“ระบบต้องทำอะไรให้ลูกค้า”
SRS	“Dev ต้องเขียนอะไรเพื่อให้ระบบทำงานได้จริง”

✅ เมื่อไหร่ควรเขียนทั้ง 3?

• ถ้าเป็น โปรเจกต์ขนาดใหญ่ → เขียนครบ BRD + FRD + SRS
• ถ้าเป็น โปรเจกต์ภายใน / พัฒนาเร็ว → อาจรวม FRD + SRS ไว้ในเอกสารเดียว
• ถ้าเป็น งานราชการ / ยื่นประกวดราคา → BRD ชัด = ชนะครึ่งหนึ่งแล้ว

💬 ปิดท้าย

เอกสารที่ดี = ทุกฝ่ายเข้าใจตรงกัน
ไม่ต้องเยอะ แต่ต้อง “ครบ ประเด็น”
เขียน BRD เพื่อ “สื่อสารกับคน”, เขียน SRS เพื่อ “สื่อสารกับเครื่อง”
SA ที่ดี = แปลทุกมุมมองให้เจอกันตรงกลาง 🧩

ในระบบราชการ — เข้าใจเร็ว ทำงานง่าย ไม่หลงระบบ

💡 Domain Knowledge คืออะไร?

คือ “ความเข้าใจเฉพาะด้าน” เกี่ยวกับเรื่องนั้น ๆ เช่น กฎหมาย, ขั้นตอน, โครงสร้าง, ภาษาราชการ

ในโลก IT มันคือ “เบื้องหลังที่ไม่เขียนอยู่ใน requirement“
แต่ถ้าไม่รู้… จะออกแบบระบบได้ไม่ตรง หรืออาจ “ตีความผิด”

🎯 ทำไมต้องเข้าใจ Domain ในระบบราชการ?

ถ้าไม่เข้าใจ	จะเจอปัญหาแบบนี้…
🔹 ไม่รู้ว่าใครมีอำนาจอนุมัติ	สร้างระบบให้ผิด flow จริง
🔹 ไม่เข้าใจคำราชการ	อ่าน requirement แล้วตีความผิด
🔹 ไม่รู้ข้อบังคับ/ระเบียบ	ระบบที่ออกแบบอาจขัดกับกฎหมาย
🔹 ไม่รู้รหัส-หน่วยงานย่อย	เขียน lookup ผิด, filter พัง

📌 ตัวอย่าง Domain Knowledge ที่พบบ่อย

หมวด	ตัวอย่าง
โครงสร้างองค์กร	สำนักงานใหญ่ ↔ ภาค ↔ จังหวัด ↔ อำเภอ ↔ ตำบล
ขั้นตอนงาน	เบิกจ่าย → ลงนาม → ตรวจสอบ → อนุมัติ
กฎหมาย & ระเบียบ	PDPA, ระเบียบเบิกจ่ายเงินราชการ, TOR
คำราชการ	“คำสั่ง”, “บันทึกข้อความ”, “หนังสือเวียน”
รหัสอ้างอิง	รหัสหน่วยงาน, รหัสประเภทบุคลากร, รหัสงบประมาณ
ศัพท์เฉพาะ	“กกต.”, “ผอ.”, “หนังสือเวียนด่วนที่สุด”

🧠 วิธีเรียนรู้ Domain อย่างไว

วิธี	ทำยังไง	เหมาะเมื่อ…
📄 อ่าน TOR + เอกสารเดิม	วง keyword, โครงสร้าง, flow งาน	เพิ่งเข้าทีม, ไม่เคยทำระบบนี้
🧑‍🏫 ถาม “พี่เจ้าหน้าที่”	ฟัง flow ที่ใช้งานจริง ๆ ไม่ใช่บนกระดาษ	อยากเข้าใจงานภาคสนาม
🔍 สังเกตเอกสารจริง	ดูฟอร์มที่ใช้งาน เช่น แบบคำขอ, แบบฟอร์มราชการ	เก็บ requirement เพิ่มเติม
🧭 ทำ “Glossary”	รวมศัพท์เฉพาะ + คำอธิบายไว้ใช้ทั้งทีม	ลดความเข้าใจคลาดเคลื่อน
🧾 จัด workshop ถอด Flow	ให้เจ้าหน้าที่ช่วยวาดขั้นตอนการทำงานจริง	มีหลายฝ่ายเกี่ยวข้อง

✨ ตัวอย่างง่าย ๆ

ระบบ “ขออนุมัติเดินทางราชการ”
ถ้าไม่รู้ว่า “ต้องแนบคำสั่งกระทรวง”, “ต้องอนุมัติล่วงหน้า 7 วัน” และ “ต้องมีใบเบิกค่าเดินทางแยก”
→ คุณอาจออกแบบระบบให้ขาดข้อมูลสำคัญ และเบิกไม่ได้จริง ❌

📦 Checklist ถามก่อนลงระบบหน่วยงานรัฐ

1. มีหน่วยงานไหนเกี่ยวข้องบ้าง? (ส่วนกลาง-ภูมิภาค?)
2. มีขั้นตอนตามกฎหมาย/ระเบียบอะไร?
3. มีฟอร์มหรือเอกสารแนบอะไร?
4. ใครเป็นคนอนุมัติ? มีกี่ลำดับ?
5. ระบบต้องรองรับภาษาราชการหรือไม่?
6. มีรหัสหน่วยงาน/รายการอ้างอิงเฉพาะไหม?