Lead Business Analyst

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

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.

Cô lập lỗi để sự cố của một phụ thuộc không lan ra toàn hệ thống (cascading failure).

• Timeout cho mọi lời gọi mạng. Thiếu timeout là nguyên nhân hàng đầu làm cạn thread hoặc connection.
• Retry có giới hạn, exponential backoff kèm jitter, và chỉ retry thao tác idempotent.
• Circuit breaker: lỗi vượt ngưỡng thì "ngắt mạch", trả lỗi nhanh trong một thời gian, sau đó thử lại dần (half-open).
• Bulkhead: tách pool thread hoặc connection theo từng phụ thuộc.
• Fallback / graceful degradation: trả dữ liệu cache, ẩn tính năng phụ thay vì lỗi cả trang.
• Load shedding: từ chối bớt request khi quá tải để bảo vệ phần còn lại.

Hay sai: retry ở nhiều tầng cùng lúc, số request nhân lên theo cấp số và làm phụ thuộc đang yếu chết hẳn (retry storm).

Tránh two-phase commit giữa các service; thay vào đó dùng Saga kết hợp Outbox pattern.

• Saga: chuỗi transaction cục bộ, mỗi bước có hành động bù trừ nếu bước sau thất bại (vd. đặt hàng → giữ tồn kho → thanh toán; thanh toán lỗi thì hoàn tồn kho, huỷ đơn). Có hai kiểu: choreography (các service phản ứng theo event) và orchestration (một service điều phối, dễ theo dõi hơn khi luồng dài).
• Transactional outbox: ghi thay đổi nghiệp vụ và event vào bảng outbox trong cùng một transaction DB, sau đó tiến trình riêng hoặc CDC đẩy event lên broker. Cách này tránh tình huống DB đã lưu mà event bị mất.
• Consumer phải idempotent (lưu id message đã xử lý) vì event có thể đến nhiều lần.

Người phỏng vấn muốn nghe: bạn chấp nhận eventual consistency và thiết kế trạng thái trung gian rõ ràng cho người dùng, vd. đơn ở trạng thái "đang xử lý".

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.

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.

Luôn có câu hỏi. Đây là cơ hội thể hiện sự quan tâm và cũng là lúc bạn đánh giá công ty.

Câu hỏi nên chuẩn bị (chọn 2–3 câu hợp với người đang phỏng vấn):

• "Một ngày làm việc của vị trí này thường như thế nào? Team có bao nhiêu người, gồm những vai trò gì?"
• "Ba tháng đầu, anh/chị kỳ vọng người vào vị trí này làm được gì?"
• "Team đang gặp thách thức kỹ thuật hoặc quy trình nào lớn nhất?"
• "Quy trình release và code review của team ra sao?"
• "Công ty đánh giá hiệu suất và review lương theo chu kỳ nào?"
• "Vì sao vị trí này đang tuyển: mở rộng team hay thay người?"

Hay sai: "Dạ không ạ", hoặc chỉ hỏi về nghỉ phép, lương thưởng ngay ở vòng kỹ thuật. Chuyện chế độ nên hỏi kỹ với HR.