และทำไม “ขาดไม่ได้” ในทุกโปรเจกต์ไอที

ลองจินตนาการ… มีสะพานหนึ่งทอดข้ามระหว่าง “ฝั่งลูกค้า” ที่พูดภาษา ธุรกิจ กับ “ฝั่งนักพัฒนา” ที่พูดภาษา โค้ด
ถ้าขาดสะพานนี้ — สองฝั่งก็ไม่มีวันเข้าใจตรงกัน!
สะพานนั้นเองคือ System Analyst (SA)

สรุปสั้น ๆ: SA ทำอะไรในหนึ่งประโยค?

“แปล ความต้องการธุรกิจให้กลายเป็น สเปคเทคนิค ที่ Dev สร้างได้จริง — แล้วคอย ประสาน ให้ทุกฝ่ายเดินไปทางเดียวกัน”

หมวก 4 ใบที่ SA ใส่สลับทั้งวัน

หมวก	ทำอะไรบ้าง	ตัวอย่างในชีวิตจริง
นักสืบ (Requirement Detective)	ถามคำถาม, ขุด pain point, จับ requirement ที่ซ่อนอยู่	ทำ “Interview Bingo” ชวนผู้ใช้เล่าปัญหาก่อนจะกลายเป็นฟีเจอร์ใหม่
นักเล่าเรื่อง (Storyteller)	เขียน Use‑Case, User Story, Wireframe ให้ทีมเห็นภาพเดียวกัน	วาด journey map ลูกค้าเข้าเว็บ e‑commerce จาก “เลือกสินค้า → ชำระเงิน”
สถาปนิกระบบ (System Designer)	แปลง requirement เป็น DFD, ER‑Diagram, API Spec	ออกแบบ ER‑D ว่า “ตะกร้าสินค้า” ผูกกับ “คำสั่งซื้อ” ยังไง
ผู้ไกล่เกลี่ย (Mediator)	ประชุมประสาน Dev, QA, PO, ฝ่ายบัญชี ฯลฯ	จัด workshop “3 ไฟจราจร” ให้ทุกฝ่ายโหวตฟีเจอร์ที่ต้องทำก่อน

5 เหตุผลที่ไม่มี SA แล้วโปรเจกต์(มักจะ)พัง

1. Requirement หลุมดำ
   ไม่มีคนถาม “แล้วถ้า … ล่ะ?” ผลคือ Dev ทำเสร็จแต่ใช้ไม่ได้จริง

2.งบ–เวลา บวม
เปลี่ยนสเปกระหว่างทางเพราะคุยไม่ครบตั้งแต่ต้น → ค่าใช้จ่ายพุ่ง

3. Dev vs. User ยกพวกตีกัน
SA คือกรรมการที่ฟังได้ทุกภาษา ลดดราม่า “ทำไมไม่ทำให้แบบนี้!”

4.เอกสารขาด–ต่อไม่ติด
SA เก็บ “ความรู้ระบบ” ไว้เป็นแผนที่ (Spec + Diagram) ใครมาใหม่ก็อ่านต่อได้

5.คุณภาพตก
ด้วย Test Case/Acceptance Criteria ที่ SA ช่วยวางล่วงหน้า ทำให้ QA ตรวจถูกจุด

Check‑List “คุณเหมาะเป็น SA ไหม?”

😎 ชอบ ตั้งคำถาม มากกว่าตอบทันที

🧩 สนุกกับ ต่อภาพใหญ่ จากจิ๊กซอว์หลายแผ่น

🗣️ พูดคุยกับ Dev, User, ผู้บริหาร แล้ว ปรับภาษา ให้เข้าใจกันได้

✍️ เขียน diagram/สรุปให้คนอ่านแล้วร้อง “อ๋อ!”

⚖️ ใจเย็น — รับแรงกดดันทั้งสองฝั่งได้

จำไว้: โปรเจกต์ไอทีไม่ล่มเพราะโค้ดเสมอไป
แต่มักล่มเพราะ “คนไม่เข้าใจกัน” — และนั่นคือเวทีของ System Analyst ✨