Vấn đề thật của một Business Analyst đang đi làm
Bạn nhận một dòng yêu cầu từ Product Owner: "Cho khách đặt lại đơn cũ trong 2 click". Đến sprint planning, dev hỏi: đặt lại thì có giữ voucher không? Hết hàng thì sao? Địa chỉ cũ đã xóa thì lấy đâu? Bạn về viết lại story, chỉnh acceptance criteria (AC) ba lần, mỗi lần một kiểu format. Kết quả: mất nửa ngày cho một story, chất lượng phụ thuộc hôm đó bạn tỉnh hay mệt.
Bốn nỗi đau lặp đi lặp lại của BA khi viết yêu cầu:
- Chậm — mỗi story tốn 20–45 phút chỉ để gõ và định dạng, chưa tính suy nghĩ.
- Không đều tay — story của bạn hôm nay khác story tuần trước, người khác đọc không nhất quán.
- Sót edge case — chỉ nghĩ ra "happy path", để lọt lỗi trống dữ liệu, quá hạn, phân quyền... đến khi QA hoặc production mới lộ.
- AC mơ hồ — viết "hệ thống phải xử lý đúng" thì dev và tester mỗi người hiểu một kiểu, dẫn tới rework.
AI thay đổi điều gì (và KHÔNG thay đổi điều gì)
AI không hiểu nghiệp vụ công ty bạn. Nhưng AI cực giỏi ở phần cơ học: chuyển một ý thô thành story đúng cấu trúc, đề xuất một danh sách edge case để bạn chọn lọc, và viết AC dạng Gherkin sạch sẽ trong vài giây. Vai trò của bạn dịch chuyển từ người gõ chữ sang người biên tập và ra quyết định nghiệp vụ.
Mô hình tư duy suốt khóa học: BA quyết định — AI soạn thảo — BA review. AI không bao giờ là người chốt.
Ví dụ cụ thể: cùng một yêu cầu, hai cách làm
Yêu cầu thô: "Khách hàng muốn đặt lại đơn hàng đã mua trước đó."
Cách cũ (thủ công): bạn mở template, gõ "Là một khách hàng...", nghĩ AC, quên mất case hết hàng, gửi đi. 30 phút.
Cách mới (có AI): bạn dán một prompt có ngữ cảnh, AI trả về story + 6 AC + danh sách edge case gợi ý, bạn xóa 2 case không liên quan, sửa 1 quy tắc voucher theo policy công ty. 6 phút.
Bạn là BA cho một sàn thương mại điện tử tại Việt Nam.
Viết 1 user story theo mẫu "Là <vai trò>, tôi muốn <mục tiêu>, để <giá trị>"
cho yêu cầu sau: khách hàng đặt lại một đơn đã mua trước đó.Sau story, liệt kê 5-7 câu hỏi làm rõ nghiệp vụ mà tôi
(BA) cần hỏi Product Owner trước khi viết acceptance criteria.
Chỉ hỏi, KHÔNG tự bịa câu trả lời.
Lưu ý câu cuối: ta chủ động chặn AI bịa quy tắc nghiệp vụ — đây là kỷ luật cốt lõi ta sẽ dùng suốt khóa.
Các bước làm trong bài này
- Chọn 1 yêu cầu thô có thật trong công việc của bạn (một dòng cũng được).
- Dán prompt mẫu ở trên, thay ngữ cảnh cho đúng sản phẩm của bạn.
- Đọc danh sách câu hỏi làm rõ AI trả về — đây là "radar" phát hiện chỗ bạn chưa biết.
- Tự trả lời được câu nào thì trả lời, câu nào không thì mang đi hỏi PO thật.
- Lưu lại prompt vào một file "thư viện prompt" cá nhân để tái dùng.
Template tái dùng: "Khung ngữ cảnh 4 dòng"
Dán 4 dòng này lên đầu MỌI prompt viết story để AI bám đúng bối cảnh:
[Sản phẩm]: (vd: app giao đồ ăn B2C)
[Người dùng chính]: (vd: khách mua, tài xế, nhà hàng)
[Ràng buộc]: (vd: chỉ thanh toán VNĐ, tuân thủ nghị định 13 về dữ liệu cá nhân)
[Quy ước]: story theo mẫu Connextra, AC theo Gherkin tiếng Việt
Sai lầm thường gặp
- Coi output của AI là chân lý. AI có thể ảo giác một quy tắc nghiệp vụ nghe rất hợp lý ("đơn đặt lại tự động áp voucher cũ") mà công ty bạn không hề có. Luôn đối chiếu với PO/tài liệu thật.
- Dán dữ liệu nhạy cảm vào AI công cộng. Đừng dán tên khách, số điện thoại, dữ liệu thật của khách hàng vào ChatGPT bản miễn phí — nguy cơ rò rỉ dữ liệu. Dùng dữ liệu giả hoặc công cụ đã được công ty phê duyệt.
- Không cho ngữ cảnh. Prompt "viết story đặt lại đơn" chung chung sẽ cho story chung chung. Ngữ cảnh càng rõ, output càng dùng được.
- Phụ thuộc quá mức, mất kỹ năng nghề. Nếu bạn không còn tự đánh giá được story tốt hay xấu, bạn đã giao quyền quyết định nghiệp vụ cho một cỗ máy không chịu trách nhiệm. AI soạn thảo — bạn vẫn phải là chuyên gia nghiệp vụ.
Kết bài
Bài sau ta đi vào phần lõi: dùng AI sinh user story chuẩn cấu trúc từ một yêu cầu thô, với những prompt bạn có thể copy dùng ngay chiều nay.
Template sẵn dùng: User Story + Acceptance Criteria
USER STORY + ACCEPTANCE CRITERIA — mẫu điềnMẪU CÂU CHUYỆN:
Là <vai trò>, tôi muốn <việc gì>, để <giá trị/lý do>.
VÍ DỤ:
Là người mua đã đăng nhập, tôi muốn lưu bản nháp đơn,
để không mất dữ liệu khi thoát giữa chừng.
ACCEPTANCE CRITERIA (Given / When / Then):
Scenario 1:
Given [bối cảnh: đang điền đơn]
When [hành động: bấm "Lưu nháp"]
Then [kết quả: đơn được lưu và hiện lại khi mở lại]
Scenario 2 (trường hợp lỗi):
Given [ ] When [ ] Then [ ]
KIỂM INVEST trước khi đưa cho dev:
[ ] Independent — không phụ thuộc story khác
[ ] Negotiable — không khóa cứng giải pháp (không nói "nút màu xanh")
[ ] Valuable — có mệnh đề "để…" nêu giá trị thật
[ ] Estimable — đủ cụ thể để ước lượng (không "tất cả", "linh hoạt")
[ ] Small — làm xong trong vài ngày; nhiều "và" thì tách nhỏ
[ ] Testable — có tiêu chí nghiệm thu đo được (không "đẹp", "nhanh")
Tải xuống: Word (.docx) · Markdown (.md) · Dùng công cụ tương tác