Bài 2 — Dùng AI nháp BRD từ ghi chú phỏng vấn stakeholder

BRD (Business Requirements Document) trả lời câu hỏi "Nghiệp vụ cần gì và tại sao?" — nó nói về mục tiêu kinh doanh, phạm vi, các bên liên quan, yêu cầu ở mức nghiệp vụ, chứ chưa đi vào chi tiết kỹ thuật. Đây là tài liệu tốn nhiều công viết nhất và cũng là nơi AI giúp bạn tiết kiệm nhiều nhất.

Vấn đề thực tế

Sau 2–3 buổi phỏng vấn, bạn có một mớ ghi chú rời rạc, câu chưa hoàn chỉnh, ý trùng lặp, thứ tự lộn xộn. Việc biến nó thành BRD mạch lạc thường mất cả ngày. AI làm phần "sắp xếp + diễn đạt" cực nhanh, để bạn tập trung vào phần "kiểm định + bổ sung".

Cấu trúc BRD chuẩn (template tái sử dụng)

Bối cảnh & Vấn đề nghiệp vụ (Business Context & Problem)
Mục tiêu & Chỉ số thành công (Objectives & Success Metrics)
Phạm vi (In-scope / Out-of-scope)
Các bên liên quan (Stakeholders & vai trò)
Yêu cầu nghiệp vụ (Business Requirements, đánh số BR-xx)
Ràng buộc & Giả định (Constraints & Assumptions)
Rủi ro (Risks)
Câu hỏi mở (Open Questions)

Prompt mẫu để nháp BRD

Vai trò: Bạn là Senior Business Analyst.
Nhiệm vụ: Từ ghi chú phỏng vấn thô bên dưới, soạn BRD theo đúng 8 mục:
1) Bối cảnh & Vấn đề  2) Mục tiêu & Chỉ số thành công
3) Phạm vi (In/Out)   4) Stakeholders & vai trò
5) Yêu cầu nghiệp vụ (đánh số BR-01, BR-02...)
6) Ràng buộc & Giả định  7) Rủi ro  8) Câu hỏi mở
Quy tắc:
CHỈ dùng thông tin có trong ghi chú. Không suy diễn thêm yêu cầu.
Nếu một mục thiếu dữ liệu, ghi "[Cần làm rõ]" và đưa câu hỏi vào mục 8.
Mỗi Business Requirement viết dạng: "Là <vai trò>, tôi cần <điều gì> để <lợi ích>."
Giọng văn trang trọng, ngắn gọn, tiếng Việt.

Ghi chú phỏng vấn:
"""
[dán ghi chú]
"""

Các bước làm từng bước

Gom & dán ghi chú thô (đã ẩn dữ liệu nhạy cảm) vào phần cuối prompt.
Chạy prompt, nhận bản BRD nháp 8 mục.
Đối chiếu mục 5 với ghi chú gốc: mỗi BR có thật sự bắt nguồn từ điều stakeholder nói không? Xóa những BR bị AI "vẽ thêm".
Đọc mục 8 (Câu hỏi mở): đây là danh sách vàng — gửi lại stakeholder để chốt.
Bổ sung phần AI không biết: ngữ cảnh nội bộ, ưu tiên, deadline — những thứ chỉ bạn nắm.
Chạy vòng soát lần 2 (xem Bài 5) để tìm mâu thuẫn.

Ví dụ minh họa

Ghi chú: "Sales than mất khách vì báo giá chậm. Muốn hệ thống tự tạo báo giá từ danh mục sản phẩm. Giám đốc muốn duyệt báo giá trên 100 triệu. Cần xem lịch sử báo giá của từng khách."

AI có thể nháp:

BR-01: Là nhân viên Sales, tôi cần tạo báo giá tự động từ danh mục sản phẩm để rút ngắn thời gian phản hồi khách hàng.
BR-02: Là Giám đốc, tôi cần duyệt các báo giá có giá trị trên 100 triệu để kiểm soát rủi ro tài chính.
BR-03: Là nhân viên Sales, tôi cần xem lịch sử báo giá theo từng khách hàng để chăm sóc nhất quán.
Câu hỏi mở: Ngưỡng 100 triệu tính theo trước hay sau thuế? Ai duyệt khi Giám đốc vắng?

Câu hỏi mở thứ hai là thứ AI nên hỏi chứ không tự trả lời — đó là chất lượng tốt.

Checklist review BRD nháp

[ ] Mỗi BR truy được về một câu stakeholder đã nói.
[ ] Không có yêu cầu "lạ" mà không ai đề cập.
[ ] Có In-scope và Out-of-scope rõ ràng.
[ ] Chỉ số thành công đo được (không phải "nhanh hơn" chung chung).
[ ] Câu hỏi mở đã được gom để gửi stakeholder.

Sai lầm thường gặp

Bịa yêu cầu (hallucination): AI hay thêm các mục "chuẩn công nghiệp" như "phân quyền", "audit log" dù stakeholder chưa nói. Không sai về mặt best practice, nhưng đưa vào BRD như thể khách đã yêu cầu là sai bản chất — hãy đánh dấu "đề xuất của BA" thay vì trộn lẫn.

Bỏ mục Out-of-scope: thiếu ranh giới phạm vi là nguồn gốc của scope creep. Ép AI luôn có mục này.

Rò rỉ: BRD thường chứa tên dự án, tên khách hàng lớn — cân nhắc ẩn danh trước khi đưa vào AI công cộng.

Phụ thuộc quá mức: đừng gửi thẳng BRD do AI viết cho stakeholder mà chưa đọc kỹ — bạn là người chịu trách nhiệm, không phải AI.

Template sẵn dùng: PRD (Product Requirements Document) + BRD vs PRD

PRODUCT REQUIREMENTS DOCUMENT (PRD)
Sản phẩm / Tính năng: [Tên]        PM/PO: [Tên]        Ngày: [ ]
>> BRD khác PRD: BRD nói DOANH NGHIỆP cần gì & VÌ SAO (do BA viết, cấp cao, cho lãnh đạo duyệt).
   PRD nói SẢN PHẨM phải LÀM GÌ & HÀNH XỬ RA SAO (chi tiết tính năng, cho dev/design/QA). Thứ tự: BRD → PRD → SRS.
TỔNG QUAN & MỤC TIÊU
   [Sản phẩm/tính năng này là gì, giải quyết vấn đề gì, mục tiêu đo bằng chỉ số nào]
NGƯỜI DÙNG MỤC TIÊU (persona)
   - [Ai dùng? Bối cảnh, nhu cầu, nỗi đau chính]
VẤN ĐỀ NGƯỜI DÙNG
   [Mô tả vấn đề từ góc nhìn người dùng — vì sao đáng giải]
USER STORIES / TÍNH NĂNG CHÍNH
   - Là <ai>, tôi muốn <việc>, để <giá trị>.
   - [ ]
LUỒNG NGƯỜI DÙNG (user flow)
   [Bước 1 → 2 → 3 …; đính kèm wireframe / sơ đồ nếu có]
YÊU CẦU CHỨC NĂNG (FR)
   FR-1: [Hệ thống phải …]      FR-2: [ ]
YÊU CẦU PHI CHỨC NĂNG (NFR)
   - Hiệu năng: [VD: tải ≤ 2 giây]     - Bảo mật: [ ]     - Khả dụng / Tương thích: [ ]
CHỈ SỐ THÀNH CÔNG (success metrics)
   [VD: tỷ lệ hoàn tất tăng từ X% lên Y%]
NGOÀI PHẠM VI (out of scope)
   [ ]
PHỤ THUỘC & CÂU HỎI CÒN MỞ
   [ ]=== MẸO ===
PRD để dev/design/QA đọc là BUILD được. Mỗi tính năng nên kèm Acceptance Criteria (Given/When/Then).

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

Buổi 1 · BRD, SRS & Tài liệu Yêu cầu