Tại sao BA phải đụng vào API?

Nhiều BA vẫn giữ tư duy "API là việc của dev". Viết xong SRS, bàn giao, rồi chờ UAT. Đến lúc UAT mới phát hiện: UI màn hình không hiển thị đủ thông tin, luồng nghiệp vụ thiếu một nhánh, hoặc dữ liệu trả về không khớp business rule đã chốt với khách hàng. Lúc đó sửa gì cũng đắt — sửa API là sửa cả FE, cả test case, cả tài liệu, và thường là sát deadline.

API chính là hiện thân kỹ thuật của nghiệp vụ. Mỗi field trong request/response là một mảnh dữ liệu nghiệp vụ. Mỗi error code là một exception flow. Mỗi validation là một business rule. Nếu API không phản ánh đúng nghiệp vụ thì sản phẩm cuối cùng cũng không đúng, dù SRS bạn viết có đẹp đến đâu.

Ba rủi ro thường gặp nhất khi BA không review API:

1. Thiếu dữ liệu cho AC. AC yêu cầu hiển thị "số ngày còn lại của gói", API chỉ trả expiry_date. FE tự tính, mỗi chỗ tính một kiểu.

2. Exception flow rơi tự do. API có 8 mã lỗi, SRS mô tả 3. Năm mã còn lại QA test ra, không ai biết hiển thị message gì.

3. Data model lệch nhau giữa các endpoint. Trường status chỗ trả số, chỗ trả chuỗi, trong khi nghiệp vụ chỉ có một khái niệm trạng thái duy nhất.

Review API không biến BA thành dev. Nó chỉ là việc BA truy vết ngược từ kỹ thuật về nghiệp vụ, để chắc chắn hai bên đang nói cùng một thứ.

Kinh nghiệm của mình thì nên làm bước này ở giai đoạn nào đây.

Sau khi dev public API spec, trước khi code. Đây là điểm vàng, sửa còn rẻ. Đừng chờ API chạy được rồi mới xem. Nên anh em chú ý yêu cầu có luôn, sớm ngay khi có BRD thì lại càng tốt. Chính vì vậy chương trình mentor mình dựng API cho các bạn test là vậy.

Song song khi viết SRS / Use Case. API spec là nguồn phát hiện gap rất tốt: field nào tồn tại mà nghiệp vụ chưa mô tả, rule nào viết ra mà không có dữ liệu đỡ.

Trước UAT, BA check lần cuối xem response có đủ data để pass toàn bộ AC không.

🤖 Cách ứng dụng AI Claude cho công đoạn review ApI này hay.

Reverse-mapping API về nghiệp vụ. Paste Swagger/OpenAPI kèm AC, yêu cầu đối chiếu từng field và liệt kê thành 3 nhóm: field API có nhưng AC không đề cập, rule trong AC không có field nào support, field required nhưng nghiệp vụ chưa định nghĩa giá trị mặc định.

Sinh coverage matrix. Yêu cầu output dạng bảng gồm Endpoint, Method, US/AC liên quan, Business rule, Gap, Câu hỏi cần clarify. Bảng này mang thẳng vào buổi review với dev/QA, chốt rất nhanh.

Soi error code với exception flow. Yêu cầu liệt kê toàn bộ error response, kiểm tra với mỗi mã lỗi thì AC đã mô tả hành vi UI và message chưa. Đây là chỗ lọt nhiều nhất happy path ai cũng viết, exception thì hay quên.

Kiểm tra nhất quán data model. Khi có nhiều API liên quan, cho Claude đối chiếu tên field, kiểu dữ liệu, enum giữa các endpoint. Bắt được sai lệch mà mắt người đọc lướt qua rất dễ bỏ sót.

Sinh câu hỏi clarify. Yêu cầu Claude đóng vai BA senior, đặt 10 câu hỏi cần hỏi dev về API này để đảm bảo cover đúng nghiệp vụ.

👨🏽‍💻Lưu ý khi dùng AI.

Claude mạnh ở phát hiện gap và kiểm tra tính nhất quán, nhưng không biết ngữ cảnh nghiệp vụ ngầm của dự án bạn. Luôn paste kèm business rule và AC đầy đủ, đừng để nó tự suy diễn. Và bạn phải là người hiểu rõ output AI gen ra cho bạn.

Quan trọng nhất: Kết quả gap phải do BA tự verify trước khi raise cho dev. AI đưa ra danh sách nghi vấn, BA là người quyết định cái nào thật sự là vấn đề. Raise issue sai vài lần là mất uy tín với team.

Nội dung này mình có chia sẻ trong chương trình BA Mentor là vì vậy.

Vẫn là chuỗi bài viết chuyên sâu về AI, BA thực chiến từ trải nghiệm làm nghề thực chiến chứ không chỉ là các bài viết từ làm content gen từ AI. Hi vọng giúp ích cho anh em làm nghề.

Phuc Nguyen

#AI #API #Businessanalyst #Claude #Vibecoding #Productmanagament #LearnBA #ITBA

Cộng Đồng Business Analyst Việt Nam

REVIEW API VIỆC BA HAY BỎ QUÊN, VÀ CÁI GIÁ…