Expert, IT Business Analysis (Banking)

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.

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.

JOIN quyết định giữ lại những dòng nào khi ghép hai bảng theo điều kiện.

• INNER JOIN: chỉ giữ dòng khớp ở cả hai bảng.
• LEFT JOIN: giữ mọi dòng bảng trái; bảng phải không khớp thì cột thành NULL.
• RIGHT JOIN: ngược lại với LEFT, ít dùng vì có thể đổi chỗ bảng.
• FULL OUTER JOIN: giữ tất cả dòng của cả hai (MySQL không hỗ trợ trực tiếp, phải UNION hai LEFT JOIN).

Ví dụ tìm khách chưa từng đặt hàng:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

Hay sai: đặt điều kiện lọc bảng phải trong WHERE (vd. WHERE o.status = 'paid') làm LEFT JOIN biến thành INNER JOIN; điều kiện đó phải để trong ON.

Scrum là framework làm việc theo sprint ngắn (thường 1–4 tuần), mỗi sprint tạo ra phần sản phẩm dùng được.

• Vai trò: Product Owner (giá trị sản phẩm, ưu tiên backlog), Scrum Master (giúp team làm Scrum hiệu quả, gỡ vướng mắc), Developers (cả dev, tester, designer cùng tạo ra increment).
• Sự kiện: Sprint Planning, Daily Scrum, Sprint Review (demo cho stakeholder), Sprint Retrospective (cải tiến cách làm). Refinement là hoạt động thường xuyên.
• Artifact: Product Backlog, Sprint Backlog, Increment; kèm cam kết là Product Goal, Sprint Goal, Definition of Done.

Hay sai: coi Daily là buổi báo cáo cho PM, hoặc nói Scrum Master là "sếp" của team. Nếu dự án bạn làm "Scrum kiểu riêng", cứ nói thật và giải thích vì sao.

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.

Chọn sơ đồ theo câu hỏi cần trả lời và người đọc.

• BPMN / flowchart: mô tả quy trình nghiệp vụ có nhiều vai trò, nhánh rẽ; hợp để trao đổi với khách hàng (dùng swimlane theo phòng ban).
• Use case diagram: ai dùng hệ thống để làm gì, phạm vi tổng quan.
• Activity diagram: luồng xử lý của một chức năng.
• Sequence diagram: tương tác giữa người dùng, hệ thống, hệ thống bên ngoài theo thời gian; hữu ích khi tích hợp API, cổng thanh toán.
• State diagram: đối tượng có nhiều trạng thái (đơn hàng, khoản vay, hồ sơ duyệt).
• ERD: dữ liệu và quan hệ, khi làm việc với dev về database.

Công cụ hay dùng: draw.io, Lucidchart, Figma/FigJam, PlantUML.

Hay sai: vẽ thật nhiều cho đủ bộ nhưng không ai đọc. Nên kể một sơ đồ bạn đã dùng để chốt được một vấn đề cụ thể.

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.