Tuần 1 • Buổi 1 — Business Analyst là ai? Vai trò, giá trị & vòng đời dự án

Business Analyst là ai?

Business Analyst (BA) là người đứng ở giữa business (phía kinh doanh) và technology (phía kỹ thuật). Công việc cốt lõi của BA là hiểu vấn đề của business, rồi chuyển hóa nó thành yêu cầu rõ ràng để đội ngũ kỹ thuật có thể xây dựng đúng sản phẩm.

Nói nôm na: nếu dev là người xây nhà, BA là người vẽ bản thiết kế và đảm bảo chủ nhà thực sự muốn cái mà mình đang xây.

---

BA làm những gì hàng ngày?

• Elicitation (thu thập yêu cầu): phỏng vấn stakeholder, tổ chức workshop, quan sát quy trình thực tế
• Phân tích & tài liệu hóa: viết BRD (Business Requirements Document), user story, use case
• Làm cầu nối: giải thích yêu cầu business cho dev, giải thích giới hạn kỹ thuật cho business
• Kiểm tra & xác nhận: đảm bảo sản phẩm được build đúng với những gì stakeholder cần
• Quản lý thay đổi: khi yêu cầu thay đổi giữa chừng, BA cần đánh giá tác động và cập nhật tài liệu

---

Giá trị BA mang lại cho dự án

Thử nghĩ đến một dự án xây hệ thống đặt lịch khám bệnh online cho một phòng khám tư. Nếu không có BA:

• Dev build form đặt lịch chỉ lấy tên + giờ, nhưng bác sĩ cần biết triệu chứng trước để chuẩn bị
• Quản lý phòng khám muốn báo cáo theo bác sĩ, nhưng hệ thống không lưu bác sĩ phụ trách
• Sau 3 tháng launch, phòng khám phải build lại từ đầu

Có BA, những khoảng trống đó được phát hiện từ tuần đầu tiên — tiết kiệm hàng chục giờ dev và tránh rủi ro launch sản phẩm sai.

BA tạo ra giá trị bằng cách giảm chi phí sai lệch yêu cầu, một trong những nguyên nhân tốn kém nhất trong phát triển phần mềm.

---

Các bên liên quan BA làm việc cùng

---

Vòng đời phát triển phần mềm (SDLC)

BA hoạt động trong bối cảnh Software Development Life Cycle (SDLC). Hai mô hình phổ biến nhất:

Waterfall (Thác nước)

Các giai đoạn tuần tự, mỗi giai đoạn hoàn thành trước khi bắt đầu giai đoạn kế. BA thường làm việc tập trung ở đầu dự án.

Agile

Phát triển theo từng sprint ngắn (thường 2 tuần), yêu cầu có thể thay đổi linh hoạt. BA tham gia liên tục — viết user story, tham dự sprint planning, review kết quả mỗi sprint.

flowchart TD
    A[Business Need] --> B[BA: Elicitation]
    B --> C[BA: Requirements Doc]
    C --> D{Waterfall or Agile?}
    D --> |Waterfall| E[Design - Build - Test - Deploy]
    D --> |Agile| F[Sprint 1: Plan - Build - Review]
    F --> G[Sprint 2: Plan - Build - Review]
    G --> H[Release]
    E --> H
    H --> I[Stakeholder Acceptance]

---

Vị trí BA trong team

Trong một team Agile thông thường:

• BA làm việc sát với Product Owner để đảm bảo backlog có đủ chi tiết
• BA tham dự sprint planning để giải thích user story cho dev
• BA hỗ trợ QA khi cần làm rõ acceptance criteria
• BA báo cáo Project Manager về tình trạng yêu cầu

Không phải team nào cũng có BA riêng — ở startup nhỏ, Product Owner thường kiêm luôn vai trò BA. Ở công ty lớn (ngân hàng, bảo hiểm), BA là một vị trí chuyên biệt với seniority rõ ràng (Junior BA → BA → Senior BA → Lead BA).

---

Tự luyện

• Task 1: Tìm một ứng dụng bạn dùng hàng ngày (Grab, MoMo, hay app đặt đồ ăn). Liệt kê 3 nhóm stakeholder mà BA của app đó phải làm việc cùng.
• Task 2: Theo dõi quy trình đặt lịch khám bệnh tại một phòng khám gần nhà (hoặc tìm hiểu online). Ghi lại 3 điểm đau (pain point) mà người dùng có thể gặp phải.
• Task 3: Hỏi một người làm dev hoặc QA trong mạng lưới của bạn: "Dự án gặp vấn đề gì khi thiếu tài liệu yêu cầu rõ ràng?" Ghi lại câu trả lời để chia sẻ ở buổi học tiếp theo.