IT Business Analyst là gì?

Công việc chính của IT BA là gì?

• Hiểu vấn đề kinh doanh: Lắng nghe các bên liên quan (stakeholders) để xác định mục tiêu và các vấn đề mà doanh nghiệp đang gặp phải.
• Phân tích và cụ thể hoá yêu cầu: Chuyển những nhu cầu đó thành các yêu cầu rõ ràng, chi tiết (requirements) mà đội kỹ thuật (developer, engineer) có thể hiểu và thực hiện.
• Đề xuất giải pháp: Đề xuất cách giải quyết vấn đề, đôi khi là vẽ sơ đồ quy trình (workflow), mô hình dữ liệu, hoặc giao diện người dùng (UI mockup).
• Hỗ trợ triển khai: Theo dõi dự án, đảm bảo giải pháp được thực hiện đúng và đáp ứng nhu cầu ban đầu.

Ví dụ

Hãy tưởng tượng bạn làm việc cho một công ty xe khách, nơi khách hàng thường phàn nàn rằng việc đặt vé online quá phức tạp. Với vai trò BA, bạn sẽ:

• Xác định vấn đề: Khách mất nhiều thời gian để tìm thông tin chuyến xe.
• Phân tích yêu cầu: Nghiên cứu dữ liệu và nhận thấy khách thường chọn cùng một tuyến xe.
• Đề xuất giải pháp: Thêm tính năng "Đặt lại vé cũ" để giảm thao tác.
• Hỗ trợ triển khai: Làm việc với đội kỹ thuật để tích hợp tính năng này vào hệ thống và kiểm tra hiệu quả sau khi áp dụng.

2. IT BA làm gì hàng ngày?

Công việc IT BA rất đa dạng. Dưới đây là những việc chính, kèm ví dụ thực tế từ app đặt vé xe khách:

• Phân tích yêu cầu: Trao đổi với các stakeholder để thảo luận về các yêu cầu mới hoặc cập nhật tiến độ dự án.
• Viết tài liệu: Viết các tài liệu như User Story, BRD, URD hoặc SRS (System Requirement Specification).
• Phân tích dữ liệu: Kiểm tra báo cáo từ hệ thống để xác định vấn đề hoặc đề xuất cải tiến.
• Làm việc với đội kỹ thuật: Giải đáp các thắc mắc và đảm bảo họ hiểu rõ yêu cầu.
• Kiểm tra kết quả: Đánh giá tính năng mới, đảm bảo sản phẩm đáp ứng đúng nhu cầu ban đầu.

Ví dụ thực tế chi tiết

Trong dự án cải thiện ứng dụng đặt vé xe khách, đội kinh doanh phản ánh: "Khách khó nhận biết chuyến xe nào còn chỗ trống."

1. Xác nhận vấn đề bằng số liệu: Mình tổ chức họp với đội kinh doanh và xem lại báo cáo — 30% khách bỏ đặt vì phải thử nhiều chuyến mới tìm được xe còn trống.
2. Phân tích hệ thống hiện tại: Mình thấy dữ liệu chỗ trống có sẵn nhưng không hiển thị real-time trên app.
3. Đề xuất giải pháp: "Thêm biểu tượng số ghế trống bên cạnh mỗi chuyến xe", kèm mockup giao diện mới — danh sách chuyến xe với số ghế trống rõ ràng.
4. Viết tài liệu yêu cầu: "Hiển thị số ghế trống real-time, cập nhật mỗi khi khách hàng tìm kiếm chuyến đi, hiển thị ở màn hình danh sách chuyến."
5. Phối hợp triển khai và kiểm thử: Mình làm việc với dev để tích hợp API dữ liệu chỗ trống từ các nhà xe đối tác, rồi kiểm tra cùng tester qua các kịch bản kiểm thử.

Kết quả: tỷ lệ huỷ đặt giảm 25%, khách phản hồi tích cực vì dễ chọn chuyến hơn.

Các con số trong ví dụ này là giả định để minh hoạ cách một BA đo lường vấn đề và kết quả, không phải số liệu thật của một dự án cụ thể.

3. IT BA khác gì với Product Owner, Project Manager, Developer?

Nhiều người mới thường nhầm lẫn vai trò của BA với các vị trí khác nghe gần giống trong dự án. Dưới đây là sự khác biệt:

Phần nhiệm vụ chính ở trên chỉ ghi ngắn gọn để hiểu đơn giản, vì mỗi công ty scope có thể khác nhau.

Ví dụ 1: dự án ứng dụng đặt vé xe khách

• Product Owner đề xuất ý tưởng: "Khách cần đặt vé nhanh hơn để cạnh tranh với các app đặt xe khách khác."
• Project Manager lập kế hoạch triển khai dự án trong 4 tuần, từ lúc lên yêu cầu đến khi hoàn thiện sản phẩm cho khách hàng sử dụng.
• Dev team (Dev, QC…) trao đổi với PO về kỹ thuật, còn BA gửi yêu cầu và tài liệu cụ thể.
• BA họp với PO, phân tích dữ liệu người dùng, nhận thấy 70% khách đặt vé lặp lại cùng tuyến, rồi đề xuất tính năng "Đặt lại chuyến đi cũ" để giảm thời gian thao tác.

Tuỳ công ty và dự án, có nơi chỉ có BA, có nơi chỉ có PO, có nơi có cả hai — và công việc có thể xen kẽ lẫn nhau.

User Story được viết ra: "Là khách hàng, tôi muốn đặt lại vé cũ chỉ bằng một nút bấm để tiết kiệm thời gian." BA vẽ thêm flowchart quy trình đặt vé mới rồi đưa dev triển khai.

Kết quả: tính năng được triển khai thành công, đội kinh doanh hài lòng vì khách hàng dùng app thường xuyên hơn nhờ trải nghiệm được cải thiện.

Ví dụ 2: dự án ứng dụng ngân hàng số

Giả sử doanh nghiệp muốn phát triển ứng dụng ngân hàng số với tính năng mở thẻ tín dụng online:

• Product Manager nhìn ở góc độ chiến lược dài hạn: nghiên cứu thị trường, xác định đối tượng mục tiêu là người trẻ thành thị, lập roadmap một năm cho sản phẩm gồm mở thẻ online, quản lý thẻ trên app, tích hợp ưu đãi tiêu dùng…
• Product Owner tập trung vào việc xác định tính năng cần làm trước. Ví dụ: quyết định tính năng OCR đọc CCCD và selfie eKYC sẽ phát triển ngay ở sprint đầu tiên, còn "ưu đãi hoàn tiền" làm sau. PO quản lý backlog và liên tục ưu tiên công việc cho dev team.
• Business Analyst lắng nghe và phân tích nhu cầu từ phía khách hàng và các phòng ban. Ví dụ: khách hàng muốn "đăng ký thẻ nhanh chóng, chỉ cần CCCD và selfie". BA viết ra các yêu cầu chi tiết, xác định luồng nghiệp vụ, điều kiện kiểm tra và mô tả cách hệ thống cần vận hành.
• Project Manager đảm bảo dự án triển khai đúng tiến độ, ngân sách, nhân sự: kiểm soát timeline ba tháng ra mắt tính năng, phân bổ nguồn lực cho Dev, QA, UI/UX, theo dõi tiến độ sprint và xử lý rủi ro nếu có chậm trễ.

4. Làm thế nào để trở thành BA?

Nếu bạn là người mới và muốn bắt đầu hành trình trở thành BA, hãy làm theo các bước sau.

4.1. Học các kỹ năng cơ bản

• Kỹ năng giao tiếp: Học cách thu thập thông tin và đặt câu hỏi đúng.
• Kiến thức nền về IT: Hiểu cách một hệ thống phần mềm được tạo ra — client và server nói chuyện với nhau thế nào, dữ liệu được lưu ở đâu, một tính năng đi từ yêu cầu tới lúc lên production qua những bước nào. Không cần code giỏi, nhưng phải đủ hiểu để nói chuyện được với dev.
• Tư duy phân tích: Tập chia nhỏ vấn đề thành các phần dễ giải quyết và đưa ra giải pháp.
• Kỹ năng viết tài liệu: Thử viết các User Story hoặc vẽ sơ đồ quy trình.

4.2. Làm quen với các công cụ BA phổ biến

• Microsoft Excel: Phân tích và trình bày dữ liệu.
• Confluence: Lưu trữ, chia sẻ và quản lý phiên bản tài liệu của cả team.
• Lucidchart, Visio, Draw.io: Vẽ sơ đồ quy trình hoặc mô hình hoá dữ liệu.
• Figma, Balsamiq: Dựng wireframe và mockup màn hình.
• Jira, Trello: Quản lý công việc và yêu cầu.

4.3. Học cách ứng dụng AI vào công việc

Phần này mình muốn nhắc tới vì đây là thứ doanh nghiệp đang quan tâm — biết dùng AI giờ là một điểm cộng khi đi làm. Nhưng nói rõ ngay từ đầu để bạn không đặt nhầm trọng tâm: AI chỉ là phần phụ trợ, cái cốt vẫn là năng lực BA trong người bạn. Nó không ngồi họp thay bạn, không hiểu bối cảnh doanh nghiệp thay bạn, và không chịu trách nhiệm khi yêu cầu viết ra bị sai.

Cái nó đỡ được cho bạn là phần tay chân: dựng bản nháp tài liệu trong vài phút thay vì vài giờ, tóm tắt biên bản họp, sinh danh sách câu hỏi để đi khơi gợi yêu cầu, rà lại user story xem còn thiếu trường hợp nào.

Vài công cụ nên biết:

• ChatGPT, Claude.AI, Gemini: Soạn nháp tài liệu, tóm tắt cuộc họp, brainstorm câu hỏi phỏng vấn stakeholder, review lại yêu cầu mình vừa viết xem có chỗ nào mơ hồ.
• Figma: Dựng wireframe và mockup, nay đã có tính năng AI hỗ trợ phác nhanh khung màn hình để mang đi hỏi stakeholder.
• Claude Code, Codex: Làm việc thẳng trên cả thư mục tài liệu của bạn, không phải copy qua copy lại từng đoạn trong khung chat. Giao cho nó soạn BRD/SRS theo đúng mẫu team đang dùng, cập nhật đồng loạt cả bộ tài liệu khi yêu cầu thay đổi, rà xem tài liệu nào đang mâu thuẫn với tài liệu nào. Dựng được luôn wireframe hoặc bản prototype bấm thử được để mang đi hỏi stakeholder, thay vì chỉ một ảnh tĩnh.

Nhưng có một cái bẫy mà mình muốn bạn biết sớm, trước cả khi biết dùng công cụ nào.

Cái bẫy không nằm ở chỗ AI trả lời sai. Nó nằm ở chỗ bạn quen để AI nghĩ hộ. Nghề BA giỏi lên nhờ những lần bạn tự ngồi bóc một vấn đề rối, tự nghĩ ra câu hỏi cho stakeholder, tự phát hiện mình hiểu sai chỗ nào rồi sửa. Giao hết phần đó cho AI thì tài liệu vẫn ra, thậm chí trông gọn gàng hơn — nhưng cái đáng lẽ phải lớn lên trong đầu bạn thì không lớn.

Trớ trêu là hậu quả đến muộn. Một hai năm đầu bạn thấy mình nhanh hơn đồng nghiệp. Đến lúc gặp bài toán mà AI đưa ra một phương án nghe rất thuyết phục nhưng sai bối cảnh, bạn lại không đủ nền để nhận ra — vì đúng cái năng lực dùng để kiểm tra AI là cái bạn đã bỏ qua không rèn.

Cách dùng mình khuyên: tự nghĩ trước, đưa AI sau. Tự phác luồng nghiệp vụ, tự viết bản nháp, tự liệt kê câu hỏi — rồi mới đưa cho AI phản biện, bổ sung trường hợp bạn bỏ sót, chỉ ra chỗ diễn đạt còn mơ hồ. Làm ngược thứ tự đó thì bạn đang trả học phí cho AI chứ không phải cho mình.

Một lưu ý nữa: đừng dán dữ liệu nhạy cảm của khách hàng vào các công cụ AI công cộng, và luôn tự kiểm tra lại kết quả trước khi đưa vào tài liệu chính thức — AI viết trôi chảy nhưng vẫn bịa như thường.

Nếu bạn muốn đi sâu hơn về việc ứng dụng AI vào đúng từng đầu việc của IT BA, có thể tham khảo AI4BA — nội dung chuyên về chủ đề này.

4.4. Thực hành qua các dự án nhỏ

• Phân tích một ứng dụng quen thuộc (ví dụ app đặt vé xe khách), tìm ra điểm chưa hiệu quả và đề xuất cải tiến.
• Tham gia các khoá học online hoặc xin làm intern để có kinh nghiệm thực tế.

4.5. Xác định lộ trình học tập

• Ngắn hạn: Học các kiến thức cơ bản qua sách, blog hoặc khoá học online.
• Dài hạn: Tính tới chứng chỉ quốc tế của IIBA. Người mới bắt đầu từ ECBA (Entry Certificate in Business Analysis) vì chứng chỉ này không yêu cầu số giờ kinh nghiệm. Hai chứng chỉ cao hơn cần kinh nghiệm thực tế mới nộp hồ sơ được: CCBA yêu cầu 3.750 giờ làm BA trong 7 năm gần nhất, CBAP yêu cầu 7.500 giờ. Nói cách khác, CCBA và CBAP là đích của vài năm sau chứ không phải thứ để thi ngay khi mới vào nghề.

5. Lời kết: tại sao bạn nên bắt đầu với BA?

Business Analyst không chỉ là một công việc, mà còn là cơ hội để bạn tạo ra giá trị thực tế từ khả năng phân tích và sáng tạo của mình. Dù bạn là người mới hay đã có kinh nghiệm, BA luôn là một vị trí đầy tiềm năng và thách thức trong nhiều lĩnh vực.

Hãy bắt đầu hành trình trở thành BA ngay hôm nay bằng cách tìm hiểu thêm tài liệu, tham gia các khoá học, hoặc thực hành qua các dự án nhỏ. Chúc bạn sớm trở thành BA, và biến ý tưởng của bạn thành giải pháp thực tế!