Khi “năng suất cao” vẫn… trễ: Bài học đo lường đúng trong quản lý dự án

Gần đây tôi gặp một nghịch lý quen thuộc: ước tính ban đầu có vẻ hợp lý, PM báo cáo năng suất đội ngũ còn cao hơn ước tính, nhưng tiến độ tổng thể vẫn trễ. Khi đi sâu, vấn đề không nằm ở con người “lười” hay “kém”, mà ở chỗ chúng ta đo sai.

Vấn đề thật sự: đo “thời gian làm” thay vì “thời gian để hoàn thành”

Nhiều đội đo productivity bằng “giờ thực sự ngồi làm task” (touch time). Nhưng để đưa một hạng mục từ Start → Done, đội còn phải trả nhiều “chi phí phối hợp”: họp, chờ review, chờ môi trường, làm rõ yêu cầu, suy ngẫm thiết kế, chuyển ngữ, báo cáo, v.v. Những phần này không phải lãng phí, mà là một phần của công việc. Loại chúng ra khỏi phép đo khiến mẫu số bị “trôi”, tạo ảo giác năng suất cao, trong khi lead time vẫn dài và deadline vẫn vỡ.

Một cách nói đơn giản:

• Touch time: thời gian “ra tay làm”.
• Lead time: toàn bộ thời gian để một công việc đi từ bắt đầu đến hoàn tất.
• Nếu chỉ đo touch time, bạn đang tối ưu… một nửa bức tranh.

Dùng “hiệu suất dòng chảy” để nhìn đúng bức tranh

Tôi thường khuyến nghị thêm chỉ số Flow Efficiency (FE):

FE = Touch time / Lead time

Ví dụ: một user story mất 20 giờ để code & test, nhưng cần 80 giờ tính từ lúc bắt đầu đến lúc Done (do họp, chờ review, chờ dữ liệu, clarify…). FE = 20/80 = 25%.
Trong báo cáo thuần “giờ làm”, bạn thấy team rất bận rộn và “năng suất”, nhưng ở cấp độ dòng chảy, bạn thấy 75% thời gian đang nằm ngoài thao tác trực tiếp — và đó mới là lý do dự án trễ.

“Kế toán nỗ lực toàn phần”: coi mọi giờ làm đều là chi phí dự án

Thay vì chỉ log giờ “động tay”, hãy tính tất cả thời gian và công sức phục vụ cho công việc:

• Thực thi: phân tích, thiết kế, code, test, viết tài liệu.
• Phối hợp: họp, trao đổi 1–1, review/approve, triage.
• Chờ đợi: pending requirement, chờ môi trường, chờ data, chờ đối tác.
• Làm lại (rework): đổi yêu cầu, fix do thiếu thông tin/hiểu sai.
• Vận hành: build, deploy, cấu hình, chăm sóc môi trường.
• Học & chuẩn hóa: đọc spec, tiêu chuẩn hoá, viết guideline.

Tất cả những khoản trên phải được log vào WBS (gắn với artefact/stream cụ thể), vì chúng giải thích tại sao lead time dài ra — và chỉ khi nhìn đủ, bạn mới tối ưu đúng chỗ.

Bộ chỉ số tinh gọn để không tự đánh lừa mình

1. Lead Time (Start → Done) & Cycle Time (In Progress → Done) theo từng loại công việc.
2. Flow Efficiency = Touch / Lead.
3. Meeting Load (giờ/người/tuần) & Focus Time Ratio (tỉ lệ giờ tập trung sâu ≥ 60’).
4. Blocking Time (giờ bị chặn/tuần) & số lượng thẻ bị chặn (blocked items).
5. Rework Ratio (giờ rework / tổng giờ) & First-Pass Yield (tỉ lệ qua review/test ngay lần đầu).
6. WIP đang mở & Throughput (đầu việc hoàn tất/tuần).

Chỉ cần 6 nhóm chỉ số này, bạn đã đủ “bản đồ” để biết trễ nằm ở đâu: do quá nhiều họp, do chờ approve, do WIP quá lớn, hay do yêu cầu thay đổi.

Cách triển khai thực tế (4 bước, làm được ngay)

Bước 1 – Chuẩn hóa cách log work (Total Effort Accounting).

• Mỗi người log 7–8h/ngày vào đúng WBS/artefact liên quan; họp gì cho task nào thì log vào task đó (đừng tạo “hố đen” tên là “meeting chung”).
• Thêm các tag loại thời gian: Execute / Collaborate / Wait / Rework / Operate / Learn.
• Quy ước: daily/retro/refine… phải gắn vào stream/artefact mà buổi họp phục vụ.

Bước 2 – Tái định nghĩa ước tính & capacity.

• Ước tính mới = Touch time dự kiến + phụ phí phối hợp (dựa trên dữ liệu 2–4 tuần gần nhất).
• Lập kế hoạch capacity theo tổng giờ (không chỉ “giờ làm task”).
• Ưu tiên giảm WIP để tăng Flow Efficiency, thay vì “đổ thêm người”.

Bước 3 – Thiết kế dashboard dòng chảy.

• Hiển thị Lead/Cycle Time, Flow Efficiency, Blocking Time, Meeting Load theo team/stream.
• Drill-down tới thẻ bị chặn và đầu mối phê duyệt để xử lý nút thắt.

Bước 4 – Nhịp điều hành cải tiến.

• Weekly: review 30’ về nơi thời gian “chết” (blocked, chờ phê duyệt, họp trùng).
• Thử nghiệm 1–2 thay đổi/tuần (ví dụ giảm họp status, gom review theo batch, đặt focus blocks 2×90’/ngày, WIP limit = 1–2/người).
• Sau 2–3 tuần, cập nhật hệ số phụ phí phối hợp trong ước tính.

Ví dụ minh họa nhanh

Một feature mất 20 giờ thao tác (touch). Nhưng tính cả trao đổi, review, chờ data và triển khai, mất 80 giờ từ Start đến Done.

• Báo cáo kiểu “giờ làm” sẽ chấm team đạt 20/20 = 100%.
• Nhưng ở cấp độ dòng chảy, Flow Efficiency = 20/80 = 25% → hệ thống đang “rò” 75% thời gian vào phối hợp/chờ đợi.
• Bài toán tối ưu lúc này không phải “làm nhanh hơn 20 giờ”, mà là rút ngắn 60 giờ xung quanh (giảm WIP, gom approval, chuẩn hoá môi trường, họp đúng mục tiêu…).

Tín hiệu tốt – xấu cần để ý

• Tín hiệu tốt: Lead/Cycle Time giảm, Blocking Time giảm, Meeting Load ổn định, Rework Ratio đi xuống; FE tăng đều.
• Tín hiệu xấu: Velocity/“giờ làm” tăng nhưng Lead Time không đổi (hoặc tăng), WIP phình to, họp dày lên, tỉ lệ qua review lần đầu thấp.

---

Kết luận:
Đo lường đúng không chỉ để “đẹp báo cáo”, mà để ra quyết định đúng. Khi coi mọi thời gian phục vụ công việc đều là chi phí dự án, bạn sẽ nhìn thấy hệ thống như nó vốn có: đâu là chỗ đang tốt, đâu là nút thắt cần gỡ. Và chỉ khi đó, “năng suất cao” mới đi cùng đúng hạn và đúng chất lượng.