Tuần 6 • Buổi 2 — Traceability (RTM) & Ưu tiên yêu cầu

RTM và Ưu tiên yêu cầu — Kiểm soát scope và focus vào đúng việc

Một trong những thách thức lớn nhất của BA là trả lời câu hỏi: "Chúng ta có build đúng thứ không?" và "Trong 50 yêu cầu này, nên làm cái nào trước?" Buổi học này trang bị cho bạn hai công cụ cực mạnh: Requirements Traceability Matrix (RTM) để đảm bảo không bỏ sót, và MoSCoW + Value/Effort Matrix để ưu tiên đúng.

---

1. Requirements Traceability Matrix (RTM) là gì?

RTM là bảng ánh xạ giữa yêu cầu business và các artifact khác: design, test case, code, và kết quả UAT. Nó giúp bạn trả lời:

• "Yêu cầu BR-05 đã được test case nào cover?"
• "Test case TC-12 đang test cho yêu cầu nào?"
• "Tính năng X đã pass UAT chưa?"

Ví dụ RTM đơn giản cho dự án App đặt xe (kiểu Grab):

Các loại traceability:

• Forward Traceability: Business Requirement → Test Case (đảm bảo mọi yêu cầu đều được test)
• Backward Traceability: Test Case → Business Requirement (đảm bảo không có test "thừa" không liên quan đến yêu cầu)
• Bidirectional: Cả hai chiều — đây là gold standard cho dự án phức tạp

---

2. Khi nào cần RTM?

RTM đặc biệt quan trọng trong:

• Dự án outsource/contract: Client cần bằng chứng mọi yêu cầu đã được implement
• Dự án regulated (fintech, healthcare, insurance): Audit trail là bắt buộc
• Dự án lớn với nhiều stakeholder: Tránh tranh cãi "cái này đã được nói trong spec chưa?"
• UAT (User Acceptance Testing): Business team dùng RTM để verify từng yêu cầu

Đối với dự án agile nhỏ, RTM có thể nhẹ hơn — chỉ cần link Jira story với test case trên Jira là đủ.

---

3. Quản lý thay đổi yêu cầu (Change Request)

Yêu cầu LUÔN thay đổi — BA giỏi không ngăn chặn thay đổi mà quản lý nó.

Change Request Process:

• Thu thập yêu cầu thay đổi: Stakeholder gửi email/Jira ticket
• Phân tích impact: Ảnh hưởng đến scope, timeline, cost như thế nào?
• Cập nhật RTM: Requirement ID mới hoặc sửa requirement cũ
• Approval: PO/PM phê duyệt trước khi dev bắt đầu
• Communicate: Thông báo cho dev, QA, design về thay đổi
• Update documentation: Cập nhật BRD, Jira, test cases

> Cạm bẫy cần tránh: "Scope creep" — thay đổi nhỏ tích lũy thành thay đổi lớn mà không ai nhận ra. Dùng RTM giúp bạn thấy một thay đổi ảnh hưởng đến bao nhiêu test case và stories.

---

4. MoSCoW Prioritization

MoSCoW là framework phân loại yêu cầu theo 4 nhóm:

Quy tắc MoSCoW:

• Must Have không được quá 60% scope — nếu mọi thứ đều Must Have thì không ai được ưu tiên
• Won't Have quan trọng để set expectation với stakeholder, không phải từ chối vĩnh viễn
• Revisit mỗi sprint planning — Could Have hôm nay có thể thành Must Have sprint sau

---

5. Value/Effort Matrix (Ma trận 2x2)

Value/Effort Matrix đặt yêu cầu vào 4 ô dựa trên 2 chiều:

         HIGH VALUE
              │
  Quick Wins  │  Major Projects
  (Làm ngay) │  (Lên kế hoạch)
─────────────┼─────────────────
  Fill-ins   │  Thankless Tasks
  (Nếu rảnh) │  (Tránh/xem lại)
              │
         LOW VALUE
    LOW EFFORT    HIGH EFFORT

• Quick Wins (High Value, Low Effort): Ưu tiên số 1 — return on investment cao nhất
• Major Projects (High Value, High Effort): Lên kế hoạch kỹ, chia nhỏ thành nhiều sprint
• Fill-ins (Low Value, Low Effort): Làm khi team có slack time, không ép deadline
• Thankless Tasks (Low Value, High Effort): Nên tránh hoặc tìm cách đơn giản hóa

Ví dụ thực tế: Tại một startup edtech Hà Nội, BA dùng Value/Effort Matrix để thuyết phục PO không làm tính năng "Gamified Avatar" (High Effort, Low Value) mà thay bằng "Smart Resume" — tự động quay lại chỗ học dở (Low Effort, High Value).

---

6. Kết hợp MoSCoW và Value/Effort

Trong thực tế, hai framework này bổ sung cho nhau:

• Dùng MoSCoW để phân loại Must/Should/Could/Won't
• Trong nhóm Must Have, dùng Value/Effort để sắp xếp thứ tự build
• Kết quả: Backlog được sắp xếp logic, dễ trình bày cho stakeholder

---

Tự luyện

• Chọn 10 yêu cầu từ bài tập Buổi 1 (hoặc từ dự án thực tế), phân loại bằng MoSCoW. Sau đó vẽ Value/Effort Matrix cho 5 yêu cầu Must Have.
• Tạo RTM đơn giản (Excel/Google Sheets) cho 5 yêu cầu: cột Req ID, Mô tả, Story Jira, Test Case, UAT Status.
• Giả sử stakeholder đột ngột yêu cầu thêm tính năng mới vào sprint đang chạy. Viết quy trình Change Request 5 bước bạn sẽ thực hiện.