Kỹ thuật estimate dự án-Lộ trình từ Developer lên PM (Phần 3)

Tiếp nối phần 2 : Kỹ năng lập kế hoạch, ở phần 3 này mình sẽ trình bày về kỹ thuật estimate, một trong những nhiệm vụ quan trọng của PM trong việc quản lý dự án.

Estimate là gì ?

Hiểu một cách ngắn gọn đơn giản Estimate là một hoạt động nhằm ước lượng bao lâu thì công việc có thể hoàn thành. 

Mục đích của estimate là dự đoán khối lượng công việc, chi phí và giá cả của các nguồn lực cần thiết để hoàn thành một công việc trong phạm vi dự án.

Các thành phần chính của Estimation

1. Scope (Phạm vi)

• Mô tả tất cả các khía cạnh của dự án, bao gồm tất cả các hoạt động liên quan, giả định và ràng buộc (Assumption), nội dung của dự án: cái gì được đưa vào, cái gì không, sản phẩm được bàn giao.
• Tất cả các thông tin này phải được tài liệu hóa và mô tả rõ ràng trong bản estimate.

2. Time-frame (Khung thời gian)

• Ước tính deadline hoàn thành dự án, các milestone dự kiến.
• Khung thời gian cần dựa trên các thành phần khác như resource, cost, risk

3. Resources (Nguồn lực)

• Con người, thiết bị, cơ sở vật chất, kinh phí, …
• Bạn cần biết chính xác cần bao nhiêu người để thực hiện.

4. Cost (Chi phí)

• Ngân sách: cần bao nhiêu tiền để hoàn thành dự án

5. Risk (Rủi ro)

• Xác định các rủi ro tiềm ẩn đối với dự án

Các kỹ thuật Estimation

Top-down estimating (Ước tính từ trên xuống)

• Estimate tổng thể dự án trước, sau đó chia thành các phases, milestones
• Tính chính xác khá thấp nhưng bù lại estimate rất nhanh, ra được kết quả ngay
• Phương pháp này không thể estimate chi tiết nên chỉ phù hợp để ước tính ngân sách sơ bộ xem có khả thi không

Bottom-up estimating (Ước tính từ dưới lên)

• Estimate từng công việc cụ thể
• Có được bức tranh tổng thể từ các mảnh ghép nhỏ
• Tốn thời gian, nhưng kết quả chính xác hơn so với phương pháp 1)

Expert estimating (Ước tính dựa trên kinh nghiệm)

• Cách nhanh nhất để estimate 1 dự án
• Dựa trên kiến thức, dữ liệu lịch sử của chuyên gia có kinh nghiệm

Analogous estimating (Ước tính dựa trên sự giống nhau, tương tự)

• Dựa trên một dự án tương tự để so sánh và ước tính

Parametric estimating (Ước tính bằng tham số)

• Có hệ thống tính toán dựa trên các thông tin về dự án và thống kê dữ liệu lịch sử
• Các thông tin về dự án có thể là: resources, requirement, type, framework, …

Three-point estimating (ước tính ba điểm)

• Phương pháp three-point estimating (ước tính 3 điểm) thường được dùng để giảm độ lệch khi estimate chi phí / thời gian làm dự án nào đó giúp tăng tính chính xác. Sử dụng ước tính từ các trường hợp tốt nhất và xấu nhất có thể xảy ra.
• Phương pháp này thường được tính theo PERT (Program Evaluation and Review Technique) :
  • E = (Eo + 4Em + Ep)/6
  • Trong đó:
    • Eo (Optimistic Estimate): estimate trong trường hợp xấu nhất.
    • Em (Most Likely Estimate): estimate trong trường hợp bình thường.
    • Ep (Optimistic Estimate): estimate trong trường hợp tốt nhất.
    • E (Expected Cost): chi phí mong muốn bỏ ra.

Tổng hợp một số kinh nghiệm khi estimation

• Không thay đổi tỷ lệ Norm thông thường khi estimate. Thông thường trong công ty thường để 1 số tỷ lệ norm cho PM tham khảo khi estimate (VD: Tỷ lệ Tester = 1/3 tỷ lệ DEV) nhưng trường hợp Norm chưa phù hợp thì cần chú ý:
  • Giới hạn Scope của dự án có thể đối ứng
  • Estimate bổ sung các yêu cầu ngoài Scope đã define
  • Trao đổi với team để điều chỉnh tỷ lệ Norm nếu cần thiết
• Testing Scope thường chỉ chọn 1 cho Mobile, 1 cho PC vì % cho testing theo template không đủ test hết scope
  • Đưa giả định scope test vào assumption
  • Nếu khách hàng muốn test nhiều hơn thì bổ sung cost vào estimate
• Trường hợp spec không rõ ràng, trong detail estimation cần note rõ là estimate dựa trên giả định spec là X, nếu giả định này không đúng thì cần estimate lại.
  • Chỗ nào chưa đánh giá được thì đưa vào Q&A để clear làm rõ với khách hàng
  • Nếu Q&A mà vẫn không đủ thông tin thì có thể note rõ và báo lại khách hàng là không đủ thông tin để estimate
  • Đưa vào assumption cả những giả định mình nghĩ là đương nhiên nhưng ảnh hưởng lớn đến estimation
  • Thêm buffer nếu cần thiết (chia sẻ rõ với khách hàng)
• Estimate càng chia nhỏ và nội dung estimate rõ ràng thì khách hàng càng dễ chấp nhận

Các vấn đề thực tế khi estimate dự án gặp phải

Dưới đây là tổng hợp 1 số vấn đề mình và các bạn PM trong công ty hay gặp phải khi estimate một dự án.

Spec không rõ ràng

Spec không rõ ràng, yêu cầu chung chung dẫn đến estimate không chính xác, tiềm ẩn nhiều rủi ro khi triển khai dự án: chi phí tăng, trễ deadline, …

• KH bàn giao tài liệu chậm
• KH đã có note ý nhỏ trong tài liệu rồi nhưng không có trong estimate

Giải pháp: Ngoài các điểm chú ý ở trên thì với các dự án có spec không rõ ràng, các bạn cũng có thể áp dụng một số phương án như:

• Nên có 1 team BA chạy trước 2 tuần, clear rõ spec trước khi đội dự án bắt tay vào thiết kế, coding,…
• Nên có Sprint 0 (khoảng 1-2 tuần – chạy theo mô hình Scrum) để dựng khung dự án, thống nhất rule làm việc cho dự án, training members, phân tích, chuẩn bị yêu cầu, planning cho Sprint 1 …
• Chia sẻ, thống nhất với khách hàng về master schedule (các milestones) và detailed schedule theo Sprint kèm độ ưu tiên của các tasks
• Nên có 1 buổi họp ngắn với khách hàng trước khi estimate nhằm clear trước 1 số vấn đề lớn, Q & A ảnh hưởng tới estimate

Không đánh giá lại estimate

Thông thường trước khi dự án bắt đầu chạy sẽ có 1 giai đoạn để PM nhận dự án và team phát triển đánh giá lại estimate vì thực tế có thể người estimate là 1 PM khác. Nhiều PM không để ý đến giai đoạn này nên khi chạy thật có thể tốn thêm chi phí so với estimate ban đầu.

Estimate sai và phát hiện muộn là vấn đề cực kỳ nghiêm trọng và khó giải quyết vì tất cả các việc khác: phân bổ resources, lên kế hoạch, … đều dựa trên estimate ban đầu.

Giải pháp: Nếu bạn là PM dự án và nhận 1 dự án bạn không estimate thì bạn và team phát triển nên estimate lại.

Bản thân PM không control, đánh giá được estimate

Khi bạn chưa có kinh nghiệm trong lĩnh vực đang estimate hoặc bạn chỉ mới làm công việc estimate thì bản thân không thể control và đánh giá được estimate đó đúng hay sai dẫn tới sai lệch nhiều.

Giải pháp:

• Break nhỏ chức năng & đặt niềm tin vào members
• Để chắc chắn hơn thì tổ chức buổi họp để bạn team leader giải trình về estimate (mời thêm các PM, Leader có kinh nghiệm join cùng)
• Nhờ thêm người có kinh nghiệm hoặc cấp quản lý của bạn review cho estimate của bạn

Cảm ơn các bạn đã đọc hết bài viết của mình, hy vọng trong phần này các bạn đã hiểu được phần nào công việc estimate đối với quản lý dự án. Bài viết sử dụng khá nhiều thuật ngữ, phần nào bạn chưa hiểu có thể tìm đọc thêm trên internet để hiểu rõ hơn. Trong phần tiếp theo của series lộ trình từ developer lên PM, mình sẽ chia sẻ cách làm sao để một PM có thể quản lý được tiến độ của dự án. Mời các bạn đón đọc phần 4 tại đây!