Nếu mới vào dự án mà nghe stakeholder nói nghiệp vụ thấy mơ hồ, không hiểu domain, thậm chí không biết nên hỏi gì trong meeting thì rất bình thường.
Không ai vừa vào dự án là hiểu domain ngay.
Vấn đề không phải là bạn “kém”, mà là bạn chưa có cách học domain có hệ thống.
Nhiều bạn mới làm BA thường học domain theo kiểu:
Đọc tài liệu từ đầu đến cuối
Ghi lại một đống thuật ngữ
Nghe meeting rồi cố hiểu hết mọi thứ
Càng học càng rối.
Cách tốt hơn là đừng cố học cả domain một lúc. Hãy học theo từng lớp.
1. Học flow trước, đừng học thuật ngữ trước
Newbie rất hay thấy từ nào lạ là tra từ đó ngay.
Ví dụ trong Banking:
Core Banking
Napas
Settlement
Reversal
Limit
Transaction status
Nhưng nếu bạn học từng từ rời rạc, bạn sẽ rất khó hiểu.
Hãy bắt đầu bằng câu hỏi:
Domain này có những quy trình chính nào?
Ví dụ trong Banking, trước tiên hãy hiểu:
Mở tài khoản
Đăng nhập
Chuyển tiền
Thanh toán hóa đơn
Đối soát giao dịch
Ví dụ trong Insurance:
Tư vấn sản phẩm
Phát hành hợp đồng
Thu phí
Yêu cầu bồi thường
Tái tục / hủy hợp đồng
Ví dụ trong E-commerce:
Tìm sản phẩm
Thêm vào giỏ
Checkout
Thanh toán
Giao hàng
Đổi trả / hoàn tiền
Khi bạn hiểu flow lớn trước, thuật ngữ sẽ dễ hiểu hơn vì nó nằm trong ngữ cảnh cụ thể.
2. Vẽ lại domain bằng một trang giấy
Khi vào dự án mới, bạn nên tự tạo một “domain map” đơn giản gồm 4 nhóm:
Ai tham gia?
Ví dụ:
Customer
Admin
Ops
CS
Shipper
Teller
Agent
Đối tượng nghiệp vụ chính là gì?
Ví dụ:
Order
Transaction
Account
Policy
Claim
Invoice
Payment
Quy trình chính là gì?
Ví dụ:
Create order
Transfer money
Submit claim
Refund
Reconciliation
Trạng thái quan trọng là gì?
Ví dụ:
Pending
Approved
Rejected
Success
Failed
Cancelled
Reversed
Chỉ cần làm được một trang này, bạn sẽ bắt đầu nhìn domain có cấu trúc hơn rất nhiều.
3. Đừng hỏi “anh/chị giải thích lại domain giúp em”, hãy hỏi theo flow
Câu hỏi quá rộng sẽ làm stakeholder khó trả lời.
Thay vì hỏi:
“Anh/chị giải thích lại domain này giúp em được không ạ?”
Hãy hỏi cụ thể hơn:
“Em đang hiểu flow là A → B → C, không biết em hiểu vậy đúng chưa ạ?”
Hoặc:
“Ở bước này, ai là người approve ạ?”
Hoặc:
“Trạng thái Pending trong flow này nghĩa là đang chờ bên nào xử lý ạ?”
Cách hỏi này giúp bạn không bị “tắt tiếng”, vì bạn không hỏi từ con số 0. Bạn đưa ra cách hiểu của mình để người khác chỉnh lại.
4. Ghi thuật ngữ theo ngữ cảnh, đừng ghi như từ điển
Ví dụ bạn ghi:
Reversal = đảo giao dịch
Như vậy chưa đủ.
Hãy ghi theo format này:
Thuật ngữ:
Reversal
Nghĩa dễ hiểu:
Hoàn / đảo lại một giao dịch đã phát sinh trước đó.
Xuất hiện trong flow nào:
Chuyển tiền, thanh toán, hoàn tiền.
Khi nào xảy ra:
User bị trừ tiền nhưng giao dịch không hoàn tất, hệ thống cần hoàn tiền lại.
Câu hỏi cần hỏi thêm:
Reversal tự động hay Ops xử lý thủ công?
Ghi như vậy thì sau này vào meeting bạn mới dùng được thuật ngữ, chứ không chỉ “biết nghĩa tiếng Việt”.
5. Sau mỗi meeting, viết lại 3 thứ
Sau meeting, đừng chỉ lưu note rồi để đó.
Hãy dành 15 phút viết lại:
Mình đã hiểu gì?
Ví dụ:
Giao dịch chuyển tiền có thể ở trạng thái Pending nếu ngân hàng nhận chưa phản hồi.
Mình chưa hiểu gì?
Ví dụ:
Pending tối đa bao lâu thì chuyển sang Failed hoặc Reversed?
Mình cần hỏi ai?
Ví dụ:
Hỏi Dev về trạng thái transaction hiện tại.
Hỏi Ops về quy trình xử lý khi user bị trừ tiền nhưng người nhận chưa nhận.
Thói quen này giúp bạn biến meeting từ “nghe cho qua” thành “học có hệ thống”.
6. Chọn một flow nhỏ để đào sâu
Đừng cố hiểu cả domain ngay.
Hãy chọn một flow nhỏ nhưng quan trọng.
Ví dụ trong Banking:
Chuyển tiền liên ngân hàng
Bạn đào sâu:
Ai khởi tạo giao dịch?
Tiền bị trừ lúc nào?
Giao dịch đi qua hệ thống nào?
Có những status nào?
Timeout thì sao?
Failed thì có reversal không?
User thấy message gì?
Ví dụ trong E-commerce:
Hủy đơn hàng
Bạn đào sâu:
Đơn ở trạng thái nào thì được hủy?
Đã thanh toán thì refund thế nào?
Voucher có hoàn lại không?
Đã giao cho shipper thì có hủy được không?
Khi bạn hiểu sâu một flow, bạn sẽ bắt đầu hiểu cách domain vận hành. Sau đó học các flow khác sẽ dễ hơn nhiều.
7. Trong meeting, chỉ cần hỏi 1–2 câu đúng trọng tâm
Newbie không cần cố nói nhiều trong meeting.
Nhưng bạn nên chuẩn bị trước vài câu hỏi kiểu BA:
Điều kiện để bước này được thực hiện là gì?
Nếu bước này thất bại thì flow đi đâu tiếp?
Sau bước này, status thay đổi thành gì?
Ai có quyền approve?
Dữ liệu này lấy từ hệ thống nào?
Trường hợp ngoại lệ thường gặp nhất là gì?
Chỉ cần hỏi được 1–2 câu đúng trọng tâm, bạn đã thể hiện là mình đang tư duy theo hướng phân tích chứ không chỉ ngồi nghe.
8. Hãy xin tài liệu, nhưng đừng chỉ đọc tài liệu
Bạn có thể xin:
BRD / SRS cũ
Flow cũ
User manual
Training document
File mapping status
Report mẫu
Ticket bug / issue cũ
Nhưng khi đọc, đừng đọc từ đầu đến cuối như đọc sách.
Hãy đọc với câu hỏi:
Flow chính là gì?
Actor là ai?
Object chính là gì?
Status gồm những gì?
Rule nào quan trọng?
Exception nào hay xảy ra?
Đọc tài liệu theo câu hỏi sẽ hiệu quả hơn đọc một cách thụ động.
Checklist học domain nhanh cho newbie BA
Khi vào domain mới, bạn có thể làm theo thứ tự này:
Xác định các flow chính
Vẽ domain map một trang
Ghi thuật ngữ theo ngữ cảnh
Chọn một flow nhỏ để đào sâu
Hỏi theo kiểu “em hiểu như này đúng không?”
Sau meeting viết lại phần đã hiểu / chưa rõ / cần hỏi
Dần dần chuyển từ nghe bị động sang hỏi có cấu trúc
Tóm lại
Không hiểu domain lúc mới vào dự án là chuyện rất bình thường.
Nhưng nếu bạn chỉ ngồi nghe và hy vọng “từ từ sẽ hiểu”, bạn sẽ mất rất nhiều thời gian.
Cách học domain nhanh nhất không phải là học thuộc thuật ngữ.
Mà là:
Hiểu flow trước.
Hiểu actor sau.
Hiểu data, rule, status, exception sau nữa.
BA không cần trở thành chuyên gia domain ngay từ đầu.
Nhưng BA cần biết cách đặt câu hỏi để biến sự mơ hồ thành hiểu biết có cấu trúc.
Khi trong đầu bạn có cấu trúc, bạn sẽ không còn bị “tắt tiếng” trong meeting nữa.
