OnProud
Module 01 Workshop Orientation

OnProud Workshop · Rails Track · Module 01

Build It.Own It.

Beyond Vibe Coding

Build with Clarity. Ship with Confidence.

จาก Vibe Coder เราจะก้าวไปเป็น Product Builder ที่สร้าง web product ให้มีคนใช้จริง และต่อยอดระบบให้รองรับการเติบโตได้อย่างไร?

Workshop สำหรับคนที่ไม่มีพื้นฐาน developer หรือเคยลอง vibe coding แล้วพบว่า AI สร้างได้เร็ว แต่ยังไม่แน่ใจว่าระบบทำอะไร ปลอดภัยพอไหม และจะดูแลต่ออย่างไร ใน workshop เราจะสร้าง ProudVault เป็นโปรเจกต์ตัวอย่าง แล้วให้คุณนำวิธีคิดเดียวกันไปใช้กับโปรเจกต์ของตัวเอง เราจะเริ่มจากการแตกปัญหา และกำหนดเส้นทางแห่งความสำเร็จ ก่อนเรียนรู้วิธีสั่งงาน AI อย่างมีขอบเขต อ่านสิ่งที่ AI แก้ ทดสอบ flow สำคัญ ป้องกันข้อมูลของผู้ใช้ และพา product ไปถึง production ในสภาพที่ยังดูแล แก้ไข และต่อยอดได้ โดยไม่ทำของเดิมพังหรือต้องสร้างใหม่ทั้งหมดในอนาคต

แม้ Workshop นี้จะใช้ Rails เป็นตัวอย่างในการอธิบายตลอดเส้นทาง แต่คุณไม่ต้องกังวล เพราะ workshop ออกแบบมาให้ผู้ที่ไม่มีพื้นฐานการเขียนโปรแกรม สามารถเรียนและลงมือทำตามได้ สิ่งที่เราคาดหวังคือคุณพร้อมเป็นคนตัดสินใจ ตรวจหลักฐาน และรับผิดชอบ product ที่สร้างขึ้น

From vibe to real users

เว็บเปิดได้ ≠ พร้อมใช้จริง

ตอน vibe coding หรือทำ demo เรามักทดลองเว็บด้วยข้อมูลและลำดับที่เรารู้อยู่แล้วว่าต้องทำอย่างไร แต่ผู้ใช้จริงไม่รู้สิ่งที่ผู้สร้างรู้ เขาจะกรอกสิ่งที่เราไม่เคยลอง กดผิดทาง เปิดเว็บจากหลายอุปกรณ์ และคาดหวังว่าข้อมูลจะยังอยู่ในวันพรุ่งนี้

1. ผู้ใช้กรอกสิ่งที่เราไม่เคยลอง

เว้นช่องว่าง วางข้อความยาว กดย้ำ หรือ refresh ระหว่างบันทึก

สิ่งที่พัง: ข้อมูลหาย ซ้ำ หรือผิดรูปแบบจน flow ต่อไปทำงานไม่ได้

2. ผู้ใช้ไม่ได้เดินตาม happy path

เปิดลิงก์เก่า ย้อนหน้า ข้ามขั้น หรือกลับมาหลัง session หมดอายุ

สิ่งที่พัง: ผู้ใช้ติดอยู่กลางทาง หรือระบบบันทึกสถานะที่ไม่ควรเกิดขึ้น

3. ผู้ใช้หลายคนใช้ระบบพร้อมกัน

สลับ account เปิดหลาย tab หรือเดา URL ของข้อมูลชิ้นอื่น

สิ่งที่พัง: คนหนึ่งเห็นหรือแก้ข้อมูลของอีกคน ความเชื่อใจหายทันที

4. วันหนึ่งระบบย่อมผิดพลาด

release ใหม่มี bug, service ล่ม, config ผิด หรือข้อมูลเสีย

สิ่งที่พัง: ถ้าไม่มี log, backup และทางย้อนกลับ เราไม่รู้ทั้งสาเหตุและวิธีกู้ระบบ
ตอนทำ Demo เราคิดแค่ว่า “ไอเดียนี้สร้างได้จริงไหม?” — แต่ก่อนปล่อย Production ต้องตอบให้ได้ว่า “ผู้ใช้พึ่งพาระบบของเราได้ไหม และเมื่อระบบพังหรือต้องแก้ไข เรายังรับผิดชอบมันได้ไหม?”

Production Readiness

Production Readiness: Product ที่ดีต้องมีอะไรบ้าง?

Product ที่ดีต้องสร้างคุณค่าให้ผู้ใช้ในวันนี้ และยังดูแลรับผิดชอบได้ในวันข้างหน้า ผู้ใช้ต้องทำงานสำคัญได้อย่างถูกต้องและปลอดภัย ส่วนเจ้าของต้องรู้เมื่อระบบมีปัญหา กู้กลับมา และพัฒนาต่อได้ เราจึงใช้ 6 คุณสมบัตินี้เป็น checklist ตลอด workshop

A. ผู้ใช้ต้องพึ่งพา product ได้

ทำงานสำคัญได้สำเร็จ ได้ผลลัพธ์ที่ถูกต้อง และไม่ต้องเสี่ยงกับข้อมูลหรือสิทธิ์ของตน

Useful

ผู้ใช้ทำงานสำคัญที่ตั้งใจเข้ามาทำได้จนจบ

ถ้าขาด: หน้าตาดีและมีหลาย feature แต่ไม่แก้ปัญหาจริง ผู้ใช้ลองครั้งเดียวแล้วเลิก

Correct

กฎ ข้อมูล และ critical flow ให้ผลลัพธ์ที่ถูกต้องและตรวจซ้ำได้

ถ้าขาด: คำนวณผิด บันทึกซ้ำ เปลี่ยนสถานะผิด หรือทำข้อมูลหายโดยไม่มีใครรู้

Safe enough

ตัวตน สิทธิ์ ข้อมูล และ secret ถูกป้องกันตามระดับความเสี่ยง

ถ้าขาด: User A เปลี่ยน URL แล้วเห็นหรือแก้ข้อมูลของ User B ได้

B. เจ้าของต้องดูแล product ต่อได้

รู้เมื่อระบบมีปัญหา กู้กลับมาได้ และเปลี่ยนแปลงต่อโดยไม่ทำของเดิมพัง

Operable

เจ้าของรู้ว่า version ใดกำลังรัน ระบบยังปกติไหม และ error เกิดตรงไหน

ถ้าขาด: ผู้ใช้แจ้งว่าเว็บพัง แต่เราไม่มี log ไม่รู้ว่าเริ่มพังหลัง release ใด

Recoverable

มี backup, rollback และขั้นตอนพาระบบกลับสู่สภาพใช้งานได้

ถ้าขาด: deploy ใหม่ทำระบบล่มหรือข้อมูลเสีย แต่ไม่มี version และข้อมูลให้ย้อนกลับ

Changeable

เพิ่มหรือแก้ feature ผ่านขอบเขต test และ checkpoint โดยไม่ทำของเดิมพัง

ถ้าขาด: ทุกการแก้ไขกระทบส่วนอื่นจนไม่มีใครกล้าเปลี่ยน และสุดท้ายต้องสร้างใหม่ทั้งหมด
Definition of done: ผู้ใช้พึ่งพาได้ เจ้าของดูแลต่อได้ — แม้วันที่โลกจริงไม่เป็นไปตามแผน

A lightweight SDLC

Software ที่ดีไม่ได้สร้างครั้งเดียว — มันถูกพัฒนาเป็นรอบ

ในวงการ software เราเรียกแผนที่ตั้งแต่เข้าใจปัญหาจนถึงดูแลระบบหลังปล่อยว่า SDLC องค์กรใหญ่อาจมีรายละเอียดมากกว่านี้ แต่ workshop นี้ใช้ Product Development Cycle แบบกระชับ เพื่อให้ผู้เริ่มต้นไม่ข้ามงานสำคัญที่ทำให้ product ใช้และดูแลต่อได้จริง

Backlog · idea · bug · request

  1. เข้าใจปัญหา

    ทบทวน feedback และ backlog แล้วเลือกปัญหาที่มีหลักฐานพอสำหรับรอบนี้

  2. กำหนดผลลัพธ์

    ระบุ success path, non-goals และความเสี่ยง

  3. วางแผน

    เลือกการเปลี่ยนแปลงเล็กถัดไปและหลักฐานที่จะใช้ตรวจ

  4. สร้างทีละน้อย

    ลงมือในขอบเขตที่ตรวจและย้อนกลับได้

  5. ตรวจหลักฐาน

    ดู diff, test และทดลอง critical flow

  6. ปล่อย

    นำ version ที่ผ่านการตรวจไปให้ผู้ใช้

  7. ดูแลและเรียนรู้

    อ่าน feedback, log และ incident แล้วเริ่มรอบถัดไป

Release ไม่ใช่จุดจบ: feedback จากโลกจริงจะกลับมา ส่วน backlog เป็นอีก input ของรอบถัดไป แต่ทั้งคู่ยังต้องผ่าน Direction gate ก่อน

AI across the cycle

AI ช่วยได้ทุกช่วง — แต่ช่วยคนละแบบ

AI ไม่ได้มีแค่บทบาทคนเขียน code มันช่วยสำรวจ นิยาม วางแผน สร้าง ตรวจ และดูแลได้ แต่ในแต่ละช่วง คนยังต้องรับผิดชอบการตัดสินใจคนละเรื่อง

สำรวจ

AI ช่วย
สรุปข้อมูล ตั้งคำถาม และท้าทายสมมติฐาน
คนยังตัดสินใจ
ตรวจแหล่งข้อมูลและเลือกปัญหาที่ควรแก้

นิยาม

AI ช่วย
ร่าง user journey, acceptance criteria และ prototype
คนยังตัดสินใจ
ตัดสินว่าอะไรสร้างคุณค่าและอะไรเป็น non-goal

วางแผน

AI ช่วย
เสนอ system map, data model, ความเสี่ยง และลำดับงาน
คนยังตัดสินใจ
อนุมัติ scope, ข้อจำกัด และ trade-off

สร้าง

AI ช่วย
เขียน code ติดตั้ง dependency แก้ไฟล์ และรันคำสั่ง
คนยังตัดสินใจ
กำหนดขอบเขต ตรวจ diff และควบคุม permission

ตรวจ

AI ช่วย
คิด edge case เขียน test และวิเคราะห์ error
คนยังตัดสินใจ
ดูหลักฐาน ทดลอง critical flow และตัดสินว่างานผ่านหรือไม่

ปล่อยและดูแล

AI ช่วย
เตรียม deploy อ่าน log วิเคราะห์ปัญหา และเสนอ rollback
คนยังตัดสินใจ
อนุมัติ release สื่อสารกับผู้ใช้ และรับผิดชอบ incident
AI เปลี่ยนบทบาทตามช่วงของงานได้ แต่สิทธิ์ตัดสินใจและความรับผิดชอบต่อ product ยังอยู่กับคุณ

Human-in-the-loop

AI ลงมือได้ แต่ 4 จุดตัดสินใจต้องอยู่ในมือคุณ

การควบคุมไม่ได้แปลว่าต้องเขียนทุกบรรทัดเอง แต่ต้องมีจุดที่คนกำหนดทิศทาง อนุมัติขอบเขต ตรวจหลักฐาน และตัดสินใจก่อนสิ่งที่ AI ทำจะไปถึงผู้ใช้ ใช้ 4 จุดนี้เป็น guideline กลางของ workshop ไม่ต้องกำหนดขอบเขต Human–AI ใหม่ใน Project Intake ทุกครั้ง

Direction gate

คนกำหนด problem, user, success path และ non-goals

ถ้ายกให้ AI: สร้างของผิดชิ้นได้อย่างรวดเร็ว

Plan gate

คนอนุมัติว่าจะเปลี่ยนอะไร กระทบส่วนไหน และจะตรวจอย่างไร

ถ้ายกให้ AI: การแก้เล็ก ๆ อาจลามจนตรวจไม่ไหว

Evidence gate

คนดู diff, test และ critical flow ก่อนรับงาน

ถ้ายกให้ AI: เหลือเพียงคำว่าเสร็จโดยไม่มีหลักฐานว่าถูกต้อง

Release gate

คนตัดสินใจ commit, deploy, stop หรือ rollback

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

Your project · Direction gate

8 คำถามก่อนเริ่มสร้าง

Project Intake เปลี่ยนไอเดียคลุมเครือให้เป็นโครงการรุ่นแรกที่คุยกับ AI หรือทีมได้ โดยเจ้าของ product ยังเป็นคนตัดสินใจ

  1. 1

    ผู้ใช้หลักคือใคร?

    เลือกคนกลุ่มหนึ่ง ไม่ใช่ “ทุกคน”

  2. 2

    เขาติดขัดเมื่อไร และเพราะอะไร?

    ระบุ situation และ pain ที่มองเห็นได้

  3. 3

    เขาต้องการผลลัพธ์อะไร?

    พูดเป็นสิ่งที่ผู้ใช้ทำสำเร็จ ไม่ใช่ feature

  4. 4

    Primary Success Path หนึ่งเส้นคืออะไร?

    เรียงรายละเอียด 3–5 ขั้นจาก trigger ไปถึง end state

  5. 5

    รุ่นแรกต้องมีอะไรเพื่อให้ path เดินได้?

    เลือก precondition, supporting path และ enabling work ที่ขาดไม่ได้

  6. 6

    รุ่นแรกจะไม่ทำอะไร?

    เขียน non-goals เพื่อกัน scope ไหล

  7. 7

    ถ้าระบบผิดพลาด อะไรอาจเสียหาย?

    ระบุผลกระทบต่อผู้ใช้ ข้อมูล เงิน สิทธิ หรือความเชื่อใจ

  8. 8

    หลักฐานอะไรพิสูจน์ว่ารุ่นแรกใช้ได้?

    จับคู่ Evidence กับ Risk แต่ละข้อ และอย่างน้อยต้องพิสูจน์ Primary outcome

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

ProudVault · โปรเจกต์ตัวอย่างตลอด Workshop

ProudVault ไม่ได้เริ่มจาก “อยากทำแอปหนังสือ”

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

คนกำลังถือหนังสือและโทรศัพท์อยู่ในร้านหนังสือ พร้อมกรอบความคิดที่เห็นหนังสือเล่มเดิมซ้ำกัน

ทำไมต้องแยกเป็น 4 ส่วน?

เรื่องเล่าช่วยให้เราเห็นบริบทและเข้าใจความรู้สึกของผู้ใช้ แต่ยังไม่ใช่ขอบเขตของ product เราจึงแยกให้ชัดว่าใครเจอปัญหา ปัญหาเกิดเมื่อไร ความติดขัดหรือความเสียหายคืออะไร และเขาอยากก้าวไปถึงผลลัพธ์ใด — โดยยังไม่รีบกระโดดไปเลือก feature

Person
คนที่ซื้อและสะสมหนังสือ
Situation
ยืนอยู่ในร้านและต้องตัดสินใจซื้อ
Pain
จำไม่ได้ว่ามีเล่มนี้แล้วหรือยัง จึงเสียเวลาค้นหรือซื้อซ้ำ
Desired outcome
เช็กชั้นหนังสือของตัวเองได้ทันที แล้วตัดสินใจอย่างมั่นใจ

Pause 01 · Draft Problem Statement · 3 นาที

ก่อนคิดชื่อแอป ลองจับเหตุการณ์จริงหนึ่งครั้ง

หยิบเหตุการณ์ที่คุณเคยพบหรือเห็นจริงมาเล่าหนึ่งครั้งก่อน คำตอบชุดนี้จะกลายเป็นส่วน problem, user และ outcome ใน Project Intake ตอนท้าย

  1. 1

    นึกถึงคนหนึ่งคนในเหตุการณ์จริง ไม่ใช่กลุ่มกว้างอย่าง “ทุกคน”

  2. 2

    ระบุว่าเขากำลังพยายามทำอะไร และเหตุการณ์เกิดขึ้นเมื่อไร

  3. 3

    บอกสิ่งที่ทำให้ติดขัด พร้อมวิธีที่เขาใช้แก้ขัดอยู่วันนี้

  4. 4

    อธิบายความก้าวหน้าที่เขาต้องการ โดยยังไม่ตั้งชื่อ feature

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 3 นาที

ตอนที่ __________ กำลัง __________ เขาติดขัดเพราะ __________ วันนี้เขาแก้ขัดด้วย __________ แต่สิ่งที่เขาต้องการจริง ๆ คือ __________

Direction gate · Refine the draft

Problem Statement ที่ดีต้องชัดพอให้เลือก scope — แต่ไม่ล็อก feature

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

ตัวอย่าง 1

คนรักหนังสือต้องการแอปจัดการหนังสือเพื่อไม่ซื้อซ้ำ

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

NOT READY · ล็อกคำตอบเร็วเกินไป

ตัวอย่าง 2

เมื่อคนที่ซื้อและสะสมหนังสือต้องตัดสินใจซื้อขณะอยู่ในร้าน เขาจำไม่ได้ว่ามีเล่มนั้นแล้วหรือยัง จึงต้องค้นรูปเก่าหรือเสี่ยงซื้อซ้ำ เขาต้องการรู้ว่าตนมีหนังสือเล่มนั้นหรือไม่ เพื่อให้ตัดสินใจได้อย่างมั่นใจ

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

READY · ใช้กำหนดทิศทางได้

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

Direction gate · Success path

Success Path คือเส้นทางสั้นที่สุดที่พาผู้ใช้ถึงผลลัพธ์

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

Draft path · ลองใส่ทุกขั้นก่อน

  1. เห็นหนังสือในร้าน
  2. Login เป็นเงื่อนไขก่อนเริ่ม
  3. เปิดหน้า My Shelf เป็นชื่อหน้าจอ ไม่ใช่ความก้าวหน้าของผู้ใช้
  4. ค้นชื่อหรือ ISBN
  5. เห็นผลว่า “มีแล้ว”
  6. Add if missing เป็นอีกทางแยกหนึ่ง
  7. ตัดสินใจไม่ซื้อซ้ำ

One Success Path · เหลือหนึ่งเส้นที่เดินตามได้

  1. เห็นหนังสือในร้าน
  2. ค้นชื่อหรือ ISBN
  3. เห็นผลว่า “มีแล้ว”
  4. ตัดสินใจไม่ซื้อซ้ำ
สิ่งที่ขีดออกไม่ได้แปลว่าต้องทิ้ง — หน้าถัดไปเราจะจัดว่าอะไรต้องมีอยู่ก่อน อะไรเป็นเส้นสนับสนุน และอะไรพักไว้ใน backlog

Direction gate · เส้นหลักและสิ่งที่ต้องพึ่ง

Product หนึ่งมีหลายเส้นทาง — แต่รอบนี้ลงรายละเอียดเพียงเส้นเดียว

Product จริงมีหลาย path และมีงานที่ต้องทำก่อนเส้นหลักจะเกิดขึ้นได้ ในขั้นวางทิศทางนี้ เรายังไม่เขียนทุก flow ให้ละเอียด แต่เลือกเส้นที่พิสูจน์คุณค่าหลักมาทำให้เดินตามได้ ส่วนสิ่งที่จำเป็นต่อเส้นนั้นให้ระบุชื่อและความสัมพันธ์ไว้ก่อน Primary Path แสดงลำดับที่ผู้ใช้ได้รับคุณค่า ไม่ใช่ลำดับการพัฒนา — ตอนลงมือเราอาจต้องสร้างระบบพื้นฐานหรือ Supporting Path ก่อน

ProudVault · สิ่งที่อยู่รอบ Primary Success Path

Primary Success Path · ลงรายละเอียด
เห็นหนังสือในร้าน → ค้นชื่อหรือ ISBN → เห็นว่า “มีแล้ว” → ตัดสินใจไม่ซื้อซ้ำ
Preconditions · ระบุให้รู้
ผู้ใช้เข้าสู่ระบบแล้ว และมีข้อมูลหนังสือของตนอยู่ในชั้น
Supporting path · ระบุชื่อ
เพิ่มหนังสือที่ยังไม่มี เพื่อเตรียมข้อมูลให้การค้นครั้งต่อไปตอบได้
Enabling work · ระบุสิ่งที่ต้องพึ่ง
Account, การแยกข้อมูลตามเจ้าของ และการค้นหาที่เชื่อถือได้
Backlog / later · ยังไม่ทำรอบนี้
Recommendation, social, lending, AI import และ native mobile app
One Success Path ที่เลือก: เห็นหนังสือในร้าน → ค้นชื่อหรือ ISBN → เห็นว่า “มีแล้ว” → ตัดสินใจไม่ซื้อซ้ำ

Pause 02 · Success path · 4 นาที

วาดเส้นทางที่จบด้วยผลลัพธ์ของผู้ใช้

ต่อจากเหตุการณ์ใน Pause 01 เลือก Primary Success Path ที่พิสูจน์คุณค่าหลัก แล้ววาดทางที่สั้นที่สุดจากจุดเริ่มไปถึงผลลัพธ์

  1. 1

    เขียน trigger ว่าเหตุการณ์ใดทำให้ผู้ใช้เริ่มลงมือ

  2. 2

    ใส่ action ที่สังเกตได้ 1–3 ขั้น โดยใช้คำกริยาของผู้ใช้

  3. 3

    จบด้วยสภาพที่มองเห็นได้ว่าผู้ใช้ได้ผลลัพธ์แล้ว

  4. 4

    ขีดฆ่าเงื่อนไขก่อนเริ่ม ชื่อหน้าจอ และทางแยกออกจากเส้นหลัก

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 4 นาที

Primary Path: เมื่อ __________ → __________ → __________ → จบที่ __________

Plan gate · Scope

รุ่นแรกต้องมีอะไร — และอะไรยังไม่ต้องมี

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

ProudVault · Must-have

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

ProudVault · Non-goals รุ่นแรก

  • Later
    Recommendation ยังไม่จำเป็นต่อการตอบว่า “มีเล่มนี้แล้วหรือยัง”
  • Later
    Social และ review community เป็นผลลัพธ์อีกเรื่องหนึ่ง ไม่ช่วยพิสูจน์ Primary Path นี้
  • Later
    Lending ต้องมีกฎและเส้นทางยืมคืนแยกต่างหาก
  • Later
    AI import ช่วยกรอกข้อมูลเร็วขึ้น แต่รุ่นแรกเริ่มด้วยการเพิ่มเองได้
ถ้าไม่มีสิ่งนี้ ผู้ใช้ยังไปถึงผลลัพธ์ที่เลือกได้ไหม? ถ้าได้ ให้ย้ายออกจากรุ่นแรก

Pause 03 · Scope · 4 นาที

คัดสิ่งที่ต้องมี แล้วบอกเหตุผลของสิ่งที่ไว้ทีหลัง

ใช้ Primary Success Path จาก Pause 02 เป็นตัวกรอง แล้วตรวจทั้งขั้นบน path, precondition, supporting path และ enabling work สิ่งที่ไม่จำเป็นต่อการพิสูจน์คุณค่ารุ่นแรกให้ย้ายไป Non-goals พร้อมเหตุผล

  1. 1

    รวบรวมขั้นบน path, precondition, supporting path และ enabling work ที่อาจจำเป็น

  2. 2

    ถามทีละข้อว่า “ถ้าไม่มี ผู้ใช้ยังไปถึงผลลัพธ์ได้ไหม?”

  3. 3

    ถ้ายังไปถึงได้ ให้ย้ายออกจาก Must-have

  4. 4

    เลือก Non-goals อย่างน้อย 3 ข้อและเขียนเหตุผลว่าทำไมรุ่นแรกยังไม่ต้องมี

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 4 นาที

Must-have + ที่มา: ________________________ | Non-goals + เหตุผล: ________________________

Evidence gate · Risk and evidence

อะไรอาจพัง — และหลักฐานอะไรทำให้เราเชื่อว่างานผ่าน

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

Risk 1

ผลค้นหาบอกสถานะผิด

หนังสือที่มีอาจขึ้นว่า “ยังไม่มี” หรือกลับกัน ทำให้ผู้ใช้ตัดสินใจซื้อผิดและอาจซื้อซ้ำ

Evidence ที่ควบคุม Risk 1

หนังสือตัวอย่างที่รู้สถานะ ให้ผลถูกต้องทั้งกรณี “มีแล้ว” และ “ยังไม่มี”

เตรียมรายการที่มีและไม่มี แล้วค้นด้วยทั้งชื่อและ ISBN ผลต้องตรงกับข้อมูลจริง — หลักฐานนี้พิสูจน์ Primary outcome ด้วย

Risk 2

Account A เห็นหรือแก้ชั้นของ Account B

ข้อมูลข้ามผู้ใช้ ทำลายความเป็นส่วนตัวและความเชื่อใจ

Evidence ที่ควบคุม Risk 2

Account A เปิดดูหรือแก้ข้อมูลของ Account B ไม่ได้

ทดลองผ่าน flow และการเข้าถึงรายการโดยตรง ผลต้องถูกปฏิเสธทุกกรณี

Evidence gate · Unresolved risk

คิด Evidence ไม่ออก ให้กลับมาเช็ก Risk ก่อน

ในขั้นนี้ยังไม่ต้องมีผลทดสอบจริง เพียงบอกให้ได้ว่า Evidence แบบใดจึงนับว่าผ่าน ถ้าคิดไม่ออก ให้ใช้ 3 ข้อนี้ทำ Risk ให้ชัดหรือลดโจทย์ก่อนลงมือ

  1. 1

    Risk ยังกว้างเกินไปหรือไม่?

    เขียนใหม่เป็นเหตุการณ์ผิดพลาดที่สังเกตได้ เช่น “ข้อมูลต้องปลอดภัย” ยังตรวจไม่ได้ แต่ “Account A ต้องไม่เห็นหรือแก้ชั้นของ Account B” ทำให้นิยาม Evidence ต่อได้

  2. 2

    รู้ว่าต้องตรวจอะไร แต่ตอนนี้ยังตรวจไม่ได้?

    เขียนว่า “ยังพิสูจน์ไม่ได้ (Unresolved Risk)” ทดลองต่อได้ แต่ยังไม่ปล่อยให้ผู้ใช้จริง

  3. 3

    การพิสูจน์ยากหรือผลกระทบสูงเกิน workshop?

    ลด scope เลือกส่วนเสี่ยงต่ำ เปลี่ยน project หรือให้ผู้เชี่ยวชาญร่วมรับผิดชอบ

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

Pause 04 · Risk & evidence · 5 นาที

คิดถึงสิ่งที่พังได้ ก่อนถามว่า “เสร็จหรือยัง”

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

  1. 1

    เขียน Risk 1 ว่า Primary outcome อาจผิดหรือไม่เกิดขึ้นอย่างไร

  2. 2

    จับคู่ Evidence 1 ที่มองเห็นและทดสอบซ้ำได้ว่าผลลัพธ์นั้นถูกต้อง

  3. 3

    ถ้ามีความเสี่ยงสำคัญอื่น ให้เขียน Risk 2 และ Evidence 2 ที่พิสูจน์ว่าควบคุมมันได้

  4. 4

    ตรวจว่า Risk ทุกข้อมี Evidence และ Evidence ทุกชิ้นบอกได้ว่าพิสูจน์ข้อใด

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 5 นาที

Risk 1: __________________ → Evidence 1: __________________ | ถ้ามี Risk 2: __________________ → Evidence 2: __________________

Studio · Your Project Intake

รวมคำตอบเป็น Project Intake ที่เล่าได้ใน 60 วินาที

เปิด Project Intake form แล้วนำ output จาก Pause ทั้ง 4 มากรอกใน artifact เดียว: problem, user และ outcome จาก Pause 01, Primary Success Path จาก Pause 02, must-have กับ non-goals จาก Pause 03 และ risk กับ evidence จาก Pause 04 แล้วค่อยเกลาให้ทั้ง 8 คำตอบต่อกันเป็นเรื่องเดียว ถ้าเล่าได้ชัดภายใน 60 วินาทีและความเสี่ยงสำคัญทุกข้อมีวิธีตรวจ โครงการก็พร้อมนำไปวางแผนต่อ หากยังมีข้อที่พิสูจน์ไม่ได้ ให้ทำ Risk ให้ชัดหรือลด scope ก่อนเข้า Module 2

  1. 1

    Problem + user

    ใครติดขัดอะไร ในสถานการณ์ใด

  2. 2

    Outcome + Primary Success Path

    ผู้ใช้จะทำอะไรสำเร็จ ผ่านขั้นใดบ้าง

  3. 3

    Must-have + non-goals

    Path ต้องพึ่งอะไร และรุ่นแรกตั้งใจยังไม่ทำอะไร

  4. 4

    Risk + evidence

    Risk แต่ละข้อจับคู่กับ Evidence อะไร และมีข้อใดเป็น Unresolved Risk

เปิด Project Intake form
ดาวน์โหลด Project Intake.md เก็บไว้ — Module 2 จะใช้ไฟล์นี้เป็น input เพื่อสร้าง Product Contract และ acceptance criteria ไม่ใช่เริ่มนิยาม project ใหม่

The paved road · Plan gate

ทำไม workshop นี้เลือก Rails

เราเลือก paved road เพื่อให้ผู้เริ่มต้นใช้พลังตัดสินใจกับ product ไม่ใช่หมดไปกับการประกอบ infrastructure Rails มี convention และเครื่องมือ web หลักอยู่บนแผนที่เดียว จึงช่วยให้เราอ่านสิ่งที่ AI เสนอและตาม request หนึ่งเส้นได้ง่ายขึ้น

  • Convention ลดการตัดสินใจที่ยังไม่จำเป็น
  • Monolith ทำให้ UI, rule และ data อยู่ใน system map เดียว
  • Mature defaults รองรับงาน web ที่พบบ่อยและมีเอกสารอ้างอิงมาก
Rails เป็นข้อจำกัดเพื่อการเรียนรู้ ไม่ใช่คำตอบที่ดีที่สุดสำหรับทุก product

Toolchain map · Recognize only

เครื่องมือแต่ละชิ้นรับผิดชอบอะไรใน Product Development Cycle

Module 1 ต้องการให้คุณเห็นว่าแต่ละเครื่องมือทำหน้าที่ใด ไม่ต้องติดตั้งหรือใช้เป็นตอนนี้ เราจะค่อยเปิด ใช้ และตรวจมันเมื่อถึง module ที่เกี่ยวข้อง เพื่อไม่ให้การ setup กลบการตัดสินใจเรื่อง product

สร้างและเก็บหลักฐาน

  • AI coding tool + IDE: โต๊ะทำงานสำหรับคิด แก้ไฟล์ และตรวจงาน
  • Rails + PostgreSQL: ตัว product และข้อมูลบนเครื่อง
  • Git + GitHub: ประวัติ จุดตรวจ และหลักฐานของการเปลี่ยนแปลง

ปล่อยและดูแล

  • Railway: รัน version ที่ผ่านการตรวจให้ผู้ใช้เข้าถึง
  • Domain + DNS: ที่อยู่ที่พาผู้ใช้ไปยัง product ที่ถูกต้อง
ชื่อเครื่องมือเปลี่ยนได้ แต่ความรับผิดชอบเรื่องสร้าง ตรวจ ปล่อย และดูแลยังต้องมีเจ้าของเสมอ

Transferable thinking

Rails คือสนามฝึก — วิธีคิดเดินทางไปกับคุณได้

คุณอาจเลือก Django, Laravel, Phoenix หรือ JavaScript stack ในอนาคต ชื่อ framework และคำสั่งจะเปลี่ยน แต่การเริ่มจาก problem การทำงานเป็นรอบ การตรวจคุณภาพ การมีหลักฐาน และการถือ decision gate จะยังเหมือนเดิม

  • เริ่มจาก user, outcome, success path และ non-goals
  • วางแผนการเปลี่ยนแปลงเล็ก ๆ แล้วตรวจ evidence ก่อนรับงาน
  • รู้ว่า version ใดกำลังรัน และหยุดหรือย้อนกลับได้เมื่อจำเป็น
เรียน Rails เพื่อเห็น product ครบวงจร แล้วแปลวิธีคิดนี้ไปใช้กับ stack ที่คุณสนใจ

How this workshop runs

ทุก module คือ Product Development Cycle ขนาดเล็ก

เราจะไม่สั่ง AI สร้างทั้ง product ในครั้งเดียว แต่ทำงานเป็นรอบเล็ก: นิยามผลลัพธ์ถัดไป อนุมัติแผน ให้ AI ช่วยลงมือ ตรวจหลักฐาน ทำ checkpoint แล้วนำสิ่งที่เรียนจาก ProudVault กลับมาใช้กับ project ของคุณ

Define next outcome Approve plan AI assists Inspect evidence Checkpoint Transfer
การทำงานช้าในจุดตัดสินใจ ช่วยให้เราทำงานเร็วและปลอดภัยขึ้นในจุดที่ AI ลงมือ

Before Module 2

เตรียมให้พร้อมเริ่ม — ยังไม่ต้องพร้อมเป็น developer

นำ Project Intake ของคุณมา เลือก AI coding tool หลักหนึ่งตัว เปิด IDE กับ terminal ได้ และเข้า GitHub account ได้ หลัง checkpoint เราจะเข้า Technical Bootstrapping Lab เพื่อ setup Ruby, Rails, PostgreSQL และ local server แบบ guided ก่อนนำ Project Intake และผล Technical Readiness ไปใช้ใน Module 2

  • เลือก Codex, Claude Code หรือ Antigravity หนึ่งตัว
  • เปิด IDE และ terminal บนเครื่องได้
  • เข้า GitHub account ได้
ไม่ต้อง setup เป็นมาก่อน แต่ต้องยอม inspect plan และหลักฐานร่วมกับ AI ใน Technical Bootstrapping Lab

Module checkpoint

สิ่งที่ต้องนำออกจากห้อง

MyShelf milestone

ผู้เรียนมี Project Intake ของโครงการตัวเองที่ลงรายละเอียด Primary Success Path หนึ่งเส้น โดยใช้ ProudVault เป็นตัวอย่างอ้างอิง

Deliverable

ไฟล์ Project Intake.md: primary user, trigger/pain, desired outcome, Primary Success Path หนึ่งเส้น, must-have/supporting work, non-goals, failure risk และ evidence

Exit gate

เล่า project ได้ใน 60 วินาทีโดยไม่เริ่มจาก feature list อธิบาย Primary Success Path หนึ่งเส้น กำหนดงานที่จำเป็น ขอบเขต ความเสี่ยง และ Evidence ที่จะใช้ตรวจได้ ไม่มีความเสี่ยงผลกระทบสูงที่ยังบอกไม่ได้ว่าจะตรวจอย่างไร และอธิบายบทบาทคร่าว ๆ ของ toolchain ได้

Module resources
Project Intake + ตัวอย่าง ProudVault → Technical Bootstrapping Lab → คู่มือผู้สอน Module 1 →

จบ module นี้แล้ว — ไปต่อหรือกลับไปดูภาพรวม

ดูทุก module Module 02 →