Vấn đề
Biết kỹ thuật là một chuyện; áp vào công ty thật — với chính sách bảo mật, đội ngũ hoài nghi AI, và deadline dồn dập — là chuyện khác. Bài này ráp mọi thứ qua các tình huống bạn gặp hằng ngày và đưa ra cách vận hành lâu dài, an toàn.
Tình huống 1: Sếp ném một dòng, cần story trước giờ họp
Yêu cầu: "Trưa nay demo được tính năng nhắc gia hạn gói cho khách sắp hết hạn." Bạn có 20 phút.
- Chạy prompt "làm rõ" — AI hỏi: nhắc trước bao lâu? Qua kênh nào? Khách đã hủy tự động gia hạn thì sao?
- Bạn trả lời được 2/3, câu còn lại ghi "GIẢ ĐỊNH — 7 ngày, cần PO xác nhận".
- Sinh story + AC + edge case qua agent.
- Vào họp với story rõ ràng và một câu hỏi treo duy nhất — chuyên nghiệp hơn nhiều so với story mơ hồ tự bịa.
Tình huống 2: Dev phản bác AC "cái này không kiểm thử được"
Acceptance criteria sau bị dev nói "không kiểm thử được":
"Thì hệ thống gửi thông báo kịp thời".
Viết lại thành tình huống Gherkin kiểm thử được, với ngưỡng thời
gian cụ thể và kênh gửi rõ ràng. Nếu ngưỡng phụ thuộc chính sách,
đề xuất 2 phương án để tôi chọn.
AI biến "kịp thời" thành "trong vòng 5 phút kể từ khi...", có kênh, có điều kiện. Bạn chọn phương án đúng policy.
Tình huống 3: Phòng bảo mật hỏi "anh đưa gì cho AI?"
Câu trả lời đúng: chỉ đưa yêu cầu nghiệp vụ đã khử dữ liệu cá nhân, dùng công cụ công ty đã phê duyệt, và luôn có người review. Nếu bạn từng dán dữ liệu khách thật vào AI công cộng, đó là sự cố phải báo cáo. Phòng ngừa quan trọng hơn xin lỗi.
Các bước xây dựng "cách làm" cho cả team
- Chuẩn hóa thư viện prompt dùng chung (6 bước ở Bài 6), lưu nơi cả team truy cập.
- Thống nhất quy ước: mẫu story, Gherkin tiếng Việt hay Anh, cách gắn nhãn giả định.
- Định nghĩa ranh giới dữ liệu: cái gì được đưa vào AI, cái gì tuyệt đối không.
- Bắt buộc review người: AI soạn, người chốt — thành quy tắc, không tùy hứng.
- Đo lường: thời gian mỗi story trước/sau, tỉ lệ rework, số edge case bắt sớm — để chứng minh giá trị với quản lý.
- Đào tạo lại định kỳ: chia sẻ prompt hay, lỗi hay gặp, cập nhật khi công cụ đổi.
Template tái dùng: "Quy tắc dùng AI cho BA" (dán vào wiki team)
1. AI soạn thảo — BA quyết định nghiệp vụ và chịu trách nhiệm.
- Luôn cho ngữ cảnh; cấm AI bịa quy tắc/con số (ghi "cần PO").
- Không đưa dữ liệu cá nhân/khách thật/bí mật kinh doanh vào
công cụ chưa được phê duyệt.
- Mọi story/AC do AI sinh phải qua review người trước khi Ready.
- Gắn nhãn "GIẢ ĐỊNH — cần xác nhận" cho mọi suy đoán.
- BA phải hiểu 100% story mình giao đi (không "AI viết hộ, tôi
không chắc").
- Dùng thư viện prompt chung để giữ nhất quán toàn team.
Sai lầm thường gặp
- Dùng AI như bí mật cá nhân. Không chuẩn hóa, mỗi BA một kiểu prompt, team mất nhất quán và rủi ro bảo mật tăng. Chuẩn hóa và minh bạch.
- Ảo giác trong tình huống gấp. Càng vội càng dễ nhắm mắt tin AI. Đúng lúc gấp lại càng phải bám nguyên tắc gắn nhãn giả định.
- Rò rỉ dữ liệu vì tiện. "Chỉ dán một chút thông tin khách cho AI hiểu" là cách sự cố bắt đầu. Không có ngoại lệ với dữ liệu thật.
- Phụ thuộc quá mức, đánh mất vai trò BA. Nếu bạn chỉ còn là người bấm nút chạy AI, giá trị nghề của bạn biến mất và chất lượng nghiệp vụ tụt. AI là đòn bẩy, không phải người thay thế tư duy phân tích.
- Không đo lường. Không có số liệu, bạn không thuyết phục được quản lý cho dùng công cụ tốt hơn, và không biết mình đang cải thiện hay không.
Kết bài & tổng kết khóa học
Bạn đã đi trọn hành trình: hiểu nỗi đau → sinh story → viết Gherkin → chấm INVEST → phủ edge case → chuẩn hóa quy trình → tự động hóa bằng agent → vận hành an toàn trong công ty. Nguyên tắc xuyên suốt gói trong một câu: AI soạn thảo, BA quyết định và chịu trách nhiệm. Giữ vững nguyên tắc đó, bạn làm nhanh gấp nhiều lần mà chất lượng và uy tín nghề vẫn nguyên vẹn. Hãy làm bài kiểm tra tổng kết để tự đánh giá khả năng vận dụng.