Newbie với vào công ty, em nên luyện kỹ năng khai thác requirement từ đâu?

Nếu mới làm BA mà khi stakeholder nói gì mình chỉ biết ghi lại đúng câu đó thì rất bình thường. Giai đoạn đầu ai cũng vậy.

Vấn đề là: BA không chỉ “ghi lại yêu cầu”, mà phải học cách đào sâu yêu cầu.

Stakeholder thường không nói ra requirement hoàn chỉnh. Họ thường chỉ nói ra:

“Anh muốn thêm nút này.”

“Chị muốn report này.”

“Làm giống hệ thống cũ.”

“Cho user thao tác nhanh hơn.”

Nếu BA chỉ ghi lại y nguyên, tài liệu sẽ rất dễ bị mơ hồ. Dev đọc không hiểu, QA không test được, còn stakeholder thì sau này bảo: “Ý anh/chị không phải vậy.”

Vậy nên bạn có thể luyện từ 5 hướng rất thực tế sau.

1. Đừng hỏi ngay "Anh/chị muốn gì?" - hãy hỏi "Vì sao cần cái đó?"

Ví dụ stakeholder nói:

“Anh muốn thêm nút Export Excel.”

BA mới thường ghi:

Hệ thống cần có nút Export Excel.

Nhưng BA nên hỏi tiếp:

“Anh/chị cần export để làm gì ạ?”
“Ai là người dùng file đó?”
“Sau khi export xong, họ xử lý tiếp thế nào?”
“Có cần format cố định không?”
“Dữ liệu trong file lấy theo điều kiện nào?”

Vì đôi khi stakeholder nói “cần export”, nhưng nhu cầu thật có thể là:

• Cần làm báo cáo định kỳ

• Cần đối soát dữ liệu

• Cần gửi file cho kế toán

• Cần lọc danh sách lỗi

Khi hiểu “vì sao”, bạn mới phân tích đúng giải pháp.

2. Luôn hỏi theo flow: Trước đó là gì? Sau đó là gì?

Một câu hỏi rất mạnh cho BA mới là:

“Trước bước này user đang làm gì?”
“Sau bước này user sẽ làm gì tiếp?”

Ví dụ stakeholder nói:

“User cần xác nhận đơn hàng.”

Đừng chỉ ghi “Xác nhận đơn hàng”.

Hãy hỏi:

• Đơn hàng được tạo từ đâu?

• Ai có quyền xác nhận?

• Xác nhận ở trạng thái nào?

• Sau khi xác nhận thì order chuyển sang trạng thái gì?

• Nếu xác nhận sai thì có hủy được không?

BA giỏi không nhìn một chức năng đứng một mình. BA nhìn nó nằm trong quy trình trước – trong – sau.

3. Mỗi yêu cầu phải hỏi thêm 3 nhóm câu hỏi: Rule – Data – Exception

Bạn có thể nhớ công thức đơn giản này:

Rule

Quy định nghiệp vụ là gì?

Ví dụ:

• Ai được làm?

• Khi nào được làm?

• Giới hạn bao nhiêu lần?

• Điều kiện hợp lệ là gì?

Data

Dữ liệu nào cần nhập, lưu, hiển thị?

Ví dụ:

• Cần những field nào?

• Field nào bắt buộc?

• Dữ liệu lấy từ đâu?

• Có cần lưu lịch sử không?

Exception

Nếu sai hoặc thất bại thì sao?

Ví dụ:

• Nhập sai thì báo gì?

• Không đủ điều kiện thì xử lý sao?

• Hệ thống lỗi thì user thấy gì?

• Có retry không?

Chỉ cần luyện hỏi theo 3 nhóm này, requirement của bạn sẽ rõ hơn rất nhiều.

4. Học cách “nói lại để xác nhận”

Sau khi stakeholder giải thích, đừng chỉ gật đầu.

Hãy tập nói:

“Để em xác nhận lại xem em hiểu đúng chưa…”

Ví dụ:

“Em hiểu là user chỉ được đổi địa chỉ khi đơn chưa chuyển sang trạng thái Shipped. Nếu đơn đã giao cho shipper thì hệ thống sẽ khóa chức năng đổi địa chỉ. Đúng không ạ?”

Câu này rất quan trọng.

Vì nó giúp bạn:

• Kiểm tra mình hiểu đúng chưa

• Giúp stakeholder phát hiện điểm còn thiếu

• Tạo dấu vết để sau này viết requirement

BA không cần tỏ ra biết hết. BA cần biết xác nhận đúng.

5. Luyện từ các tính năng nhỏ, đừng bắt đầu bằng hệ thống lớn

Bạn không cần đợi dự án lớn mới luyện elicitation.

Hãy lấy các tính năng quen thuộc để tự luyện:

• Quên mật khẩu

• Đăng ký tài khoản

• Đổi số điện thoại

• Apply voucher

• Hủy đơn hàng

• Chuyển khoản

• Upload hồ sơ KYC

Với mỗi tính năng, tự đặt câu hỏi:

• User là ai?

• Mục tiêu là gì?

• Flow chính gồm những bước nào?

• Có rule gì?

• Có exception gì?

• Dữ liệu nào cần lưu?

• Khi nào coi là thành công?

Luyện như vậy 10–20 tính năng, bạn sẽ bắt đầu hình thành “phản xạ BA”.

Một checklist đơn giản cho bạn khi nhận yêu cầu

Lần sau stakeholder nói một yêu cầu, bạn thử hỏi theo khung này:

1. Mục tiêu của yêu cầu này là gì?

2. Ai là người sử dụng?

3. Quy trình hiện tại đang diễn ra thế nào?

4. Sau khi có hệ thống mới, flow mong muốn là gì?

5. Điều kiện nào để thực hiện thành công?

6. Trường hợp lỗi/thất bại thì xử lý sao?

7. Dữ liệu nào cần nhập, lưu, hiển thị?

8. Ai có quyền thao tác?

9. Có giới hạn, rule, deadline, trạng thái nào không?

10. Khi nào thì xem là hoàn thành đúng yêu cầu?

Không cần hỏi hết 10 câu một lúc. Nhưng bạn nên dùng nó như “bản đồ” để không bị bí.

Tóm lại

Newbie BA hay mắc lỗi là nghĩ stakeholder nói gì thì đó là requirement.

Thực tế:

Câu stakeholder nói chỉ là điểm bắt đầu.

Việc của BA là biến câu nói đó thành:

• Flow rõ ràng

• Rule rõ ràng

• Data rõ ràng

• Exception rõ ràng

• Acceptance Criteria test được

Bạn không thể giỏi elicitation chỉ bằng cách đọc lý thuyết. Cách tốt nhất là luyện phân tích từng tính năng nhỏ, tập hỏi “vì sao”, tập đi theo flow, và tập xác nhận lại sau mỗi buổi trao đổi.

Làm nhiều, bạn sẽ dần hết cảm giác “không biết hỏi gì tiếp theo”.