← กลับ Module 1

Module 1 · Facilitator guide

คู่มือผู้สอน Module 1

Workshop Orientation — จากไอเดียกว้าง ๆ สู่ Project Intake ที่เริ่มวางแผนต่อกับ AI ได้

เป้าหมายของบท

เมื่อจบ Module 1 ผู้เรียนควร:

  1. อธิบายได้ว่าเป้าหมายของ workshop คือ product ที่ตรวจและดูแลต่อได้ ไม่ใช่เพียงเว็บที่เปิดได้
  2. แยกสิ่งที่มนุษย์ต้องตัดสินใจออกจากสิ่งที่ AI ช่วยลงแรงได้
  3. แตกไอเดียเป็น problem, primary user, desired outcome, Primary Success Path, must-have/supporting work, non-goals, risk และ evidence
  4. อธิบายได้ว่า AI ช่วยงานได้ตลอด Product Development Cycle แต่คนยังถือ decision gates
  5. ชี้บทบาทคร่าว ๆ ของ local stack, GitHub, Railway และ domain/DNS ได้
  6. ดาวน์โหลด Project Intake.md ที่ตอบ 8 คำถามของโครงการ ลงรายละเอียด Primary Success Path หนึ่งเส้น และกำหนดงานที่จำเป็นใน must-have พร้อมนำไปแปลงเป็น Product Contract กับ acceptance criteria ใน Module 2

รูปแบบและเวลา

ใช้เวลาประมาณ 85–100 นาทีสำหรับ content และการประกอบ Project Intake ทีละส่วน จากนั้นอาจใช้เวลาเพิ่ม 20–30 นาทีใน kickoff หรือ clinic เพื่อตรวจ scope รายคน Technical setup เป็น guided lab ของ Module 2 เนื้อหามี 23 frames และ cover/checkpoint อีก 2 frames รวม 25 หน้า เดินจากผลลัพธ์ที่ดี → วิธีทำงาน → ตัวอย่าง → Pause ให้คิด project ของตัวเอง → แผนที่ workshop

แผนที่ 25 หน้า

  1. คำถามของ workshop
  2. เว็บเปิดได้ ≠ พร้อมใช้จริง
  3. Production Readiness: product ที่ดีมีอะไรบ้าง
  4. Product Development Cycle (lightweight SDLC)
  5. AI ช่วยแต่ละช่วงของ cycle อย่างไร
  6. Human-in-the-loop และ 4 decision gates
  7. Project Intake: 8 คำถามที่ต้องตอบก่อนสร้าง
  8. ที่มาของ ProudVault: pain-first story จากเหตุการณ์ซื้อหนังสือซ้ำ
  9. Pause 01: Draft Problem Statement ของ project ตัวเอง
  10. Refine Problem Statement ด้วย 3 quality tests โดยไม่ล็อก feature
  11. Refine One Success Path: ตัด precondition, ชื่อหน้าจอ และทางแยกออก
  12. Primary Path และสิ่งที่ต้องพึ่ง: precondition, supporting path, enabling work และ backlog
  13. Pause 02: ร่าง Primary Path หนึ่งเส้นของ project ตัวเอง
  14. รุ่นแรกต้องมีอะไร และอะไรตั้งใจไว้ทีหลัง
  15. Pause 03: คัด Must-have และให้เหตุผลของ Non-goals
  16. Evidence gate: risk และ evidence
  17. คิด Evidence ไม่ออก: เช็ก Risk ด้วย 3 กรณี
  18. Pause 04: กำหนด risk และ evidence ของ project ตัวเอง
  19. กรอก Project Intake form จาก output ทั้ง 4 Pause, ตรวจสรุป 60 วินาที และดาวน์โหลดไฟล์
  20. ทำไม workshop เลือก Rails
  21. Toolchain at a glance
  22. วิธีคิดที่ย้ายไปใช้กับ stack อื่นได้
  23. Product Development Cycle ขนาดเล็กของแต่ละ module
  24. Light readiness for Module 2
  25. Module checkpoint
เวลา กิจกรรม หลักฐาน
0–12 นาที เว็บที่เปิดได้ ≠ พร้อมใช้จริง และ Production Readiness อธิบายว่าทำไม product ต้องพึ่งพาได้และดูแลต่อได้
12–25 นาที Product Development Cycle, บทบาท AI และ Human-in-the-loop แยก AI assistance ออกจาก decision gates ของคน
25–38 นาที ProudVault origin และ Pause 01: Draft Problem Statement ได้ประโยคเหตุการณ์จริงที่ยังไม่เริ่มจาก feature
38–53 นาที Refine Problem Statement, Primary Path, ภาพรวมสิ่งรอบ path และ Pause 02 ได้ Primary Path ที่จบด้วยคุณค่าหลักหนึ่งเส้น
53–63 นาที Must-have, non-goals และ Pause 03 ได้ scope รุ่นแรกที่ยังพาผู้ใช้ไปถึง end state
63–78 นาที Risk–Evidence pairs, Pause 04 และ Unresolved Risk ได้คู่ Risk→Evidence และรู้สถานะเมื่อ Evidence ยังไม่มี
78–85 นาที กรอก output ทั้ง 4 Pause ลง Project Intake form และอ่าน pitch คำตอบ 8 ช่องต่อกันเป็นเรื่องเดียวและดาวน์โหลดเป็น Markdown
85–94 นาที Rails paved road, toolchain และ transferable thinking ชี้บทบาทของ stack และสิ่งที่ใช้ข้าม stack ได้
94–100 นาที Product Development Cycle ของแต่ละ module, light readiness และ checkpoint รู้สิ่งที่ต้องเตรียมก่อน Module 2 โดยไม่ต้อง setup ตอนนี้

Talk track สำคัญ

จาก prototype สู่ product

หลีกเลี่ยงการบอกว่า prototype “ไม่ดี” เพราะการทดลองเร็วเป็นประโยชน์ ให้ชี้ว่าความรับผิดชอบเปลี่ยนเมื่อมีผู้ใช้ ข้อมูล และความคาดหวังเข้ามา

ถามผู้เรียน:

  • ถ้าเว็บเปิดได้ แต่ข้อมูลของผู้ใช้สลับกัน ถือว่าสำเร็จหรือไม่?
  • ถ้า AI เพิ่ม feature ได้ แต่เราไม่รู้ว่าแก้ไฟล์ใด เรากล้าปล่อยหรือไม่?
  • นอกจาก URL เราต้องการหลักฐานอะไรอีก?

Product Development Cycle และ Human–AI decision rights

ก่อนพูดว่า AI ช่วยอะไร ให้ย้ำว่า product ไม่ได้เกิดจาก prompt เดียว แต่เดินเป็นวงจร: เข้าใจปัญหา → กำหนด outcome และ scope → วางแผน → สร้างทีละน้อย → ตรวจหลักฐาน → ปล่อย → ดูแลและเรียนรู้ แล้วจึงพัฒนารอบถัดไป

AI ช่วยเสนอทางเลือก วางแผน เขียน code ตรวจงาน และช่วยวิเคราะห์ evidence ได้ในทุกช่วง แต่มนุษย์ต้องเป็นเจ้าของ direction, scope, risk, acceptance และการตัดสินใจปล่อย

เช็กความเข้าใจด้วยสถานการณ์:

AI เสนอให้เพิ่ม role แบบ admin เพื่อแก้ปัญหา permission ง่ายขึ้น ใครควรตัดสินใจ และต้องถามอะไรต่อก่อนรับแผน?

คำตอบที่ต้องการไม่ใช่ “รับ” หรือ “ไม่รับ” แต่ต้องกลับไปดูว่าใครต้องทำ action ใด ข้อมูลใดเปิดเผยได้ และมีทางที่เล็กกว่าหรือไม่

Direction gate: Problem framing

Pause 01 ให้เพียงวัตถุดิบ หน้า Refine the draft ต้องสอนให้ตรวจคุณภาพร่างด้วยคำถาม 3 ข้อ:

  1. ชี้คนและสถานการณ์จริงได้ไหม: ใครกำลังพยายามทำอะไร และเหตุการณ์เกิดในช่วงใด ไม่ใช้กลุ่มกว้างอย่าง “ทุกคน” หรือ “คนรักหนังสือ”
  2. เห็นผลกระทบที่เกิดขึ้นจริงไหม: เช่น เสียเวลาค้นรูปเก่า ซื้อหนังสือซ้ำ หรือต้องใช้วิธีใดแก้ปัญหาอยู่ในวันนี้ ไม่ใช่เพียงบอกว่า “อยากได้”
  3. ยังเปิดให้เลือกวิธีแก้ได้หรือไม่: บอกผลลัพธ์ที่ผู้ใช้ต้องการโดยไม่ฝังชื่อแอป หน้าจอ ระบบอัตโนมัติ หรือ feature ไว้ในปัญหา

ใช้ before/after ของ ProudVault ให้ผู้เรียนเห็นความต่าง:

  • ยังไม่พร้อม: “คนรักหนังสือต้องการแอปจัดการหนังสือเพื่อไม่ซื้อซ้ำ” — ผู้ใช้กว้าง ไม่บอกว่าเหตุการณ์เกิดเมื่อไร เกิดผลกระทบอย่างไร หรือวันนี้แก้ปัญหาแบบไหน และกำหนดคำตอบเป็นแอปไปแล้ว
  • พร้อมกำหนดทิศทาง: เมื่อคนที่ซื้อและสะสมหนังสือต้องตัดสินใจซื้อขณะอยู่ในร้าน เขาจำไม่ได้ว่ามีเล่มนั้นแล้วหรือยัง จึงต้องค้นรูปเก่าหรือเสี่ยงซื้อซ้ำ และต้องการรู้ว่าตนมีเล่มนั้นหรือไม่เพื่อให้ตัดสินใจได้อย่างมั่นใจ

ก่อนชี้ verdict ด้านล่างของแต่ละกล่อง ให้ผู้เรียนอ่านทั้งสองตัวอย่างแล้วตอบว่า “ตัวอย่างใดทำให้เราเข้าใจคน เหตุการณ์ และผลลัพธ์ที่ต้องการได้ชัดกว่า และเพราะอะไร?” รับเหตุผลจากห้องก่อนจึงค่อยเชื่อมคำตอบกลับไปยัง 3 tests ไม่ต้องทำ interaction สำหรับซ่อนหรือเปิด verdict จริง

ถ้าผู้เรียนเริ่มด้วย “อยากทำแอป booking” ให้ถามว่าเกิดกับใคร เมื่อไร วันนี้เขาแก้ปัญหาอย่างไร และผลลัพธ์ที่ต้องการคืออะไร พร้อมไปต่อเมื่อคนอื่นอ่านแล้วเข้าใจว่าใครกำลังติดขัด เหตุการณ์เกิดขึ้นเมื่อไร และเขาต้องการไปถึงผลลัพธ์ใด โดย statement ยังไม่รีบกำหนดว่าจะสร้าง feature อะไร

ProudVault

เล่า ProudVault จากเหตุการณ์ในร้านหนังสือ ไม่เริ่มจาก model หรือหน้าจอ: ผู้ใช้จำปกที่เคยอ่านรีวิวได้ แต่ไม่แน่ใจว่าเคยสั่งจากช่องทางอื่นหรือยัง จึงคิดว่ายังไม่ได้ซื้อและหยิบไปจ่ายเงิน ก่อนกลับบ้านมาพบหนังสือปกเดียวกันอยู่บนชั้น — และนี่ไม่ใช่ครั้งแรกที่ซื้อซ้ำ

เรื่องเล่าช่วยสร้าง empathy แต่ยังไม่ใช่ขอบเขตของ product ให้หยุดและแยกเรื่องออกเป็น Person, Situation, Pain และ Desired outcome เพื่อชี้ให้ชัดว่าใครเจอปัญหา ปัญหาเกิดเมื่อไร เกิดความติดขัดหรือความเสียหายอะไร และผู้ใช้ต้องการก้าวไปถึงผลลัพธ์ใด โดยยังไม่กระโดดไปเลือก feature จากนั้นจึงเปิด Project Intake ที่กรอกเสร็จแล้วและชี้ให้เห็นความสัมพันธ์:

  1. Problem statement บอกว่าใครติดขัดเมื่อไร
  2. Success path บอกเส้นทางที่สั้นที่สุดไปถึง outcome
  3. Must-have รองรับแต่ละก้าวบน path รวมถึง precondition, supporting path และ enabling work ที่ขาดไม่ได้
  4. Non-goals เก็บไอเดียที่มีประโยชน์ไว้ทีหลัง พร้อมเหตุผลว่าทำไมรุ่นแรกยังพิสูจน์คุณค่าได้โดยไม่มีมัน
  5. Evidence บอกว่าจะตรวจความสำเร็จอย่างไร

Project Intake จบที่ risk และ evidence ไม่ต้องเพิ่ม Human–AI boundary หรือ next smallest step เป็นช่องในเอกสาร ใช้ 4 decision gates เป็น guideline กลางของ workshop: AI ช่วยสำรวจ ร่าง วางแผน สร้าง และตรวจ ส่วนคนเลือกทิศทาง อนุมัติแผน รับหลักฐาน และตัดสินใจปล่อย หาก project มีความเสี่ยงเฉพาะจึงค่อยเพิ่มข้อจำกัดหรือผู้เชี่ยวชาญเป็นกรณีไป

หลัง Intake เสร็จจึงเริ่มรอบถัดไป ใน Module 2 workshop กำหนดก้าวแรกไว้แล้ว คือแปลง Intake เป็น Product Contract และ acceptance criteria ก่อนเริ่มสร้าง ไม่ต้องให้ผู้เรียนคิด next smallest step เป็นช่องถาวรของโครงการ

Feature อย่าง recommendation, social feed, lending และ AI import มีประโยชน์ แต่ยังไม่จำเป็นต่อคำถาม “ฉันมีเล่มนี้แล้วหรือยัง?”

Success Path: ร่างให้ครบ แล้วขีดสิ่งที่ไม่ใช่ path ออก

ย้ำความต่างก่อน: Problem Statement บอกว่าเรากำลังช่วยใครและทำไม ส่วน Success Path เปลี่ยน desired outcome ให้เป็นเหตุการณ์หนึ่งกรณีที่เดินตามและสังเกตได้ตั้งแต่ปัญหาเกิดจนผู้ใช้ได้ผลลัพธ์ เราตั้งใจเลือกเพียงหนึ่งเส้นโดยยังไม่รวมทุกกรณีและทุกทางแยก

เดิน Draft path ของ ProudVault จากซ้ายไปขวา แล้วขีดฆ่าทีละจุดพร้อมเหตุผล:

  • Login เป็น precondition เพราะตัวอย่างนี้สมมติว่าผู้ใช้เดิมมี account และมีข้อมูลหนังสืออยู่แล้ว ให้เขียนกำกับไว้ข้าง path
  • เปิดหน้า My Shelf เป็นชื่อหน้าจอและ navigation ไม่ได้บอกว่าผู้ใช้เข้าใกล้ผลลัพธ์อย่างไรในระดับนี้
  • Add if missing เป็นอีกทางแยกหนึ่ง ควรแยกเป็น supporting path สำหรับเตรียมข้อมูลบนชั้น ไม่ปนกับกรณี “มีแล้ว”

One Success Path ที่เหลือคือ เห็นหนังสือในร้าน → ค้นชื่อหรือ ISBN → เห็นผลว่า “มีแล้ว” → ตัดสินใจไม่ซื้อซ้ำ ให้ชี้ว่าหนึ่งเส้นนี้จะกลายเป็นแกนในการเลือก scope, ทดลอง flow และใช้เป็นหลักฐานในขั้นต่อไป ถ้ายังมีหลายทางแยกหรือจบเพียงชื่อหน้าจอ ให้กลับไปขีดฆ่าต่อ

จาก Primary Path ไปสู่สิ่งที่ Product ต้องพึ่ง

สิ่งที่ขีดออกจาก Primary Path ไม่ได้แปลว่าถูกทิ้ง หน้าถัดไปมีหน้าที่จัดประเภทโดยยังไม่ลงรายละเอียดทุก flow:

  • Primary Success Path: เส้นที่พิสูจน์คุณค่าหลัก รอบนี้ลงรายละเอียดตั้งแต่ trigger ถึง end state
  • Preconditions: สิ่งที่ต้องเป็นจริงก่อน path เริ่ม ระบุให้รู้แต่ไม่นับเป็นขั้น
  • Supporting path: อีก flow ที่เตรียมข้อมูลหรือสภาพให้เส้นหลักทำงาน ระบุชื่อไว้ก่อน
  • Enabling work: ระบบพื้นฐานที่หลาย path ต้องพึ่ง เช่น account, ownership และ search
  • Backlog / later: path หรือความสามารถที่ยังไม่จำเป็นต่อการพิสูจน์คุณค่ารอบนี้

คำตอบพร้อมใช้เมื่อผู้เรียนถามว่าหนึ่ง product มีได้กี่ path:

Product หนึ่งมี Success Path ได้หลายเส้น แต่ใน Module 1 เราลงรายละเอียดเพียง Primary Success Path หนึ่งเส้น ถ้าคน จุดเริ่ม หรือผลลัพธ์เปลี่ยน ให้แยกเป็นอีก path ส่วน precondition, supporting path และ enabling work ให้รู้จักไว้ก่อน แล้วค่อยตัดสินว่าอะไรจำเป็นใน Must-have

ใน ProudVault เส้นหลักคือการค้นแล้วพบว่า “มีแล้ว” เพื่อช่วยตัดสินใจไม่ซื้อซ้ำ การเพิ่มหนังสือที่ยังไม่มีเป็น supporting path, account และการแยกข้อมูลตามเจ้าของเป็น enabling work, ส่วน recommendation และ social อยู่ใน backlog

อ่านตัวอย่างคำตอบให้เห็นว่าส่วนต่าง ๆ เชื่อมกันอย่างไร:

Primary Path ของ ProudVault คือ เห็นหนังสือในร้าน → ค้น → พบว่า “มีแล้ว” → ไม่ซื้อซ้ำ; ก่อนเริ่มต้องมี account และข้อมูลหนังสือ; Supporting Path คือเพิ่มหนังสือเข้าชั้น; ระบบพื้นฐานต้องแยกข้อมูลตามเจ้าของและค้นหาได้อย่างเชื่อถือ

การคิดย้อนกลับช่วยไม่ให้ infrastructure หรือ feature กลบคุณค่าที่ต้องพิสูจน์ แต่ตอนลงมือจริง เราต้องสร้าง enabling work, precondition และ supporting path ตามลำดับที่ Primary Path ต้องพึ่ง

ใน Pause 02 ให้ผู้เรียนร่างก่อนแล้วค่อยขีดฆ่า precondition, ชื่อหน้าจอหรือ navigation, ขั้นที่ไม่จำเป็น และทางแยกอื่น จากนั้นส่งรายละเอียด Primary Path เพียงเส้นเดียว หน้าถัดไปจึงค่อยย้าย precondition, supporting path และ enabling work ที่จำเป็นเข้า Must-have ส่วน backlog ย้ายเข้า Non-goals

Scope: สิ่งที่ต้องมี กับสิ่งที่ตั้งใจไว้ทีหลัง

นิยาม Must-have ด้วยผลกระทบ ไม่ใช่ความรู้สึกว่า feature สำคัญ:

ถ้าไม่มีสิ่งนี้ ผู้ใช้ยังไปถึงผลลัพธ์ที่เลือกได้ไหม? ถ้าได้ ให้ย้ายออกจากรุ่นแรก

ให้ชี้ tag ของ ProudVault ทีละข้อ เพื่อให้เห็นว่า Must-have มาจากหลายแหล่ง:

  • Primary Path: ค้นชื่อหรือ ISBN และเห็นผลว่ามีเล่มนี้อยู่แล้วหรือยัง
  • Precondition: ผู้ใช้มี account และเข้าสู่ระบบแล้ว
  • Supporting Path: เพิ่มหนังสือที่ยังไม่มีเพื่อเตรียมข้อมูลให้การค้นครั้งต่อไป
  • Enabling Work: แยกข้อมูลตามเจ้าของเพื่อไม่ให้ข้อมูลข้ามผู้ใช้

Non-goals ไม่ใช่ไอเดียที่ไม่ดีหรือถูกทิ้งถาวร แต่เป็นสิ่งที่ตั้งใจไว้ทีหลัง ให้ผู้เรียนพูดเหตุผลทุกข้อ เช่น Recommendation ยังไม่จำเป็นต่อคำถาม “มีเล่มนี้แล้วหรือยัง” หรือ Lending ต้องมี rule และ path แยกต่างหาก ถ้าบอกเหตุผลไม่ได้ อาจยังไม่ได้ตัดสิน scope จริง

Risk และ Evidence ต้องมาเป็นคู่

ทุก project ต้องออกแบบ Evidence ของตัวเอง ไม่คัดลอก ProudVault ให้ผู้เรียนเขียนสิ่งที่อาจเกิดขึ้นหรือผิดพลาดเป็น Risk แล้ววาง Evidence ที่พิสูจน์ว่าควบคุม Risk นั้นได้ไว้คู่กัน:

  • Risk 1: ผลค้นหาอาจบอกสถานะผิด ทำให้ผู้ใช้ซื้อซ้ำ Evidence 1: หนังสือตัวอย่างที่รู้ว่า “มี” และ “ไม่มี” เมื่อค้นด้วยชื่อและ ISBN ต้องคืนสถานะถูกต้อง หลักฐานนี้พิสูจน์ Primary outcome ไปพร้อมกัน
  • Risk 2: Account A อาจเห็นหรือแก้ชั้นของ Account B Evidence 2: A ต้องเปิดดูหรือแก้ข้อมูลของ B ไม่ได้ทั้งผ่าน flow และการเข้าถึงรายการโดยตรง

ตรวจสองทิศทางเสมอ: Risk ทุกข้อมี Evidence ที่แสดงว่าถูกควบคุม และ Evidence ทุกชิ้นตอบได้ว่ากำลังพิสูจน์ผลลัพธ์หรือความเสี่ยงข้อใด อย่ารับรายการ test ที่ลอยเดี่ยว

เมื่อ Evidence ยังนิยามหรือเก็บไม่ได้

ย้ำว่าขั้นนี้ให้ผู้เรียน นิยามว่า Evidence แบบใดจึงนับ ยังไม่ต้องมีผลทดสอบจริง ถ้ายังหาไม่ได้ ห้ามช่วยแต่งหลักฐาน ให้ใช้ 3 กรณีก่อนเข้า Pause 04:

  1. Risk ยังกว้างเกินไป — เขียน Risk ให้เป็น failure ที่สังเกตได้ก่อน ไม่ใช่ฆ่า project เช่น “ข้อมูลต้องปลอดภัย” กว้างจนไม่รู้ว่าจะตรวจอะไร แต่ “Account A ต้องไม่เห็นหรือแก้ชั้นของ Account B” ทำให้นิยาม Evidence ต่อได้
  2. รู้ว่าต้องตรวจอะไร แต่ตอนนี้ยังตรวจไม่ได้ — เขียนว่า ยังพิสูจน์ไม่ได้ (Unresolved Risk) ทดลองต่อได้ แต่ยังไม่ปล่อยให้ผู้ใช้จริง
  3. การพิสูจน์ยากหรือผลกระทบสูงเกิน workshop — ลด scope เลือกส่วนเสี่ยงต่ำ เปลี่ยน project หรือให้ผู้เชี่ยวชาญร่วมรับผิดชอบ

หา Evidence ไม่ได้ไม่ใช่ความล้มเหลว แต่เป็นสัญญาณให้ทำ Risk ชัดขึ้นหรือลด scope ก่อน

วิธีเดิน 4 Pause โดยไม่ทำคำตอบแทนผู้เรียน

ให้ผู้เรียนเก็บ output ทุกครั้งไว้ในกระดาษหรือ Project Intake form เดียวกัน เมื่อขึ้น Pause ถัดไป ให้เริ่มจาก output ก่อนหน้าเสมอ เพื่อให้เห็นว่า Intake ถูกประกอบทีละชั้น ไม่ใช่แบบฟอร์มที่ต้องคิดพร้อมกันทั้งหมด

Pause ผู้สอนช่วยด้วยคำถาม Output ที่ต้องเก็บ
01 · Draft Problem Statement “เกิดขึ้นกับใคร เมื่อไร และวันนี้เขาแก้ปัญหาอย่างไร?” ถ้าได้ชื่อ feature ให้พากลับไปหาเหตุการณ์จริง ร่าง Problem Statement ที่ระบุคน เหตุการณ์ สิ่งที่ติดขัด วิธีที่ใช้อยู่วันนี้ และผลลัพธ์ที่ต้องการ
02 · Primary Success Path “ปัญหาเริ่มเมื่อไร ผู้ใช้ทำอะไร และจบตรงไหน?” ให้ขีด precondition ชื่อหน้าจอ และทางแยกออก เส้นลูกศร Primary Path หนึ่งเส้นจาก trigger ถึง end state
03 · Scope “ถ้าไม่มีสิ่งนี้ ผู้ใช้ยังไปถึงผลลัพธ์ได้ไหม?” ตรวจ Primary Path, precondition, supporting path และ enabling work ทีละข้อ Must-have ที่ติดป้ายแหล่งที่มา และ Non-goals อย่างน้อย 3 ข้อพร้อมเหตุผล
04 · Risk & evidence “Risk นี้มี Evidence ข้อใดควบคุม และ Evidence นี้พิสูจน์ Risk ข้อไหน?” Risk → Evidence อย่างน้อยหนึ่งคู่สำหรับ Primary outcome และเพิ่มอีกคู่เมื่อมีความเสี่ยงสำคัญ

ใช้เวลา 3, 4, 4 และ 5 นาทีตามลำดับ ให้สัญญาณเมื่อเหลือหนึ่งนาที AI ช่วยตั้งคำถาม เปรียบเทียบทางเลือก หรือทำให้ข้อความชัดขึ้นได้ แต่ผู้เรียนต้องยืนยันว่าประสบการณ์ ขอบเขต ความเสี่ยง และเกณฑ์ผ่านเป็นสิ่งที่ตนยอมรับ หลัง Pause 04 หน้า Studio มีหน้าที่กรอกและเกลา output เดิมใน Project Intake form ไม่ใช่เริ่มนิยาม project ใหม่อีกครั้ง ให้ผู้เรียนอ่านสรุป 60 วินาทีที่ form ประกอบขึ้น ตรวจว่าทั้ง 8 ข้อต่อกันเป็นเรื่องเดียว แล้วดาวน์โหลด Project Intake.md เก็บไว้ใช้ต่อใน Module 2

ทำไมเลือก Rails และ stack นี้

อธิบายว่าเป้าหมายไม่ใช่การพิสูจน์ว่า Rails “ดีที่สุด” แต่คือการสร้างพื้นที่เรียนรู้ที่ทุกคนมีแผนที่ร่วมกัน:

  • Rails ใช้ convention ทำให้ route, controller, model และ view มีตำแหน่งที่คาดเดาได้
  • Monolith ทำให้ผู้เรียนตาม request จาก browser ผ่าน business rule ไปถึง database ได้ใน codebase เดียว
  • PostgreSQL เป็นฐานข้อมูล relational ที่เหมาะกับ ownership, relation และ constraint ที่ workshop ต้องสอน
  • Server-rendered HTML และ Turbo ทำให้สร้าง interaction สำหรับ product จริงได้โดยยังมองเห็น request/response ชัด
  • Git, staging และ production path เดียวกันทำให้ทุกคนใช้ checkpoint และวิธีตรวจแบบเดียวกัน

ย้ำว่า Rails เป็นข้อจำกัดที่ตั้งใจเลือกเพื่อลดภาระการตัดสินใจ ไม่ใช่คำตอบบังคับสำหรับทุก product

สิ่งที่นำไปใช้กับ stack อื่นได้

ให้ผู้เรียนลองแทน Rails ด้วย Django, Laravel, Phoenix หรือ stack ที่สนใจ แล้วถามคำถามเดิม:

  • Product กำลังแก้ problem อะไร และ success path คืออะไร?
  • Request เข้ามาทางไหน และ business rule ถูกตัดสินตรงไหน?
  • ข้อมูลถูกเก็บอย่างไร เป็นของใคร และใครมี permission?
  • เราจะตรวจการเปลี่ยนแปลง ทดสอบ critical flow และเก็บ checkpoint อย่างไร?
  • เมื่อ release มีปัญหา จะสังเกตและถอยกลับอย่างไร?

ชื่อเครื่องมือเปลี่ยนได้ แต่ responsibility และ evidence ไม่หายไป

Development tool ไม่ใช่ main stack

ใช้แผนที่หนึ่งหน้าเพื่อช่วยผู้เรียนแยกคำที่มักถูกพูดรวมกัน:

  • Codex, Claude Code และ Antigravity เป็นเครื่องมือช่วยพัฒนา ไม่ใช่ framework ที่ production ต้องรัน
  • IDE และ terminal เป็น workspace ที่ใช้ทำงานกับ project บนเครื่อง
  • Rails กับ PostgreSQL คือ application stack ที่รันทั้ง local และ production
  • Git เป็น version control ในเครื่อง ส่วน GitHub เป็น remote repository
  • Railway เป็น deployment platform ส่วน domain/DNS เป็นทางเข้าที่ชี้ผู้ใช้ไปยัง deployment

ยังไม่อธิบาย installation, command หรือ configuration ในหน้านี้ เป้าหมายคือให้ผู้เรียนชี้ได้ว่าเครื่องมืออยู่ช่วงใดของเส้นทางเท่านั้น

สิ่งที่ตั้งใจยังไม่สอนใน Module 1

  • Dependency, Ruby, PostgreSQL และ local server เป็น guided setup ใน Module 2
  • การอ่าน diff, Git checkpoint และ GitHub workflow ฝึกใน Module 4
  • Browser DevTools, logs, environment variables และ Railway staging ฝึกใน Module 5
  • Production database, domain, DNS, backup และ rollback ฝึกใน Module 9
  • Dependency update และ maintenance rhythm อยู่ Module 10

หากผู้เรียนถามล่วงหน้า ให้ชี้ตำแหน่งบนแผนที่และบอก module ที่จะได้ทำ ไม่เปิดบทใหม่กลาง orientation

Design system อยู่ตรงไหน

Module 1 ตัดสินว่าเรากำลังช่วยใครและ success path คืออะไร ส่วน Module 2 รับ Project Intake.md ไปสร้าง PRODUCT_PLAN.md, acceptance criteria, site/system map, DESIGN.md และ BUILD_PLAN.md

ยังไม่ให้เลือกสี font หรือ component ใน Module 1 เพราะงานออกแบบต้องรับใช้ flow ที่เลือกแล้ว ไม่ใช่เป็นตัวกำหนดปัญหาแทนเรา

ความเข้าใจผิดที่พบบ่อย

  • “ยิ่งมี feature มาก รุ่นแรกยิ่งดูคุ้ม” — รุ่นแรกมีหน้าที่พิสูจน์ว่า core journey มีคุณค่า
  • “ให้ AI ช่วยคิด requirement ทั้งหมดได้” — AI เสนอได้ แต่ไม่รู้บริบท ความเสี่ยง และสิ่งที่ผู้สร้างยอมรับแทนผู้สร้าง
  • “เอาไว้ค่อยคิดเรื่องข้อมูลคนอื่น” — ownership เป็นส่วนหนึ่งของ problem และ risk ตั้งแต่ต้น แม้ implementation จะอยู่ Module 3
  • “ทำ responsive web แปลว่ากำลังทำ mobile app” — workshop ทำ web app ที่ใช้บนมือถือได้ แต่ไม่ทำ native mobile app
  • “ต้องเลือก design system ก่อนจึงจะเริ่มได้” — เลือก problem และ flow ก่อน แล้วค่อยกำหนด design contract ใน Module 2

วิธีตรวจ Project Intake

ให้ผู้เรียน pitch ภายใน 60 วินาที แล้วตรวจเจ็ดข้อ:

เกณฑ์ ผ่านเมื่อ
Problem specificity มีคน สถานการณ์ pain และ desired outcome ไม่ใช่แค่ชื่อประเภทแอป
Primary Success Path ลงรายละเอียดเส้นหลักหนึ่งเส้น จบใน 3–5 ขั้น และมี end state
Real priorities Must-have ครอบคลุมขั้นของ Primary Path, precondition, supporting path หรือ enabling work ที่ขาดไม่ได้ และทุกข้อผ่านคำถาม “ถ้าไม่มี path ยังจบไหม?”
Meaningful non-goals ระบุของที่น่าทำแต่ยังไม่จำเป็นอย่างน้อยสามข้อ พร้อมเหตุผลที่เลื่อนไปทีหลัง
Appropriate risk ผลเสียจาก bug อยู่ในระดับที่ cohort รับผิดชอบและทดสอบได้ภายในเวลาของ workshop
Evidence pairing Risk ทุกข้อมี Evidence ที่ควบคุม และ Evidence ทุกชิ้นระบุผลลัพธ์หรือความเสี่ยงที่พิสูจน์
Unresolved status ไม่มีความเสี่ยงผลกระทบสูงที่ยังบอกไม่ได้ว่าจะตรวจอย่างไร; ข้อที่ผลต่ำและย้อนกลับได้ถูกติดป้าย prototype-only

ให้ผลเป็น Pass หรือ Revise พร้อมคำแนะนำให้ตัดหรือทำให้เฉพาะเจาะจงหนึ่งเรื่อง อย่าออกแบบ solution ทั้งหมดแทนผู้เรียน

Exit ticket

ให้ผู้เรียนกรอก Project Intake form แล้วอ่านสรุปที่ประกอบจากคำตอบภายใน 60 วินาทีโดยไม่เปิดรายการ feature:

ฉันกำลังสร้าง ________ สำหรับ____________ เพื่อใช้ในช่วงที่__________________ เพื่อให้เขา________________ รุ่นแรกจะพาเขาผ่าน Primary Path: ____________________ สิ่งที่ต้องมีคือ ______________ ส่วนสิ่งที่ยังไม่ทำคือ ______________ ความเสี่ยงหลักคือ __________________ และเราจะถือว่ารุ่นแรกผ่านเมื่อมีหลักฐานว่า ____________________

ให้ผู้เรียนดาวน์โหลด Project Intake.md ก่อนออกจากห้อง ไฟล์นี้คือ learner artifact ที่ Module 2 จะเปิดใช้ต่อ

จากนั้นให้ชี้บน toolchain map ว่า project จะเริ่มบนเครื่อง อยู่ใน GitHub และไป live ที่ Railway ผ่าน domain โดยยังไม่ต้องอธิบายวิธี setup

ให้ผู้เรียนอธิบายเพิ่มผ่าน 4 decision gates ว่า AI ช่วยงานชนิดใดได้ และจุดใดที่คนยังต้องเป็นผู้อนุมัติ โดยไม่เพิ่มคำตอบเหล่านี้เป็นช่องใน Project Intake

ผู้เรียนที่ลงรายละเอียด Primary Path หนึ่งเส้น กำหนด must-have/supporting work และ non-goals ได้ ผ่าน risk/evidence check ไม่มีความเสี่ยงผลกระทบสูงที่ยังบอกไม่ได้ว่าจะตรวจอย่างไร และเข้าใจ decision gates พร้อมไป Technical Bootstrapping Lab เพื่อพิสูจน์เครื่อง จากนั้น Module 2 จึงแปลง Intake เป็น Product Plan และ acceptance criteria ก่อนเริ่ม project จริง

Technical Bootstrapping Lab (Day 1 Part B)

ส่วนนี้เป็น lab ที่ต่อท้าย Module 1 checkpoint โดยแยกจาก 25 classroom frames และ Project Intake ที่ผู้เรียนส่งแล้ว เป้าหมายไม่ใช่สร้าง ProudVault หรือสอน database design แต่ทำให้ผู้เรียนผ่าน setup จริงหนึ่งรอบ: AI, bounded folder, AI browser capability, Ruby, Rails และ PostgreSQL บนเครื่องเดียวกัน

ให้ใช้เอกสาร Technical Bootstrapping Lab เป็น learner handout หลัก

เวลาและผลลัพธ์

วางเวลา 90–150 นาที หลังช่วง orientation 85–100 นาที และควรเผื่อ setup clinic อีก 20–30 นาทีสำหรับผู้ที่ติด blocker ซ้ำ

เวลาโดยประมาณ Facilitator flow หลักฐาน
0–20 นาที Connect bounded workspace + AI browser ผู้เรียนบอกขอบเขต AI และ browser capability ได้
20–35 นาที Inspect เฉพาะข้อมูลใน Version Matrix Machine Readiness Report แบบ Current → Target
35–55 นาที AI เสนอ plan; ผู้เรียนตอบ Blocking Decisions และอนุมัติ Approved Plan มี verifier, stop rules และไม่มี hidden risky change
55–125 นาที AI execute แผนต่อเนื่อง; หยุดเฉพาะ verifier fail หรือ deviation Ruby/Rails/PostgreSQL และ sandbox ผ่านตามแผน
125–150 นาที Human + AI browser รัน Final Readiness Check และหยุด server PASS หรือมี Clinic Handoff

เวลาจริงต่างกันตาม lane และสภาพเครื่อง อย่าตัด verifier ทิ้งเพื่อให้ทันเวลา หากวันแรกมีเวลาน้อย ให้จบด้วย Clinic Handoff ไม่ให้ผู้เรียนเดา setup ต่อคนเดียว

Facilitator flow

  1. ประกาศ supported lane ก่อนเริ่ม — ระบุ OS/architecture ที่ workshop รองรับและวิธีติดตั้งของ lane นั้นชัด ๆ เช่น macOS หรือ Windows ผ่าน WSL2. เครื่องนอก lane ไม่ใช่ความผิดของผู้เรียน แต่ต้องเข้าคลินิก แทนการลองคำสั่งจากหลายระบบปฏิบัติการ
  2. ย้ำ productive struggle — ผู้เรียนควรเห็น error จริงและให้ AI ช่วยอ่านมัน แต่การวนผิดซ้ำไม่ใช่เป้าหมาย. ให้แก้หนึ่งสาเหตุแล้วรัน verifier เดิมซ้ำ; blocker เดิม 20–30 นาทีให้ handoff เข้า clinic พร้อม log.
  3. ให้ Inspect ก่อน Install — AI ต้องรายงานเฉพาะ machine state ที่ใช้เทียบ Version Matrix ห้ามไล่ PID, plist, log, data directory หรือเครื่องมือทุกตัวที่ไม่มี หากข้อมูลพอวางแผนให้จบที่ READY FOR INSTALL PLAN.
  4. ใช้ Workshop Version Matrix เดียวกัน — Ruby 4.0.6, Rails 8.1.3 และ Bundler 2.7.2 เป็น exact versions; PostgreSQL ล็อก major 18.x และรับ minor security/bugfix ล่าสุดของ supported package manager. Git ใช้ supported version ของ lane และ Technical Bootstrapping Lab ยังไม่ติดตั้ง Node.js.
  5. ใช้ Human Plan Gate ครั้งเดียวให้มีคุณภาพ — ผู้เรียนตอบ Blocking Decisions ไม่เกิน 3 ข้อและตรวจ target, existing data/service, risky changes, verifier และ stop conditions ก่อนอนุมัติทั้งแผน. หลังอนุมัติ AI ทำทุก phase ต่อเนื่องได้ ไม่ต้องให้ผู้เรียน copy command ทีละบรรทัด.
  6. หยุดเมื่อแผนเปลี่ยน ไม่ใช่ทุก phase — verifier ผ่านให้เดินต่อ; verifier fail หรือต้องเพิ่ม/เปลี่ยน command, target, role, port, config หรือ service ต้องหยุดขออนุมัติใหม่. คำว่า “ไม่ติดตั้ง Node” ไม่อนุญาตให้ถอนหรือ disable Node เดิม.
  7. สอน PostgreSQL เป็นสามชั้นผ่าน evidence — psql client, PostgreSQL server/service, และ database ที่ Rails สร้างต้องผ่าน connection และ db:prepare; ไม่ต้องแตกเป็น lesson ติดตั้งแยก.
  8. ทำ sandbox และปิดด้วยหลักฐาน — ใช้ rails new rails-pg-sandbox --database=postgresql; ห้ามเริ่ม ProudVault. ผู้เรียนและ AI browser ต้องเห็น Rails Welcome page, server log ต้องเห็น request, แล้วหยุด server. ผลสุดท้ายเป็น TECHNICAL READINESS: PASS หรือ Clinic Handoff.

สิ่งที่ผู้สอนต้องคอยกัน

  • ห้ามแทนที่ system Ruby หรือเพิ่ม version manager ตัวที่สองโดยไม่เข้าใจ state เดิม
  • ห้ามใส่ password, token หรือ credential ใน prompt, source control หรือ screenshot
  • ห้ามใช้ superuser เป็น shortcut, แก้ authentication config ทั้งเครื่อง หรือเปลี่ยน port/role แบบสุ่ม
  • ห้าม AI เพิ่ม --force, overwrite, unlink, destructive command หรือ role/config ใหม่ที่ไม่มีใน approved plan
  • ห้ามลบ sandbox เดิมเพื่อสร้างทับ; ให้เปลี่ยน target หลังคนอนุมัติ
  • ก่อนคำสั่งสร้าง, reset หรือ ลบ database ต้องให้ AI พูดชื่อ target database, role, host และ port
  • ห้ามแก้ test ให้ผ่านด้วยการลบ test และห้ามเปลี่ยนเป็น SQLite เพื่อข้าม PostgreSQL error
  • ห้ามปล่อยให้ผู้เรียนที่ติด error เดิมนานเกิน 20–30 นาทีทำต่อเงียบ ๆ; clinic handoff ต้องมี error ล่าสุด, สิ่งที่ลอง, และ verifier ที่จะรันซ้ำ

ความเข้าใจผิดที่ควรแก้ทันที

ความเข้าใจผิด คำอธิบายที่ผู้สอนให้
“AI ต่อกับเครื่องแล้ว จึงทำอะไรก็ได้ถูก” AI ยังต้องอยู่ใน folder และ permission ที่เราระบุ; คนต้องตรวจ path, plan และผลที่เปลี่ยน
“มี psql แปลว่า Postgres พร้อม” psql เป็น client; ต้องตรวจ service ที่รันและ connection ของ role ที่ Rails จะใช้ด้วย
“server รันแล้ว แปลว่า database พร้อม” Rails Welcome page พิสูจน์ web server; db:prepare และ test ต่างหากที่พิสูจน์ Rails database path
“เจอ error ก็ลอง install ทุกอย่าง” เก็บ error จริง แยกชั้นที่พัง แก้ทีละสาเหตุ และรัน verifier เดิมซ้ำ
“sandbox นี้คือ ProudVault เริ่มต้น” sandbox มีไว้พิสูจน์เครื่องและทิ้งได้; Module 2 เริ่ม product จาก Project Context ที่อนุมัติแล้ว

Day 1 technical readiness gate

ให้ผ่านหรือเข้าคลินิกตามหลักฐานต่อไปนี้:

  • AI coding tool ทำงานใน bounded folder ที่ผู้เรียนตรวจแล้ว
  • AI browser capability เปิดและตรวจ localhost ได้
  • Ruby, Bundler และ Rails ที่ workshop รองรับทำงานได้
  • PostgreSQL client มี, server/service รัน, และ Rails role เชื่อมได้
  • Rails sandbox สร้างด้วย PostgreSQL (ไม่ใช่ SQLite), db:prepare สำเร็จ และ baseline tests ผ่าน
  • ผู้เรียนและ AI browser เห็น Rails Welcome page; server log แสดง request
  • Final Readiness Check แสดง TECHNICAL READINESS: PASS

ผู้ที่ gate ยังไม่ผ่านไม่ควรถูกตีความว่า “ตามไม่ทัน Module 1” เพราะ Product Readiness และ Technical Readiness เป็นหลักฐานคนละชุด: Project Intake ยังคงเป็น checkpoint ของ Module 1 classroom ส่วนผล BLOCKED เป็น Clinic Handoff และ Module 2 จะรัน live preflight ใหม่.