อย่าให้ AI เติมช่องว่างใน Requirement—ให้มันสร้าง Open Questions

AI ที่ประกอบ Flow หรือ Requirement ได้ทุกอย่าง อาจกำลังพาเราไปผิดทางอยู่

และนี่เป็นจุดที่อันตรายมาก—ฝันร้ายของ Developer เลยล่ะ 5555—ถ้าเราใช้ AI ช่วยทำงานตั้งแต่ Requirement ไปจนถึง Test Case

สมมติว่ามี User Story เขียนไว้ว่า

ในฐานะลูกค้า ฉันต้องการยกเลิกการจอง เผื่อเปลี่ยนแผนได้เมื่อต้องการ

Acceptance Criteria เขียนแค่ว่า

ลูกค้าสามารถยกเลิกการจองก่อนวันใช้งานได้

ถ้าเราสั่ง AI แค่ว่า

จาก Acceptance Criteria ช่วยสร้าง Test Case ให้ครบ

AI อาจสร้าง Flow ที่ดูดีออกมาให้ทันที

กดปุ่มยกเลิก → ยืนยัน → สถานะเปลี่ยนเป็น Cancelled

อ่านแล้วเหมือน Requirement พร้อมทำต่อมาก แต่จริงๆ แล้วยังมีคำถามที่ไม่มีคำตอบเต็มไปหมด

• ต้องยกเลิกล่วงหน้ากี่ชั่วโมง
• การจองที่จ่ายเงินแล้วคืนเงินอย่างไร
• สถานะไหนยกเลิกได้บ้าง
• ใครมีสิทธิ์ยกเลิก

ถ้า AI เดาคำตอบให้เอง ทีมอาจเอาสิ่งที่เดานั้นไปเขียน Code และ Test ต่อ ซึ่งจะเป็นปัญหาตามมาจน Developer อยากจะกรี๊ด

แต่ปัญหาแทบจะไม่โผล่ตอน AI ตอบเลย มักมาโผล่ตอน QA ทดสอบ ตอน Business มา Review หรือแย่กว่านั้นคือตอนระบบถูกใช้งานจริงแล้ว

กรี๊ดดดด

นั่นแหละ Developer ปวดใจแน่นอน เพราะฉันคือคนแก้ของ

ตองเลยชอบเปลี่ยน Prompt ให้ AI จาก

สร้าง Test Case ให้ครบ

เป็น

สร้าง Test Case จากข้อมูลที่มี และถ้าข้อมูลไม่พอให้สร้าง Open Question ห้ามเดา Business Rule เอง

จากนั้นให้ AI map แบบนี้เลย

Acceptance Criteria → Test Case → Open Question

Open Question ที่ดีควรบอกมากกว่าคำว่า “ข้อมูลไม่ครบ”

1. Missing Rule คืออะไร

เช่น Requirement ยังไม่บอกเวลาสุดท้ายที่ลูกค้าสามารถยกเลิกได้

2. ถ้าเข้าใจผิดจะกระทบอะไรบ้าง

เช่น ลูกค้าอาจยกเลิกหลัง Business เตรียมบริการไปแล้ว หรือระบบอาจคืนเงินผิดเงื่อนไข เป็นไปได้ทั้งนั้น

3. มีตัวเลือกอะไรที่เป็นไปได้บ้าง

เช่น ยกเลิกได้ก่อน 24 ชั่วโมง ก่อนเริ่มวันใช้งาน หรือให้เฉพาะ Admin ยกเลิกหลังเลยเวลา

4. ใครควรเป็นคนรับผิดชอบคำตอบของ Business

คำถามเรื่อง Business Rule ควรกลับไปหา Product Owner หรือเจ้าของ Process ไม่ใช่ให้ Developer หรือ AI เลือกแทน

เมื่อได้คำตอบแล้ว ค่อยบันทึกเป็น Decision และนำกลับไปอัปเดต Requirement จากนั้นจึงสร้าง Test Case ที่ตรวจสอบกฎข้อนั้นจริงๆ

Flow จะกลายเป็น

Requirement → Acceptance Criteria → Test Case → Open Question → Decision

สิ่งที่ตองชอบในวิธีนี้คือ AI ไม่ได้พยายามทำตัวเป็นคนที่รู้ทุกอย่าง

AI ได้ทำหน้าที่ในส่วนที่ตัวมันเองรู้ และเราก็ทำสิ่งที่ AI ไม่รู้—ซึ่งคือ Business Rule ไง

มันช่วยชี้ว่าตรงไหนที่ทีมยังไม่รู้ ก่อนที่ความไม่ชัดนั้นจะกลายเป็น Code

AI ควรช่วยทีมตรวจจับช่องว่างของ Requirement แต่คนที่รับผิดชอบ Business ยังต้องเป็นคนตัดสินใจ

เพราะคำตอบที่ดูสมบูรณ์แต่ตั้งอยู่บน Assumption ผิดๆ อาจทำให้ทีมเสียเวลาทั้งพัฒนา ทดสอบ และกลับมา Rework ของเดิม

Prompt ที่ทีมคุณใช้อยู่ สั่งให้ AI “ตอบให้ครบ” หรือเปิดทางให้มันบอกว่า “ข้อมูลยังไม่พอ” มาแชร์กัน