Test & Decide · Module 04

Private Beta & Product Change

เมื่อผู้ใช้ขอ feature กลางทาง เราจะตัดสินใจและเปลี่ยนแผนก่อนเปลี่ยน code ได้อย่างไร?

StagingPrivate betaFeedback evidenceChange controlMigration planning

Why beta now

ก่อนเพิ่ม feature ให้คนอื่นลองของที่มีอยู่

Primary Path ผ่านในเครื่องผู้เรียนแล้ว แต่ยังไม่รู้ว่าคนนอกเข้าใจภาษาและเส้นทางหรือไม่ Module นี้นำ release ปัจจุบันขึ้น staging แล้วสังเกต tester โดยไม่บอกทาง

Staging gate

พื้นที่ทดลองต้องคล้ายของจริง แต่ยังไม่ใช่ production

แยก environment variables, database และ deploy process รัน migration และ smoke test โดยไม่ใช้ production credential หรือข้อมูลจริง

Prompt · Prepare a staging plan

อ่าน repository และ Build evidence ปัจจุบัน
เสนอ staging deployment plan: environment, secrets, database, migrations,
seed/test accounts, smoke tests, rollback point และ stop conditions
แสดง plan ให้ฉันอนุมัติ ห้าม deploy หรือเปลี่ยน production

Private beta

สังเกต behavior ก่อนถามว่า “อยากได้อะไร”

ให้ tester ทำ Search/ISBN และเพิ่มหนังสือเอง จดจุดที่หยุด ลังเล ผิดพลาด และ workaround แยกสิ่งที่เห็นจริงออกจากคำอธิบายหรือ solution ที่ tester เสนอ

Change event

“ช่วยเติมชื่อหนังสือให้อัตโนมัติได้ไหม?”

Feedback ชี้ว่าการเพิ่มหนังสือต้องพิมพ์ซ้ำ ผู้ใช้เสนอให้ค้น external API หรือใช้ข้อมูลชื่อ/ISBN ที่คนอื่นเคยกรอก นี่คือ product change ที่กระทบ model และ privacy

ห้ามเริ่มต่อ API จากคำขอหนึ่งประโยค ต้องกลับไปถาม outcome, evidence และผลกระทบก่อน

Compare solution paths

External API, shared catalog และ Hybrid แก้คนละความเสี่ยง

เปรียบเทียบความครอบคลุม คุณภาพข้อมูล privacy, downtime, rate limit, duplicate และต้นทุนดูแล สำหรับ ProudVault เสนอ Hybrid: ค้น Book ในระบบก่อน แล้วค่อยเรียก API เมื่อไม่พบ

ทางลัดที่ไม่รับ

ค้น Asset ของ user อื่นโดยตรง
Copy API response ลง Asset ทันที
เปลี่ยน model โดยไม่มี backfill

Direction ที่เสนอ

Book เป็น shared metadata
Asset เป็น owned record ใน Vault
Suggestion ต้องให้คนยืนยัน

Reopen the Product Plan

Feature ใหม่ต้องมี Story, criteria และ Non-goals ใหม่

อัปเดต Product Map, Site Map/state, Acceptance Criteria, Risk→Evidence และ Deferred พร้อมระบุว่า manual entry ยังเป็น fallback และ autocomplete ห้ามเปิดเผยว่าใครมีหนังสือ

Prompt · Draft the Product Change

อ่าน beta observation และ PRODUCT_PLAN.md ปัจจุบัน
เสนอ change สำหรับ autocomplete ตอนเพิ่มหนังสือ โดยแยก:
problem evidence, Story/Requirement, Site Map states, AC, risks,
privacy boundary, manual fallback และ Non-goals
ทำเครื่องหมายทุก decision ที่ต้องให้คนตอบ
ห้ามแก้ไฟล์หรือ code ก่อน Human Change Gate

Data impact

Asset ที่มีข้อมูลหนังสืออยู่ ต้องย้ายไปหา Book อย่างไร

ร่าง target relationship `User → Vault → Asset → Book`, ISBN normalization, duplicate resolution, provenance และ backfill/rollback โดยยังไม่รัน migration

Human Change Gate

อนุมัติ outcome, model และ fallback ก่อนวาง Build Plan

คนต้องตัดสินว่า feedback นี้ควรทำหรือไม่, เลือก Hybrid หรือทางอื่น, ยอมรับ migration risk แค่ไหน และ evidence ใดพิสูจน์ว่า change สำเร็จ

1
ตรวจ beta evidence และ problem statement
2
อนุมัติ Product/Data/API direction
3
ตรวจ backfill, rollback และ privacy risks
4
เปลี่ยน Change Plan เป็น READY หรือ BLOCKED

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

Human-approved Change Plan โดยยังไม่แก้ข้อมูลจริง

Module checkpoint

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

MyShelf milestone

ProudVault ผ่าน private beta และมี Change Plan ที่อนุมัติสำหรับ Book catalog + autocomplete

Deliverable

Staging URL, beta observation, updated PRODUCT_PLAN.md/DESIGN.md/BUILD_PLAN.md และ Data Migration Plan

Exit gate

คนนอกทำ Primary Path ได้, feedback ถูกแยกจาก solution request และ Human Change Gate อนุมัติ model/API direction โดยยังไม่แก้ production data