VTRC Knowledge Manual (V2)

ธีม

16.9 Risk management ​

บทนี้ระบุความเสี่ยงของ modernization ทั้งหมด พร้อมวิธี monitor และ mitigate

กรอบการประเมินความเสี่ยง ​

แต่ละ risk ประเมินด้วย 2 มิติ:

มิติระดับคำอธิบาย
Likelihood (โอกาสเกิด)ต่ำ / กลาง / สูงโอกาสที่ risk จะเกิดจริง
Impact (ผลกระทบ)ต่ำ / กลาง / สูงความรุนแรงถ้าเกิด

Risk score = Likelihood × Impact → จัดลำดับ priority

Risk register ​

R-01 · ทีมไม่มี skill Go/Vue 3 ​

Likelihoodสูง
Impactสูง
Risk score9 (สูงมาก)

อาการ

  • migration ช้ากว่าแผน
  • bug ใน code service ใหม่
  • ทีมหมดกำลังใจ

Mitigation

  • ทำ context เล็กที่สุดก่อน (document-renderer) เป็นการเรียนรู้
  • training 2-4 สัปดาห์ก่อนเริ่ม
  • จ้าง consultant 1-2 เดือนเพื่อ pair
  • ทำ code review ทุก PR

Trigger ที่ต้องหยุด: migration ใช้เวลา > 150% ของประมาณการ → ปรับแผน

R-02 · Migration มี bug ทำข้อมูลผิด ​

Likelihoodกลาง
Impactสูงมาก
Risk score9

อาการ

  • ข้อมูล payslip ผิดพลาด
  • ยอดเงินคลาดเคลื่อน
  • ข้อมูลผู้ใช้สูญหาย

Mitigation

  • contract test สำหรับทุก operation
  • dual-write + verifier ก่อน cutover
  • gradual cutover (5% → 25% → 50% → 100%)
  • สำรองข้อมูลก่อน cutover ทุกครั้ง
  • rollback plan พร้อมใช้

Trigger ที่ต้องหยุด: verifier พบความแตกต่าง > 0.1% → halt

R-03 · Modernization ยาวจนทีมหมดแรง ​

Likelihoodสูง
Impactสูง
Risk score9

อาการ

  • ความเร็วลดลงเรื่อย ๆ ทุก sprint
  • ทีมลาออก
  • "modernization fatigue"

Mitigation

  • แบ่งเป็น Wave เล็ก ๆ ที่เห็นผลชัดเจน
  • celebrate wins ทุก Wave
  • หมุนเวียนคนระหว่าง modernization และ feature work
  • ตั้ง "modernization day" แทน "modernization sprint" (เช่น 20% เวลา)
  • ถ้าทีมเหนื่อย → พัก Wave 1-2 sprint

Trigger ที่ต้องหยุด: ทีม retrospective บอกว่าเหนื่อย → pause modernization 1 sprint

R-04 · งบประมาณบานปลาย ​

Likelihoodกลาง
Impactสูง
Risk score6

อาการ

  • ค่า vendor / cloud เพิ่มเก่าแผน
  • ต้องจ้างคนเพิ่ม
  • เลื่อน scope แต่งบไม่เพิ่ม

Mitigation

  • budget contingency 20%
  • ติดตาม spending รายเดือน
  • ตัด scope ก่อนตัดคุณภาพ

Trigger: spending > 90% ของงบใน Wave → review กับผู้บริหาร

R-05 · Production incident ระหว่าง migration ​

Likelihoodกลาง
Impactสูงมาก
Risk score9

อาการ

  • service พังหลัง cutover
  • ผู้ใช้ไม่สามารถใช้งานได้
  • ข้อมูลสูญ

Mitigation

  • gradual cutover (ไม่ใช่ 0 → 100 ในครั้งเดียว)
  • ตั้ง monitor error rate แบบ real-time
  • rollback runbook สำหรับทุก cutover
  • ทีม on-call ระหว่าง cutover
  • ห้าม cutover วันศุกร์ / ก่อน holiday

Trigger: error rate > 1% ภายใน 15 นาที → rollback ทันที

R-06 · Dependency ระหว่าง Wave ทำให้ติดขัด ​

Likelihoodกลาง
Impactปานกลาง
Risk score4

อาการ

  • Wave 1 ล่าช้า → Wave 2 เริ่มไม่ได้
  • context หนึ่ง depend บนอีก context ที่ยังไม่แยก

Mitigation

  • Wave สามารถทำ parallel ได้ (Wave 2 กับ Wave 3)
  • context ที่ไม่ depend → ทำก่อน
  • ติดตาม dependency ใน planning

R-07 · ผู้ใช้ complaint เรื่อง UX เปลี่ยน ​

Likelihoodสูง (โดยเฉพาะ Wave 3)
Impactปานกลาง
Risk score6

อาการ

  • ผู้ใช้ไม่ชอบ UI ใหม่
  • สูญเสียความเคยชิน
  • ต้อง support เพิ่ม

Mitigation

  • migrate ทีละ page (strangler)
  • รักษา design language ให้ใกล้เคียงเดิม
  • visual regression test เพื่อดักจับการเปลี่ยนแปลงที่ไม่ตั้งใจ
  • ประกาศล่วงหน้า + ทำ user guide
  • เก็บ feedback และ iterate

R-08 · การ upgrade runtime ทำให้ dependency พัง ​

Likelihoodกลาง
Impactปานกลาง
Risk score4

อาการ

  • Node 20 ทำให้บาง package ไม่ทำงาน
  • PhantomJS (html-pdf) ไม่รองรับ
  • esm shim ไม่จำเป็นอีก แต่มี code ที่ยังพึ่ง

Mitigation

  • ตรวจ dependency ทุกตัวก่อน upgrade
  • ทดสอบใน staging อย่างน้อย 1 สัปดาห์
  • ทำทีละขั้น (Node 12 → 16 → 18 → 20)

R-09 · ทีมปฏิบัติการไม่พร้อมรับการเปลี่ยนแปลง ​

Likelihoodกลาง
Impactปานกลาง
Risk score4

อาการ

  • runbook ใหม่ไม่ถูกใช้
  • alert ใหม่ถูก ignore
  • deployment ยังทำแบบเดิม

Mitigation

  • ฝึกทีมปฏิบัติการทุก Wave
  • เขียน runbook ที่อ่านง่าย (ภาษาไทย)
  • สร้าง chat สำหรับ support

R-10 · Modernization ตาม deadline แต่คุณภาพแย่ ​

Likelihoodกลาง
Impactสูง
Risk score6

อาการ

  • service ใหม่รันได้แต่มี debt ใหม่
  • ไม่มี test
  • ไม่มี document
  • "หนี้เก่าใหม่"

Mitigation

  • ตั้ง definition of done ที่เข้มแข็ง (ใน playbook)
  • code review ทุก PR
  • วัด debt ทุก Wave (Volume 14 scorecard)
  • "stop line" — ห้ามเดินหน้า Wave ถัดไปถ้า DoD ไม่ครบ

Risk heatmap ​

                  Impact
            ต่ำ      กลาง      สูง
         ┌────────┬────────┬────────┐
   สูง   │        │   R-07 │ R-01   │
         │        │        │ R-03   │
         ├────────┼────────┼────────┤
Likelihood กลาง │        │ R-06   │ R-02   │
         │        │ R-08   │ R-04   │
         │        │ R-09   │ R-05   │
         ├────────┼────────┼────────┤
   ต่ำ   │        │        │ R-10   │
         └────────┴────────┴────────┘

Risk review process ​

รายสัปดาห์ ​

  • review risk score ใน sprint planning
  • อัปเดต likelihood ตามสถานการณ์

ราย Wave ​

  • ทำ risk retrospective ท้าย Wave
  • เพิ่ม risk ใหม่ที่เจอ
  • ปรับ mitigation strategy

หลัง incident ​

  • blameless postmortem (ดู Volume 13.10)
  • เพิ่ม mitigation ที่ได้เรียนรู้
  • อัปเดต playbook

Decision gate ระหว่าง Wave ​

ก่อนเริ่ม Wave ถัดไป ตอบ "ใช่" ทุกข้อ:

  • [ ] Wave ก่อนหน้าเสร็จตาม definition of done
  • [ ] KPI ของ Wave ผ่านเกณฑ์ (ดูบท 15.0)
  • [ ] Risk score รวมไม่เพิ่มขึ้น
  • [ ] ทีมพร้อม (ไม่หมดแรง)
  • [ ] งบประมาณเพียงพอ
  • [ ] stakeholder (ผู้บริหาร) ยังสนับสนุน

ถ้าตอบ "ไม่" → pause และปรับแผน ไม่ใช่เดินหน้า

สรุป ​

Modernization ที่ดีไม่ใช่ migration ที่ไร้ความเสี่ยง — แต่เป็น migration ที่รู้จักความเสี่ยงและจัดการมัน

บทถัดไปจะพูดถึงทีมและ skill ที่ต้องการ