Ước lượng độ phức tạp của yêu cầu quan trọng như thế nào với BA PO

Ước lượng thời gian phân tích yêu cầu sai thì đau khổ cả giai đoạn sau.

Có nhiều anh em rơi vào trường hợp đánh giá không chính xác dẫn đến không đáp ứng được tiến độ dự án đúng không. Và tất nhiên điều này cũng có kể cả ở những công ty lớn hay có kiểu bốc timeline từ “trên” xuống, ấn định ngày golive.

Chính vì vậy BA cần làm tốt việc ước lượng độ phức tạp của yêu cầu khi có “cơ hội”.

Mục tiêu estimate của BA, PO.

1. Estimate effort/time: Dự đoán thời gian BA cần để phân tích, viết tài liệu, review, UAT…

2. Estimate scope/complexity: Đánh giá độ phức tạp của từng yêu cầu (user story, use case, feature).

3. Estimate size: Ước lượng độ lớn của backlog, giúp lập kế hoạch sprint hoặc release

II. Các kỹ thuật estimate phổ biến bạn có thể tham khảo.

1. Expert Judgment (Ước lượng theo kinh nghiệm)

• Cách làm: Dựa trên kinh nghiệm cá nhân hoặc tham khảo từ BA senior / SME.

• Khi dùng: Dự án mới, ít dữ liệu lịch sử.

• Ưu điểm: Nhanh, đơn giản.

• Nhược điểm: Mang tính chủ quan, khó tái lặp.

➡️ Ví dụ: “Feature dạng này team thường mất 3–4 ngày để làm rõ yêu cầu.”

Đây là cách khá phổ biến khi làm sản phẩm mà nhiều bạn BA, PO hay dùng.

2. Analogous Estimation (So sánh tương tự)

• Cách làm: So sánh với các yêu cầu hoặc dự án tương tự trước đây.

• Khi dùng: Có historical data hoặc các dự án tương tự.

• Ví dụ: “Module thanh toán mới này tương tự module chuyển khoản, nên effort khoảng 80% effort cũ.”

3. Top-Down Estimation

• Cách làm: Ước lượng tổng thể trước (ví dụ toàn dự án), sau đó chia nhỏ dần.

• Khi dùng: Ở giai đoạn early planning, chưa có nhiều chi tiết.

• Ví dụ: Tổng effort phân tích 100 giờ → phân bổ cho các phần:

• Yêu cầu nghiệp vụ: 40%

• Luồng UI/UX: 30%

• Rule & Validation: 20%

• Review/UAT support: 10%

4. Bottom-Up Estimation

• Cách làm: Ước lượng chi tiết từng task nhỏ (viết BRD, vẽ flow, review, meeting…) rồi cộng tổng.

• Khi dùng: Khi đã có breakdown cụ thể.

• Ưu điểm: Chính xác hơn.

• Nhược điểm: Tốn thời gian.

5. Three-Point Estimation (PERT technique)

Hơi toán một chút nhưng không dễ anh em nhé.

• Công thức:

Expected Time= {O + 4M + P}

• O: Optimistic (thời gian ít nhất)

• M: Most likely (thời gian trung bình)

• P: Pessimistic (thời gian nhiều nhất)

• Khi dùng: Khi cần phản ánh rủi ro, độ không chắc chắn.

• Ví dụ: Viết SRS:

• O = 6h, M = 8h, P = 12h → Expected = (6 + 4×8 + 12)/6 = 8.7h

Quan trọng là đoạn chọn thời gian sao cho chuẩn.

6. Planning Poker (Agile Estimation)

• Cách làm: Team (BA, Dev, QA, PO) cùng estimate độ phức tạp mỗi user story bằng điểm (story point).

• Khi dùng: Trong dự án Agile/Scrum.

• Ưu điểm: Cả team cùng tham gia, tăng tính đồng thuận.

• BA role: Giúp team hiểu rõ yêu cầu để estimate chính xác hơn.

7. T-Shirt Sizing (Relative Estimation)

• Cách làm: Dùng các mức độ S, M, L, XL… thay vì số giờ.

• Khi dùng: Khi chưa cần chi tiết, giúp nhanh chóng hình dung effort.

• Ví dụ:

• S: Yêu cầu nhỏ (1–2 ngày)

• M: Vừa (3–5 ngày)

• L: Lớn (1–2 tuần)

• XL: Rất lớn (>2 tuần)

8. Function Point Analysis (FPA)

• Cách làm: Đánh giá “kích thước logic” của hệ thống dựa trên số lượng input, output, file, interface, query.

• Khi dùng: Dự án lớn, cần estimate effort cho toàn hệ thống.

• Ưu điểm: Có thể chuyển đổi thành effort/time tương đối chính xác.

• Nhược điểm: Cần kinh nghiệm và dữ liệu đầu vào chi tiết.

9. Use Case Points

• Cách làm: Tính điểm dựa trên số lượng và độ phức tạp của use case + actor.

• Khi dùng: Phù hợp khi BA mô hình hoá yêu cầu dưới dạng use case UML.

III. Kinh nghiệm thực tế

Anh em xem mô hình và lựa chọn phương án phù hợp.

• Với dự án Agile (Scrum) → dùng Planning Poker + T-Shirt Sizing.

• Với Waterfall / Tender / Estimation Phase → dùng Bottom-Up + Three-Point.

• Khi chưa có đủ thông tin → dùng Expert Judgment hoặc Analogous trước.

• Khi đã có historical data → nên xây estimation template riêng (benchmark).

Các bạn đang dùng kỹ thuật nào để đánh giá thời gian triển khai yêu cầu. Cùng comment thảo luận nhé.

Đừng quên share bài viết gốc và theo dõi page BA Zone nhé.

#businessanalyst #baschool #bazone #ProductManagement