Volume 16 · Modernization Plan

วัตถุประสงค์ของ Volume

Volume นี้แปลง debt register (Volume 14) ให้เป็นแผนงานระดับ sprint ที่ทีมทำได้จริง ทุก Wave ระบุว่าใครทำอะไร เมื่อไหร่ อย่างไร ผลลัพธ์อะไร และจะยกเลิกอย่างไรถ้าเกิดปัญหา

จุดประสงค์คือให้ทีมสามารถเริ่มทำได้ทันทีโดยไม่ต้องตีความ debt register เอง

เชื่อมโยงกับ Volume อื่น

• Volume 14 ระบุว่ามี debt อะไรบ้าง ที่ไหน รุนแรงแค่ไหน
• Volume 16 (เล่มนี้) ระบุว่าจะแก้ debt เหล่านั้นอย่างไร ในระดับ task
• Volume 16 (Appendices) รวบรวม reference material ที่เกี่ยวข้อง

Volume 16 อ้างถึง debt ID จาก Volume 14 โดยตรง (เช่น SEC-1, PERF-3, LEG-2)

ผู้อ่านที่คาดไว้

• หัวหน้าทีมวิศวกรรม — ใช้วางแผน sprint และจัดทรัพยากร
• นักพัฒนา — ใช้เป็น playbook สำหรับ task ที่ได้รับมอบหมาย
• ผู้บริหาร — ใช้เข้าใจ timeline, budget, และความเสี่ยง
• ทีมปฏิบัติการ — ใช้ทำความเข้าใจการเปลี่ยนแปลงที่จะเกิดขึ้น

สมมติฐานที่ใช้ในแผนนี้

1. ทีมปัจจุบัน — ทีมวิศวกรรมที่มีอยู่สามารถ dedicate เวลา 30-50% ให้ modernization ได้
2. ไม่มี freeze — การพัฒนา feature ใหม่ยังทำต่อไปในระหว่าง modernization
3. Modernization target — Go (Hexagonal/DDD) สำหรับ backend, Nuxt 3 (Feature-Sliced Design) สำหรับ frontend (ตาม audit doc เดิม) แต่ทีมสามารถเลือกทิศทางอื่นได้
4. ** strangler pattern** — ย้ายทีละ bounded context ไม่ใช่ big-bang rewrite
5. Reversibility — ทุกขั้นตอนต้องย้อนกลับได้

KPI ของ Modernization

KPI	ปัจจุบัน	Wave 0	Wave 1	Wave 2	Wave 3
Critical debt	13	3	0	0	0
Node runtime version	12.5	12.5	20 LTS	20 LTS	20 LTS
Service ที่มี health endpoint	0/5	0/5	5/5	5/5+	5/5+
CI/CD coverage	2/5	2/5	5/5	5/5	5/5
_bk files	131	0	0	0	0
Bounded context แยกแล้ว	0	0	0	3-7	7
Frontend บน Nuxt 3	0/2	0/2	0/2	0/2	2/2
MTTR	หลายชม.	หลายชม.	< 1 ชม.	< 30 นาที	< 15 นาที

โครงสร้าง Volume

ภาพรวม (15.0)
    │
    ▼
หลักการ (15.1)
    │
    ▼
Wave 0/1/2/3 (15.2-15.5)
    │
    ▼
Playbook กลาง (15.6-15.8)
    │
    ├── Bounded context playbook (15.6)
    ├── Data migration (15.7)
    └── Infrastructure (15.8)
    │
    ▼
ส่วนสนับสนุน (15.9-15.12)
    │
    ├── Risk (15.9)
    ├── Team & skills (15.10)
    ├── Budget & timeline (15.11)
    └── Success criteria + rollback (15.12)

วิธีใช้ Volume นี้

หัวหน้าทีมวิศวกรรม

1. อ่าน 15.1 (หลักการ) ก่อนเพื่อเข้าใจกลยุทธ์
2. ดู 15.2-15.5 (Wave) เพื่อเลือก sprint แรก
3. ใช้ 15.10 (Team & skills) ประเมินทรัพยากรที่ต้องการ
4. ใช้ 15.11 (Budget) เสนอผู้บริหาร

นักพัฒนา

1. อ่าน Wave ที่ตัวเองจะทำ
2. ใช้ 15.6 (playbook) เป็นแนวทาง task
3. ใช้ 15.7 (data migration) สำหรับ task ที่กระทบ schema
4. ใช้ 15.9 (risk) เพื่อรู้ล่วงหน้าว่าอะไรอาจผิดพลาด

ทีมปฏิบัติการ

1. อ่าน 15.8 (Infrastructure) เพื่อรู้การเปลี่ยนแปลง
2. อัปเดต Volume 13 (Runbooks) ตามการเปลี่ยนแปลง

ข้อจำกัดของแผนนี้

1. Timeline เป็นการประมาณ — ความเร็วจริงขึ้นกับทีมและ priority ของ feature
2. Budget เป็น rough order of magnitude — ตัวเลขจริงต้อง quote จาก vendor/CL อีกครั้ง
3. Modernization target อาจเปลี่ยน — ทีมอาจเลือกทิศทางอื่น (เช่น NestJS แทน Go) ตามความถนัด
4. ไม่ครอบคลุม organizational change — การย้ายทีม, ปรับ role, training plan อยู่นอกเหนืองานเทคนิค

คำเตือนสำคัญ

Modernization ไม่ใช่เป้าหมายปลายทาง — เป้าหมายคือระบบที่บริการผู้ใช้ได้ดีขึ้น

ถ้า modernization ทำให้:

• ผู้ใช้ได้รับผลกระทบ (downtime, regression)
• ทีมหมดแรงก่อนเสร็จ
• งบประมาณบานปลาย

แผนนี้ต้องหยุดและปรับ ไม่ใช่เดินหน้าต่อเพราะ "วางแผนไว้แล้ว"

ทุก Wave ต้องมีจุดตัดสินใจ (decision gate) ที่ทีม stop และ evaluate ก่อน Wave ถัดไป