จาก “อยากได้ Chatbot” สู่ Problem Statement

Why this matters

ทักษะที่แยก BA ออกจากคนจดออเดอร์ คือการไม่หยุดที่คำขอแรก บทนี้แสดงให้ดูทั้งกระบวนการด้วยเคสเดียว

Example from Automotive QA

User บอกว่า:

อยากมี chatbot ตอบเรื่อง defect

BA ไม่ควรหยุดแค่นั้น ต้องถามต่อ:

• ทำไมต้อง chatbot?
• ตอนนี้ถามใคร?
• เสียเวลาตรงไหน?
• คำถามประเภทไหนเยอะ?
• ข้อมูลอยู่ที่ไหน?
• ใครมีสิทธิ์อ่าน?
• ข้อมูล confidential หรือไม่?
• ถ้า AI ตอบผิดเกิดอะไรขึ้น?
• Success วัดจากอะไร?

สิ่งที่คำถามเหล่านี้ขุดเจอ

สุดท้ายอาจพบว่าปัญหาจริงไม่ใช่ “ไม่มี chatbot” แต่คือ:

QA ใช้เวลาเฉลี่ย 25 นาทีในการค้น complaint และ specification จากหลายระบบ

นี่คือ problem statement ที่ดีกว่า เพราะ:

• ระบุ ใคร เจอปัญหา (QA)
• ระบุ อะไร คือปัญหา (ค้นข้อมูลจากหลายระบบ)
• ระบุ ต้นทุน ที่วัดได้ (เฉลี่ย 25 นาทีต่อครั้ง)
• และ ไม่ผูกกับ solution ใด solution หนึ่ง — คำตอบอาจเป็น chatbot, ระบบ search ที่ดีขึ้น หรือแค่จัดเอกสารใหม่ก็ได้

Common Mistakes

• รีบรับคำขอมาเขียน requirement ทันที — ได้ solution ที่ตอบความอยาก ไม่ตอบปัญหา
• ถามแต่ฝั่งเทคโนโลยี ลืมถามเรื่องข้อมูล สิทธิ์เข้าถึง และความเสี่ยง (สามข้อหลังในชุดคำถามข้างบนคือคำถามที่มักถูกลืม)
• เขียน problem statement โดยไม่มีตัวเลข — “ค้นข้อมูลช้า” เถียงได้ แต่ “เฉลี่ย 25 นาที” วัดซ้ำและใช้ตั้งเป้าได้