IT Business Analyst(ITBA)
Nhánh BA gắn với phần mềm: đầu ra là tài liệu cho đội phát triển, đầu vào là nghiệp vụ của khách. Ở Việt Nam gần như mọi tin tuyển BA đều là tin tuyển IT BA, dù tiêu đề chỉ ghi hai chữ BA.
Định nghĩa
Mở một trang tuyển dụng ở Việt Nam, gõ "business analyst", rồi đọc phần mô tả công việc của mười tin đầu tiên. Gần hết trong số đó là IT BA: làm ở công ty phần mềm hoặc phòng IT của doanh nghiệp, đầu ra là tài liệu để dev code. Cách gọi này là đặc sản của thị trường châu Á, chứ IIBA không có chức danh riêng tên "IT Business Analyst".
IT BA là BA làm việc trong bối cảnh giải pháp là phần mềm, nên phải hiểu đủ về hệ thống để mô tả được thứ dev dựng lên được.
Ranh giới với BA nghiệp vụ thuần
| IT Business Analyst | BA nghiệp vụ (business-side BA) | |
|---|---|---|
| Bài toán đặt ra | Hệ thống cần làm được gì | Doanh nghiệp cần thay đổi gì |
| Ngồi cùng ai | Dev, QC, designer, DevOps | Trưởng phòng, vận hành, tài chính |
| Đầu ra | FRD/SRS, user story, sơ đồ luồng màn hình, mô tả API | Đề xuất quy trình, business case, phân tích chi phí |
| Kiến thức nền | Kiến trúc hệ thống cơ bản, API, database, quy trình test | Ngành dọc: ngân hàng, bán lẻ, logistics |
| Đo bằng gì | Yêu cầu rõ tới mức dev không phải hỏi lại nhiều | Quy trình mới có tiết kiệm được không |
| Ở VN | Rất nhiều tin tuyển | Thường nằm trong phòng cải tiến hoặc chuyển đổi số |
Trên thực tế một người hay làm cả hai, đặc biệt ở công ty product Việt Nam quy mô 50–200 người.
Cần biết kỹ thuật tới đâu
Chỗ này gây tranh cãi nhiều nhất trong các nhóm BA. Quan điểm của mình sau vài năm: bạn không cần code được, nhưng cần đọc hiểu được. Cụ thể là đọc được một response JSON và biết trường nào bắt buộc, trường nào nullable; bắn thử một request bằng Postman để tự kiểm chứng thay vì ngồi đợi dev rảnh; viết được câu SELECT có JOIN hai bảng để tự đếm số bản ghi lỗi.
Thêm hai thứ ít người nhắc. Hiểu đồng bộ khác bất đồng bộ, và vì sao hai hệ thống có thể lệch dữ liệu trong ba mươi giây mà chẳng bên nào sai. Rồi biết môi trường dev, staging, production khác nhau ở đâu — chủ yếu để đừng bao giờ buột miệng đề nghị test thử trên production cho nhanh.
Quá mức đó thì tuỳ sở thích. Có BA đọc được cả sequence diagram của dev, có BA không, cả hai vẫn làm tốt.
Ví dụ thực tế
Yêu cầu từ phòng marketing dài đúng một dòng trong email: thêm trả góp qua thẻ tín dụng, kịp đợt sale tháng 11. Sàn thương mại điện tử nội địa, ngày thường tầm 11.400 đơn.
Phần nghiệp vụ mất một buổi: chọn ngân hàng, kỳ hạn 3/6/9 tháng, ai chịu phí chuyển đổi. Phần IT BA mất ba tuần, vì phải chốt những thứ như: webhook báo kết quả về chậm thì đơn hàng ở trạng thái nào; khách bấm back giữa chừng thì có tạo đơn treo không; đối soát cuối ngày lấy theo giờ nào khi cổng thanh toán chốt lúc 23:00 còn hệ thống chốt lúc 00:00; hoàn tiền một phần cho đơn trả góp xử lý ra sao. Toàn bộ những câu đó không nằm trong đầu người làm marketing, nhưng nếu BA không hỏi thì sau go-live sẽ có một danh sách đơn treo mà kế toán phải đối soát bằng tay.
Câu hay bị hỏi phỏng vấn
- "Dev bảo yêu cầu này không làm được, bạn xử lý thế nào?" — họ muốn nghe bạn tách "không làm được về mặt kỹ thuật" khỏi "làm được nhưng tốn thời gian", rồi mang phương án đánh đổi lên cho người quyết.
- "Bạn viết tài liệu bằng công cụ gì?" — Confluence, Word, Jira, draw.io hay Figma đều được, quan trọng là bạn giải thích được vì sao chọn.
- "Kể một lần bạn hiểu sai yêu cầu." — đừng trả lời là chưa bao giờ. Người phỏng vấn đang tìm dấu hiệu bạn biết rút kinh nghiệm.
- "Làm sao biết một yêu cầu đã đủ rõ?" — câu trả lời an toàn: khi QC viết được test case từ nó mà không cần hỏi thêm bạn.
Nếu bạn đang chuyển từ QC sang IT BA, phần kỹ thuật gần như miễn phí, thứ cần luyện là dẫn dắt một cuộc họp có ba phòng ban đang mâu thuẫn nhau.
