Intern/Fresher cần biết: IT BA thực sự sẽ làm những công việc gì trong 1 dự án thực tế?
Rất nhiều bạn mới học Business Analyst nghĩ rằng:
“BA là người viết tài liệu yêu cầu.”
Đúng, nhưng chỉ đúng một phần.
Trong dự án thực tế, IT BA không chỉ ngồi viết BRD, SRS, User Story hay vẽ flow.
BA thường là người đứng giữa nhiều bên:
Business / Product Owner
User / Stakeholder
Developer
Tester / QA
UI/UX Designer
Project Manager
Operation / Support
Đôi khi cả đối tác tích hợp bên ngoài
Nhiệm vụ chính của BA là:
Biến một nhu cầu còn mơ hồ thành yêu cầu rõ ràng để team có thể build, test và triển khai được.
Vậy cụ thể IT BA làm gì trong một dự án thật?
1️⃣ Hiểu bài toán business
Trước khi viết bất kỳ tài liệu nào, BA phải hiểu:
Dự án này giải quyết vấn đề gì?
Ai đang gặp vấn đề?
Vì sao phải làm tính năng này?
Nếu không làm thì ảnh hưởng gì?
Thành công được đo bằng gì?
Ví dụ stakeholder nói:
“Anh muốn cải thiện checkout.”
BA không nên viết ngay User Story.
BA cần hỏi:
Checkout đang lỗi/chậm ở bước nào?
Tỷ lệ bỏ giỏ hàng hiện tại là bao nhiêu?
User thường rớt ở bước chọn địa chỉ, áp voucher hay payment?
Mục tiêu là tăng conversion hay giảm complaint?
Có KPI cụ thể không?
=> BA không chỉ hỏi “muốn hệ thống làm gì”.
BA phải hiểu “vì sao business cần làm điều đó”.
2️⃣ Khai thác và làm rõ requirement
Stakeholder thường không đưa requirement hoàn chỉnh ngay từ đầu.
Họ thường nói kiểu:
“Cho user thanh toán nhanh hơn.”
“Làm màn hình quản lý đơn hàng.”
“Thêm trạng thái giao dịch.”
“Cần export báo cáo.”
“Muốn hệ thống bảo mật hơn.”
Những câu này đều còn mơ hồ.
BA phải làm rõ:
User nào sử dụng?
Dùng trong tình huống nào?
Flow chính là gì?
Có rule nghiệp vụ nào không?
Có exception nào không?
Dữ liệu đầu vào/đầu ra gồm gì?
Khi nào được xem là hoàn thành?
Ví dụ:
“Thêm trạng thái giao dịch.”
BA cần hỏi:
Có những status nào?
Status nào user được thấy?
Status nào chỉ dùng nội bộ?
Ai/hệ thống nào được quyền cập nhật status?
Có cho chuyển từ Pending sang Failed không?
Nếu timeout thì status là gì?
Có cần audit log không?
=> Đây gọi là elicitation: không phải hỏi nhiều, mà là hỏi đúng.
3️⃣ Phân tích flow nghiệp vụ
Sau khi hiểu yêu cầu, BA thường phải vẽ hoặc mô tả flow.
Ví dụ với tính năng chuyển tiền:
User nhập thông tin chuyển tiền
→ System kiểm tra số dư
→ System kiểm tra hạn mức
→ System yêu cầu OTP
→ User nhập OTP
→ System xác thực OTP
→ System xử lý giao dịch
→ System cập nhật trạng thái
→ User nhận kết quả
Nhưng flow thực tế không chỉ có happy path.
BA cần nghĩ thêm:
OTP sai thì sao?
OTP hết hạn thì sao?
Core Banking timeout thì sao?
User bấm chuyển tiền 2 lần thì sao?
Tiền bị trừ nhưng người nhận chưa nhận thì sao?
Giao dịch pending thì user nhìn thấy gì?
=> BA giỏi không chỉ vẽ flow đẹp.
BA giỏi nhìn được những điểm dễ lỗi trong flow.
4️⃣ Viết tài liệu / User Story / Acceptance Criteria
Tùy công ty và mô hình dự án, BA có thể viết nhiều loại tài liệu khác nhau:
BRD
SRS
FRS/FRD
User Story
Use Case
Acceptance Criteria
Business Rule
Process Flow
Wireframe
API requirement
Data mapping
Traceability Matrix
Với Agile team, BA thường viết User Story:
As a customer, I want to apply a voucher so that I can reduce my order total.
Nhưng User Story thôi chưa đủ.
BA cần viết thêm Acceptance Criteria:
Nếu voucher hợp lệ, hệ thống áp dụng giảm giá vào tổng đơn.
Nếu voucher hết hạn, hệ thống hiển thị message lỗi.
Một đơn hàng chỉ được áp dụng tối đa một voucher.
Nếu đơn không đạt giá trị tối thiểu, voucher không được áp dụng.
=> Tài liệu BA viết không phải để “cho có”.
Tài liệu phải giúp Dev build được và QA test được.
5️⃣ Làm việc với UI/UX Designer
Trong nhiều dự án, BA sẽ phối hợp với UI/UX để đảm bảo màn hình đúng nghiệp vụ.
BA có thể góp ý:
Màn hình cần hiển thị field nào?
Field nào bắt buộc?
Button nào cần disable trong trạng thái nào?
Error message hiển thị ra sao?
Empty state / loading state / success state / failed state thế nào?
User có cần confirm trước khi thực hiện hành động không?
Ví dụ với màn hình payment:
Khi user bấm Pay, nút Pay nên disable.
Nếu xử lý lâu hơn 3 giây, hiển thị Processing.
Nếu payment timeout, không nên báo Failed ngay nếu chưa có kết quả cuối.
Nếu thanh toán thành công, hiển thị order number và payment status.
=> UI đẹp nhưng sai rule nghiệp vụ thì vẫn fail.
6️⃣ Giải thích requirement cho Dev
Sau khi tài liệu được viết, BA thường phải tham gia grooming/refinement với Dev.
Dev có thể hỏi:
Field này lấy từ đâu?
API này trả status nào?
Nếu callback về trễ thì sao?
Nếu user double click thì xử lý thế nào?
Rule này áp dụng cho tất cả user hay chỉ một nhóm?
Có cần log không?
Có phân quyền không?
BA không cần code thay Dev.
Nhưng BA cần hiểu đủ để giải thích requirement rõ.
Ví dụ Dev hỏi:
“Payment timeout thì set order status là Failed hay Pending?”
BA phải biết đây là câu hỏi quan trọng, không trả lời cảm tính.
Cần confirm rule:
Timeout có đồng nghĩa failed không?
Có cần inquiry lại payment status không?
User có được retry không?
Có đưa vào reconciliation không?
=> Một BA tốt giúp Dev giảm đoán mò.
7️⃣ Hỗ trợ QA viết test case
BA không phải Tester, nhưng BA cần giúp QA hiểu requirement.
QA thường cần BA làm rõ:
Expected result là gì?
Rule nào cần test?
Edge case nào quan trọng?
Status nào đúng?
Message lỗi nào hiển thị?
Data test cần chuẩn bị gì?
Ví dụ với voucher, QA cần test:
Voucher hợp lệ
Voucher hết hạn
Voucher sai code
Voucher hết lượt
Đơn không đủ giá trị tối thiểu
Sản phẩm không thuộc phạm vi áp dụng
User áp dụng nhiều voucher cùng lúc
Nếu BA viết AC tốt, QA sẽ dễ tạo test case hơn.
=> BA không test thay QA, nhưng BA phải giúp QA biết “đúng là gì”.
8️⃣ Quản lý thay đổi requirement
Trong dự án thật, requirement thay đổi là chuyện bình thường.
Stakeholder có thể nói:
“À, thêm giúp anh điều kiện này nữa.”
“Màn này đổi logic một chút.”
“Flow payment phải thêm OTP.”
“Report cần thêm 3 cột.”
BA không nên nhận ngay mọi thay đổi.
BA cần đánh giá:
Change này có thuộc scope không?
Ảnh hưởng flow nào?
Ảnh hưởng API/data/test case nào?
Có làm tăng effort không?
Có ảnh hưởng timeline không?
Có thể đưa vào phase sau không?
Ví dụ:
Thêm OTP cho payment không chỉ là thêm một màn hình.
Nó có thể ảnh hưởng:
Flow checkout
Payment status
OTP service
Retry rule
Timeout rule
Security
Test case
User experience
=> BA phải giúp team nhìn thấy impact của change.
9️⃣ Hỗ trợ UAT với user/stakeholder
UAT là giai đoạn user hoặc business kiểm tra hệ thống trước khi go-live.
BA thường tham gia:
Chuẩn bị UAT scenario
Giải thích flow cho user
Hỗ trợ user test
Ghi nhận feedback
Phân loại issue: bug, change request, unclear requirement hay training issue
Làm việc với Dev/QA để xử lý
Ví dụ user nói:
“Tôi thấy màn này sai.”
BA cần làm rõ:
Sai so với requirement đã thống nhất?
Hay user muốn đổi nghiệp vụ?
Hay do user chưa hiểu cách dùng?
Hay UI message gây hiểu nhầm?
=> Không phải feedback nào trong UAT cũng là bug.
🔟 Hỗ trợ triển khai và sau go-live
Sau khi hệ thống lên production, BA vẫn có thể tham gia:
Theo dõi issue sau go-live
Hỗ trợ phân tích lỗi
Làm rõ ticket từ user/support
Kiểm tra dữ liệu hoặc log ở mức cơ bản
Đề xuất cải tiến cho phiên bản tiếp theo
Ví dụ sau go-live, support báo:
“Nhiều user phản ánh thanh toán thành công nhưng đơn chưa cập nhật.”
BA cần phối hợp kiểm tra:
Payment status
Order status
Callback log
Thời điểm phát sinh lỗi
Có timeout không?
Có reconciliation chưa?
User thấy message gì?
=> BA không chỉ làm trước khi Dev code.
BA còn giúp sản phẩm vận hành đúng sau khi release.
Một ngày làm việc của IT BA có thể gồm gì?
Một ngày thực tế của BA có thể là:
09:00 - Daily meeting với team
09:30 - Review requirement với PO/stakeholder
10:30 - Update User Story và Acceptance Criteria
11:30 - Trả lời câu hỏi của Dev về exception flow
13:30 - Grooming backlog với Dev/QA
15:00 - Review UI wireframe với Designer
16:00 - Hỗ trợ QA làm rõ expected result
17:00 - Update tài liệu và gửi recap cho team
Tùy công ty, BA có thể thiên về nghiệp vụ, tài liệu, Agile, product, system analysis hoặc integration.
Nhưng điểm chung là:
BA luôn phải làm rõ thông tin để team không hiểu sai.
Intern/Fresher BA thường được giao việc gì?
Nếu bạn mới vào nghề, bạn có thể chưa được giao ownership lớn ngay.
Nhưng thường sẽ được tham gia:
Ghi meeting note
Viết recap sau buổi họp
Vẽ flow đơn giản
Viết User Story nhỏ
Viết Acceptance Criteria
Update tài liệu theo feedback
Chuẩn bị test data
Hỗ trợ UAT
Review màn hình so với requirement
Tìm hiểu nghiệp vụ/domain
Hỏi Dev/QA để hiểu hệ thống
Đừng xem những việc này là nhỏ.
Nếu làm nghiêm túc, bạn sẽ học được:
Cách stakeholder nói requirement
Cách Dev đặt câu hỏi
Cách QA nghĩ về test case
Cách requirement thay đổi
Cách một feature đi từ ý tưởng đến production
Checklist năng lực Intern/Fresher BA nên rèn
Nếu muốn làm tốt trong dự án thật, hãy rèn các kỹ năng sau:
Biết hỏi để làm rõ requirement
Biết viết User Story cơ bản
Biết viết Acceptance Criteria test được
Biết tách Business Rule khỏi Flow
Biết nghĩ exception case
Hiểu API, SQL, Database cơ bản
Biết đọc flow và state
Biết ghi meeting note rõ ràng
Biết follow up sau buổi họp
Biết giao tiếp với Dev/QA
Biết quản lý thay đổi requirement
Kết
IT BA trong dự án thực tế không chỉ là người viết tài liệu.
BA là người:
Hiểu bài toán
→ Khai thác requirement
→ Phân tích flow/rule/exception
→ Viết tài liệu rõ
→ Làm việc với Dev/QA/UIUX
→ Hỗ trợ UAT
→ Theo dõi sau go-live
Với Intern/Fresher, bạn không cần biết hết ngay từ đầu.
Nhưng bạn cần hiểu rằng:
BA không phải “người ghi chép yêu cầu”.
BA là người giúp cả team hiểu đúng vấn đề và build đúng giải pháp.
Nếu bạn luyện được tư duy này, bạn sẽ không còn học BA theo kiểu thuộc template nữa.
Bạn sẽ bắt đầu học BA như một người thật sự tham gia vào dự án.
