Skip to content
Home » Knowledge Sharing » Làm gì khi dự án vẫn dùng Man Day để estimate?

Làm gì khi dự án vẫn dùng Man Day để estimate?

Việc dùng Man Day (thời gian của một người) hay nói đơn giản là dùng thời gian để đánh giá và ước lượng một Task trong quản lý dự án, là chưa tối ưu.
Bạn sẽ làm thế nào để do lường tốc độ (Velocity) của team trong Sprint, trừ phi bạn chấp nhận team luôn làm cùng một khối lượng công việc và không có sự tiến triển !
Hãy cùng mình xem các phương pháp đo lường khác cho từng Task trong team, khi đó bạn hãy đưa ra lựa chọn chính xác nhé !

  1. Sử dụng Story Points (Điểm câu chuyện) – Ước tính tương đối:
    • Khái niệm: Thay vì quy đổi trực tiếp ra ngày công, Story Points là một đơn vị đo lường tương đối về nỗ lực (effort), độ phức tạp (complexity) và sự không chắc chắn (uncertainty) của một công việc (User Story/tính năng). Team sẽ so sánh các công việc với nhau. Ví dụ: “Tính năng B này có vẻ phức tạp gấp đôi tính năng A”.
    • Cách thực hiện: Team chọn một công việc đơn giản, đã hiểu rõ làm mốc (ví dụ: 1 hoặc 2 points). Sau đó, các công việc khác sẽ được ước tính dựa trên việc so sánh với công việc mốc đó. Thang điểm phổ biến là dãy Fibonacci (1, 2, 3, 5, 8, 13…) hoặc T-shirt size (XS, S, M, L, XL).
    • Lợi ích cho kế hoạch quý: Theo thời gian, team sẽ xác định được Velocity (tổng số Story Points trung bình mà team hoàn thành được trong một Sprint/Iteration). Dựa vào Velocity lịch sử, bạn có thể dự báo một cách thực tế hơn về khối lượng công việc (tính bằng Story Points) mà team có thể xử lý trong một quý, từ đó chọn lựa các tính năng phù hợp. Cách này tách biệt ước tính khỏi ràng buộc thời gian cứng nhắc.
    • Hình dung:
      • Bạn có thể tạo một bảng so sánh đơn giản:
      | Tính năng | Ước tính (Ngày công – cũ) | Ước tính (Story Points – mới) | Ghi chú độ phức tạp/không chắc chắn | | :———- | :———————— | :————————— | :———————————- | | Login | 2 ngày | 3 SP | Đơn giản, quen thuộc | | Search | 5 ngày | 8 SP | Phức tạp hơn, cần xử lý nhiều case | | Payment | 8 ngày | 13 SP | Phức tạp, tích hợp bên thứ 3 | | Tổng Q1 | ~X ngày | ~Y SP (Dựa trên Velocity) | |
  2. Lập kế hoạch dựa trên Kết quả (Outcome-Based Planning / OKRs):
    • Khái niệm: Thay vì tập trung vào việc “sẽ làm những tính năng gì” (output), phương pháp này tập trung vào “muốn đạt được kết quả gì” (outcome). Bạn sẽ xác định các Mục tiêu (Objectives) chính cho quý (ví dụ: “Tăng mức độ tương tác của người dùng trên trang Dashboard”) và các Kết quả then chốt (Key Results) có thể đo lường được để biết đã đạt mục tiêu hay chưa (ví dụ: “Tăng thời gian trung bình trên Dashboard thêm 15%”, “Giảm tỷ lệ thoát khỏi Dashboard 10%”).
    • Cách thực hiện: Dựa trên OKRs đã định, bạn và team sẽ cùng xác định các sáng kiến (initiatives) hoặc các nhóm tính năng lớn (epics) có khả năng đóng góp nhiều nhất vào việc đạt được các Key Results đó.
    • Lợi ích cho kế hoạch quý: Giúp cả team tập trung vào việc tạo ra giá trị kinh doanh thực sự, thay vì chỉ hoàn thành danh sách tính năng. Nó cũng tạo sự linh hoạt cho team Dev trong việc đề xuất giải pháp tốt nhất để đạt mục tiêu. Việc ước tính (có thể dùng Story Points hoặc T-shirt size ở mức cao) vẫn cần thiết cho các sáng kiến lớn để đảm bảo tính khả thi trong quý.
    • Hình dung:
      • Bạn có thể dùng một bảng OKRs đơn giản:
      | Objective (Mục tiêu) | Key Result (Kết quả then chốt) | Sáng kiến/Epic tiềm năng (Ước tính sơ bộ) | | :————————————— | :—————————————————— | :—————————————– | | Tăng tương tác trên Dashboard | KR1: Tăng thời gian TB trên trang 15% | Epic A: Cải thiện biểu đồ (Size M) | | | KR2: Giảm tỷ lệ thoát 10% | Epic B: Thêm gợi ý cá nhân hóa (Size L) | | Cải thiện hiệu năng thanh toán | KR1: Giảm thời gian xử lý thanh toán xuống dưới 3 giây | Epic C: Tối ưu API thanh toán (Size M) | | | KR2: Giảm tỷ lệ lỗi thanh toán 50% | Epic D: Thêm phương thức thanh toán mới (Size S) |
  3. NoEstimates / Lập kế hoạch dựa trên Luồng công việc (Flow-Based Planning):
    • Khái niệm: Tập trung vào việc chia nhỏ công việc thành các phần có kích thước tương đối đồng đều (nếu có thể) và tối ưu hóa luồng công việc (flow). Thay vì ước tính từng mục, bạn sẽ đo lường các chỉ số luồng.
    • Cách thực hiện: Theo dõi các chỉ số như Cycle Time (thời gian từ lúc bắt đầu làm đến lúc hoàn thành một công việc) và Throughput (số lượng công việc hoàn thành trong một đơn vị thời gian, ví dụ: số user stories/tuần).
    • Lợi ích cho kế hoạch quý: Giảm thời gian dành cho việc họp ước tính. Sử dụng dữ liệu lịch sử về Throughput để dự báo số lượng công việc có thể hoàn thành trong quý. Phương pháp này đòi hỏi việc chia nhỏ công việc (decomposition) phải thật tốt. Có thể dùng các kỹ thuật dự báo xác suất như Monte Carlo.
    • Hình dung:
      • Biểu đồ Cumulative Flow Diagram (CFD) để theo dõi tiến độ và tắc nghẽn.
      • Biểu đồ kiểm soát (Control Chart) cho Cycle Time.
      • Biểu đồ Throughput hàng tuần/Sprint. Dựa vào Throughput trung bình, bạn dự báo cho quý. Ví dụ: Team làm được trung bình 5 stories/tuần => 1 quý (12 tuần) có thể làm ~60 stories (với kích thước tương đồng).
  4. T-Shirt Sizing (Cho Epics/Tính năng lớn):
    • Khái niệm: Tương tự Story Points nhưng ở mức độ cao hơn, dùng cho các hạng mục công việc lớn (Epics, features) trong giai đoạn lập kế hoạch ban đầu hoặc roadmap. Gán các kích thước như XS, S, M, L, XL.
    • Lợi ích cho kế hoạch quý: Nhanh chóng có cái nhìn tổng quan về quy mô tương đối của các mục tiêu lớn trong quý mà không cần đi sâu vào chi tiết. Giúp bạn và stakeholders dễ dàng hình dung những gì có thể “vừa vặn” trong quý trước khi chia nhỏ ra để ước tính chi tiết hơn.

Lời khuyên dành cho bạn:

  • Bắt đầu với Story Points: Đây là bước cải tiến tự nhiên từ “điểm = ngày”. Hãy trao đổi với team về lợi ích của việc ước tính tương đối và tách biệt khỏi thời gian.
  • Kết hợp với OKRs: Đặt mục tiêu theo OKRs để định hướng cho quý, sau đó sử dụng Story Points (hoặc T-shirt size ban đầu) để ước tính các sáng kiến/epics cần thiết nhằm đạt được OKRs đó. Điều này giúp bạn vừa có định hướng chiến lược, vừa có cơ sở để lập kế hoạch dung lượng (capacity).
  • Nhấn mạnh sự hợp tác: Ước tính là hoạt động của cả team (Dev, QA, có thể cả UX/Design và PO) để cùng hiểu và đưa ra con số ước lượng nỗ lực chung.
  • Theo dõi dữ liệu lịch sử: Dù dùng phương pháp nào, việc theo dõi Velocity (với Story Points) hoặc Throughput (với NoEstimates) là rất quan trọng để các dự báo trong tương lai ngày càng chính xác.