Business Analyst Officer

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

Estimate là việc của cả team, không phải PM tự đặt rồi giao xuống.

• Story point: đo độ lớn tương đối (khối lượng, độ phức tạp, rủi ro), so với một story mẫu. Hay dùng planning poker với dãy gần Fibonacci để cả team thảo luận chỗ hiểu khác nhau.
• Giờ/ngày công: cần khi báo giá dự án outsourcing, hợp đồng fixed-price hoặc lập kế hoạch nguồn lực.
• Với dự án lớn: chia nhỏ (WBS), estimate theo khoảng (lạc quan, khả dĩ, bi quan), cộng buffer cho rủi ro, tích hợp, test, sửa bug.
• Dùng dữ liệu cũ (velocity, dự án tương tự) để kiểm tra lại.

Hay sai: đổi story point ra giờ một cách cứng nhắc, hoặc dùng velocity để so sánh hiệu suất giữa các team.

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.

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

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

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

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.

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

Tìm hiểu trước mặt bằng lương cho vị trí và số năm kinh nghiệm (dữ liệu lương trên Drama Công Ty, bạn bè cùng ngành), rồi đưa ra một khoảng có căn cứ.

• Nói rõ gross hay net. Gross là lương trước khi trừ bảo hiểm bắt buộc và thuế thu nhập cá nhân; net là số thực nhận.
• Hỏi tổng thu nhập: lương tháng 13 (không bắt buộc theo luật), thưởng, chu kỳ review lương, bảo hiểm sức khoẻ.
• Lương thử việc theo luật tối thiểu bằng 85% lương chính thức; nhiều công ty trả 100%, cứ hỏi rõ.

Câu mẫu: "Dựa trên kinh nghiệm và mặt bằng thị trường, em mong muốn khoảng X đến Y triệu gross. Em cũng muốn hiểu thêm về thưởng và review lương bên mình."

Hay sai: nói "tuỳ công ty" (dễ bị trả thấp), hoặc khai khống lương hiện tại.