Ước lượng 3.960 giờ công, ngân sách nhân sự 675 triệu, thực chi gấp đôi: tính đơn giá nhân công đầy đủ trước khi lập ngân sách
Lấy giờ công nhân với lương chia cho giờ hành chính là cách lập ngân sách nhân sự phổ biến nhất, và cũng thiếu hụt phổ biến nhất. Bài viết dựng đơn giá nhân công đầy đủ từ lương, các khoản doanh nghiệp đóng, thưởng, chi phí chung và giờ làm hữu ích, trên ví dụ một dự án phần mềm có ngân sách bị đánh giá thấp đúng một nửa.
Tình huống minh hoạ
Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ. Các tỷ lệ bảo hiểm, phúc lợi chỉ để minh hoạ phương pháp; khi lập ngân sách thật hãy lấy số của phòng tài chính – nhân sự theo quy định hiện hành.
Một công ty phần mềm nhận làm hệ thống quản lý đơn hàng cho khách hàng nội bộ. Đội ước lượng từ dưới lên được 3.960 giờ công. PM lập ngân sách nhân sự theo cách quen thuộc:
- Lương gộp bình quân của kỹ sư: 30 triệu đồng/tháng.
- Một tháng có 22 ngày × 8 giờ = 176 giờ → đơn giá ≈ 170.000 đồng/giờ.
- Ngân sách nhân sự = 3.960 ÷ 176 × 30 = 675 triệu đồng.
Kết thúc dự án, phòng tài chính phân bổ chi phí nhân sự thực tế cho dự án: 1.353 triệu đồng, gấp đôi. Giờ công thực tế gần đúng ước lượng. Lỗi nằm ở đơn giá.
Hai chỗ đơn giá "lương ÷ giờ hành chính" sai
1. Mẫu số quá lớn — không phải giờ nào cũng là giờ dự án. Trong 176 giờ hành chính có nghỉ phép, lễ, họp toàn công ty, đào tạo, hỗ trợ sự cố sản phẩm cũ, chuyển đổi giữa các việc. Dữ liệu chấm công của công ty cho thấy chỉ khoảng 75% thời gian được ghi vào dự án, tức 132 giờ hữu ích mỗi tháng.
Với 132 giờ, 3.960 giờ công cần 30 người-tháng, không phải 22,5.
2. Tử số quá nhỏ — công ty trả nhiều hơn lương. Chi phí thật của một người mỗi tháng (giả định minh hoạ):
| Khoản | Triệu đồng/tháng |
|---|---|
| Lương gộp | 30,0 |
| Bảo hiểm và các khoản doanh nghiệp đóng (giả định 22% lương) | 6,6 |
| Thưởng tháng 13 phân bổ đều (30 ÷ 12) | 2,5 |
| Chi phí chung: chỗ ngồi, máy tính, bản quyền phần mềm, quản lý | 6,0 |
| Chi phí đầy đủ | 45,1 |
Đơn giá nhân công đầy đủ = 45,1 triệu ÷ 132 giờ ≈ 341.700 đồng/giờ — gấp đôi con số 170.000.
Phân rã khoản chênh lệch
Tình huống liên quan
Rút ngắn 4 ngày tốn bao nhiêu: nén tiến độ bằng crashing theo chi phí biên và chi phí gián tiếp
Khi khách hàng muốn bàn giao sớm hơn, câu hỏi đúng không phải là "có làm được không" mà là "mỗi ngày rút ngắn tốn thêm bao nhiêu". Bài viết đi qua một ví dụ số đầy đủ: chọn hoạt động nén theo chi phí biên, theo dõi đường găng đổi chỗ và tìm điểm dừng khi tính cả chi phí gián tiếp và tiền phạt.
Sếp hỏi "bao giờ xong 40 hạng mục còn lại?": dự báo bằng mô phỏng Monte Carlo trên throughput thay vì cộng story point
Thay vì ngồi ước lượng lại từng hạng mục rồi chia cho velocity trung bình, đội có thể dùng chính lịch sử throughput của mình để mô phỏng hàng nghìn tương lai và trả lời sếp bằng một xác suất: 85% khả năng xong trong 10 tuần. Bài viết hướng dẫn cách làm, cách đọc kết quả và những giới hạn cần nói rõ.
Cho lập trình bắt đầu khi thiết kế mới xong một nửa: tính lợi và rủi ro làm lại của fast-tracking
Fast-tracking rút ngắn tiến độ bằng cách cho các hoạt động vốn nối tiếp chạy chồng lên nhau. Không tốn thêm tiền ngay, nhưng phải trả bằng rủi ro làm lại. Bài viết lượng hoá đánh đổi đó bằng giá trị kỳ vọng và gợi ý cách chọn mức chồng lấn hợp lý.
Ngày ra mắt đã chốt trước Tết, phạm vi thì chưa: lập kế hoạch phát hành bằng dải velocity "chắc có – có thể có – không kịp"
Khi ngày phát hành không được dời, câu hỏi đúng không còn là "bao giờ xong" mà là "đến ngày đó sẽ có những gì". Dùng velocity thấp và cao của chính đội để vạch hai đường trên backlog đã sắp thứ tự, PM chia phạm vi thành ba vùng và cập nhật sau mỗi sprint. Bài viết hướng dẫn cách tính và cách trình bày với nhà tài trợ.