Business Analyst – POEMS Digital Trading (Agile, Jira)

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ũ.

Đ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.

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.

Tận dụng giờ làm trùng nhau cho việc cần trao đổi trực tiếp, phần còn lại làm bất đồng bộ có tài liệu.

• Thống nhất lịch họp cố định trong khung giờ trùng (daily hoặc vài buổi mỗi tuần), có agenda và biên bản.
• Câu hỏi gom lại, viết rõ ràng kèm ngữ cảnh và phương án đề xuất, để khách trả lời được ngay trong một lần.
• Báo cáo định kỳ: đã làm, sẽ làm, rủi ro, quyết định cần khách đưa ra.
• Demo cuối sprint để khách thấy sản phẩm thật; ghi hình nếu khách không tham gia được.
• Lưu ý khác biệt văn hoá: một số khách cần nói thẳng, một số cần trang trọng; chủ động báo tin xấu sớm.

Hay sai: để team chờ câu trả lời của khách cả ngày mà không có việc dự phòng.

Quản lý rủi ro là xác định sớm, đánh giá, có kế hoạch ứng phó và theo dõi liên tục.

• Lập danh sách rủi ro (risk register) ngay từ đầu: nhân sự, công nghệ mới, phụ thuộc bên thứ ba, yêu cầu chưa rõ, hạ tầng.
• Đánh giá khả năng xảy ra và mức ảnh hưởng, ưu tiên rủi ro cao.
• Chọn cách ứng phó: tránh, giảm thiểu, chuyển giao, chấp nhận; mỗi rủi ro có người chịu trách nhiệm theo dõi.
• Xem lại trong các buổi họp định kỳ, cập nhật khi tình hình thay đổi.

Ví dụ theo STAR: "API của đối tác chưa sẵn sàng (S), em cần giữ tiến độ tích hợp (T). Em đề xuất team làm mock theo tài liệu API, đồng thời hẹn mốc kiểm tra với đối tác hàng tuần (A). Khi API thật có, phần tích hợp chỉ mất vài ngày điều chỉnh (R)."

Zero Trust bỏ giả định "ở trong mạng nội bộ là tin cậy": mọi truy cập đều được xác thực, kiểm tra thiết bị và cấp quyền tối thiểu theo từng ứng dụng.

Lộ trình thực tế:

• Tập trung danh tính (SSO), bắt buộc MFA, ưu tiên loại chống phishing (passkey, FIDO2).
• Kiểm kê tài sản và ứng dụng, phân loại dữ liệu.
• Kiểm tra trạng thái thiết bị (đã mã hoá, đã vá, có EDR) trước khi cho truy cập.
• Thay VPN toàn mạng bằng truy cập theo từng ứng dụng qua access proxy.
• Phân đoạn mạng để hạn chế di chuyển ngang.
• Ghi log mọi truy cập và giám sát liên tục.

Người phỏng vấn muốn nghe: Zero Trust là chiến lược làm dần, không phải mua một sản phẩm.

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.

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ý.

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.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.