Business Analyst (ERP - Logistics, WMS)

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.

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.

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.

Scrum làm theo nhịp sprint cố định với cam kết đầu sprint; Kanban là luồng liên tục, giới hạn số việc đang làm (WIP limit) và tối ưu thời gian hoàn thành.

• Scrum hợp với phát triển sản phẩm có lộ trình, cần nhịp demo và lập kế hoạch đều đặn.
• Kanban hợp với việc đến liên tục và khó dự đoán: vận hành, hỗ trợ, bảo trì, xử lý ticket khách hàng.
• Chỉ số: Scrum thường nhìn velocity, burndown; Kanban nhìn lead time, cycle time, throughput.
• Nhiều team kết hợp: sprint cho tính năng, một làn Kanban cho bug gấp.

Người phỏng vấn muốn nghe: bạn chọn theo bản chất công việc, không theo sở thích. Ví dụ: "Team maintain hệ thống cho khách, yêu cầu đến mỗi ngày, em chuyển sang Kanban với WIP limit và cam kết thời gian phản hồi theo mức ưu tiên."

Region là một vùng địa lý; mỗi region có nhiều Availability Zone, là các trung tâm dữ liệu tách biệt về điện, mạng, làm mát nhưng nối với nhau độ trễ thấp.

Để chịu được mất một AZ:

• Chạy ứng dụng ở ít nhất 2 AZ, đứng sau load balancer.
• Dùng Auto Scaling group/managed instance group trải trên nhiều AZ.
• Database bật chế độ Multi-AZ (bản standby ở AZ khác, failover tự động).
• Ứng dụng stateless, session để ở Redis hoặc DB.

Hay sai: đặt NAT Gateway hoặc một thành phần duy nhất ở một AZ, tạo điểm lỗi đơn mà không để ý.

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

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

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."