Business Analyst (Banking/ Finance)

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.

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

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.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

• Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
• Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
• Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
• Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
• Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
• Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

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.

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.

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.

Người phỏng vấn muốn biết mục tiêu của bạn có khớp với hướng phát triển ở công ty và bạn có định gắn bó không.

• Nêu hướng phát triển cụ thể, thực tế: đi sâu chuyên môn (senior, chuyên gia một mảng) hay quản lý (lead, PM).
• Kèm kế hoạch: kỹ năng cần học, trách nhiệm muốn nhận thêm.
• Gắn với cơ hội ở vị trí đang ứng tuyển.

Câu mẫu: "Trong 2–3 năm tới em muốn trở thành senior có thể tự thiết kế và chịu trách nhiệm một module lớn, đồng thời hướng dẫn được các bạn mới. Em đang học thêm về thiết kế hệ thống và thấy team bên mình có nhiều bài toán ở quy mô lớn, rất hợp để em phát triển theo hướng đó."

Hay sai: "Em muốn mở công ty riêng" hoặc "em chưa nghĩ tới". Cũng đừng nói muốn ngồi vào chỗ của người đang phỏng vấn.