Business Analyst - 3YOE

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.

Công cụ chỉ hữu ích khi team cập nhật thật và bạn nhìn đúng chỉ số.

• Cấu trúc: Epic cho tính năng lớn, Story/Task cho việc trong sprint, Bug riêng; có quy ước đặt tên và trạng thái thống nhất.
• Board phản ánh đúng workflow của team (To Do, In Progress, Code Review, Testing, Done).
• Theo dõi: burndown/burnup của sprint, việc bị kẹt lâu ở một cột, số bug mở theo mức độ.
• Dashboard hoặc báo cáo định kỳ cho khách hàng/sếp: tiến độ theo milestone, rủi ro, quyết định cần họ đưa ra.
• Kết hợp Confluence hoặc wiki cho tài liệu, biên bản họp.

Người phỏng vấn muốn nghe: bạn dùng dữ liệu để phát hiện vấn đề sớm (ví dụ ticket nằm ở cột Testing quá lâu là dấu hiệu thiếu tester), không chỉ để báo cáo.

Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.

• Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
• Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
• Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
• Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
• Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.

Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.

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

Mỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.

• Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
• Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
• Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
• Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
• Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.

Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.