Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười sinh viên mới ra trường rằng "Business Analyst làm gì?", có lẽ bạn sẽ nhận được mười câu trả lời mơ hồ na ná nhau: "làm cầu nối", "viết tài liệu", "ngồi họp với dev". Không sai, nhưng cũng chẳng đủ để bạn hình dung một ngày làm việc thật của một BA sẽ trôi qua như thế nào — bạn dậy, mở laptop, và rồi làm gì trong 8 tiếng tiếp theo?
Bài học này tồn tại để chữa đúng cái mơ hồ đó. Trước khi bạn học viết user story (Bài 4, Bài 29), trước khi bạn học elicitation (Bài 31) hay BPMN (Bài 26), bạn cần một bức tranh sống động về con người BA là ai và công việc BA thực sự diễn ra ra sao trong một ngày. Vì một sự thật phũ phàng: rất nhiều bạn trẻ theo nghề BA vì nghe nói "lương tốt, không cần code" — rồi ba tháng sau vỡ mộng vì phát hiện công việc thật khác xa tưởng tượng.
Khi bạn hiểu rõ chân dung và nhịp làm việc của BA ngay từ đầu, ba thứ xảy ra: bạn tự đánh giá được mình có hợp không, bạn biết mình đang thiếu kỹ năng gì để chuẩn bị, và trong buổi phỏng vấn (Bài 19) bạn nói về nghề bằng ngôn ngữ của người trong cuộc chứ không phải người đọc mô tả tuyển dụng. Đó là lợi thế cực lớn với một fresher.
Khái niệm cốt lõi
BA là ai — định nghĩa mà bạn dùng được
Business Analyst (BA — chuyên viên phân tích nghiệp vụ) là người đứng giữa hai thế giới nói hai ngôn ngữ khác nhau: thế giới business (kinh doanh, vận hành, khách hàng — những người biết muốn gì nhưng không biết diễn đạt cho máy tính) và thế giới technical (dev, QA, data — những người biết làm thế nào nhưng không biết chính xác phải làm cái gì). Nhiệm vụ của BA là biến mong muốn mơ hồ của bên business thành yêu cầu rõ ràng, đủ chi tiết để bên technical xây được đúng thứ khách hàng cần.
Hãy tránh cái định nghĩa sáo rỗng "BA là cầu nối". Cầu nối chỉ là ẩn dụ. Cụ thể hơn, một BA làm ba việc lõi:
- Khai thác và làm rõ (elicit & clarify): đặt câu hỏi đúng để moi ra nhu cầu thật, kể cả những nhu cầu mà stakeholder chưa tự nói ra được.
- Phân tích và cấu trúc (analyze & structure): sắp xếp mớ thông tin lộn xộn thành mô hình, quy trình, danh sách yêu cầu có logic.
- Truyền đạt và xác nhận (communicate & validate): viết tài liệu, vẽ sơ đồ, trình bày lại cho các bên xác nhận "đúng ý tôi rồi đấy".
BA không phải là ai
Để định nghĩa cho sắc, phải nói cả những gì BA không làm. BA không phải là người quyết định cuối cùng về ngân sách hay ưu tiên sản phẩm (đó thường là Product Owner hoặc Product Manager). BA không phải là người viết code (đó là developer). BA không phải là người test toàn bộ hệ thống (đó là QA — dù BA có hỗ trợ UAT, xem Bài 35). Và BA không phải là "thư ký ghi biên bản họp" — nếu công việc của bạn dừng ở mức ghi lại lời người khác nói mà không phân tích, bạn chưa làm đúng vai BA.
Các "loại" BA bạn sẽ gặp
Trên thực tế, một chức danh "Business Analyst" có thể mang nhiều màu sắc tùy công ty:
- IT BA / System BA: tập trung vào phần mềm, làm việc sát dev, viết tài liệu chức năng. Đây là loại phổ biến nhất với fresher tại Việt Nam.
- Business Process BA: tập trung cải tiến quy trình vận hành, đôi khi không đụng nhiều tới phần mềm.
- Data BA: thiên về phân tích dữ liệu, báo cáo, dashboard (khác với Data Analyst nhưng dễ nhầm).
Nhịp công việc: reactive hay proactive?
Điều mà ít ai nói với sinh viên: công việc BA có hai nhịp đan xen. Nhịp proactive là khi bạn chủ động khai thác yêu cầu, viết tài liệu, vẽ sơ đồ — công việc "sâu", cần tập trung. Nhịp reactive là khi dev nhắn "chỗ này em không hiểu, giải thích giúp", QA hỏi "case này expected result là gì", stakeholder đổi ý phút chót. Một ngày của BA hiếm khi yên ả từ đầu đến cuối — bạn liên tục bị kéo ra khỏi công việc sâu để trả lời. Hiểu điều này giúp bạn không sốc khi đi làm.
Tình huống thực tế
Tình huống 1 — Một ngày của Linh, IT BA fresher tại một fintech ở TP.HCM
Linh, 23 tuổi, tốt nghiệp ngành Hệ thống thông tin, mới vào làm BA được 4 tháng tại một công ty fintech khoảng 120 người ở Quận 1. Đây là một ngày thứ Ba điển hình của Linh:
- 8h45: Linh mở Jira, xem lại các task được gán. Có một ticket dev comment tối qua: "Màn hình xác thực OTP — nếu user nhập sai 5 lần thì hệ thống làm gì?" Linh nhận ra tài liệu của mình quả thật chưa nói rõ tình huống này.
- 9h00 – 9h15: Daily standup của team Scrum. Linh báo cáo ngắn: hôm qua làm gì, hôm nay làm gì, đang vướng gì (chi tiết Scrum ở Bài 34).
- 9h20 – 10h30: Linh làm "công việc sâu" — hoàn thiện đặc tả cho tính năng chuyển tiền liên ngân hàng. Cô liệt kê các business rule: hạn mức 500 triệu/ngày, phí 0 đồng dưới 500 nghìn, chặn giao dịch nếu tài khoản chưa định danh eKYC.
- 10h30 – 11h15: Họp với chị trưởng phòng Vận hành để làm rõ quy tắc tính phí — hóa ra có ngoại lệ cho khách VIP mà tài liệu chưa hề nhắc. Đây chính là elicitation trong thực tế.
- 13h30 – 14h00: Trả lời loạt câu hỏi của dev và QA trên Slack. Bổ sung câu trả lời cho ticket OTP sáng nay: sai 5 lần thì khóa 30 phút.
- 14h00 – 15h30: Vẽ lại luồng nghiệp vụ chuyển tiền bằng sơ đồ, cập nhật lên Confluence, tag người liên quan review.
- 16h00: Ngồi cùng designer để rà lại wireframe màn hình phí giao dịch, bổ sung annotation (Bài 40).
Tình huống 2 — Khoa, Process BA tại chuỗi bán lẻ, và một ngày "không đụng code"
Khoa làm BA tại một chuỗi cửa hàng tiện lợi 200 điểm bán ở miền Bắc. Khác với Linh, một ngày của Khoa gần như không dính tới phần mềm. Vấn đề công ty giao: quy trình kiểm kê tồn kho cuối ngày ở các cửa hàng đang quá chậm, nhân viên phải ở lại thêm 45 phút mỗi tối.
Ngày làm việc của Khoa gồm: buổi sáng ra thẳng một cửa hàng ở Cầu Giấy, đứng quan sát nhân viên kiểm kê thật (kỹ thuật observation), ghi lại từng bước và bấm giờ. Buổi chiều, anh vẽ quy trình hiện tại (as-is) lên giấy, khoanh tròn 3 điểm gây tắc: đếm thủ công hai lần, nhập liệu trên giấy rồi mới gõ lại vào máy, và phải chờ quản lý ký duyệt. Cuối ngày anh phác quy trình mới (to-be) cắt bỏ bước nhập liệu trùng.
Bài học rút ra: BA không nhất thiết ngồi trước màn hình cả ngày. Có những vai BA mà "phòng làm việc" chính là hiện trường vận hành. Điểm chung với Linh vẫn là ba việc lõi: khai thác (quan sát), phân tích (vẽ as-is/to-be), truyền đạt (đề xuất quy trình mới). Chức danh giống nhau, bối cảnh khác nhau — nên khi đọc JD, đừng chỉ nhìn chữ "Business Analyst".
Tình huống 3 — Một ngày "vỡ trận" và cách BA giỏi phản ứng
Không phải ngày nào cũng đẹp. Hãy hình dung ngày của Linh khi mọi thứ trục trặc: 10h sáng, khách hàng lớn đột ngột yêu cầu đổi luồng duyệt giao dịch — thứ đã được dev code gần xong. Product Owner hoảng. Dev bực vì "sắp xong rồi lại đổi". Nếu là fresher non tay, Linh sẽ cuống lên hứa đại "được ạ, em cập nhật ngay".
Nhưng Linh làm khác. Cô dành 20 phút đặt câu hỏi cho PO để hiểu vì sao khách đổi ý (hóa ra do một quy định mới của Ngân hàng Nhà nước). Cô đánh giá tác động: thay đổi này đụng 3 màn hình, ảnh hưởng 2 story đang chạy. Cô viết lại một bản tóm tắt tác động ngắn gọn gửi PO để PO quyết định có đưa vào sprint này hay sprint sau.
Bài học rút ra: Trong ngày "vỡ trận", giá trị của BA không nằm ở tốc độ gõ tài liệu, mà ở khả năng giữ bình tĩnh, hỏi đúng, đánh giá tác động và trình bày để người có thẩm quyền ra quyết định. Đây là kỹ năng phân biệt BA làng nhàng với BA được tin tưởng.
Hướng dẫn từng bước
Nếu bạn muốn tự "sống thử" một ngày làm BA để cảm nhận, hãy làm theo các bước sau — đây cũng là khung tư duy bạn sẽ dùng khi đi làm thật:
- Bắt đầu bằng việc rà "hộp thư đến" của yêu cầu. Mỗi sáng, BA kiểm tra Jira/email/Slack xem có câu hỏi, thay đổi, hay vướng mắc nào cần xử lý. Việc đầu tiên không phải là viết, mà là phân loại việc.
- Tách rõ hai loại thời gian. Chủ động chặn 1–2 khối "công việc sâu" (deep work) mỗi ngày để viết tài liệu, vẽ sơ đồ. Phần còn lại dành cho họp và trả lời. Nếu không tự bảo vệ khối deep work, bạn sẽ bị các câu hỏi lặt vặt cuốn trôi cả ngày.
- Với mỗi yêu cầu mới, luôn hỏi ba câu: Ai cần cái này? Vì sao họ cần? Điều gì xảy ra nếu không có nó? Ba câu này lọc ra được nhu cầu thật và loại bỏ yêu cầu "cho vui".
- Ghi lại, đừng tin trí nhớ. Sau mỗi cuộc trao đổi, viết ngay lại điều đã thống nhất và gửi cho các bên xác nhận. BA sống bằng "văn bản hóa", không phải bằng lời hứa miệng.
- Kết ngày bằng việc cập nhật trạng thái. Đánh dấu task nào xong, task nào còn vướng, ghi chú việc cần làm mai. Một ngày BA gọn gàng là ngày mà sáng hôm sau bạn mở máy lên là biết ngay phải làm gì.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ BA là "nghề nhàn, không cần suy nghĩ nhiều". Nhiều bạn chọn BA để né code rồi sốc vì phải tư duy phản biện liên tục cả ngày. Mẹo: nhìn nghề BA như "nghề đặt câu hỏi khó" — nếu bạn thích tìm hiểu vì sao mọi thứ vận hành thế này thế kia, bạn hợp.
Lỗi 2 — Trở thành "máy ghi âm cuộc họp". Fresher hay chỉ chép lại nguyên văn lời stakeholder mà không phân tích, không phát hiện mâu thuẫn. Mẹo: sau mỗi cuộc họp, tự hỏi "có điều gì stakeholder nói mâu thuẫn nhau không? có gì họ chưa nói mà mình cần hỏi thêm không?".
Lỗi 3 — Nhận yêu cầu là "gật đầu ngay". Khi PO hay khách nói "làm cái này đi", fresher hay đáp "vâng" mà chưa hiểu bối cảnh. Mẹo: tập phản xạ hỏi "để em hiểu rõ hơn, mục tiêu của việc này là gì ạ?" trước khi cam kết.
Lỗi 4 — Đánh đồng mọi vai BA giống nhau. Bạn đọc một JD IT BA rồi tưởng mọi BA đều thế. Mẹo: khi tìm việc, đọc kỹ phần "trách nhiệm" trong JD để biết đây là IT BA, Process BA hay Data BA — nó quyết định một ngày của bạn sẽ trông ra sao.
Mẹo vàng cho fresher: Trong buổi phỏng vấn, nếu bạn mô tả được một ngày làm việc của BA cụ thể như ba tình huống ở trên, nhà tuyển dụng lập tức thấy bạn "hiểu nghề" hơn hẳn ứng viên chỉ đọc thuộc định nghĩa.
Bài tập thực hành
- Viết lại định nghĩa BA bằng lời của bạn trong đúng 3 câu, không dùng cụm "cầu nối". Câu 1 nói BA đứng giữa những ai, câu 2 nói BA giải quyết vấn đề gì, câu 3 nói BA tạo ra sản phẩm cụ thể gì.
- Dựng "thời khóa biểu một ngày" giả định của một IT BA từ 8h30 đến 17h30, chia rõ đâu là khối deep work, đâu là họp, đâu là thời gian reactive trả lời dev/QA. Cố gắng phân bổ thực tế — đừng để cả ngày toàn "viết tài liệu".
- Phỏng vấn nhanh một người đang làm BA (qua LinkedIn hoặc người quen — Bài 8 và Bài 46 sẽ dạy cách tiếp cận). Hỏi đúng một câu: "Một ngày làm việc điển hình của anh/chị gồm những gì?" So sánh câu trả lời của họ với ba tình huống trong bài này và ghi lại điểm giống, khác.
- Tự đánh giá độ hợp nghề: liệt kê 3 việc lõi của BA (khai thác, phân tích, truyền đạt), tự chấm mỗi việc từ 1–5 xem bạn hiện đang mạnh/yếu ở đâu, và ghi một hành động cải thiện cho mục yếu nhất.
Tóm tắt
Business Analyst là người biến mong muốn mơ hồ của bên business thành yêu cầu rõ ràng cho bên technical, thông qua ba việc lõi: khai thác, phân tích và truyền đạt. Đừng dừng lại ở ẩn dụ "cầu nối" — hãy hiểu BA qua công việc thật hằng ngày.
Một ngày của BA đan xen hai nhịp: công việc sâu (viết tài liệu, vẽ sơ đồ) và công việc phản ứng (trả lời dev/QA, xử lý thay đổi phút chót). Chức danh "BA" có nhiều màu — IT BA, Process BA, Data BA — nên một ngày của Linh (fintech) và của Khoa (bán lẻ) trông rất khác nhau dù cùng tên nghề.
Điều phân biệt BA giỏi với BA làng nhàng không phải tốc độ gõ tài liệu, mà là khả năng đặt câu hỏi đúng, phát hiện lỗ hổng trước khi người khác vấp phải, và giữ bình tĩnh đánh giá tác động khi mọi thứ thay đổi. Nếu bạn thấy nhịp làm việc này hấp dẫn thay vì đáng sợ — chúc mừng, bạn đang đi đúng đường. Các bài tiếp theo sẽ trang bị cho bạn từng kỹ năng cụ thể để sống tốt trong một ngày như thế.