Business Analyst (3+ YOE)

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.

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.

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

Nói chuyện riêng, sớm và dựa trên sự việc trước khi kết luận.

• Chuẩn bị ví dụ cụ thể (task nào, trễ bao lâu, ảnh hưởng gì), tránh nhận xét chung chung kiểu "em làm chậm".
• Hỏi để hiểu nguyên nhân: việc quá sức, thiếu kiến thức, yêu cầu không rõ, vấn đề cá nhân, hay mất động lực.
• Cùng thống nhất kế hoạch: chia task nhỏ hơn, ghép cặp với người kinh nghiệm, check-in thường xuyên hơn, hỗ trợ đào tạo.
• Theo dõi và phản hồi định kỳ. Nếu không cải thiện, phối hợp với line manager/HR theo quy trình của công ty.

Hay sai: góp ý trước cả team, hoặc lẳng lặng giao việc cho người khác làm thay. Cách đó làm người giỏi kiệt sức và vấn đề không được giải quyết.

PO ưu tiên theo giá trị mang lại so với chi phí và rủi ro, gắn với mục tiêu sản phẩm.

• Mục tiêu sản phẩm/công ty trong giai đoạn này: tăng người dùng mới, giữ chân, doanh thu, hay giảm chi phí vận hành.
• Dữ liệu: số liệu sử dụng, phản hồi người dùng, ticket hỗ trợ, kết quả phỏng vấn người dùng.
• Effort và rủi ro do team ước lượng; phụ thuộc kỹ thuật; nợ kỹ thuật cần trả.
• Ràng buộc bắt buộc: quy định pháp lý, cam kết hợp đồng, hạn chót của đối tác.
• Framework hỗ trợ: RICE, MoSCoW, Kano, value/effort.

Người phỏng vấn muốn nghe: ví dụ một lần bạn từ chối hoặc hoãn một yêu cầu từ sếp/khách lớn nhờ dữ liệu, và cách bạn giải thích để họ đồng ý.

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

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.

Dùng STAR: Situation (bối cảnh), Task (nhiệm vụ), Action (bạn làm gì), Result (kết quả). Phần Action nên chiếm nhiều nhất.

Câu mẫu:

• S: "Lead muốn dùng một thư viện mới cho module báo cáo, em thấy thư viện đó còn ít người dùng và lo về bảo trì."
• T: "Em cần nêu rủi ro mà không làm chậm tiến độ."
• A: "Em gặp riêng anh, đưa so sánh hai phương án và đề xuất làm thử một bản nhỏ trong hai ngày để đánh giá."
• R: "Kết quả thử cho thấy thư viện cũ đáp ứng đủ, anh đồng ý giữ lại. Từ đó team có thói quen làm bản thử trước khi đổi công nghệ."

Người phỏng vấn muốn nghe: bạn tranh luận bằng dữ liệu, tôn trọng người khác, và chấp nhận quyết định cuối cùng kể cả khi không theo ý mình.