Chipi Limited
Silverdale, Auckland, New Zealand
NZBN: 9429053537539
Buổi họp kết thúc dự án bằng một kết luận cuối slide: vượt 30% giờ so với báo giá. Trưởng dự án giải thích hệ thống của khách phức tạp hơn dự kiến, mọi người đồng ý, và cuộc họp tan. Hai tuần sau, báo giá cho khách mới được làm đúng theo cách cũ, với cùng những con số ước lượng, vì không ai giữ lại được gì ngoài câu “dự án khó hơn dự kiến”.
Các hướng dẫn tiếng Việt về man month (tháng công, lượng việc một người làm trong một tháng) dạy rất kỹ cách lập dự toán. Gần như không bài nào hướng dẫn việc cần làm sau khi dự án đóng: lấy dự toán ra so với giờ công thực tế, theo từng hạng mục, để lần sau ước lượng bằng dữ liệu. Bài vì sao dự án phần mềm lãi trên báo giá nhưng lỗ khi bàn giao xếp sai số ước lượng là nguồn rò rỉ biên lợi nhuận lớn nhất, còn bài cách tính giá dự án phần mềm đặt vòng đối chiếu ở bước cuối của báo giá. Bài này đi vào chính vòng đó.
Bài viết dành cho bên nhận việc, tức công ty phần mềm, công ty outsourcing và agency kỹ thuật, cụ thể là người duyệt báo giá và người ước lượng.
Sai số ước lượng là gì và đo bằng gì
Sai số ước lượng là phần chênh giữa giờ thực tế và giờ đã báo của một hạng mục, chia cho giờ đã báo. Hạng mục báo 320 giờ, làm hết 480 giờ, sai số là 50%. Sai số chỉ tính trên việc nằm trong phạm vi báo giá. Việc khách hỏi thêm ngoài phạm vi không phải lỗi của người ước lượng.
Khi dùng cho báo giá sau, cách viết tiện hơn là hệ số lệch: giờ thực chia giờ báo. Hệ số 1,50 nghĩa là hạng mục tốn gấp rưỡi giờ đã báo, hệ số 0,80 nghĩa là còn dư 20%. Hệ số tiện vì nhân thẳng được vào ước lượng mới.
Khi gom hệ số của nhiều dự án theo từng loại việc, bạn có định mức nội bộ: con số cho biết đội của chính công ty bạn thường tốn bao nhiêu so với ước lượng ở mỗi loại việc.
Nên đo bằng giờ, không đo bằng tiền. Tiền trộn thêm cost rate (đơn giá chi phí của một giờ công) và giá bán, hai thứ thay đổi theo năm và theo người làm, còn giờ chỉ đo việc đó tốn bao nhiêu công. Bài này cũng không dùng các tỷ lệ vượt giờ “trung bình ngành phần mềm” đang lan truyền, vì không kiểm được nguồn gốc, và chúng không nói gì về đội của bạn.
Vì sao “dự án vượt 30%” chưa nói được gì
Dự án mẫu dùng trong bài này là dự án đã xuất hiện ở bài cách tính giá và bài dự án lỗ khi bàn giao. Báo giá 10 man month theo quy ước 160 giờ, tức 1.600 giờ, gồm 640 giờ của nhân sự cấp cao (senior) và 960 giờ của nhân sự cấp trung (middle). Quyết toán ra 2.080 giờ, vượt 480 giờ, đúng 30% (*).
Con số 30% đó gồm bốn phần rất khác nhau:
| Phần vượt | Giờ | Tỷ lệ trên giờ báo | Có phải sai số ước lượng |
|---|---|---|---|
| Việc ngoài phạm vi khách hỏi thêm | 160 | 10% | Không |
| Lệch trên các hạng mục trong phạm vi (ròng) | 160 | 10% | Có |
| Làm lại và sửa lỗi trước bàn giao | 100 | 6,25% | Một phần |
| Hạng mục báo giá không có dòng (họp và chờ khách) | 60 | 3,75% | Có, dạng bỏ sót |
| Tổng | 480 | 30% |
Một phần ba con số vượt không phải lỗi ước lượng
160 giờ ngoài phạm vi là những việc báo giá chưa từng hứa. Khách hỏi thêm màn hình báo cáo, thêm trường vào biểu mẫu, đổi luồng duyệt, và đội làm mà không ai báo giá. Tính 160 giờ này vào sai số là bắt người ước lượng gánh hậu quả từ quyết định của người nhận lời khách.
Nếu không tách, hệ quả xấu đi theo hai hướng. Người ước lượng lần sau tự đội giờ lên cho an toàn, báo giá đắt hơn mà không có căn cứ. Còn chuyện cần sửa, tức cách xử lý yêu cầu phát sinh, thì không ai đụng tới. Bài scope creep (phạm vi phình dần) tính ra tiền đi riêng vào phần này (*).
Bù trừ giữa các hạng mục làm tổng trông gọn hơn thật
Phần lệch trong phạm vi là 160 giờ ròng. Mở từng hạng mục ra thì tổng giờ lệch, không kể chiều, là 240 giờ. Phân tích vượt 20 giờ, quản lý dự án dư 20 giờ. Backend (phần xử lý nghiệp vụ phía máy chủ) vượt 40 giờ, giao diện dư 40 giờ. Hai cặp này triệt tiêu nhau trên con số tổng, nên người chỉ nhìn tổng sẽ tin rằng chỉ có hạng mục tích hợp bị lệch (*).
Lần báo giá sau, nếu dự án mới ít phần tích hợp mà nhiều phần backend, hai sai số trước đây bù cho nhau sẽ không còn bù nữa.
Đúng giờ chưa chắc là ước lượng đúng
Giao diện được báo 360 giờ và quyết toán đúng 360 giờ. Nhìn qua thì đây là hạng mục ước lượng tốt nhất dự án. Mở nhãn giờ ra thì thấy 320 giờ làm và 40 giờ làm lại, vì thiết kế màn hình bị khách đổi sau khi đã lập trình xong một lượt. Đội làm nhanh hơn dự kiến, rồi mất phần nhanh đó vào việc làm lại (*).
Hai thông tin này cần cho hai việc khác nhau. Định mức dùng tổng 360 giờ, vì báo giá sau cũng phải gánh giờ làm lại. Còn tỷ lệ làm lại thì là chuyện chất lượng quy trình, phải theo dõi riêng.
Chuẩn bị trước khi so
Đối chiếu chỉ cho kết quả đúng khi ba điều kiện có sẵn từ lúc dự án bắt đầu. Thiếu một điều kiện thì cuối dự án vẫn ra con số, nhưng con số đó sai.
- Một quy ước giờ cho cả ba khâu. 10 man month theo 160 giờ là 1.600 giờ, theo 176 giờ là 1.760 giờ. Báo giá theo 160 mà lúc đối chiếu lấy 1.760 làm mốc thì 2.080 giờ thực trông như vượt 18% thay vì 30%. Chọn một quy ước, ghi vào báo giá, và dùng đúng quy ước đó khi ước lượng, khi chấm công và khi đối chiếu, như bài cách tính giá dự án phần mềm đã nêu (*).
- Lưu cố định hai bản dự toán. Bản thứ nhất là ước lượng của đội kỹ thuật. Bản thứ hai là số giờ trong báo giá đã ký. Hai bản thường khác nhau, vì trong lúc đàm phán, bộ phận kinh doanh hay cắt bớt giờ để hạ giá. Nếu chỉ lưu bản đã ký, phần giờ bị cắt sẽ hiện ra như sai số của người ước lượng. Cả hai bản đều cần chia theo hạng mục và theo cấp bậc.
- Bảng chấm công gắn hạng mục và nhãn loại giờ. Nhãn tối thiểu gồm: trong phạm vi, ngoài phạm vi, làm lại, họp với khách, chờ khách, bảo hành. Không có nhãn, bốn phần trong bảng ở trên trộn thành một con số. Mẫu chấm công theo dự án có sẵn cột dự án và cột loại giờ, thêm cột hạng mục là đủ dùng.
Bảng đối chiếu theo hạng mục của một dự án
Đặt hai bản số cạnh nhau theo từng hạng mục, dự án mẫu cho ra bảng sau (*).
| Hạng mục | Giờ báo | Giờ thực | Lệch | Hệ số |
|---|---|---|---|---|
| Phân tích và thiết kế (senior) | 120 | 140 | +20 | 1,17 |
| Tích hợp hệ thống của khách (senior) | 320 | 480 | +160 | 1,50 |
| Backend nghiệp vụ (100 giờ senior, 400 giờ middle) | 500 | 600 | +100 | 1,20 |
| Giao diện (middle) | 360 | 360 | 0 | 1,00 |
| Kiểm thử (middle) | 200 | 200 | 0 | 1,00 |
| Quản lý dự án và triển khai (senior) | 100 | 80 | −20 | 0,80 |
| Họp và chờ khách (senior) | 0 | 60 | +60 | |
| Trong phạm vi | 1.600 | 1.920 | +320 | 1,20 |
| Ngoài phạm vi (40 giờ senior, 120 giờ middle) | 160 | |||
| Tổng giờ thực | 2.080 | +480 |
Giờ thực của backend gồm 60 giờ làm lại, của giao diện gồm 40 giờ làm lại. Hệ số tính trên giờ trong phạm vi, đã bao gồm giờ làm lại và không tính việc ngoài phạm vi.
Tích hợp lệch lớn nhất, vượt 160 giờ, vì tài liệu API của bên khách sai ba chỗ và môi trường thử nghiệm của họ chỉ mở trong giờ hành chính. Quản lý dự án dư 20 giờ nghe như tin tốt, nhưng nên kiểm nhãn trước khi tin, vì trưởng dự án rất hay ghi giờ quản lý thành giờ họp với khách. Họp và chờ khách tốn 60 giờ senior mà báo giá không có dòng nào cho nó, nên báo giá sau phải có dòng này (*).
Quy ra tiền, cost rate dùng ở đây là 447.727 đồng một giờ cho senior và 288.647 đồng cho middle, tính trên giờ bán được và chưa gồm bảo hiểm bắt buộc. Hai con số này dựng từ lương gross 45 triệu và 28 triệu một tháng, cộng phụ cấp, thưởng, thiết bị, rồi chia cho số giờ bán được cho khách trong năm, nên cao hơn nhiều so với lương chia giờ làm. Cách dựng nằm ở bảng tính cost rate theo giờ, và bạn nên thay bằng lương của công ty mình (*).
Với đơn giá đó, phần lệch ròng trên các hạng mục là 71,6 triệu chi phí nhân công, làm lại 28,9 triệu, họp và chờ khách 26,9 triệu, việc ngoài phạm vi 52,5 triệu. Cộng lại là 179,9 triệu, đúng phần nhân công vượt của dự án này trong bài dự án lỗ khi bàn giao. Bảng đối chiếu theo hạng mục và bảng sáu nguồn rò rỉ là hai cách đọc cùng một bộ giờ, một bảng để sửa ước lượng, một bảng để tìm chỗ mất biên (*).
Ghi nguyên nhân để biết sai số nào sẽ lặp lại
Một hệ số lệch chưa đủ để đưa vào định mức. Cần biết vì sao nó lệch, vì có yếu tố sẽ lặp lại ở dự án sau, có sự cố chỉ xảy ra một lần. Với mỗi hạng mục lệch quá một ngưỡng, ví dụ 10% theo cả hai chiều, ghi một dòng nguyên nhân theo năm nhóm:
- Yêu cầu chưa rõ lúc ước lượng. Đặc tả mơ hồ, người ước lượng phải đoán. Hay lặp lại ở các hạng mục nghiệp vụ phức tạp.
- Phụ thuộc bên thứ ba. Tích hợp với hệ thống của khách, cổng thanh toán, đối tác. Lặp lại gần như chắc chắn, và là lý do tích hợp thường có hệ số cao nhất.
- Công nghệ mới với đội. Lần đầu dùng một nền tảng hay một thư viện. Lặp lại cho tới khi đội đã làm vài lần.
- Cấp người làm khác với lúc ước lượng. Ước lượng giả định senior làm, thực tế giao cho middle, hoặc ngược lại. Lặp lại nếu cách phân công không đổi.
- Sự cố một lần. Nhân sự nghỉ dài đột xuất, máy chủ của khách hỏng một tuần. Ghi lại để biết, nhưng không nhân vào định mức.
Bốn nhóm đầu đi vào định mức. Nhóm thứ năm chỉ ghi chú, vì nếu nhân nó vào báo giá sau thì báo giá đắt lên vì một chuyện chưa chắc xảy ra lần nữa.
Buổi họp đóng dự án là chỗ điền các dòng này. Không cần dài, khoảng một giờ là đủ, với ba người: người đã ước lượng, trưởng dự án, và người giữ số giờ (kế toán hoặc văn phòng quản lý dự án, PMO). Đầu ra của buổi họp là bảng đối chiếu theo hạng mục cộng một dòng nguyên nhân cho mỗi hạng mục vượt ngưỡng. Ngưỡng 10% ở trên là đề xuất, mỗi công ty tự đặt theo quy mô dự án của mình.
Từ ba dự án ra định mức nội bộ
Một dự án cho một bộ hệ số, và một bộ hệ số thì chưa tin được, vì có thể dự án đó gặp đúng một khách khó. Ba dự án là mức tối thiểu để bắt đầu thấy loại việc nào lệch đều, loại nào lệch thất thường. Bảng dưới gộp dự án mẫu (A) với hai dự án khác của cùng công ty: B là cổng thông tin nội bộ cho một nhà bán lẻ, C là ứng dụng đặt lịch trên điện thoại (*).
| Loại việc | Dự án A | Dự án B | Dự án C | Định mức |
|---|---|---|---|---|
| Phân tích và thiết kế | 1,17 | 1,10 | 1,24 | 1,17 |
| Tích hợp hệ thống bên ngoài | 1,50 | 1,30 | 1,46 | 1,42 |
| Backend nghiệp vụ | 1,20 | 1,10 | 1,15 | 1,15 |
| Giao diện | 1,00 | 0,94 | 1,09 | 1,01 |
| Kiểm thử | 1,00 | 1,12 | 1,15 | 1,09 |
| Quản lý dự án và triển khai | 0,80 | 1,04 | 0,97 | 0,94 |
| Họp và chờ khách (tỷ lệ trên tổng giờ báo) | 3,75% | 4,5% | 3,0% | 3,75% |
Định mức ở đây là trung bình cộng của ba dự án, cách đơn giản nhất khi mới có ít dữ liệu. Sau mỗi dự án đóng, thêm một cột và tính lại. Khi đã có chừng mười dự án, nên tách định mức theo loại dự án, vì một ứng dụng di động và một hệ thống quản trị nội bộ thường lệch theo những kiểu khác nhau (*).
Tích hợp lệch đều từ 30% tới 50% qua cả ba dự án, tức vấn đề nằm ở cách ước lượng loại việc này, và một hệ số 1,42 là cách vá tạm. Về lâu dài, nên dựng mốc giờ theo đơn vị việc, ví dụ số giờ cho một điểm tích hợp với hệ thống bên ngoài, rút từ chính các dự án đã làm. Còn giao diện thì gần như khớp, không cần sửa gì (*).
Nếu đội của bạn ước lượng bằng story point (điểm câu chuyện, đơn vị đo độ phức tạp tương đối của một việc), cách làm không đổi. Story point không quy ra tiền được, nên cần thêm một bước: ghi giờ thực vào từng việc, cuối dự án tính số giờ thực trên một điểm theo loại việc. Con số đó đóng vai trò của hệ số lệch, và cũng phải tách việc ngoài phạm vi ra như trên.
Báo giá lần sau dùng định mức thế nào
Một cách kiểm định mức là áp nó vào chính báo giá cũ. Nếu ngày đó công ty đã có định mức, báo giá của dự án mẫu sẽ ra thế này (*):
| Hạng mục | Giờ ước lượng | Định mức | Giờ sau định mức |
|---|---|---|---|
| Phân tích và thiết kế (senior) | 120 | 1,17 | 140 |
| Tích hợp (senior) | 320 | 1,42 | 454 |
| Backend, phần senior | 100 | 1,15 | 115 |
| Backend, phần middle | 400 | 1,15 | 460 |
| Giao diện (middle) | 360 | 1,01 | 364 |
| Kiểm thử (middle) | 200 | 1,09 | 218 |
| Quản lý dự án và triển khai (senior) | 100 | 0,94 | 94 |
| Họp và chờ khách (senior) | 3,75% | 60 | |
| Tổng | 1.600 | 1.905 |
1.905 giờ, gồm 863 giờ senior và 1.042 giờ middle, so với 1.920 giờ thực trong phạm vi. Lệch 15 giờ, chưa tới 1%. Chi phí đã tính đủ gián tiếp theo định mức là 824,6 triệu, trong khi thực tế trong phạm vi là 829,2 triệu (*).
Giá thì chênh xa hơn. Tính theo giá sàn của bài cách tính giá, tức giá thấp nhất còn giữ được biên 25% sau khi gánh chi phí gián tiếp, 1.905 giờ cho ra khoảng 1,1 tỷ. Báo giá cũ dựa trên 1.600 giờ ra 901,8 triệu. Chênh 22%, và khoản chênh đó có từ ngày ký hợp đồng mà báo giá không thể hiện (*).
Có định mức rồi, dự phòng trong báo giá đổi vai trò. Trước đây nó phải gánh cả những sai lệch đã biết, như tích hợp luôn vượt. Nay phần đó nằm trong giờ ước lượng, còn dự phòng chỉ để cho rủi ro chưa biết của riêng dự án mới. Như bài cách tính giá đã nói, dự phòng vẫn là một dòng riêng, tách khỏi biên.
Chuyện khó là khi giá theo định mức cao hơn mức khách chịu trả. Còn ba lựa chọn, và lựa chọn nào cũng tốt hơn ký giá cũ mà không biết:
- Thu hẹp phạm vi cho vừa ngân sách của khách, và ghi rõ hạng mục nào bị bỏ.
- Tách hạng mục rủi ro cao ra tính theo giờ thực tế. Ở dự án mẫu, đó là phần tích hợp, hạng mục có hệ số cao nhất và phụ thuộc nhiều nhất vào phía khách.
- Nhận giá thấp nhưng biết biên thật. Bán 900 triệu với chi phí theo định mức 824,6 triệu thì biên còn khoảng 75,4 triệu, tức khoảng 8%, chưa tính bảo hành, mua ngoài và mọi việc ngoài phạm vi. Đó là quyết định của ban giám đốc, chẳng hạn để vào được một khách hàng chiến lược, và ban giám đốc nên quyết khi đã có con số này (*).
Với hợp đồng fixed price (giá trọn gói), định mức gần như bắt buộc, vì công ty nhận việc gánh toàn bộ sai số. Với time and material (tính theo giờ thực tế), sai số được khách trả một phần, nhưng định mức vẫn cần để ước tính ngân sách mà khách nhìn thấy và duyệt. So sánh đầy đủ các mô hình hợp đồng sẽ có bài riêng.
Có số đối chiếu ngay khi dự án đóng
Bảng đối chiếu cần ba nguồn: bản dự toán đã ký theo hạng mục, giờ chấm công gắn hạng mục và nhãn, và cost rate theo cấp bậc. Ba nguồn đó thường nằm ở ba chỗ, nên phần lớn công ty bỏ qua bước đối chiếu, vì ghép tay mất cả ngày cho một dự án đã đóng.
Excel làm được việc này khi công ty có ít dự án và có một người chịu trách nhiệm ghép số. Bài quản lý chi phí dự án bằng Excel nói rõ cách đó làm được tới đâu, và mẫu Excel tính lãi lỗ từng dự án có sẵn phần quy giờ ra tiền. Khi giờ công gắn dự án, hạng mục và nhãn ở cùng một chỗ với dự toán và cost rate, CostDesk dựng được bảng đối chiếu ngay lúc dự án đóng, và theo dõi được từ tháng thứ hai, khi hạng mục tích hợp đã tốn 300 trên 320 giờ mà mới xong một nửa.
Các mảnh ghép liên quan
Bài này là bước cuối của vòng báo giá. Cách dựng báo giá từ man month tới cost rate và giá sàn nằm ở bài cách tính giá dự án phần mềm. Sáu nguồn làm biên trên báo giá thành lỗ khi bàn giao nằm ở bài vì sao dự án phần mềm lãi trên báo giá nhưng lỗ khi bàn giao, còn phần việc ngoài phạm vi được tính ra tiền ở bài scope creep tính ra tiền. Kết quả cuối cùng của dự án đọc theo ba tầng biên ở bài báo cáo lãi lỗ từng dự án. Khung tổng thể nằm ở bài quản lý chi phí dự án cho công ty phần mềm, và nếu từng dự án đều sát định mức mà công ty vẫn không lãi thì xem utilization rate (tỷ lệ giờ tính phí trên giờ khả dụng). File để bắt đầu là bảng chấm công, bảng cost rate và bảng lãi lỗ.
Câu hỏi thường gặp
Sai số ước lượng bao nhiêu là chấp nhận được?
Không có con số chung đáng tin. Nên xem sai số có đều hay không: một loại việc luôn vượt 40% thì xử lý được bằng định mức, còn một loại việc lúc vượt 10%, lúc vượt 80% thì phải sửa cách ước lượng.
Nên đối chiếu theo giờ hay theo tiền?
Theo giờ, rồi mới quy ra tiền để biết mức ảnh hưởng. Tiền trộn thêm cost rate và giá bán, nên hai dự án cùng lệch 100 giờ có thể ra hai con số tiền khác nhau chỉ vì người làm khác cấp.
Dự án chưa chấm công theo hạng mục thì có đối chiếu được không?
Được phần thô: tổng giờ thực so với tổng giờ báo, và giờ sau ngày bàn giao. Phần theo hạng mục thì không dựng lại được. Nên thêm cột hạng mục vào bảng chấm công ngay từ dự án tiếp theo.
Đội ước lượng bằng story point thì đối chiếu thế nào?
Ghi giờ thực vào từng việc, cuối dự án tính số giờ trên một điểm theo loại việc. Con số đó dùng như hệ số lệch. Không ghi giờ thì story point chỉ đo được tốc độ của đội, không quy ra chi phí được.
Giờ ngoài phạm vi có tính vào sai số không?
Không. Đó là việc báo giá chưa từng hứa, nên phải tách ra một dòng riêng. Tính chung vào sai số thì người ước lượng sẽ tự đội giờ lên ở lần sau, còn cách xử lý yêu cầu phát sinh thì không được sửa.
Bao nhiêu dự án thì đủ để có định mức?
Ba dự án là mức tối thiểu để bắt đầu. Sau đó cập nhật sau mỗi dự án đóng, và khi có khoảng mười dự án thì tách định mức theo loại dự án.
Có nên đối chiếu khi dự án đang chạy không?
Có, và nên làm mỗi tuần cho các hạng mục rủi ro. Đối chiếu cuối dự án giúp rút kinh nghiệm, nhưng làm giữa chừng mới kịp điều chỉnh kế hoạch hoặc trao đổi lại với khách.
Định mức có thay được dự phòng không?
Không thay được. Định mức xử lý phần sai lệch đã biết, như tích hợp luôn vượt. Dự phòng vẫn cần cho rủi ro chưa biết của dự án mới, và vẫn là dòng riêng trong báo giá.
Ai nên giữ bảng định mức?
Người chịu trách nhiệm báo giá, thường là trưởng bộ phận kỹ thuật hoặc PMO, với số giờ lấy từ bộ phận giữ chấm công. Nên giao bảng này cho một người giữ, để mọi báo giá dùng chung một bộ hệ số.
Dự án time and material có cần đối chiếu không?
Có. Khách trả theo giờ thực nên sai số ít ăn vào biên hơn, nhưng ngân sách dự kiến gửi khách vẫn dựa trên ước lượng. Ước lượng lệch nhiều thì khách mất niềm tin vào ngân sách, và lần sau khó ký.
Để tự kiểm tra, hãy lấy dự án đóng gần nhất của bạn. Bạn có tìm lại được bản dự toán theo hạng mục, cả bản của đội kỹ thuật lẫn bản đã ký với khách, không? Và trong phần giờ vượt, bạn tách được bao nhiêu giờ là việc ngoài phạm vi, bao nhiêu giờ là làm lại? Nếu chỉ còn một con số tổng, báo giá tiếp theo sẽ dùng lại đúng những ước lượng đã sai lần này.
(*) Tình huống giả định để minh họa
CostDesk Newsletters
Đăng ký nhận bản tin miễn phí hàng tuần từ CostDesk
[email protected]
Đăng ký