"Risk management là không để bất ngờ xảy ra. Nếu bạn bất ngờ, bạn đã thất bại ở khâu nhận diện." - Tom DeMarco
1. Risk Identification Techniques
1.1 Brainstorming Sessions
Tổ chức workshop với cross-functional team (dev, QA, PO, ops):
- Timebox 60 phút, mỗi người viết risk lên sticky note
- Nhóm theo category: Technical, Schedule, Resource, External
- Không judge trong giai đoạn brainstorm - quantity over quality
1.2 Checklist-Based Identification
Dùng checklist chuẩn để không bỏ sót rủi ro phổ biến:
| Category | Câu hỏi kiểm tra |
|---|---|
| Technology | Có dùng tech mới team chưa kinh nghiệm? |
| Integration | Có phụ thuộc API bên thứ 3 không kiểm soát? |
| Performance | Đã có benchmark cho expected load? |
| Security | Có xử lý PII/payment data? |
| Team | Có key person dependency (bus factor = 1)? |
| Timeline | Deadline có fixed bởi external event (compliance, marketing)? |
| Infrastructure | Có single point of failure? |
| Data | Migration data lớn hoặc phức tạp? |
1.3 SWOT Analysis cho Software Projects
┌─────────────────────────┬─────────────────────────┐
│ STRENGTHS │ WEAKNESSES │
│ - Team kinh nghiệm .NET│ - Thiếu DevOps engineer │
│ - CI/CD pipeline mature │ - Legacy codebase phức │
│ - Good test coverage │ tạp, ít documentation │
├─────────────────────────┼─────────────────────────┤
│ OPPORTUNITIES │ THREATS │
│ - Cloud migration giảm │ - Vendor lock-in với │
│ cost infrastructure │ third-party API │
│ - .NET 8 performance │ - Key developer có thể │
│ improvements │ nghỉ việc Q2 │
└─────────────────────────┴─────────────────────────┘
2. Risk Assessment Matrix
Probability x Impact Grid
| Impact: Low (1) | Impact: Medium (2) | Impact: High (3) | Impact: Critical (4) | |
|---|---|---|---|---|
| Probability: High (4) | 4 - Medium | 8 - High | 12 - Critical | 16 - Critical |
| Probability: Medium (3) | 3 - Low | 6 - Medium | 9 - High | 12 - Critical |
| Probability: Low (2) | 2 - Low | 4 - Medium | 6 - Medium | 8 - High |
| Probability: Rare (1) | 1 - Low | 2 - Low | 3 - Low | 4 - Medium |
Scoring Guide
Probability:
- Rare (1): < 10% xảy ra
- Low (2): 10-30%
- Medium (3): 30-60%
- High (4): > 60%
Impact:
- Low (1): Chậm 1-2 ngày, không ảnh hưởng scope
- Medium (2): Chậm 1 Sprint, cần điều chỉnh scope nhỏ
- High (3): Chậm > 1 Sprint, ảnh hưởng budget hoặc quality
- Critical (4): Dự án có thể fail, mất khách hàng, data breach
3. Mitigation Strategies - 4T Framework
Avoid (Tránh)
Loại bỏ hoàn toàn nguồn rủi ro.
| Rủi ro | Chiến lược Avoid |
|---|---|
| Tech mới chưa proven | Dùng tech đã quen, đã có production experience |
| Vendor lock-in | Dùng abstraction layer, multi-cloud strategy |
| Scope creep | Fixed scope contract, strict change control |
Transfer (Chuyển giao)
Chuyển rủi ro cho bên khác chịu.
- Outsource module phức tạp cho team chuyên gia
- SLA contract với third-party - nếu API down, vendor chịu penalty
- Insurance - cyber insurance cho data breach risk
- Cloud managed services - chuyển operational risk cho AWS/Azure
Mitigate (Giảm thiểu)
Giảm probability hoặc impact.
- Spike/PoC trước khi commit timeline → giảm technical uncertainty
- Automated testing → giảm probability regression bugs
- Cross-training → giảm impact khi key person nghỉ
- Blue-green deployment → giảm impact khi deploy lỗi
Accept (Chấp nhận)
Chấp nhận rủi ro khi cost mitigation > impact.
- Ghi nhận vào risk register
- Chuẩn bị contingency plan (kế hoạch dự phòng)
- Dành contingency budget (thường 10-20% tổng effort)
4. Technical Risk Register Template
| ID | Risk Description | Category | Prob (1-4) | Impact (1-4) | Score | Strategy | Mitigation Action | Owner | Status | Due Date |
|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | Third-party payment API thay đổi contract không báo trước | Integration | 3 | 4 | 12 | Mitigate | Tạo adapter pattern, viết contract test | Dev Lead | Open | Sprint 5 |
| R-002 | Senior dev nghỉ việc giữa dự án | Resource | 2 | 3 | 6 | Mitigate | Cross-training, pair programming, tài liệu hoá | Tech Lead | Open | Ongoing |
| R-003 | Database migration 10M records gây downtime | Technical | 3 | 3 | 9 | Mitigate | Dry-run trên staging, online migration strategy | DBA | Open | Sprint 4 |
| R-004 | Performance không đạt SLA 200ms response time | Technical | 2 | 4 | 8 | Mitigate | Load test sớm từ Sprint 2, caching strategy | Dev Lead | Open | Sprint 3 |
| R-005 | Compliance requirement thay đổi (GDPR update) | External | 1 | 4 | 4 | Accept | Monitor regulatory changes, contingency 2 Sprint | PO | Watch | Quarterly |
5. Sprint Risk Review
Khi nào review risk?
Tích hợp risk review vào các Scrum ceremonies:
| Ceremony | Risk Activity |
|---|---|
| Sprint Planning | Review risk register, xác định risk nào ảnh hưởng Sprint này |
| Daily Standup | Flag risk mới phát sinh (blockers = risks hiện thực hoá) |
| Sprint Review | Đánh giá lại risk score sau Sprint - có giảm chưa? |
| Retrospective | Bổ sung risk mới, đóng risk đã mitigate xong |
Risk Burndown
Track tổng risk score theo thời gian - giống burndown chart nhưng cho risk:
Risk Score
60 | ████
50 | ████ ███
40 | ████ ███ ██
30 | ████ ███ ██ ███
20 | ████ ███ ██ ███ ██
10 | ████ ███ ██ ███ ██ █
0 |________________________
S1 S2 S3 S4 S5 S6
Mục tiêu: Risk score phải giảm dần qua các Sprint. Nếu tăng, team cần escalate.
6. Common Software Project Risks and Mitigations
Top 10 Rủi Ro Phổ Biến
| # | Rủi ro | Probability | Mitigation |
|---|---|---|---|
| 1 | Scope creep - yêu cầu liên tục thay đổi | High | Change control process, MoSCoW prioritization |
| 2 | Unrealistic timeline - deadline không khả thi | High | Evidence-based estimation, velocity tracking |
| 3 | Key person dependency - bus factor = 1 | Medium | Pair programming, code review, documentation |
| 4 | Technical debt accumulation - code quality xuống dần | High | 20% Sprint capacity cho tech debt, quality gates |
| 5 | Third-party dependency failure - API down, vendor bỏ | Medium | Adapter pattern, fallback mechanisms, SLA contract |
| 6 | Security vulnerability - data breach, injection | Medium | SAST/DAST scanning, security Sprint, threat modeling |
| 7 | Performance degradation - hệ thống chậm dần | Medium | Load testing mỗi Sprint, APM monitoring |
| 8 | Integration failures - services không nói chuyện được | Medium | Contract testing, integration test environment |
| 9 | Team burnout - overtime liên tục | Medium | Sustainable pace, WIP limits, mental health check-in |
| 10 | Deployment failures - deploy gây outage | Low | Blue-green deploy, automated rollback, canary releases |
Risk Response Decision Tree
Session tiếp theo: Session 07 - Requirements Engineering sẽ đi sâu vào kỹ thuật thu thập và quản lý yêu cầu phần mềm.