SE บทที่ 1 — จากปัญหาสู่ Requirement · สั่งให้ชัด ก่อนที่ AI จะเดาแทนเรา
ใช้ปุ่ม ← → เปลี่ยนสไลด์ได้SE TRACK — MODULE 1 · จากปัญหาสู่ REQUIREMENT
AI สร้างของเก่งมาก — แต่ถ้าโจทย์คลุมเครือ มันจะ "เดา"
สั่ง AI ว่า "ทำระบบแจ้งเตือนสต๊อกให้หน่อย" แล้วมันตอบกลับว่า "I've implemented a basic version based on my assumptions" — ได้ของมาจริง แต่ไม่ใช่ของที่เราต้องการ แล้วต้องนั่งแก้กันอีกสามรอบ ปัญหาไม่ได้อยู่ที่ AI ไม่เก่ง — อยู่ที่โจทย์ที่เราให้มันไป บทนี้สอนวิธีเปลี่ยน "ปัญหาในหัวเรา" ให้กลายเป็น Requirement ที่ AI ทำตามได้ตรงใจตั้งแต่รอบแรก
ไม่ต้องเขียนเอกสารเป็นสิบหน้า — รู้แค่ว่าต้องบอกอะไร AI บ้าง แล้วให้ AI ช่วยร่างเอกสารเองได้เลย
ทำไมต้องรู้
โจทย์คลุมเครือ = จ่ายค่าเดาของ AI ด้วยเวลาของเรา
01AI ไม่ถาม มันเดา
- ข้อมูลไหนที่เราไม่บอก AI จะสมมติเอาเอง (มันเรียกว่า assumption) แล้วลุยต่อทันที
- ของที่ได้ "ถูกตามที่มันเข้าใจ" แต่ผิดจากที่เราต้องการ
02งานงอกเพราะขอบเขตไม่ชัด
- ไม่เคยตกลงว่า "รอบนี้ทำแค่ไหน" — AI ก็แถมของที่ไม่ได้ขอ หรือตัดของที่เราคิดว่าต้องมี
- แก้ไปแก้มา ไม่มีเส้นชัยให้จบงาน
03ตรวจรับไม่ได้เพราะไม่มีเกณฑ์
- AI บอก "done!" — แต่เสร็จของมัน กับเสร็จของเรา คนละเรื่อง
- ถ้าไม่เขียนเกณฑ์ตรวจรับไว้ก่อน เราไม่มีทางรู้ว่า "เสร็จจริง" หน้าตาเป็นยังไง
MENTAL MODEL ประจำบท
Requirement ชัด = AI ทำตามสั่ง · Requirement คลุมเครือ = AI เดาแทนเรา
ทุกช่องว่างในโจทย์ คือช่องให้ AI เติมเอง
Analogy ประจำบท
สั่งงาน AI = สั่งอาหารกับเชฟที่ไม่เคยถามกลับ
สั่งคลุมเครือ"ขอผัดกะเพรา"
- เชฟตัดสินใจแทนหมด: หมูหรือไก่ ใส่ถั่วฝักยาวไหม เผ็ดแค่ไหน ไข่ดาวสุกหรือไม่สุก
- ได้จานที่ "เป็นกะเพราจริง" แต่อาจไม่ใช่จานที่อยากกิน
- ต้องส่งกลับไปแก้ — เสียเวลา เสียของ ทั้งที่เชฟทำตามสั่งเป๊ะ
สั่งชัด"กะเพราหมูสับ ไข่ดาวไม่สุก ไม่ใส่ถั่วฝักยาว เผ็ดน้อย"
- ทุกจุดที่เชฟต้องเดา ถูกปิดด้วยคำสั่งของเรา
- ได้ตรงใจตั้งแต่จานแรก — ไม่ต้องแก้
- แถมตรวจรับง่าย: ชิมแล้วเทียบกับที่สั่งได้ทีละข้อ
บทนี้ทั้งบทคือการเรียนรู้วิธี "สั่งให้ชัด" แบบขวามือ — ศัพท์แต่ละคำที่กำลังจะเจอ คือส่วนประกอบของใบสั่งอาหารที่ดี: บอกว่าหิวอะไร (ปัญหา) อยากได้จานไหน (เป้าหมาย) ไม่เอาอะไร (ขอบเขต) และเกณฑ์ชิมแล้วผ่านคืออะไร
ภาพรวมก่อนเจาะศัพท์
เส้นทางจาก "ปัญหาในหัว" สู่ "แผนที่ AI ลงมือได้"
ใครเดือดร้อน เพราะอะไร กระทบธุรกิจแค่ไหน — "หิว" ก่อนคิดเมนู
ความเปลี่ยนแปลงที่ต้องการเห็น — เลือกจานที่จะสั่ง
ทำอะไร — และตั้งใจ "ไม่ทำ" อะไร — สั่งจานเดียว ไม่เหมาทั้งเมนู
ความต้องการมุมมองผู้ใช้ พร้อมเงื่อนไขตรวจรับที่เช็คได้จริง
AI แปลงใบสั่งเป็นแผน: ทำอะไรก่อน-หลัง ทดสอบยังไง
เอกสารที่รวบ 4 สถานีแรกไว้ในที่เดียว มีชื่อเรียกว่า PRD (Product Requirements Document) — "จะสร้างอะไร เพื่อใคร ทำไม" · ไม่ต้องเขียนเองทั้งหมด: เล่าปัญหาให้ AI ฟัง แล้วสั่ง "ช่วยร่าง PRD ให้หน่อย" ได้เลย — หน้าที่เราคือตรวจว่ามันเข้าใจถูก
ศัพท์ชุดที่ 1 · 6 คำ
ฝั่ง "ตั้งโจทย์ให้ชัด"
PROBLEM STATEMENTคำอธิบายปัญหา
- ปัญหาคืออะไร ใครโดน กระทบธุรกิจยังไง — เขียน 3-4 บรรทัดก็พอ
- เช่น "ของหมดสต๊อกโดยไม่รู้ตัว เดือนละ 2-3 ครั้ง เสียยอดขายช่วงของขาด"
GOAL / OBJECTIVEผลลัพธ์ที่ต้องการ
- อยากเห็นอะไรเปลี่ยนไป เช่น "ไม่มีสินค้าขายดีหมดสต๊อกโดยไม่รู้ตัวอีก"
- ระวัง: goal คือผลลัพธ์ ไม่ใช่วิธีทำ
SCOPE · IN/OUTขอบเขตรอบนี้
- In scope = รอบนี้ทำ · Out of scope = ตั้งใจยังไม่ทำ
- การเขียน out of scope ไว้ คือเกราะกันงานงอกที่ดีที่สุด
REQUIREMENTสิ่งที่ระบบต้องทำ
- ความสามารถที่ต้องมี เช่น "แจ้งเตือนเมื่อสต๊อกต่ำกว่าจุดสั่งซื้อ" (สายเทคนิคเรียกแบบเต็มว่า functional requirement)
- AI: "Could you clarify the requirements?"
NFRเกณฑ์ด้านคุณภาพ
- Non-functional Requirement — ไม่ใช่ "ทำอะไรได้" แต่ "ต้องดีแค่ไหน": เร็วเท่าไร ปลอดภัยแค่ไหน ล่มได้ไหม
- เช่น "แจ้งเตือนต้องมาภายใน 5 นาที"
CONSTRAINT · ASSUMPTIONข้อจำกัด · สมมติฐาน
- Constraint = เปลี่ยนไม่ได้ เช่น "ต้องใช้ LINE OA เดิม งบไม่เกิน 500 บาท/เดือน"
- Assumption = สิ่งที่สมมติว่าจริง ยังต้องเช็ค — AI: "I'm assuming…"
ครบ 6 คำนี้ = ปิดช่องเดาของ AI ไปเกินครึ่ง — เหลือแค่เขียน "ใบสั่ง" ให้ตรวจรับได้ ซึ่งคือศัพท์ชุดถัดไป
ศัพท์ชุดที่ 2 · 6 คำ
ฝั่ง "เขียนใบสั่ง + เกณฑ์ตรวจรับ"
USER STORYใบสั่งมุมมองผู้ใช้
- สูตรสำเร็จ: "ในฐานะ… ฉันต้องการ… เพื่อที่จะ…"
- บังคับให้เราคิดจากคนใช้จริง ไม่ใช่จากฟีเจอร์
ACCEPTANCE CRITERIA · ACเกณฑ์ชิมแล้วผ่าน
- เงื่อนไขที่เช็คได้จริงว่างานชิ้นนี้เสร็จตรงใจ — ผ่าน/ไม่ผ่าน ไม่มีตรงกลาง
- AI: "I'll draft acceptance criteria" — คือมันจะเขียนเกณฑ์ให้เราตรวจก่อนลงมือ
DEFINITION OF DONE · DoDมาตรฐาน "เสร็จ" ของทุกงาน
- เกณฑ์กลางที่ใช้ร่วมกันทุกชิ้น เช่น "ผ่านการทดสอบ + มีคนตรวจแล้ว" (วิธีทดสอบอยู่บท SE6)
- ต่างจาก AC ที่เขียนใหม่ทุกงาน — เดี๋ยวเจอในตารางคู่ศัพท์สับสน
MVPเวอร์ชันเล็กสุดที่ใช้จริงได้
- Minimum Viable Product — ตัดจนเหลือแก่นที่ผู้ใช้จริงใช้แล้วเราได้เรียนรู้
- สั่ง AI ว่า "เอา MVP ก่อน" = ได้ของเร็ว เห็นของจริงแล้วค่อยต่อยอด
PRDเอกสารรวมโจทย์
- Product Requirements Document — รวมปัญหา เป้าหมาย ขอบเขต requirement ไว้ที่เดียว
- เป็น "สัญญาใจ" ระหว่างเรากับ AI ว่ากำลังสร้างอะไร
IMPLEMENTATION PLANแผนลงมือทำ
- เรียงลำดับงานจริง: แก้ไฟล์ไหนก่อน ทดสอบตรงไหน ปล่อยของยังไง
- ควรขอดูก่อนเสมอ เมื่อจะให้ AI ทำงานใหญ่หรือแตะของหลายจุด
ตัวอย่างจริง — ระบบแจ้งเตือนสต๊อกต่ำ: User Story "ในฐานะเจ้าของร้าน ฉันต้องการรับแจ้งเตือนใน LINE เมื่อสต๊อกต่ำกว่าจุดสั่งซื้อ เพื่อสั่งของเติมได้ทัน" · AC: แจ้งภายใน 5 นาทีหลังสต๊อกแตะเกณฑ์ · ข้อความบอกชื่อสินค้า + จำนวนคงเหลือ · ไม่แจ้งซ้ำเกินวันละ 1 ครั้งต่อสินค้า
⭐ หัวใจของบท
ตารางแปลภาษา AI — ได้ยินแบบนี้ ต้องทำยังไง
| AI พูดว่า | กำลังจะเกิดอะไร | เราควรทำอะไร |
|---|---|---|
| "Could you clarify the requirements?" | AI เจอโจทย์คลุมเครือ และเลือกถามแทนที่จะเดา | ✅ สัญญาณดีมาก — ตอบให้ครบ ยิ่งละเอียดยิ่งได้ของตรงใจ |
| "I'm assuming X — correct me if wrong" | AI กำลังเดา และแจ้งสมมติฐาน (assumption) ให้เรารู้ | 🟡 หยุดอ่านตรงนี้ก่อนเสมอ — แก้สมมติฐานตอนนี้ถูกกว่าแก้โค้ดทีหลังมาก |
| "I'll draft acceptance criteria first" | AI จะเขียนเกณฑ์ตรวจรับให้ดูก่อนลงมือทำ | ✅ ดีที่สุด — อ่านทีละข้อ ข้อไหนไม่ตรงใจแก้ตอนนี้เลย |
| "That's out of scope for this task" | สิ่งที่เราเพิ่งขอ อยู่นอกขอบเขตงานรอบนี้ | 🟡 ตัดสินใจเอง: เก็บไว้รอบหน้า หรือสั่งขยาย scope อย่างตั้งใจ — อย่าปล่อยให้งานงอกเงียบ ๆ |
| "I'll also add Y while I'm at it" | AI กำลังแถมของที่ไม่ได้อยู่ในโจทย์ | ⚠️ เบรกก่อน — ของแถมคืองานงอกกลับด้าน ให้ทำเฉพาะที่ตกลง แล้วจดของแถมไว้พิจารณาทีหลัง |
| "I've implemented a basic version" | AI ตีความเองว่า "เวอร์ชันพื้นฐาน" ต้องมีอะไรบ้าง | ⚠️ เทียบกับ AC ทีละข้อ — ถ้าไม่เคยเขียน AC แปลว่าเราไม่มีเกณฑ์ตรวจเลย ต้องกลับไปเขียนก่อน |
| "This meets all the acceptance criteria" | AI อ้างว่างานผ่านเกณฑ์ครบทุกข้อแล้ว | 🟡 อย่าเชื่อคำอ้างเปล่า ๆ — ไล่เช็คเองทีละข้อ (วิธีทดสอบจริงจังอยู่บท SE6) |
สูตรจำเร็ว: AI ถามหรือขอเขียนเกณฑ์ก่อน = ทิศทางดี · AI assume หรือ แถมของ = จุดที่ต้องหยุดอ่านก่อนพิมพ์ "โอเค"
กันหลงทาง
5 คู่ที่คนสับสนบ่อยที่สุด
| คู่ศัพท์ | ต่างกันตรงไหน |
|---|---|
| Acceptance Criteria vs DoD | AC = เกณฑ์เฉพาะของงานชิ้นนั้น เขียนใหม่ทุกงาน · DoD = มาตรฐาน "เสร็จ" กลางที่ใช้กับทุกงานเหมือนกันหมด |
| Output vs Outcome | Output = สิ่งที่สร้างออกมา เช่น ระบบแจ้งเตือนสต๊อก · Outcome = ผลที่เกิดกับธุรกิจ เช่น ของไม่ขาดสต๊อกอีก — สร้าง output สำเร็จแต่ outcome ไม่มาก็เกิดขึ้นได้ |
| Prototype vs MVP | Prototype = ของทดลองไว้ดูแนวคิด/หน้าตา ยังใช้จริงไม่ได้ · MVP = ผลิตภัณฑ์ขั้นต่ำที่ผู้ใช้จริงใช้ได้จริงและให้ข้อมูลกลับมา |
| PoC vs MVP | PoC (Proof of Concept) พิสูจน์ว่า "เทคนิคนี้ทำได้จริงไหม" · MVP พิสูจน์ว่า "ผู้ใช้ต้องการจริงไหม" — คนละคำถามกัน |
| Requirement vs Solution | Requirement = สิ่งที่ต้องได้ ("รู้ทันทีเมื่อสต๊อกต่ำ") · Solution = วิธีทำให้ได้ ("แจ้งผ่าน LINE OA") — บอก requirement แล้วเปิดให้ AI เสนอ solution มักได้ทางเลือกดีกว่าที่เราคิดเอง |
คู่สุดท้ายสำคัญกับการสั่ง AI ที่สุด: ถ้าเราสั่งเป็น solution ทันที ("เขียน Python ต่อ API ตัวนี้") AI จะไม่มีวันบอกว่ามีทางที่ง่ายกว่า — เล่าปัญหาและสิ่งที่ต้องได้ แล้วให้มันเสนอวิธี
QUICK-CHECK · กดดูเฉลย
จริงหรือไม่? — เช็คก่อนปิดบท
1 · "AI ฉลาดอยู่แล้ว บอกสั้น ๆ ว่า 'ทำระบบแจ้งเตือนสต๊อก' เดี๋ยวมันคิดรายละเอียดแทนเราเอง"
ไม่จริง — มันคิดแทนได้จริง แต่คิดจากการเดา ไม่ใช่จากธุรกิจเรา เหมือนสั่ง "ขอผัดกะเพรา" แล้วลุ้นว่าเชฟจะใส่อะไรมา — ทุกช่องว่างในโจทย์คือช่องให้ AI เติมเอง
2 · "Acceptance Criteria กับ Definition of Done คือสิ่งเดียวกัน แค่เรียกต่างกัน"
ไม่จริง — AC เป็นเกณฑ์เฉพาะของงานชิ้นนั้น เขียนใหม่ทุกงาน ส่วน DoD เป็นมาตรฐาน "เสร็จ" กลางที่ใช้กับทุกงานเหมือนกัน
3 · "ถ้า AI ตอบว่า 'that's out of scope' แปลว่าสิ่งนั้นทำไม่ได้"
ไม่จริง — แปลแค่ว่า "อยู่นอกขอบเขตที่ตกลงกันรอบนี้" เราขยาย scope ได้เสมอ แต่ต้องเป็นการตัดสินใจของเรา ไม่ใช่ปล่อยให้งานงอกเอง
KEY TAKEAWAY
Problem = หิวอะไร · Goal = จานที่อยากได้ · Scope = สั่งแค่ไหน · AC = เกณฑ์ชิมแล้วผ่าน
กฎเหล็กประจำบท: "ทุกช่องว่างในโจทย์ คือช่องให้ AI เดา — ปิดช่องเดาด้วย Scope และ AC ก่อนให้ลงมือทุกครั้ง"