Mid/Sr Business Analyst (English) - 2V074

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

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.

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)."

Đầu tiên là minh bạch: báo sớm, kèm nguyên nhân và phương án, không chỉ báo tin xấu.

• Đánh giá lại thực trạng: còn bao nhiêu việc, velocity thực tế, đường găng (critical path).
• Đưa các phương án với đánh đổi rõ ràng: cắt bớt phạm vi cho đợt đầu, dời mốc, bổ sung nguồn lực (lưu ý người mới cần thời gian làm quen), song song hoá một số việc.
• Đề xuất một phương án bạn khuyến nghị và lý do.
• Sau khi chốt: kế hoạch mới, mốc kiểm tra gần hơn, báo cáo thường xuyên hơn để lấy lại niềm tin.
• Tìm nguyên nhân gốc để không lặp lại.

Người phỏng vấn muốn nghe: bạn không giấu, không đổ lỗi cho team hay khách, và biết rằng thêm người vào dự án đang trễ thường không giúp kịp ngay.

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

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

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

"Yes, for the last two years I've worked with a client in Europe, so we only had about three overlapping hours a day. To make the most of that time, we kept a short daily call and I prepared questions in advance. For everything else, I wrote clear updates in Jira and Slack so they could reply when they started their day. This helped us avoid waiting a whole day for answers."

Mẹo: nhấn vào cách bạn giao tiếp chủ động và viết rõ ràng. Dùng "overlapping hours", "asynchronous communication", "I kept them updated". Tránh nói "I have worked with them since 2 years", đúng là "for two years".

Chọn sai lầm thật, có hậu quả vừa phải, nhận trách nhiệm rõ ràng, và nhấn mạnh việc bạn đã thay đổi sau đó.

Cấu trúc: chuyện gì xảy ra, phần lỗi của bạn, bạn khắc phục ngay thế nào, bài học và thay đổi lâu dài.

Câu mẫu: "Có lần em deploy một thay đổi cấu hình lên production vào chiều thứ Sáu mà không kiểm tra kỹ trên staging, làm một tính năng lỗi khoảng một giờ. Em báo ngay cho lead, rollback và viết báo cáo sự cố. Sau đó em đề xuất checklist trước deploy và quy ước hạn chế deploy cuối tuần; team áp dụng tới giờ."

Hay sai: kể một "thất bại" thực ra là khoe, đổ lỗi cho người khác, hoặc nói mình chưa từng thất bại.