Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Chủ đề 9 · Traceability & Quản lý Thay đổi Yêu cầu — Phân tích Tác động Thay đổi (Change Impact) bằng AI

AI cho BA — Toàn tập (10 chủ đề) Bài 67/80

Bài 3 — Phân tích Tác động Thay đổi (Change Impact) bằng AI

Bối cảnh

PO gửi một Change Request: "Đổi thời hạn giữ giỏ hàng từ 30 phút xuống 15 phút." Nghe nhỏ, nhưng nó có thể chạm tới: logic hết hạn phiên, job dọn giỏ hàng, thông báo nhắc khách, test hiệu năng, tài liệu API, và cả điều khoản hiển thị cho khách. Bỏ sót một mắt xích → lỗi dây chuyền. Impact analysis là kỹ năng lõi của BA, và AI giúp bạn lập bản đồ tác động nhanh, đầy đủ hơn.

Điều kiện tiên quyết: có RTM tốt

AI phân tích tác động chỉ mạnh khi bạn cho nó ngữ cảnh liên kết — chính là RTM ở Bài 2, cộng với mô tả kiến trúc/luồng nghiệp vụ. Không có RTM, AI chỉ đoán mò.

Ví dụ cụ thể + prompt mẫu

Bạn là trợ lý BA phân tích tác động thay đổi. 
Dưới đây là RTM rút gọn và một Change Request (CR).
Hãy phân tích và xuất theo cấu trúc:

1) DIỄN GIẢI CR: viết lại thay đổi bằng 1-2 câu rõ ràng, nêu giả định. 2) BẢNG TÁC ĐỘNG: cột = Artifact bị ảnh hưởng | Loại(Req/US/TC/Design/Doc) | Mức tác động(Cao/TB/Thấp) | Lý do | Hành động đề xuất. 3) TÁC ĐỘNG LAN TỎA (ripple): những thứ liên quan gián tiếp dễ bị quên (hiệu năng, bảo mật, báo cáo, trải nghiệm, pháp lý...). 4) CÂU HỎI CẦN LÀM RÕ với PO trước khi ước lượng. 5) RỦI RO nếu thực hiện thay đổi vội.

Nguyên tắc: chỉ dựa trên dữ liệu được cung cấp; nếu suy đoán ngoài dữ liệu, ghi rõ [SUY ĐOÁN].

[RTM] REQ-051: Giỏ hàng giữ 30 phút -> US-70 -> TC-40, TC-41; Design: SessionCartService. REQ-052: Nhắc khách trước khi giỏ hết hạn -> US-71 -> TC-42. REQ-060: Job dọn giỏ hết hạn chạy mỗi 10 phút -> TC-50.

[CHANGE REQUEST] CR-09: Đổi thời hạn giữ giỏ hàng từ 30 phút xuống 15 phút.

AI sẽ chỉ ra: TC-40/41 cần cập nhật mốc thời gian; REQ-052 (nhắc khách) phải tính lại thời điểm nhắc; REQ-060 job dọn mỗi 10 phút giờ có thể để giỏ "sống" tới 24 phút thực tế → mâu thuẫn cần điều chỉnh chu kỳ job. Đó là ripple mà mắt thường dễ bỏ.

Các bước thực hiện

  • Chốt phát biểu CR rõ ràng (con số, phạm vi, đối tượng).
  • Nạp RTM liên quan + mô tả job/luồng nền (những thứ không nằm trong story).
  • Chạy prompt impact ở trên.
  • Đọc kỹ mục ripple và câu hỏi làm rõ — đây là phần AI tạo giá trị lớn nhất.
  • Xác minh từng dòng "Mức tác động Cao" với dev/QA (đừng ước lượng effort chỉ từ AI).
  • Ghi kết quả vào phiếu CR + cập nhật RTM sau khi CR được duyệt.

Template phiếu Impact (tái dùng)

[CHANGE IMPACT REPORT]
CR-ID: ____  Người yêu cầu: ____  Ngày: ____
Mô tả thay đổi: ____
Giả định: ____

Artifact ảnh hưởng | Loại | Mức(C/TB/T) | Lý do | Hành động -------------------|------|-------------|-------|----------

Tác động lan tỏa cần kiểm tra: [ ] Hiệu năng [ ] Bảo mật [ ] Báo cáo/BI [ ] Job/batch nền [ ] Thông báo/email [ ] Pháp lý/điều khoản [ ] Tài liệu/API

Câu hỏi cho PO: ____ Rủi ro: ____ Đã xác minh với Dev/QA: (Y/N) ____

Sai lầm thường gặp

  • Coi ước lượng effort của AI là số thật. AI không biết codebase của bạn; nó suy đoán. Dùng nó để tìm ra chỗ bị ảnh hưởng, còn effort phải hỏi dev.
  • Ảo giác quan hệ. AI có thể khẳng định "CR-09 ảnh hưởng module thanh toán" dù RTM không có liên kết đó. Ép nó gắn nhãn [SUY ĐOÁN] cho mọi suy luận ngoài dữ liệu.
  • RTM lỗi thời → impact analysis sai từ gốc. Rác vào, rác ra. Giữ RTM cập nhật (Bài 7).
  • Phụ thuộc quá mức, bỏ bước hỏi PO. Nhiều tác động phụ thuộc vào ý định nghiệp vụ mà chỉ PO/khách trả lời được. AI không thay được cuộc hội thoại đó.
  • Rò rỉ dữ liệu: mô tả kiến trúc nội bộ có thể nhạy cảm; dùng công cụ được duyệt và mô tả ở mức trừu tượng đủ dùng.
> Impact analysis bằng AI biến bạn từ người "đoán ảnh hưởng" thành người "lập bản đồ ảnh hưởng có bằng chứng" — và luôn kết thúc bằng xác minh của con người.