98 lines
4.2 KiB
Markdown
98 lines
4.2 KiB
Markdown
# RISK — Sổ rủi ro & giả định — <Tên module/dự án>
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Version** | 1.0 |
|
||
| **Date** | YYYY-MM-DD |
|
||
| **Author** | <BA> (skill ba-1-discovery) |
|
||
| **Status** | 🟡 Draft |
|
||
| **Approved by** | — |
|
||
| **Source** | |
|
||
| **Scope** | |
|
||
|
||
---
|
||
|
||
## 1. Giả định (`ASM-nn`)
|
||
|
||
Mọi thứ đang tin là đúng nhưng **chưa ai xác nhận**. Giả định không ghi ra là giả định sẽ
|
||
nổ ở GĐ3 hoặc UAT.
|
||
|
||
| ID | Giả định | Ai/cái gì làm nó đúng | Cách xác minh | Hạn xác minh | Hệ quả nếu sai | Trạng thái |
|
||
|---|---|---|---|---|---|---|
|
||
| ASM-01 | | | | | | ☐ Chưa xác minh |
|
||
|
||
**Bốn chỗ giả định hay ẩn nấp — rà đích danh, đừng chờ nó tự lộ:**
|
||
|
||
| Chỗ | Giả định điển hình | Cách xác minh rẻ nhất |
|
||
|---|---|---|
|
||
| **Dữ liệu** | "Hệ thống cũ có sẵn trường này" | Mở DB/màn hình cũ ra xem, chụp màn hình |
|
||
| **Tích hợp** | "API bên kia trả về realtime" | Xin tài liệu API + gọi thử một lần |
|
||
| **Con người** | "Vận hành sẽ nhập liệu hằng ngày" | Hỏi thẳng chính người đó, không hỏi sếp họ |
|
||
| **Pháp lý** | "Được phép lưu thông tin này" | Gửi câu hỏi bằng văn bản cho pháp chế |
|
||
|
||
🔴 Giả định có **hệ quả nếu sai ở mức Cao** ⇒ nâng thành `RISK` và **xác minh ngay trong
|
||
GĐ1**. Để sang GĐ3 mới phát hiện thì phải viết lại spec.
|
||
|
||
## 2. Rủi ro (`RISK-nn`)
|
||
|
||
| ID | Mô tả rủi ro | Loại | Khả năng | Tác động | Mức | Người chịu trách nhiệm | Phương án ứng phó | Dấu hiệu sớm | Trạng thái |
|
||
|---|---|---|---|---|---|---|---|---|---|
|
||
| RISK-01 | | | Cao/TB/Thấp | Cao/TB/Thấp | 🔴/🟠/🟢 | | | | Mở |
|
||
|
||
**Viết rủi ro đúng cách** — công thức ba vế, thiếu vế nào cũng thành khẩu hiệu:
|
||
|
||
```
|
||
Vì <nguyên nhân có thật>, có thể xảy ra <sự kiện>, dẫn tới <hậu quả đo được>.
|
||
```
|
||
|
||
❌ "Rủi ro về tiến độ."
|
||
✅ "Vì hệ thống POS do bên thứ ba vận hành và chưa cam kết lịch mở API, có thể tới cuối
|
||
tháng 10 vẫn chưa tích hợp được, dẫn tới trượt go-live tháng 11 hoặc phải nhập tay
|
||
~3.000 giao dịch/ngày."
|
||
|
||
**Ma trận mức** — 3×3, mermaid không có loại sơ đồ này nên dùng bảng (`diagram-rules.md`):
|
||
|
||
| Tác động ↓ · Khả năng → | Thấp | Trung bình | Cao |
|
||
|---|---|---|---|
|
||
| **Cao** | 🟠 | 🔴 | 🔴 |
|
||
| **Trung bình** | 🟢 | 🟠 | 🔴 |
|
||
| **Thấp** | 🟢 | 🟢 | 🟠 |
|
||
|
||
🔴 = phải có phương án ứng phó và người chịu trách nhiệm **ngay trong GĐ1**, báo PM.
|
||
🟠 = theo dõi, rà lại ở mỗi gate.
|
||
🟢 = ghi nhận.
|
||
|
||
**Loại rủi ro — rà đủ 6 loại, đừng chỉ nghĩ tới tiến độ:**
|
||
|
||
| Loại | Câu hỏi rà |
|
||
|---|---|
|
||
| Nghiệp vụ | Hiểu sai quy trình? Bỏ sót ngoại lệ quan trọng? |
|
||
| Dữ liệu | Dữ liệu cũ bẩn? Không migrate được? Không đối chiếu được? |
|
||
| Tích hợp | Bên thứ ba không sẵn sàng? Đổi contract giữa chừng? |
|
||
| Con người | Người dùng không chịu đổi thói quen? Người biết nghiệp vụ nghỉ việc? |
|
||
| Tuân thủ | Vi phạm quy định về dữ liệu cá nhân? Thiếu lưu vết? |
|
||
| Tổ chức | Hai bên stakeholder mâu thuẫn chưa giải quyết? Không ai ký được? |
|
||
|
||
## 3. Phụ thuộc bên ngoài
|
||
|
||
*Những thứ dự án cần nhưng không tự quyết được.*
|
||
|
||
| # | Phụ thuộc vào | Bên nào | Cần trước ngày | Nếu trễ thì sao | Đầu mối | Trạng thái |
|
||
|---|---|---|---|---|---|---|
|
||
|
||
## 4. Rủi ro đã đóng
|
||
|
||
*Giữ lại, không xoá — để lần sau biết cái gì từng xảy ra và xử lý thế nào.*
|
||
|
||
| ID | Rủi ro | Ngày đóng | Kết cục | Bài học |
|
||
|---|---|---|---|---|
|
||
|
||
## 5. Lịch rà soát
|
||
|
||
| Mốc | Việc |
|
||
|---|---|
|
||
| Mỗi gate | Rà toàn bộ 🔴 và 🟠, cập nhật trạng thái |
|
||
| GĐ3 bắt đầu | Mọi `ASM` phải chuyển sang **đã xác minh** hoặc thành `RISK` |
|
||
| GĐ4 UAT | Rà rủi ro con người và dữ liệu — đây là lúc chúng hiện hình |
|
||
| GĐ5 | Chuyển bài học vào `BENEFIT` |
|