အခန်း ၁၂ :: Risk Management
Project တစ်ခု စတင်ပြီဆိုတာနဲ့ မသေချာ မရေရာမှု (Uncertainty) တွေက အရိပ်လို လိုက်ပါလာစမြဲပါ။ "Server မီးပျက်ရင် ဘယ်လိုလုပ်မလဲ"၊ "Developer အဓိက လူ နှုတ်ထွက်သွားရင် ဘယ်လိုလုပ်မလဲ"၊ "Third-party API ကြီး down သွားရင် ဘယ်လိုလုပ်မလဲ" စသည်ဖြင့်ပေါ့။
Risk Management ဆိုတာ "အဆိုးမြင်ခြင်း" (Pessimism) မဟုတ်ပါဘူး။ "ကြိုတင်ပြင်ဆင်ခြင်း" (Preparation) ဖြစ်ပါတယ်။ Software Engineering မှာ Risk Management ဆိုတာ Project ရဲ့ အောင်မြင်မှုကို ထိခိုက်စေနိုင်တဲ့ အရာတွေကို စောစီးစွာ ရှာဖွေဖော်ထုတ်ပြီး၊ ထိခိုက်မှု အနည်းဆုံးဖြစ်အောင် စီမံခန့်ခွဲခြင်း ဖြစ်ပါတယ်။
၁၂.၁ Proactive vs. Reactive Risk Strategies
Risk ကို ကိုင်တွယ်တဲ့အခါ ချဉ်းကပ်ပုံ နှစ်မျိုး ရှိပါတယ်။
Reactive Strategy (မီးလောင်မှ မီးငြိမ်းသတ်ခြင်း)
ပြဿနာ တကယ် ဖြစ်လာမှ လိုက်ရှင်းတဲ့ နည်းလမ်းပါ။ Software လောကမှာတော့ "Firefighting Mode" လို့ ခေါ်ပါတယ်။
- လက္ခဏာ: Team တစ်ခုလုံး အမြဲတမ်း ပြာယာခတ်နေမယ်။ အချိန်မီ မပြီးနိုင်လို့ OT တွေ ဆင်းရမယ်။ ဖိအား (Stress) တွေ များနေမယ်။
- ရလဒ်: ပြဿနာတော့ ရှင်းလို့ ပြီးသွားနိုင်ပေမယ့်၊ ကုန်ကျစရိတ် (Cost) များပြီး Project Quality ကျဆင်းသွားတတ်ပါတယ်။
Proactive Strategy (မီးမလောင်ခင် တားဆီးခြင်း)
ပြဿနာ မဖြစ်ခင် ကတည်းက "ဘာတွေ ဖြစ်နိုင်မလဲ" တွက်ချက်ပြီး ကြိုတင် ကာကွယ်ထားတာပါ။
- လက္ခဏာ: Risk Analysis လုပ်ဖို့ အချိန်ပေးရပေမယ့်၊ တကယ် ပြဿနာ တက်တဲ့အခါ အေးအေးဆေးဆေး ဖြေရှင်းနိုင်ပါတယ်။ Plan B, Plan C ရှိပြီးသား ဖြစ်လို့ပါ။
- ရလဒ်: ယုံကြည်မှု ရှိရှိနဲ့ Project ကို မောင်းနှင်နိုင်ပါတယ်။
The Cost of Calm: Proactive Risk Management ဟာ အချိန်နဲ့ အားစိုက်မှုကို အစမှာ ပိုသုံးရပေမယ့်၊ Crisis အချိန်မှာ Team ကို အေးအေးဆေးဆေး ဆုံးဖြတ်နိုင်တဲ့ အခြေအနေကို ပေးစွမ်းနိုင်ပါတယ်။
ဥပမာ:
- Reactive: Server Hard Disk ပျက်သွားမှ Data Recovery လုပ်ဖို့ ကြိုးစားတာ။ (ဒါက ကံတရားကို ပုံအပ်လိုက်တာပါ)
- Proactive: Hard Disk မပျက်ခင် RAID စနစ် ခံထားတာ၊ နေ့စဉ် Backup လုပ်ထားတာ။ (ဒါက Engineering ပါ)
၁၂.၂ Risk Identification, Analysis, and Prioritization
Risk Management လုပ်ငန်းစဉ်ကို အဆင့် ၄ ဆင့် ခွဲခြားနိုင်ပါတယ်။
graph TD
Identify[<b>1. Risk Identification</b><br/>ဘာတွေ ဖြစ်နိုင်မလဲ?] --> Analyze[<b>2. Risk Analysis</b><br/>ဖြစ်နိုင်ခြေ ဘယ်လောက်ရှိလဲ?]
Analyze --> Prioritize[<b>3. Risk Prioritization</b><br/>ဘယ်ဟာ အရေးအကြီးဆုံးလဲ?]
Prioritize --> Plan[<b>4. Response Planning</b><br/>ဘယ်လို ဖြေရှင်းမလဲ?]
style Identify fill:#e1f5fe,stroke:#01579b
style Analyze fill:#fff3e0,stroke:#e65100
style Prioritize fill:#ffebee,stroke:#b71c1c
style Plan fill:#e8f5e9,stroke:#1b5e20
၁။ Risk Identification (အန္တရာယ်များကို ဖော်ထုတ်ခြင်း)
ပထမဆုံး အဆင့်ကတော့ ဖြစ်နိုင်ခြေ ရှိသမျှ ပြဿနာတွေကို စာရင်းပြုစု (List Down) လုပ်တာပါ။ Brainstorming လုပ်ပြီး "What If" မေးခွန်းတွေ မေးရပါမယ်။
Software Project တွေမှာ အတွေ့ရများတဲ့ Risk အမျိုးအစားတွေကတော့ -
- Product Size Risks: Project က ထင်ထားတာထက် ကြီးသွားနိုင်သလား။ (Scope Creep)
- Business Impact Risks: ဒီ Software ကို ပြိုင်ဘက်တွေက အရင် ထုတ်လိုက်ရင် ဘာဖြစ်မလဲ။
- Customer Related Risks: Customer က Requirement တွေ ခဏခဏ ပြောင်းနေသလား။ Communication လုပ်ရ ခက်နေသလား။
- Process Risks: Team က နည်းပညာ အသစ်ကို သုံးမှာလား။ Deadline က အရမ်း ကျပ်နေသလား။
- Technology Risks: သုံးမယ့် Library က Deprecated ဖြစ်သွားနိုင်သလား။ Server က Traffic ဒဏ် ခံနိုင်ပါ့မလား။
- People Risks: အဓိက Key Developer နေမကောင်းဖြစ်ရင်၊ အလုပ်ထွက်သွားရင် ဘယ်သူ ဆက်လုပ်မလဲ။
Note: Risk List ဆိုတာ Project အစမှာ တစ်ခါရေးပြီး ပစ်ထားရမယ့် Document မဟုတ်ပါဘူး။ Sprint တစ်ခု ပြီးတိုင်း၊ Milestone တစ်ခု ပြီးတိုင်း ပြန်လည် Update လုပ်ရမယ့် Living Document ဖြစ်ပါတယ်။
၂။ Risk Analysis & Ownership (ဆန်းစစ်လေ့လာခြင်း)
Risk တွေကို စာရင်းရပြီဆိုရင် တစ်ခုချင်းစီကို Probability (ဖြစ်နိုင်ခြေ) နဲ့ Impact (ထိခိုက်မှု) တိုင်းတာရုံသာမက၊ ဒီ Risk ကို ဘယ်သူ တာဝန်ယူမလဲ ဆိုတဲ့ Owner ကိုပါ သတ်မှတ်ရပါမယ်။ Owner မရှိတဲ့ Risk ကို ဘယ်သူမှ မကိုင်တွယ်ကြပါဘူး။
Risk Register Example:
| Risk Description | Probability | Impact | Owner | Status |
|---|---|---|---|---|
| Key Dev leaves | Medium | High | Tech Lead | Mitigating (Documentation) |
| API downtime | High | Medium | Backend Team | Monitoring (Health Checks) |
| Server Cost Overrun | Medium | Low | Project Manager | Ignored |
၃။ Risk Prioritization (ဦးစားပေး အဆင့်သတ်မှတ်ခြင်း)
Risk တိုင်းကို လိုက်ဖြေရှင်းဖို့ မဖြစ်နိုင်ပါဘူး။ ဒါကြောင့် Probability နဲ့ Impact ကို မြှောက်ပြီး ရလာတဲ့ ရလဒ်အပေါ် မူတည်ပြီး ဦးစားပေး စီရပါမယ်။
- High Probability + High Impact: ချက်ချင်း ကိုင်တွယ်ရမယ့် အန္တရာယ် (Critical Risk)။
- Low Probability + Low Impact: လစ်လျူရှုထားလို့ ရတဲ့ အရာ (Monitor Only)။
Risk Map Example:
| Impact \ Probability | Low | Medium | High |
|---|---|---|---|
| High | Monitor | Plan | Action Now |
| Medium | Ignore | Monitor | Plan |
| Low | Ignore | Ignore | Monitor |
၁၂.၃ Risk Mitigation, Monitoring, and Management (RMMM)
Risk တွေကို သိပြီ ဆိုရင် ဘယ်လို တုံ့ပြန်မလဲ (Response Strategy) ဆိုတာ ဆုံးဖြတ်ရပါမယ်။ အဓိက နည်းလမ်း (၄) မျိုး ရှိပါတယ်။
1. Avoidance (ရှောင်ရှားခြင်း)
Risk ဖြစ်စေမယ့် အကြောင်းရင်းကို လုံးဝ ဖယ်ရှားလိုက်တာပါ။
- Example: နည်းပညာ အသစ်တစ်ခုကို သုံးရင် Risk များမယ်လို့ ယူဆရင်၊ ကျွမ်းကျင်ပြီးသား နည်းပညာ အဟောင်းကိုပဲ ပြောင်းသုံးလိုက်တာမျိုးပါ။
2. Mitigation (လျော့ချခြင်း)
Risk ဖြစ်နိုင်ခြေ (Probability) သို့မဟုတ် ဖြစ်လာရင် ထိခိုက်မှု (Impact) ကို လျော့နည်းအောင် လုပ်တာပါ။
- Example: Database ပျက်နိုင်တဲ့ Risk အတွက်၊ Master-Slave Replication လုပ်ထားတာမျိုးပါ။ ပျက်တော့ ပျက်နိုင်တယ်၊ ဒါပေမယ့် Slave က ချက်ချင်း အလုပ်ဆက်လုပ်မှာမို့ ထိခိုက်မှု နည်းသွားပါမယ်။
Warning (Over-Mitigation): Risk Mitigation ဟာ "အကောင်းဆုံးနည်းပညာ" ကို သုံးရမယ်ဆိုတာ မဟုတ်ပါဘူး။ Risk တစ်ခုကို လျော့ချဖို့ သုံးတဲ့ ကုန်ကျစရိတ်က Risk ကိုယ်တိုင်ထက် ပိုကြီးနေပြီဆိုရင် အဲဒါဟာ Over-Engineering ဖြစ်သွားနိုင်ပါတယ်။
3. Transfer (လွှဲပြောင်းခြင်း)
Risk ကို ကိုယ်တိုင် မယူဘဲ သူများဆီ လွှဲလိုက်တာပါ။
- Example: Server Security အတွက် ကိုယ်တိုင် တာဝန်မယူချင်ရင်၊ Cloud Provider (AWS, Google Cloud) သုံးလိုက်တာမျိုး၊ Insurance (အာမခံ) ဝယ်ထားတာမျိုးပါ။
4. Acceptance (လက်ခံခြင်း)
Acceptance ဆိုတာ Risk ကို မသိမသာ လွှတ်ထားတာ (သို့) တာဝန်မယူချင်တာ မဟုတ်ပါဘူး။ Risk ရဲ့ Probability, Impact, Cost ကို သေချာတွက်ချက်ပြီး၊ ဖြေရှင်းရမယ့် ကုန်ကျစရိတ်က အလွန်များပြားနေတဲ့အတွက်၊ အမြင့်ဆုံး ဆုံးဖြတ်ချက်နဲ့ လက်ခံလိုက်ခြင်း (Calculated Decision) ဖြစ်ပါတယ်။
- Example: ငလျင်လှုပ်ရင် ရုံးပိတ်မယ် ဆိုတာမျိုးပါ။ ငလျင်မလှုပ်အောင် တားလို့မရသလို၊ ငလျင်ဒဏ်ခံ ရုံးခန်းဆောက်ဖို့လည်း Budget မရှိရင် "ဖြစ်လာရင်တော့ ပိတ်လိုက်မယ်" ဆိုပြီး Contingency Plan ဆွဲကာ လက်ခံထားရပါမယ်။
Monitoring (စောင့်ကြည့်ခြင်း)
Risk Management ဟာ Project အစမှာ တစ်ခါတည်း လုပ်ပြီး ပစ်ထားရမယ့် အရာ မဟုတ်ပါဘူး။ အပတ်စဉ် Meeting တွေမှာ Risk List ကို ပြန်စစ်ဆေးရပါမယ်။
Monitoring လုပ်ရာမှာ Risk တစ်ခုချင်းစီအတွက် Trigger Point (ဥပမာ – Error Rate > 5%, Cost > Budget 80%) သတ်မှတ်ထားသင့်ပါတယ်။ ဒါမှသာ Trigger Point ကို ထိလာရင် Risk ဖြစ်လာပြီလို့ သတ်မှတ်ပြီး၊ ခံစားနေရတာမျိုး မဟုတ်ဘဲ ချက်ချင်း သိသိသာသာ ကိုင်တွယ်ဖြေရှင်းနိုင်မှာ ဖြစ်ပါတယ်။
၁၂.၄ Business Continuity and Disaster Recovery Planning
Software Engineer တွေ အနေနဲ့ Technical ပိုင်းသာမက Business ပိုင်းဆိုင်ရာ ဆက်လက် လည်ပတ်နိုင်မှု (Continuity) ကိုပါ ထည့်သွင်း စဉ်းစားရပါမယ်။
Business Continuity Planning (BCP)
BCP ဆိုတာ "ကပ်ဘေး တစ်ခုခု (Disaster) ကြုံလာခဲ့ရင် လုပ်ငန်းကြီး ဆက်လက် လည်ပတ်နိုင်ဖို့ ဘာတွေ လုပ်မလဲ" ဆိုတဲ့ မဟာဗျူဟာ (Strategy) ဖြစ်ပါတယ်။
Software ကြောင့် မဟုတ်ဘဲ၊ ရုံးမီးလောင်သွားတာ၊ ကိုဗစ်ကပ်ရောဂါကြောင့် ရုံးတက်မရတာ၊ Cyber Attack ခံရတာ စတဲ့ အခြေအနေတွေမှာ ဝန်ထမ်းတွေ ဘယ်လို အလုပ်ဆက်လုပ်မလဲ၊ Customer တွေကို ဝန်ဆောင်မှု ဘယ်လို ဆက်ပေးမလဲ ဆိုတာ ပါဝင်ပါတယ်။
Disaster Recovery (DR)
DR ကတော့ BCP ရဲ့ အစိတ်အပိုင်း တစ်ခုဖြစ်ပြီး IT System တွေကို ဘယ်လို ပြန်ကယ်မလဲ (Restore) ဆိုတာကို အဓိက ထားပါတယ်။
DR Plan တစ်ခု ရေးဆွဲရာမှာ အရေးကြီးဆုံး Metric နှစ်ခု ရှိပါတယ်။
1. Recovery Point Objective (RPO)
"Data ဘယ်လောက် ပျက်စီးတာကို လက်ခံနိုင်မလဲ"
- RPO = 24 Hours ဆိုရင်၊ မနေ့က Backup လုပ်ထားတဲ့ နေရာကနေ ပြန်စမယ်။ ဒီနေ့ တစ်နေ့လုံး စာ Data တွေ ပျက်သွားတာကို လက်ခံမယ်လို့ ဆိုလိုတာပါ။
- Banking System တွေမှာတော့ RPO က Zero (0) နီးပါး ရှိရပါမယ်။
2. Recovery Time Objective (RTO)
"System ပြန်ကောင်းဖို့ အချိန် ဘယ်လောက် ပေးနိုင်မလဲ"
- RTO = 1 Hour ဆိုရင်၊ System Down ပြီး ၁ နာရီ အတွင်း ပြန်သုံးလို့ ရအောင် လုပ်ပေးရပါမယ်။
- RTO နည်းလေလေ၊ High Availability (HA) System တွေ တည်ဆောက်ရလေလေ ဖြစ်ပြီး ကုန်ကျစရိတ် ပိုများလေလေ ဖြစ်ပါတယ်။
timeline
title Disaster Recovery Timeline
Last Backup : RPO (Max Data Loss)
Disaster Strikes : System Goes Down
Recovery Starts : Log Analysis / Restore
System Restored : RTO (Max Downtime)
Critical Note: Disaster Recovery Plan ဟာ စာရွက်ပေါ်မှာ ရေးထားရုံနဲ့ မလုံလောက်ပါဘူး။ Periodic DR Drill (Restore Test) မလုပ်ရင်၊ တကယ် အရေးပေါ် အချိန်မှာ အလုပ်မလုပ်နိုင်တဲ့ Plan ဖြစ်သွားနိုင်ပါတယ်။ Backup လုပ်ထားရုံနဲ့ မပြီးဘဲ၊ Restore ပြန်လုပ်လို့ ရမရ စမ်းသပ်ထားမှသာ Plan ဟု ခေါ်ဆိုနိုင်ပါသည်။
Summary
Risk Management ဆိုတာ Project တစ်ခုအတွက် "အသက်အာမခံ" ဝယ်ထားသလိုပါပဲ။
- Identify: မကောင်းတာ ဘာဖြစ်နိုင်လဲ ကြိုတွေးပါ။ (Living Document အဖြစ်ထားပါ)
- Prioritize: ဘယ်ဟာက ငါတို့ကို သတ်နိုင်လဲ အရင်ရွေးပါ။ (Risk Owner သတ်မှတ်ပါ)
- Mitigate: မဖြစ်ခင် ကြိုကာကွယ်ပါ။ (Over-engineering မဖြစ်ပါစေနှင့်)
- Plan for Disaster: ဖြစ်လာရင်လည်း ဘယ်လို ပြန်ထမလဲ (RPO/RTO) တွက်ထားပြီး၊ ပုံမှန် ဇာတ်တိုက် လေ့ကျင့် (Test) ထားပါ။
Risk Management ဆိုတာ ပြဿနာ မဖြစ်အောင် ဆုတောင်းတာ မဟုတ်ဘဲ၊ ပြဿနာ ဖြစ်လာရင်တောင် ထိန်းချုပ်နိုင်အောင် ပြင်ဆင်ထားခြင်း ဖြစ်ပါတယ်။