Nếu bạn mới làm BA mà Dev hỏi:
“Case này status là gì?”
“Data lấy từ đâu?”
“API trả lỗi thì sao?”
“Nếu user bấm lại thì hệ thống xử lý thế nào?”
và bạn không trả lời được, thì cũng đừng hoảng.
Điều đó không có nghĩa là bạn phải học code ngay.
Nó chỉ cho thấy bạn đang thiếu một lớp kiến thức rất quan trọng của IT BA:
Hiểu hệ thống vận hành như thế nào ở mức đủ để nói chuyện với Dev.
BA không cần trở thành Developer.
Nhưng BA cần hiểu những kiến thức IT nền tảng sau.
1. Học về trạng thái hệ thống trước tiên
Câu Dev hỏi rất nhiều là:
“Status của case này là gì?”
Vì hệ thống không chỉ có “xong” và “không xong”.
Ví dụ đơn hàng có thể có:
Draft
Confirmed
Paid
Packed
Shipped
Delivered
Cancelled
Refunded
Giao dịch ngân hàng có thể có:
Initiated
Pending
Success
Failed
Timeout
Reversed
Nếu BA không chốt status rõ, Dev sẽ không biết:
Khi nào cho user thao tác tiếp?
Khi nào khóa chức năng?
Khi nào hiển thị lỗi?
Khi nào chuyển sang bước sau?
Vậy nên kiến thức IT đầu tiên nên học là:
State / Status / State Transition
Tức là: một đối tượng trong hệ thống đang ở trạng thái nào và có thể chuyển sang trạng thái nào tiếp theo.
Cách luyện rất đơn giản:
Lấy một tính năng nhỏ như “hủy đơn hàng”, rồi tự hỏi:
Đơn ở trạng thái nào thì được hủy?
Đơn ở trạng thái nào thì không được hủy?
Sau khi hủy thì status thành gì?
Nếu đã thanh toán thì có thêm status refund không?
Chỉ cần luyện status như vậy, bạn sẽ trả lời Dev tự tin hơn rất nhiều.
2. Học về dữ liệu: field, table, source of data
Câu Dev hay hỏi tiếp là:
“Data này lấy từ đâu?”
Nhiều BA mới chỉ nhìn màn hình và nói:
“Hiển thị tên khách hàng, số điện thoại, địa chỉ.”
Nhưng Dev cần biết sâu hơn:
Dữ liệu này lấy từ hệ thống nào?
Field nào là bắt buộc?
Field nào có thể để trống?
Dữ liệu này do user nhập hay hệ thống tự sinh?
Có cần lưu lịch sử thay đổi không?
Ví dụ màn hình đơn hàng hiển thị:
Tên người nhận
Số điện thoại
Địa chỉ
Phí ship
Trạng thái đơn
BA nên hỏi:
Tên người nhận lấy từ order hay từ profile khách hàng?
Nếu user đổi địa chỉ sau khi đặt thì lấy địa chỉ cũ hay mới?
Phí ship được tính từ đâu?
Trạng thái đơn do OMS cập nhật hay logistics cập nhật?
Bạn không cần học database quá sâu ngay từ đầu.
Nhưng nên hiểu các khái niệm cơ bản:
Entity: đối tượng dữ liệu, ví dụ User, Order, Transaction
Attribute/Field: thuộc tính, ví dụ order_id, amount, status
Primary Key: mã định danh duy nhất
Foreign Key: liên kết giữa các bảng
Source of Truth: hệ thống nào là nguồn dữ liệu đúng nhất
BA hiểu data thì requirement sẽ ít mơ hồ hơn rất nhiều.
3. Học API ở mức BA cần dùng
Câu Dev hỏi:
“API trả lỗi thì sao?”
Đây là câu rất phổ biến.
BA không cần viết API, nhưng cần hiểu:
API là gì?
Request là gì?
Response là gì?
Status code là gì?
Error code là gì?
Hiểu đơn giản:
API là cách hai hệ thống nói chuyện với nhau.
Ví dụ app gọi API chuyển tiền.
Request gửi lên:
accountFrom
accountTo
amount
description
Response trả về:
transactionId
status
message
errorCode nếu lỗi
BA cần hỏi được:
Nếu API success thì màn hình hiển thị gì?
Nếu API failed thì user thấy message gì?
Nếu API timeout thì status là gì?
Có retry không?
Có tạo trùng giao dịch không?
Đặc biệt, với Banking, Fintech, E-commerce, Logistics, API lỗi không phải chuyện nhỏ.
Ví dụ:
Payment API timeout
Voucher API trả mã không hợp lệ
KYC API pending
Delivery API không cập nhật trạng thái
Nếu BA không mô tả exception từ API, Dev sẽ tự đoán. Và khi Dev tự đoán, mỗi người có thể xử lý một kiểu.
4. Học về validation và business rule
Dev cũng hay hỏi:
“Trường này validate thế nào?”
“Điều kiện hợp lệ là gì?”
Ví dụ user nhập số tiền chuyển khoản.
BA phải chốt:
Số tiền tối thiểu là bao nhiêu?
Số tiền tối đa là bao nhiêu?
Có vượt hạn mức ngày không?
Số dư có đủ không?
Tài khoản nhận có hợp lệ không?
Đây là phần giao giữa business và system.
Bạn nên học cách phân biệt:
Validation
Là kiểm tra dữ liệu nhập vào.
Ví dụ:
Email đúng format
Số tiền > 0
Số điện thoại đủ 10 số
Business Rule
Là quy định nghiệp vụ.
Ví dụ:
User KYC level 1 chỉ được chuyển tối đa 5 triệu/ngày
Voucher chỉ áp dụng cho đơn từ 300.000đ
Đơn đã shipped thì không được đổi địa chỉ
BA mà không chốt validation và rule thì Dev không thể code đúng được.
5. Học exception flow
Newbie BA hay viết happy flow rất ổn, nhưng thiếu exception.
Ví dụ flow quên mật khẩu:
Happy flow:
User nhập số điện thoại
Hệ thống gửi OTP
User nhập OTP
User tạo mật khẩu mới
Nhưng Dev sẽ hỏi:
Số điện thoại không tồn tại thì sao?
OTP sai thì sao?
OTP hết hạn thì sao?
Gửi OTP thất bại thì sao?
User nhập sai quá 5 lần thì sao?
Đây là exception flow.
Một BA tốt không chỉ mô tả lúc hệ thống chạy đúng.
BA phải mô tả cả lúc hệ thống gặp lỗi.
Cách luyện:
Với mỗi bước trong flow, hãy hỏi:
“Nếu bước này fail thì sao?”
Chỉ một câu này thôi sẽ giúp bạn tìm ra rất nhiều case bị thiếu.
6. Học sequence flow ở mức đơn giản
Một số câu Dev hỏi thực ra liên quan đến thứ tự xử lý:
“Trừ tiền trước hay tạo transaction trước?”
“Gửi notification trước hay update status trước?”
“Gọi API payment trước hay lưu order trước?”
BA không cần vẽ sequence diagram phức tạp ngay.
Nhưng nên biết tư duy:
Bước nào xảy ra trước?
Bước nào xảy ra sau?
Nếu bước giữa thất bại thì rollback hay giữ pending?
Ví dụ checkout:
Tạo order
Gọi payment
Payment success
Update order status = Paid
Gửi email xác nhận
Nếu payment timeout ở bước 2 thì order status là gì?
Pending Payment?
Failed?
Cancelled?
Đây chính là chỗ BA cần làm rõ.
7. Vậy nên học theo thứ tự nào?
Nếu bạn là newbie BA, đừng học lan man quá nhiều.
Hãy học theo thứ tự này:
Bước 1: Status & State Transition
Hiểu trạng thái và chuyển trạng thái.
Bước 2: Data basics
Hiểu entity, field, source of data, required/optional.
Bước 3: API basics
Hiểu request, response, status code, error code, timeout.
Bước 4: Validation & Business Rule
Biết cách chốt điều kiện hợp lệ và rule nghiệp vụ.
Bước 5: Exception Flow
Biết hỏi “nếu fail thì sao?”
Bước 6: Basic SQL
Biết đọc dữ liệu cơ bản, hiểu JOIN đơn giản để không bị mù data.
Chỉ cần nắm 6 nhóm này, bạn đã làm việc với Dev dễ hơn rất nhiều.
Một cách luyện rất thực tế
Chọn một tính năng nhỏ, ví dụ:
Quên mật khẩu
Apply voucher
Chuyển tiền
Hủy đơn hàng
Đổi địa chỉ giao hàng
Rồi tự phân tích theo checklist:
Object chính là gì?
Object đó có những status nào?
Data nào cần nhập/lưu/hiển thị?
API nào có thể được gọi?
API success thì sao?
API failed thì sao?
API timeout thì sao?
Business rule là gì?
Exception flow gồm những case nào?
QA sẽ test những scenario nào?
Luyện 10 tính năng như vậy, bạn sẽ thấy mình nói chuyện với Dev khác hẳn.
Tóm lại
BA không cần học code đầu tiên.
Nhưng BA cần học cách hệ thống suy nghĩ.
Dev hỏi “status là gì”, “data lấy từ đâu”, “API lỗi thì sao” không phải để làm khó bạn.
Họ hỏi vì những thứ đó quyết định hệ thống sẽ code thế nào.
Nếu muốn làm BA tốt hơn, hãy bắt đầu từ:
Status
Data
API
Rule
Exception
SQL cơ bản
Khi bạn hiểu được những thứ này, bạn sẽ không còn chỉ viết requirement kiểu “hệ thống xử lý thành công”.
Bạn sẽ bắt đầu viết được requirement mà Dev đọc hiểu, QA test được, và stakeholder ít phải sửa lại hơn.
