Trả lời ngắn: làm BA không cần viết code sản phẩm, nhưng nên đọc được SQL, tài liệu API và luồng dữ liệu, mức đó đủ để bạn tự kiểm tra requirement với dữ liệu thật và nói chuyện thẳng với dev, thay vì chuyển lời qua lại.
Hỏi ba nhà tuyển dụng câu “BA có cần biết code không” thì bạn có thể nhận về ba câu trả lời khác nhau, chỗ này bảo chỉ cần hiểu nghiệp vụ, chỗ kia hỏi SQL, chỗ khác lại đưa một đoạn JSON rồi hỏi thiếu trường gì. Người mới nghe xong rất dễ hoang mang, nhưng thật ra ba câu đó không mâu thuẫn nhau, chúng chỉ phản ánh ba kiểu dự án khác nhau. Câu trả lời của mình là BA cần biết đọc, chưa cần biết viết, còn đọc cái gì và đến mức nào thì ở phần dưới.
không viết code, nhưng phải hiểu logic#
BA không cần viết vòng lặp bằng Java, nhưng khi dev nói “endpoint này trả về 2.000 dòng, frontend mỗi lần gọi 100 dòng” thì BA nên hiểu chuyện đó ảnh hưởng tới người dùng ra sao, màn hình có phân trang không, tìm kiếm chạy trên toàn bộ dữ liệu hay chỉ trên trang đang xem.
Thử hình dung một BA rất vững nghiệp vụ kho, thuộc từng bước nhập, xuất, kiểm kê, rồi dev hỏi “API tracking trả về cấu trúc thế nào, có trường số lô không?”. Nếu BA không đọc được tài liệu API thì một câu hỏi hai phút biến thành một vòng hỏi qua hỏi lại kéo dài cả buổi, chẳng ai sai cả, chỉ là thiếu một kỹ năng đọc.
Những vị trí BA thuần cầu nối, nhận yêu cầu từ user rồi chuyển cho dev, vẫn tồn tại. Theo mình đó là chỗ làm được nhưng dễ chạm trần, vì giá trị BA tạo ra chỉ dừng ở việc truyền lời.
SQL là thứ nên học đầu tiên#
Nếu chỉ học một thứ kỹ thuật thì hãy học SQL, không phải để thành developer, mà để tự mở dữ liệu xem hệ thống đang chạy thế nào, tự viết query kiểm tra logic, và tự đối chiếu số trên báo cáo với dữ liệu gốc.
Lý do là người dùng mô tả quy trình theo cách họ nghĩ nó đang chạy, còn dữ liệu cho thấy nó thật sự chạy ra sao. Giả sử quản lý kho khẳng định tồn kho lúc nào cũng khớp, bạn chạy một câu cộng số lượng theo vị trí và trạng thái thì thấy lệch với báo cáo, đào thêm mới biết báo cáo không tính hàng đang chờ kiểm tra chất lượng. Phát hiện ở bước phân tích thì rẻ hơn rất nhiều so với phát hiện sau go-live.
Học tới đâu là đủ thì xem bài SQL cho BA: SELECT, JOIN, GROUP BY là đủ sống, và học kèm cách đọc sơ đồ dữ liệu ở bài ERD cho BA để hiểu vì sao query phải JOIN.
API và tích hợp là lợi thế khi làm ERP#
Ở dự án ERP hay chuỗi cung ứng, tích hợp gần như là chuyện mặc định, ERP trao đổi dữ liệu với MES, MES với hệ thống kho, kho với bên vận chuyển. Hiểu cơ bản về request, response, HTTP method và xác thực thì bạn tự đọc được tài liệu API của bên thứ ba, đánh giá sớm tích hợp có khả thi không, và bắt được chỗ không khớp trước khi dev mất công debug.
Bạn không cần code API, bạn chỉ cần chỉ vào một đoạn JSON và nói được “thiếu trường số lô, mà requirement cần truy vết theo lô”. Câu đó tiết kiệm cho cả đội hơn mọi slide.
biết code là con dao hai lưỡi#
BA đi lên từ dev có lợi thế rõ, nghe requirement là thấy ngay technical constraint, ước lượng được độ phức tạp, chuyện rẽ hướng này có trong bài Dev muốn chuyển sang BA thì nên làm gì.
Nhưng có một cái bẫy, là biết code thì rất dễ rơi vào chế độ giải pháp. Thử hình dung buổi khảo sát với bộ phận kho, BA biết code ngồi phác luôn giao diện màn hình nhập liệu mới, trong khi câu cần hỏi là vì sao thủ kho phải nhập lại con số mà máy quét đã đọc rồi, biết đâu giải pháp tốt nhất là bỏ hẳn cái màn hình đó. BABOK Guide v3 tách rõ việc hiểu need trước khi định nghĩa solution là có lý do cả.
BA cần kỹ thuật tới mức nào#
Mình chia ba mức để bạn tự định vị.
Mức một là biết đọc, tức SQL cơ bản, đọc tài liệu API, hiểu luồng dữ liệu. Theo mình đây là mức tối thiểu cho BA làm ERP hay dự án nhiều tích hợp.
Mức hai là biết chạy, tự viết query phức tạp hơn, tự gọi thử API bằng Postman hoặc curl, tự đọc log để khoanh vùng lỗi, ở mức này bạn làm việc với dev rất trơn dù chẳng viết dòng code sản phẩm nào.
Mức ba là biết code, viết script tự động hóa, dựng prototype, hiểu kiến trúc hệ thống. Mức này đưa bạn đến gần vai Technical BA hay Solution Architect, với điều kiện đừng để giải pháp chạy trước vấn đề.
khi nào nghiệp vụ quan trọng hơn kỹ thuật#
Tự phản biện lại chính mình một chút, ở các lĩnh vực như ngân hàng, bảo hiểm, y tế thì hiểu quy định và nghiệp vụ domain thường quyết định nhiều hơn, kỹ thuật có thể học sau. Đừng bỏ ra nửa năm học lập trình trong khi vị trí bạn nhắm cần hiểu nghiệp vụ tín dụng hơn.
Còn nếu bạn nhắm ERP, SaaS hay dự án nặng tích hợp thì nền kỹ thuật ở mức một là thứ nên có sớm, và bước đầu rất nhỏ thôi, cài một database mẫu, viết câu SELECT đầu tiên, rồi mở Postman gọi thử một API công khai.
Bạn đang ở mức nào trong ba mức trên, và đang kẹt ở bước nào? Kể mình nghe qua Facebook hoặc LinkedIn.
