Business Analyst Intern (Company Secretariat)

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

b = a không sao chép gì: hai tên cùng trỏ đến một object. Sửa qua b thì a cũng đổi.

• Shallow copy (a.copy(), list(a), a[:], copy.copy(a)): tạo container mới nhưng các phần tử bên trong vẫn là object cũ.
• Deep copy (copy.deepcopy(a)): sao chép đệ quy toàn bộ cấu trúc.

a = [[1, 2], [3]]
b = a.copy()
b[0].append(99)   # a cũng thành [[1, 2, 99], [3]]

Hay sai: tạo ma trận bằng [[0] * 3] * 3. Ba hàng là cùng một list, sửa một ô thì cả cột đổi theo. Viết đúng: [[0] * 3 for _ in range(3)].

Generator sinh giá trị lười (lazy): mỗi lần được hỏi mới tính phần tử tiếp theo, rồi tạm dừng tại yield. Nhờ vậy nó không phải giữ toàn bộ dữ liệu trong bộ nhớ.

def read_lines(path):
    with open(path) as f:
        for line in f:
            yield line.rstrip()

total = sum(len(l) for l in read_lines("big.log"))

• List comprehension [x * 2 for x in data] tạo cả list ngay. Generator expression (x * 2 for x in data) thì không.
• Hợp với file lớn, dữ liệu stream, phân trang API, pipeline xử lý nhiều bước.

Hay sai: duyệt một generator hai lần. Lần thứ hai không có gì vì nó đã cạn; cần duyệt lại thì tạo generator mới hoặc chuyển thành list.

Attention cho mỗi token "nhìn" tất cả token khác và tính trọng số mức liên quan, nhờ đó nắm được phụ thuộc xa trong câu. Mỗi token tạo ra query, key, value; trọng số là softmax của tích query với key (chia cho căn bậc hai số chiều), rồi lấy tổng có trọng số của value.

Transformer thắng RNN vì:

• Xử lý song song cả chuỗi khi train, tận dụng GPU tốt; RNN phải đi tuần tự.
• Ít gặp vấn đề mất thông tin ở chuỗi dài.
• Mở rộng quy mô tốt, là nền của các LLM hiện nay.

Đánh đổi: chi phí attention tăng theo bình phương độ dài chuỗi, nên ngữ cảnh dài tốn bộ nhớ và tính toán.

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

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.