SA-Me.life

พูดง่าย ๆ คือ การไปเก็บโจทย์ ให้ชัดก่อนลงมือสร้างระบบ—จะถาม, จะสังเกต, จะเวิร์กช็อปอะไรก็ได้ ขอแค่ได้คำตอบว่า “ระบบต้องทำ อะไร ให้ ใคร ภายใต้ข้อจำกัดไหน”

ทำไมต้อง Elicitation?

กัน ระบบหลงทาง : ทำเสร็จแล้วใช้ไม่ได้ เพราะเข้าใจกันคนละอย่าง

ลด งบบาน/เดดไลน์ล่ม : เจอ requirement แอบแฝงช้า = ต้องแก้โค้ดแพง

สร้าง ความไว้ใจ : ทุกฝ่ายรู้สึก “เสียงฉันมีค่า”—ยอมจับมือเดินไปทางเดียวกัน

ตัวอย่างแบบไทย  ๆ 

1. “แอปจองคิวร้านก๋วยเตี๋ยว”

สัมภาษณ์เจ้าของร้าน

คำถาม: “เวลาคนแน่นสุดกี่โมง?”

Insight: ช่วงพักเที่ยง 11.30‑13.00 ลูกค้า Work‑From‑Office แห่กันมา → ต้องมีระบบคิวล่วงหน้าภายใน 2 ชั่วโมง

สังเกตคนกิน

เห็นว่าคนไทยชอบ “เพิ่มลูกชิ้น‑ใส่ถั่ว” ต่างกัน → แอปต้องมีช่อง “โน้ตพิเศษ” ต่อจาน

เวิร์กช็อปกับพนักงาน

ให้เสิร์ฟ ลวกเส้น และเก็บเงินลองจำลอง flow บนไวท์บอร์ด → เจอ Pain point “ตอนคิดเงินรวมเส้นเล็ก/ใหญ่สับสน”

สรุป: ระบบต้องแยกประเภทเส้น + มีปุ่มรวมราคาด่วน (กรณี ประเภทเส้นราคาต่างกันนะ )

ผลลัพธ์: ได้ Requirement ว่า

• ลูกค้าสามารถจองคิวล่วงหน้า ≤ 2 ชม.
• จานหนึ่งมี field “หมายเหตุพิเศษ” 100 ตัวอักษร
• ฝั่งพนักงานมีปุ่ม “คิดเงินทันที” + สรุปยอดแยกตามชนิดเส้น

เทคนิคง่าย ๆ เวลา Elicit แบบบ้าน ๆ

เทคนิค	ทำยังไง	เหมาะเมื่อ…
ถาม 5 ทำไม (5 Whys)	ไล่ถาม “ทำไม?” ซ้ำ ๆ จนเจอต้นเหตุจริง	เจอ requirement กว้าง ๆ เช่น “อยากให้เร็ว”
เลียนแบบชีวิตจริง (Shadowing)	นั่งข้าง ๆ ดูเค้าทำงาน 1 วัน	งานที่ผู้ใช้บอกไม่หมด (เช่น flow กระดาษ)
Mind‑map เจาะร่วมกัน	วาดกิ่ง keyword แล้วให้ทุกคนต่อยอด	ต้องการภาพรวมก่อนลงรายละเอียด
Story Card Game	แจก Post‑it ให้ทุกฝ่ายเขียน “ฉันต้องทำอะไร” แล้วเรียงเส้นเวลา	กลุ่มใหญ่ หลายแผนก