BA Kỳ 1: Business Analyst là gì và làm gì mỗi ngày

Duy Anh
04/11/2026
11:41 sáng

Chị Hà mở tiệm cơm văn phòng gần khu công nghiệp. Một hôm chị gọi cậu em làm công nghệ sang chơi và nói: “Chị muốn làm cái app đặt cơm, em làm giúp chị nhé.”

Nghe thì rõ ràng quá rồi. Nhưng nếu lúc đó có một người ngồi xuống cạnh chị, rót ly trà đá và hỏi vài câu thật bình thường, câu chuyện sẽ rẽ sang hướng khác hẳn. Người ngồi xuống hỏi đó, trong thế giới công việc, được gọi là Business Analyst, gọi tắt là BA. Đây là Kỳ 1 của chuỗi bài về nghề BA. Mình sẽ kể từ từ, gặp từ nào “nghe lạ tai” là giải thích luôn cho khỏi phải tra.

(Chị Hà và tiệm cơm là tình huống tưởng tượng để dễ hình dung, không phải một khách hàng có thật nhé.)

Ba câu hỏi đổi hướng cả câu chuyện

Người ngồi cạnh chị Hà không hỏi “app màu gì, nút nằm đâu”. Bạn ấy hỏi:

“Vì sao chị muốn làm app?” Chị đáp: “Trưa nào khách cũng nhắn Zalo đặt cơm, chị ghi không xuể, hay nhầm, có hôm nấu thiếu.”
“Nhầm nhiều nhất ở chỗ nào hả chị?” Nghĩ một lúc chị mới nhận ra: không phải nhầm món, mà là nhiều người đặt muộn, khi bếp đã bắt đầu nấu.
“Nếu mai chưa có app, chị cần thay đổi gì để bớt nhầm?” Chị Hà trầm ngâm: “Chắc cần có giờ chốt đơn rõ ràng, và khách phải biết đơn của mình đã được ghi.”

Ba câu thôi mà vấn đề thật lộ ra rồi. Chị Hà không thiếu cái app. Chị thiếu giờ chốt đơn và một cách ghi đơn cho ra ghi đơn. Có khi giải pháp tốt nhất lúc này chỉ là một bảng tính chia sẻ, thêm quy định chốt đơn 9 giờ 30 và một tin nhắn xác nhận. Ngày mai dùng được, gần như không tốn tiền. Khi tiệm đông hơn nữa, lúc đó hãy tính chuyện app.

Việc “ngồi xuống hỏi cho ra vấn đề thật” đó chính là cốt lõi của nghề BA.

Giải nghĩa mấy từ nghe “to tát”

Nghề này hay dùng tiếng Anh. Thực ra mỗi từ đều có nghĩa rất đời thường, mình lần lượt giải thích bằng chuyện tiệm cơm nhé.

Stakeholder (các bên liên quan) là tất cả những ai có phần trong chuyện này. Tưởng tượng một đám cưới: cô dâu, chú rể, hai bên gia đình, nhà hàng, ban nhạc đều là “bên liên quan”, vì ai cũng có điều mong muốn và có thể bị ảnh hưởng nếu mọi thứ hỏng. Ở tiệm chị Hà, đó là chị Hà (chủ tiệm), bếp trưởng, người giao cơm và khách đặt cơm.

Business objective (mục tiêu nghiệp vụ) là điều doanh nghiệp muốn đạt, nói bằng kết quả chứ không nói bằng cách làm. Mục tiêu của chị Hà không phải “làm app”, mà là “giảm số suất cơm nấu sai, nấu thiếu”.

Solution (giải pháp) là cách để đạt mục tiêu. Nhiều người nghĩ giải pháp là phần mềm. Không hẳn. Giải pháp có thể là một bảng tính, một quy định mới, một buổi tập huấn, hay một cái app. Miễn là giải quyết được vấn đề.

Requirement (yêu cầu) là điều giải pháp phải làm được. Ví dụ: “Khách đặt xong phải thấy đơn của mình đã được ghi.” Kỳ 3 sẽ nói kỹ hơn.

Scope (phạm vi) là ranh giới của việc sẽ làm và không làm lần này. Chẳng hạn lần này chỉ làm khâu đặt cơm, chưa làm thanh toán trực tuyến. Nghe thì đơn giản nhưng đây là thứ cứu dự án khỏi chuyện “thêm một tí” mãi không dứt.

Nếu bạn từng nghe ai đó đi cải tạo nhà thì dễ hiểu hơn. Cả nhà là stakeholder. “Nhà phải mát vào mùa hè” là business objective. Trồng cây, làm mái che hay lắp điều hòa là các solution. “Phòng ngủ phải xuống dưới 30 độ” là một requirement. “Lần này chỉ làm tầng một” là scope.

Vậy BA làm gì, nói thật gọn?

BA là người hỏi cho ra vấn đề thật, cùng các bên liên quan chọn giải pháp hợp lý, rồi viết rõ điều cần làm để ai cũng hiểu cùng một chuyện.

Nhiều người hay nói BA là “cầu nối” giữa khách hàng và đội kỹ thuật. Cũng đúng, nhưng chưa đủ. Cầu chỉ chuyển lời. BA còn phải tự hỏi: lời này có đúng thứ họ cần không? Giống như người bán hàng giỏi không chỉ chuyển lời “em muốn mua áo”, mà hỏi thêm “mặc đi đâu, mùa nào”, để biết thật ra bạn đang cần áo gió chứ không phải áo thun.

Và BA không chỉ có trong ngành phần mềm. Ngân hàng, sản xuất, bán lẻ, y tế, vận tải… chỗ nào cần cải tiến cách làm việc thì chỗ đó có công việc của BA. Chỉ là trong ngành phần mềm, cái tên ấy phổ biến nhất.

Một ngày của BA trông thế nào?

Không ngày nào giống ngày nào, nhưng thường xoay quanh mấy việc này:

Gặp người dùng và khách hàng, hỏi họ đang làm việc ra sao và vướng ở đâu.
Ghi lại và sắp xếp yêu cầu thành danh sách rõ ràng.
Viết tài liệu mô tả từng chức năng và quy tắc nghiệp vụ.
Họp với đội kỹ thuật, giải thích yêu cầu và nghe họ báo chỗ nào khó làm.
Theo dõi kiểm thử, xem sản phẩm làm ra có đúng điều đã thống nhất chưa.
Xử lý thay đổi. Khi có người muốn đổi ý, BA ghi lại và cân nhắc ảnh hưởng thay vì gật đầu ngay.

BA khác gì mấy vị trí gần giống?

Nhìn từ ngoài, dễ nhầm BA với những vị trí khác trong dự án:

Quản lý dự án lo “làm khi nào, bao nhiêu người, tốn bao nhiêu tiền”. BA lo “làm cái gì”.
Lập trình viên viết mã để hiện thực hóa giải pháp. BA làm rõ yêu cầu trước khi viết.
Kiểm thử (tester) kiểm tra sản phẩm có đúng yêu cầu không. BA là người viết ra yêu cầu đó.
Product owner (người chịu trách nhiệm sản phẩm) quyết định làm gì trước, làm gì sau. BA phân tích và làm rõ, còn thứ tự ưu tiên thì product owner chốt.

Ở công ty nhỏ, một người có thể kiêm cả mấy vai. Ở công ty lớn, các vai tách riêng ra.

Ai hợp với nghề này?

Không cần giỏi lập trình, cũng không cần là “dân kinh doanh” từ trong trứng nước. Mấy thứ này mới giúp bạn đi lâu:

Thích hỏi “tại sao” thay vì nhận việc rồi làm luôn.
Viết rõ, nói gọn, vì thứ bạn viết ra là thứ nhiều người cùng đọc.
Kiên nhẫn, vì có những ý phải hỏi lại ba bốn lần mới ra.
Hiểu một lĩnh vực nào đó, như ngân hàng, bán lẻ, sản xuất. Đây là lợi thế lớn khi vào nghề.

Nhiều người bắt đầu từ vị trí vận hành, kế toán hay chăm sóc khách hàng, rồi chuyển sang BA vì họ hiểu công việc từ bên trong.

Muốn thử thì bắt đầu từ đâu?

Từ chính công việc của bạn bây giờ. Chọn một việc hay lặp lại, ghi ra từng bước, chỉ ra chỗ nào chậm hoặc dễ sai, rồi nghĩ cách cải thiện. Đó đã là một bài tập BA thu nhỏ rồi.

Tạm kết

BA đơn giản là người giúp người khác nhìn ra đúng vấn đề của mình, rồi cùng tìm cách giải quyết cho hợp lý. Cái hay của nghề này là bạn thấy được cả bức tranh, từ lúc một ý tưởng còn mơ hồ cho tới khi nó thành một thứ mọi người dùng được.