SA-Me.life

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

คำย่อ	ย่อมาจาก	คือใครในโปรเจกต์
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 ก็ได้
แต่ต้อง “สลับหมวก” ให้เป็น!