# CR — Change Request — `CR-nnn`

| | |
|---|---|
| **ID** | CR-001 |
| **Ngày nhận** | YYYY-MM-DD |
| **Người đề xuất** | |
| **Kênh** | |
| **Ưu tiên đề xuất** | Khẩn / Cao / Trung bình / Thấp |
| **Trạng thái** | 🟡 Đang đánh giá / 🟠 Chờ PO quyết / ✅ Chấp nhận / ⏸ Hoãn / ❌ Từ chối |
| **Author** | <BA> (skill ba-4-delivery-support) |
| **Liên quan** | US-011 · SRS_US011 v1.2 · AC-05 |

---

## 0. Phân loại — làm trước mọi thứ khác

> 🔴 Đây là phân loại tốn kém nhất khi làm sai. Áp dụng phép thử **máy móc**, không theo cảm tính.

```mermaid
flowchart TD
    Q1{"Sản phẩm có làm đúng<br/>tài liệu đã ký (SRS Baselined)?"}
    Q2{"Tài liệu có nói về<br/>tình huống này không?"}
    D(["DEFECT<br/>Dev sửa, không tính thêm chi phí<br/>→ Đóng phiếu này"])
    CR(["CHANGE REQUEST<br/>PO quyết<br/>→ Tiếp tục §1"])
    GAP(["SPEC GAP<br/>Thiếu sót đặc tả, trách nhiệm BA<br/>→ Tiếp tục, xem §0.1"])

    Q1 -->|KHÔNG| D
    Q1 -->|CÓ| Q2
    Q2 -->|"CÓ, khách muốn khác đi"| CR
    Q2 -->|"KHÔNG nói gì"| GAP
```

| | |
|---|---|
| **Kết luận** | Defect / Change Request / **Spec gap** |
| **Căn cứ** | *(trích đích danh mục tài liệu — không viết "theo tôi nghĩ")* |

### 0.1 Nếu là Spec gap

Tài liệu im lặng về tình huống này ⇒ **thiếu sót của đặc tả, trách nhiệm thuộc BA**.

| | |
|---|---|
| Vì sao đặc tả bỏ sót | |
| Lẽ ra phải nằm ở mục nào | |
| Đưa vào bài học GĐ5 | ☐ |

Xử lý tiếp như một CR (đánh giá tác động, PO quyết), nhưng **nói rõ nguyên nhân gốc** —
đừng đẩy sang khách như CR bình thường, cũng đừng nhận là bug của dev.

---

## 1. Yêu cầu — nguyên văn

> "…"

*Chép nguyên văn. Diễn giải lại theo ý mình là cách làm mất thông tin ngay từ bước đầu.*

## 2. Làm rõ — vấn đề gốc là gì

> 🔴 **Bước cứu được nhiều tiền nhất.** Khách nói "thêm cột X vào bảng" → hỏi *"để làm gì?"*
> → hoá ra để tìm nhanh hơn → hoá ra chỉ cần thêm bộ lọc, rẻ hơn nhiều.

| Câu hỏi | Trả lời |
|---|---|
| Việc này giải quyết vấn đề gì? | |
| Hiện tại không có nó thì xử lý thế nào? | |
| Bao lâu gặp một lần? Ai gặp? | |
| Nếu để sau bản phát hành này thì sao? | |
| Có cách nào khác đạt cùng kết quả không? | |

**Vấn đề gốc:**
> *(phát biểu lại bằng ngôn ngữ vấn đề, không phải ngôn ngữ giải pháp)*

## 3. Đánh giá tác động

*Rà đủ 6 trục như `IMPACT` ở GĐ2.*

| Trục | Tác động | Mức |
|---|---|---|
| Màn hình/chức năng | | 🔴/🟠/🟢 |
| Dữ liệu | | |
| Business rule | | |
| Phân quyền | | |
| Tích hợp | | |
| Báo cáo/đối soát | | |

**Tài liệu phải sửa:**

| Tài liệu | Mục | Version hiện tại → mới |
|---|---|---|
| SRS_US011 | §2.3.3, §4.1 | v1.2 → v1.3 |
| AC_US011 | AC-05, AC-09 | |
| RTM | | |

**Ảnh hưởng tới việc đã làm:**

| | |
|---|---|
| Code đã viết phải sửa | |
| Test case phải viết lại | |
| Đã UAT rồi thì phải test lại phần nào | |

**Ước lượng** *(làm cùng dev, không ước lượng một mình)*:

| Hạng mục | Công sức | Ai ước lượng |
|---|---|---|
| Phân tích + sửa tài liệu | | BA |
| Phát triển | | Dev |
| Kiểm thử | | QA |
| **Tổng** | | |

**Ảnh hưởng tiến độ:** …

## 4. Phương án

> 🔴 **Luôn trình ≥2 phương án.** Một phương án không phải là lựa chọn, đó là thông báo.

| # | Phương án | Công sức | Rủi ro | Đáp ứng vấn đề gốc |
|---|---|---|---|---|
| A | Làm đúng như đề xuất | | | Hoàn toàn |
| B | Giải pháp thay thế rẻ hơn | | | Một phần — thiếu … |
| C | Hoãn sang phase sau | 0 | Người dùng phải làm tay tới … | Không |

**Khuyến nghị của BA:** Phương án … vì …

*(Khuyến nghị, không phải quyết định — nguyên tắc 2.)*

## 5. Quyết định của PO

| | |
|---|---|
| **Người quyết** | |
| **Ngày** | |
| **Quyết định** | ✅ Chấp nhận PA… / ⏸ Hoãn tới… / ❌ Từ chối |
| **Lý do** | |
| **Ghi vào** | `DEC-nn` trong `00-index/` |
| **Ảnh hưởng tiến độ được chấp nhận** | |
| **Chi phí được chấp nhận** | |

## 6. Thực thi

> Thứ tự bắt buộc: **sửa tài liệu trước, code sau.** Ngược lại thì tài liệu không bao giờ đuổi kịp.

| # | Việc | Ai | Hạn | Trạng thái |
|---|---|---|---|---|
| 1 | Sửa SRS + tăng version + Change Log | BA | | ☐ |
| 2 | Cập nhật RTM | BA | | ☐ |
| 3 | **Báo cho team** (dev, QA, ai đã đọc bản cũ) | BA | | ☐ |
| 4 | Sửa code | Dev | | ☐ |
| 5 | Cập nhật test case | QA | | ☐ |
| 6 | Test lại phạm vi hồi quy | QA | | ☐ |

## 7. Đóng phiếu

| | |
|---|---|
| Ngày đóng | |
| Đã verify | ☐ |
| Người xác nhận | |

---

# Sổ tổng hợp CR

| ID | Ngày | Người đề xuất | Tóm tắt | Loại | Công sức | Trạng thái | Quyết định | Ngày quyết |
|---|---|---|---|---|---|---|---|---|
| CR-001 | | | | CR | 3d | ✅ | PA-B | |

**Thống kê:**

| Chỉ số | Giá trị | Ý nghĩa nếu cao |
|---|---|---|
| Tổng CR | | |
| Trong đó **Spec gap** | | 🔴 Đặc tả GĐ3 chưa kỹ — rà lại checklist G3 |
| Trong đó bị phân loại nhầm ban đầu | | Cần thống nhất lại phép thử §0 với team |
| Tổng công sức phát sinh | | So với ước lượng ban đầu |
| CR chờ quyết > 5 ngày | | 🔴 Đang chặn team |