01Theo bạn, Business Analyst trong dự án phần mềm làm những việc gì?Junior
Gợi ý trả lời
BA là cầu nối giữa business và đội phát triển: hiểu vấn đề của khách hàng, chuyển thành yêu cầu rõ ràng để team làm đúng thứ cần làm.
- Thu thập và làm rõ yêu cầu (phỏng vấn, workshop, đọc tài liệu, quan sát quy trình hiện tại).
- Phân tích, mô hình hoá: quy trình nghiệp vụ, use case, user story, acceptance criteria.
- Viết tài liệu (BRD, SRS hoặc backlog trên Jira/Confluence), phối hợp làm wireframe.
- Giải đáp cho dev và tester, review kết quả, hỗ trợ UAT.
- Quản lý thay đổi yêu cầu.
Người phỏng vấn muốn nghe: bạn hiểu BA không phải "người ghi chép" mà là người đặt câu hỏi "tại sao" để tìm ra nhu cầu thật. Nếu bạn chuyển từ tester, dev hay ngành khác sang, nói rõ kinh nghiệm cũ giúp gì cho vai trò BA.
02Yêu cầu chức năng (functional) và phi chức năng (non-functional) khác nhau thế nào? Cho ví dụ.Junior
Gợi ý trả lời
Functional mô tả hệ thống làm gì; non-functional mô tả hệ thống làm tốt đến mức nào hoặc chịu ràng buộc gì.
- Functional: "Khách hàng có thể chuyển khoản tới tài khoản cùng ngân hàng", "Quản lý duyệt hoặc từ chối đơn nghỉ phép".
- Non-functional: thời gian phản hồi, số người dùng đồng thời, bảo mật (xác thực OTP, mã hoá dữ liệu), khả dụng, hỗ trợ trình duyệt/thiết bị, tuân thủ quy định pháp lý, khả năng audit log.
Non-functional nên viết đo được: thay vì "hệ thống phải nhanh", viết "trang danh sách đơn hàng tải xong dưới X giây với Y người dùng đồng thời", với con số thống nhất cùng khách hàng và team kỹ thuật.
Hay sai: bỏ quên non-functional, đến lúc UAT hoặc go-live mới phát hiện hệ thống chậm hay thiếu phân quyền.
03Bạn viết một user story và acceptance criteria như thế nào? Ví dụ cho chức năng quên mật khẩu.Junior
Gợi ý trả lời
Dùng mẫu "Là [ai], tôi muốn [làm gì], để [đạt được gì]", kèm acceptance criteria dạng Given/When/Then để dev và tester hiểu giống nhau.
Ví dụ:
- Là người dùng đã đăng ký, tôi muốn đặt lại mật khẩu qua email, để đăng nhập lại khi quên mật khẩu.
- AC1: Given email đã đăng ký, When tôi gửi yêu cầu, Then hệ thống gửi link đặt lại có hiệu lực trong khoảng thời gian quy định.
- AC2: Given email chưa đăng ký, When tôi gửi yêu cầu, Then hệ thống hiện cùng một thông báo chung (không lộ việc email có tồn tại hay không).
- AC3: Link đã dùng hoặc hết hạn thì không dùng lại được.
- AC4: Mật khẩu mới phải theo quy tắc độ mạnh đã thống nhất.
Người phỏng vấn muốn nghe: story đủ nhỏ, có giá trị cho người dùng, và AC bao cả trường hợp lỗi, không chỉ happy path.
04Bạn đã dùng những sơ đồ nào (UML, BPMN, flowchart…)? Khi nào dùng loại nào?Junior
Gợi ý trả lời
Chọn sơ đồ theo câu hỏi cần trả lời và người đọc.
- BPMN / flowchart: mô tả quy trình nghiệp vụ có nhiều vai trò, nhánh rẽ; hợp để trao đổi với khách hàng (dùng swimlane theo phòng ban).
- Use case diagram: ai dùng hệ thống để làm gì, phạm vi tổng quan.
- Activity diagram: luồng xử lý của một chức năng.
- Sequence diagram: tương tác giữa người dùng, hệ thống, hệ thống bên ngoài theo thời gian; hữu ích khi tích hợp API, cổng thanh toán.
- State diagram: đối tượng có nhiều trạng thái (đơn hàng, khoản vay, hồ sơ duyệt).
- ERD: dữ liệu và quan hệ, khi làm việc với dev về database.
Công cụ hay dùng: draw.io, Lucidchart, Figma/FigJam, PlantUML.
Hay sai: vẽ thật nhiều cho đủ bộ nhưng không ai đọc. Nên kể một sơ đồ bạn đã dùng để chốt được một vấn đề cụ thể.
05Khách hàng đưa yêu cầu rất chung chung, ví dụ 'làm cho tôi một app quản lý kho'. Bạn bắt đầu như thế nào?
Gợi ý trả lời
Đi từ mục tiêu kinh doanh xuống chi tiết, đừng nhảy vào màn hình ngay.
- Hỏi bối cảnh: vấn đề hiện tại là gì (sai lệch tồn kho, chậm xuất hàng, báo cáo thủ công?), mục tiêu đo bằng gì, ai sẽ dùng, đang dùng công cụ gì.
- Xác định stakeholder và người dùng: thủ kho, kế toán, quản lý, chi nhánh.
- Vẽ quy trình hiện tại (as-is), tìm điểm đau, đề xuất quy trình mới (to-be).
- Liệt kê nhóm chức năng, ưu tiên bằng MoSCoW hoặc chia MVP và các giai đoạn sau.
- Làm rõ ràng buộc: ngân sách, thời hạn, tích hợp với phần mềm kế toán/ERP có sẵn.
- Xác nhận lại bằng tài liệu hoặc wireframe trước khi team estimate.
Người phỏng vấn muốn nghe: bạn đặt câu hỏi "tại sao" và giúp khách hàng thu hẹp phạm vi, thay vì ghi lại mọi mong muốn.
06Giữa sprint, khách hàng muốn thay đổi yêu cầu (change request). Bạn xử lý thế nào?
Gợi ý trả lời
Tiếp nhận nhưng không nhận ngay vào làm; đánh giá tác động rồi để người có thẩm quyền quyết định.
- Ghi lại thay đổi và lý do: nhu cầu mới hay requirement cũ hiểu sai?
- Phân tích ảnh hưởng cùng dev/tester: phần nào phải sửa, effort, rủi ro, có ảnh hưởng tới phần đã xong không.
- Trao đổi với PM/PO và khách hàng về lựa chọn: đưa vào sprint sau, đổi lấy một hạng mục khác cùng độ lớn, hoặc tính thêm chi phí/thời gian (dự án fixed-price thường cần CR chính thức).
- Khi đã thống nhất: cập nhật tài liệu, backlog, thông báo cho cả team, lưu lịch sử thay đổi.
Hay sai: gật đầu với khách rồi nhờ dev "làm thêm chút". Việc đó gây scope creep, trễ tiến độ và mất lòng team.
07Hai stakeholder đưa ra yêu cầu mâu thuẫn nhau. Bạn làm gì?
Gợi ý trả lời
Mục tiêu là làm lộ ra mâu thuẫn và đưa về mục tiêu chung, không phải tự chọn phe.
- Gặp riêng từng bên để hiểu nhu cầu thật phía sau yêu cầu (thường hai bên muốn kết quả khác nhau vì KPI khác nhau).
- Trình bày mâu thuẫn bằng dữ liệu: ảnh hưởng tới quy trình, chi phí, người dùng của mỗi phương án.
- Tìm phương án dung hoà: cấu hình theo vai trò, chia giai đoạn, hoặc một giải pháp thứ ba.
- Vẫn chưa thống nhất thì đưa lên người có quyền quyết (sponsor, PO) và ghi lại.
Ví dụ ngắn: "Phòng kinh doanh muốn duyệt đơn nhanh, phòng tài chính muốn kiểm tra hạn mức kỹ. Em đề xuất tự duyệt đơn dưới một hạn mức, đơn lớn hơn mới qua tài chính; hai bên đồng ý."
Người phỏng vấn muốn nghe: bạn trung lập, có cấu trúc và biết khi nào cần escalate.
08Bạn làm gì để dev và tester hiểu đúng yêu cầu, tránh làm xong mới phát hiện sai?
Gợi ý trả lời
Làm rõ sớm và thường xuyên, không chỉ ném tài liệu sang rồi thôi.
- Tham gia refinement/grooming: giải thích bối cảnh, trả lời câu hỏi, cùng tách story.
- Acceptance criteria rõ ràng, có ví dụ dữ liệu cụ thể và trường hợp lỗi.
- Có wireframe/mockup, sơ đồ luồng cho phần phức tạp.
- Mời tester review AC trước khi dev bắt đầu; dev có thể "kể lại" cách hiểu để kiểm tra.
- Có mặt khi dev làm: trả lời nhanh, demo sớm phần đã xong để phát hiện lệch hướng.
- Giữ tài liệu là nguồn chính xác duy nhất, cập nhật khi có thay đổi.
Hay sai: chốt trong chat riêng với một dev mà không cập nhật ticket, khiến tester test theo bản cũ.
09Làm BA cho dự án ngân hàng/fintech, bạn cần lưu ý gì khác so với dự án thông thường?Senior
Gợi ý trả lời
Điểm khác chính là quy định, bảo mật và độ chính xác của dữ liệu tiền.
- Tuân thủ quy định của cơ quan quản lý và chính sách nội bộ: cần làm việc với bộ phận pháp chế, compliance, rủi ro ngay từ đầu.
- Phân quyền và kiểm soát: nguyên tắc maker-checker, hạn mức, phê duyệt nhiều cấp, audit log đầy đủ.
- Xác thực: OTP, sinh trắc học, quy trình eKYC.
- Nghiệp vụ tính toán: lãi, phí, làm tròn, ngày làm việc, cut-off time; cần ví dụ số cụ thể trong AC.
- Tích hợp nhiều hệ thống: core banking, cổng thanh toán, hệ thống cũ, đối soát.
- UAT nghiêm ngặt, nhiều tầng phê duyệt, tài liệu kỹ hơn.
Người phỏng vấn muốn nghe: bạn biết domain knowledge quan trọng ngang kỹ năng BA. Nếu chưa làm fintech, nói rõ bạn đã tìm hiểu nghiệp vụ nào và cách bạn học domain mới.
10Khách hàng UAT xong nói 'không giống những gì tôi muốn', dù đã ký duyệt tài liệu. Bạn xử lý ra sao?Senior
Gợi ý trả lời
Trước hết phân loại: đây là lỗi (làm sai so với tài liệu), hiểu sai giữa hai bên, hay nhu cầu mới phát sinh khi khách thấy sản phẩm thật.
- Lắng nghe cụ thể từng điểm khách không hài lòng, ghi lại, đừng phản ứng phòng thủ.
- Đối chiếu với tài liệu đã duyệt: lỗi thì team sửa; nhu cầu mới thì đi theo quy trình change request.
- Với điểm mơ hồ trong tài liệu, nhận phần trách nhiệm và cùng PM thương lượng hướng xử lý hợp lý.
- Ưu tiên cùng khách: điểm nào chặn go-live, điểm nào để giai đoạn sau.
Rút kinh nghiệm cho lần sau: demo sớm theo từng sprint, dùng prototype có thể bấm thử, để khách thấy sản phẩm trước UAT.
Hay sai: chỉ vào chữ ký trên tài liệu để từ chối mọi thứ. Đúng quy trình nhưng mất quan hệ khách hàng.
11Bạn ưu tiên backlog như thế nào khi mọi stakeholder đều nói yêu cầu của họ là gấp nhất?Senior
Gợi ý trả lời
Dùng tiêu chí minh bạch để quyết định, thay vì ai nói to hơn thì được làm trước.
- Gắn mỗi yêu cầu với mục tiêu kinh doanh: tăng doanh thu, giảm chi phí, tuân thủ quy định, giảm rủi ro.
- Ước lượng giá trị và effort cùng team, dùng ma trận value/effort, MoSCoW, hoặc chấm điểm kiểu RICE/WSJF.
- Yêu cầu bắt buộc theo luật hoặc hạn chót cố định thường được ưu tiên.
- Xét phụ thuộc kỹ thuật: một số việc phải làm trước để mở đường.
- Chia sẻ kết quả ưu tiên và lý do cho stakeholder; người quyết định cuối cùng thường là PO.
Người phỏng vấn muốn nghe: bạn có framework, biết nói "chưa" một cách có lý do và giữ được quan hệ với các bên.
12Làm sao bạn đo được giá trị công việc của BA sau khi sản phẩm go-live?Senior
Gợi ý trả lời
Giá trị của BA thể hiện qua việc sản phẩm giải quyết đúng vấn đề và dự án ít lãng phí.
- Đặt chỉ số thành công từ đầu cùng stakeholder (thời gian xử lý một hồ sơ, tỷ lệ hoàn tất đăng ký, số thao tác thủ công giảm).
- Sau go-live: theo dõi số liệu, phản hồi người dùng, số ticket hỗ trợ, tỷ lệ dùng tính năng.
- Chất lượng requirement: số bug do hiểu sai yêu cầu, số change request phát sinh vì thiếu sót, số lần làm lại.
- Rút kinh nghiệm (retrospective) để điều chỉnh cách làm.
Ví dụ trả lời: "Trước khi làm, em cùng khách thống nhất chỉ số thời gian duyệt hồ sơ. Sau go-live em theo dõi số liệu đó và các ticket hỗ trợ để đề xuất cải tiến giai đoạn 2."
Hay sai: coi việc xong khi tài liệu được ký.
Gặp câu hỏi khác khi phỏng vấn? Kể lại ẩn danh để người sau ôn đúng trọng tâm, hoặc xem câu hỏi thật hay gặp ở nhiều công ty.