และทำไม “ขาดไม่ได้” ในทุกโปรเจกต์ไอที
ลองจินตนาการ… มีสะพานหนึ่งทอดข้ามระหว่าง “ฝั่งลูกค้า” ที่พูดภาษา ธุรกิจ กับ “ฝั่งนักพัฒนา” ที่พูดภาษา โค้ด
ถ้าขาดสะพานนี้ — สองฝั่งก็ไม่มีวันเข้าใจตรงกัน!
สะพานนั้นเองคือ 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 แล้วโปรเจกต์(มักจะ)พัง
- 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 ✨
SA-Me.life 