APO Leader (Japanese IT Comtor, Bridge Engineer, BrSE)

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

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.

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.

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

Điểm khác chính là quy định, bảo mật và độ chính xác của dữ liệu tiền.

• Tuân thủ quy định của cơ quan quản lý và chính sách nội bộ: cần làm việc với bộ phận pháp chế, compliance, rủi ro ngay từ đầu.
• Phân quyền và kiểm soát: nguyên tắc maker-checker, hạn mức, phê duyệt nhiều cấp, audit log đầy đủ.
• Xác thực: OTP, sinh trắc học, quy trình eKYC.
• Nghiệp vụ tính toán: lãi, phí, làm tròn, ngày làm việc, cut-off time; cần ví dụ số cụ thể trong AC.
• Tích hợp nhiều hệ thống: core banking, cổng thanh toán, hệ thống cũ, đối soát.
• UAT nghiêm ngặt, nhiều tầng phê duyệt, tài liệu kỹ hơn.

Người phỏng vấn muốn nghe: bạn biết domain knowledge quan trọng ngang kỹ năng BA. Nếu chưa làm fintech, nói rõ bạn đã tìm hiểu nghiệp vụ nào và cách bạn học domain mới.

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.

PO ưu tiên theo giá trị mang lại so với chi phí và rủi ro, gắn với mục tiêu sản phẩm.

• Mục tiêu sản phẩm/công ty trong giai đoạn này: tăng người dùng mới, giữ chân, doanh thu, hay giảm chi phí vận hành.
• Dữ liệu: số liệu sử dụng, phản hồi người dùng, ticket hỗ trợ, kết quả phỏng vấn người dùng.
• Effort và rủi ro do team ước lượng; phụ thuộc kỹ thuật; nợ kỹ thuật cần trả.
• Ràng buộc bắt buộc: quy định pháp lý, cam kết hợp đồng, hạn chót của đối tác.
• Framework hỗ trợ: RICE, MoSCoW, Kano, value/effort.

Người phỏng vấn muốn nghe: ví dụ một lần bạn từ chối hoặc hoãn một yêu cầu từ sếp/khách lớn nhờ dữ liệu, và cách bạn giải thích để họ đồng ý.

Chọn điểm yếu thật, không chí mạng với vị trí, và cho thấy bạn đang cải thiện.

Cấu trúc: điểm yếu, ảnh hưởng đã gặp, việc bạn đang làm để khắc phục, tiến bộ đến nay.

Câu mẫu: "Trước đây em hay ngại hỏi khi bị kẹt, tự loay hoay quá lâu, có lần làm trễ task. Giờ em tự đặt giới hạn: kẹt quá một hai giờ mà không có hướng thì em hỏi đồng đội, kèm những gì đã thử. Từ khi làm vậy em xong việc đúng hạn hơn và học được nhanh hơn từ người khác."

Ví dụ khác có thể dùng: chưa quen nói trước đám đông, tiếng Anh nói chưa trôi chảy, hay ôm việc.

Hay sai: "Điểm yếu của em là quá cầu toàn" (nghe như né câu hỏi), hoặc nêu điểm yếu là kỹ năng cốt lõi của vị trí.