Bài 1 — Vì sao BA cần AI cho tài liệu yêu cầu: bối cảnh & cạm bẫy

Một Business Analyst (BA) trung bình dành 40–60% thời gian cho việc viết và chỉnh sửa tài liệu: BRD (Business Requirements Document), SRS (Software Requirements Specification), FRS (Functional Requirements Specification), user story, biên bản họp. Phần lớn thời gian đó không nằm ở tư duy nghiệp vụ mà ở thao tác cơ học: gõ lại ghi chú phỏng vấn thành câu hoàn chỉnh, định dạng theo template, dò lại xem có thiếu mục nào, viết lại cho mượt.

Đây chính là chỗ AI tạo giá trị lớn nhất cho BA. AI không thay bạn quyết định nghiệp vụ, nhưng nó rút ngắn khủng khiếp phần thao tác: từ ghi chú lộn xộn sau buổi phỏng vấn stakeholder, AI có thể nháp ra bản BRD 8 mục có cấu trúc trong 2 phút — thứ trước đây bạn mất nửa ngày.

Ba tác vụ AI làm tốt ngay cho BA

• Nháp đầu tiên (first draft): biến gạch đầu dòng thô thành văn bản có cấu trúc theo template.
• Chuẩn hóa & định dạng: ép nội dung vào đúng khung mục lục, đúng giọng văn, đúng thuật ngữ công ty.
• Soát chất lượng: tìm yêu cầu mơ hồ, mâu thuẫn, thiếu tiêu chí chấp nhận (acceptance criteria), thiếu non-functional requirement.

Ví dụ cụ thể

Sau buổi phỏng vấn phòng Kế toán, ghi chú của bạn là:

> "Kế toán muốn export báo cáo công nợ ra Excel. Cần lọc theo khách hàng, theo tháng. Sếp kế toán nói phải có nút gửi email báo cáo. Ai cũng than báo cáo hiện tại load chậm."

Bạn có thể yêu cầu AI biến nó thành các yêu cầu chức năng đánh số, kèm ghi chú chỗ còn thiếu. Dưới đây là prompt khởi đầu:

Bạn là BA cấp cao. Từ ghi chú phỏng vấn thô dưới đây, hãy:
Liệt kê các Functional Requirement, đánh số FR-01, FR-02...
Với mỗi FR ghi rõ: mô tả, tác nhân (actor), điều kiện.
Ở cuối, liệt kê "Câu hỏi cần làm rõ" cho những chỗ ghi chú chưa đủ.
Không tự bịa thông tin không có trong ghi chú.
Ghi chú:
"""
[dán ghi chú vào đây]
"""

Dòng "Không tự bịa thông tin" và mục "Câu hỏi cần làm rõ" là hai lớp bảo vệ quan trọng — chúng ta sẽ dùng lại xuyên suốt khóa.

Các bước bắt đầu ngay hôm nay

• Chọn một tài liệu bạn đang phải viết tuần này (BRD nhỏ hoặc vài user story).
• Gom ghi chú thô lại vào một chỗ (Google Docs/Notepad).
• Chạy prompt nháp ở trên với ghi chú thật.
• Đọc bản nháp AI, không copy mù — sửa mọi chỗ sai, xóa mọi chỗ bịa.
• Ghi lại: AI đúng bao nhiêu %, sai chỗ nào. Đây là baseline để bạn cải thiện prompt.

Checklist "AI-ready" cho BA (tái sử dụng)

• [ ] Tôi đã tách rõ: đâu là dữ kiện từ stakeholder, đâu là suy diễn của tôi.
• [ ] Prompt của tôi có yêu cầu "không bịa" và "liệt kê chỗ thiếu".
• [ ] Tôi đã ẩn/giả lập dữ liệu nhạy cảm (tên khách hàng thật, số liệu mật) trước khi dán vào AI.
• [ ] Tôi sẽ tự review bản nháp AI trước khi gửi bất kỳ ai.
• [ ] Tôi lưu lại prompt hiệu quả để dùng lần sau.

Sai lầm thường gặp

1. Coi bản nháp AI là bản cuối. AI viết trôi chảy nên dễ tạo cảm giác "đúng". Nhưng văn hay không có nghĩa là đúng nghiệp vụ. Luôn xem đó là nháp.

2. Ảo giác (hallucination). AI có thể tự "phát minh" ra một yêu cầu nghe rất hợp lý mà stakeholder chưa từng nói — ví dụ tự thêm "hỗ trợ đa ngôn ngữ". Nếu bạn không kiểm, nó lọt vào BRD và biến thành cam kết sai. Cách chống: bắt AI trích dẫn ghi chú gốc và tách riêng phần suy diễn.

3. Rò rỉ dữ liệu. Dán nguyên hợp đồng, số liệu tài chính, dữ liệu khách hàng vào công cụ AI công cộng có thể vi phạm chính sách bảo mật công ty. Luôn ẩn danh dữ liệu nhạy cảm hoặc dùng công cụ AI được công ty phê duyệt.

4. Phụ thuộc quá mức. Nếu bạn để AI làm hết, kỹ năng tư duy yêu cầu của bạn sẽ mai một, và bạn mất khả năng phát hiện khi AI sai. AI là đòn bẩy, không phải người thay thế.

Tóm lại: Bài này đặt tư duy nền — AI là công cụ tăng tốc thao tác, còn phán đoán nghiệp vụ vẫn là của bạn. Các bài sau đi sâu vào từng loại tài liệu.

Template sẵn dùng: BRD (Business Requirements Document)

BUSINESS REQUIREMENTS DOCUMENT (BRD)
Dự án: [Tên dự án]        Người viết (BA): [Tên]        Ngày: [ ]
VẤN ĐỀ KINH DOANH (vì sao làm)
   [Mô tả vấn đề/cơ hội. Ai đang chịu ảnh hưởng? Tốn kém/rủi ro gì?]
MỤC TIÊU & CHỈ SỐ THÀNH CÔNG
   - Mục tiêu: [ ]
   - Đo bằng: [chỉ số + con số mục tiêu]
PHẠM VI
   Trong phạm vi (in scope): [ ]
   Ngoài phạm vi (out of scope): [ ]
STAKEHOLDER
   - Người quyết định: [ ]      - Người dùng cuối: [ ]      - Bên liên quan khác: [ ]
YÊU CẦU CHỨC NĂNG (mỗi dòng một yêu cầu, đánh số FR-1, FR-2…)
   FR-1: [Hệ thống phải cho phép …]
   FR-2: [ ]
YÊU CẦU PHI CHỨC NĂNG (hiệu năng, bảo mật, khả dụng…)
   NFR-1: [VD: trang tải ≤ 2 giây với 1000 người dùng đồng thời]
RỦI RO & GIẢ ĐỊNH
   - Giả định: [ ]      - Rủi ro: [ ] → cách giảm thiểu: [ ]
PHỤ LỤC: sơ đồ quy trình, wireframe, thuật ngữ.

=== MẸO ===
Viết để CẢ business lẫn dev đều hiểu. Mỗi yêu cầu phải kiểm thử được: đọc xong biết "làm sao để nghiệm thu".

Tải xuống: Word (.docx) · Markdown (.md) · Dùng công cụ tương tác