Trong nhiều trường hợp các kĩ sư nhận được công việc và được yêu cầu phải đưa ra estimate. Vì vậy trong bài viết này tôi sẽ giải thích về đơn vị cũng như cách tính toán nhân công đặc trưng như man-month, man-day và các phân bổ estimate của các kĩ sư trong cách viết estimate document để giao cho khách hàng.
Ngày công của kĩ sư phần mềm và đơn vị man-month
Trong tài liệu estimate chi phí, cần tính toán số nhân công để đưa ra được số tiền dự toán cần thiết. Nhân công nghĩa là số lượng công việc tính trên 1 người, được tính bằng đơn vị man-month hoặc man-day. Để tính toán nhân công, ta lấy man-day x chi phí ngày công. Đối với dự án outsource, thì chi phí được trả theo giờ (billable hour). Có nghĩa là, thù lao của kĩ sư là số tiền được trả ứng với số giờ lao động, chứ không phải ứng với sản phẩm được hoàn thành. Những người có năng lực kĩ thuật cao sẽ có năng lực làm việc cao, và chỉ cần số nhân công ít để hoàn thành công việc.
Có rất nhiều cách tính toán man-month, man-day. Giá của 1 man-month phụ thuộc và thay đổi theo kinh nghiệm cũng như khả năng kĩ thuật. Chi phí phụ thuộc tùy vào từng quốc gia. Chi phí man-month ở các nước phát triển như Mỹ, Tây Âu khá cao. Ở châu Á thì thấp hơn. Ở Nhật Bản, man-month nhìn chung rơi vào khoảng từ 50 vạn yên (96 triệu VNĐ) đến 150 vạn yên (288 triệu VNĐ).
Tính toán số tiền dự toán
Khi đưa ra số tiền dự toán, trước tiên cần tìm số nhân công từ quy mô của công việc. Lấy số nhân công đó nhân với giá của man-month hoặc man-day sẽ ra được số tiền dự toán. Tuy trên công thức là vậy song có nhiều trường hợp cần cộng thêm các chi phí khác cũng như nhân công quản lý, chi phí tài liệu… rồi mới đưa ra được số tiền dự toán. Hơn nữa, ngay trước khi hoàn thành cũng có thể xảy ra những thay đổi không thể dự đoán được nên thông thường sẽ thêm vào khoảng 20% nhân công thực tế rồi mới tính toán và đưa ra số tiền dự toán.
Hợp đồng khoán sản phẩm
Trong nhiều trường hợp, kỹ sư phần mềm sẽ nhận công việc với cách tính toán nhân công như phía trên, nhưng cũng có trường hợp làm theo hợp đồng khoán sản phẩm.Trong hợp đồng khoán sản phẩm, phía khách hàng sẽ quyết định giá của sản phẩm. Khi đó, khách hàng cũng sẽ quyết định số nhân công dự tính nên trong trường hợp này rõ ràng để khách hàng viết hợp đồng khoán sản phẩm sẽ có hiệu quả hơn. Ngoài ra, dù trong trường hợp dùng hợp đồng khoán sản phẩm thì phía kỹ sư phần mềm nhận công việc cũng cần tính toán số tiền dự toán và xác nhận xem có sự khác biệt so với số tiền phía khách hàng đưa ra hay không.
Điều kiện tiền đề của việc estimate
Khi thực hiện estimate, không chỉ việc viết dự toán mà còn cân nhắc cả việc quyết định những điều kiện tiền đề sẽ giúp tránh được những phiền toái, vấn đề về sau này. Cần quyết định những điều kiện tiền đề được thống nhất và hiểu rõ bởi cả 2 bên khách hàng và kĩ sư.
Về phạm vi estimate và ngoài phạm vi estimate
Cần phải giải thích rõ ràng xem phạm vi estimate của hệ thống là tới đâu, và vì có những trường hợp dùng văn bản thì sẽ không truyền tải được hết nên nếu có thể nên kèm theo cả một bản phụ lục hoặc sơ đồ riêng về cấu trúc cấu thành hệ thống. Hơn nữa những mục không nằm trong hệ thống như hướng dẫn người dùng cũng cần quyết định trước xem có thực hiện hay không.
Kì hạn của dự án
Việc thiết lập thời gian hoàn thành sản phẩm cũng là rất quan trọng khi thực hiện estimate.Ví dụ như dù có là trường hợp 2 man-month đi chăng nữa thì việc tập trung hoàn thành trong 2 tháng sẽ khác với làm từ từ từng chút một trong 10 tháng. Thông thường thì nếu thời gian hoàn thành và giao nộp sản phẩm ngắn thì số tiền dự toán thường cao, còn nếu thời gian dài thì sẽ có thương lượng để giảm giá xuống.
Phân bổ tỉ lệ chi phí dự toán phần mềm
Khi bắt đầu nhận yêu cầu dự án, các kỹ sư gặp khó khăn khi cần ra dự toán gấp. Các kỹ sư sẽ estimate từng tính năng, sau đó nhân trọng số và cộng lại ra tổng chi phí kỹ thuật. Khi gửi cho khách hàng cũng vội vàng dẫn đến bỏ qua các chi phí khác. Đây là điểm "yếu" chết người của rất nhiều kỹ sư phần mềm.
Mỗi công ty đều có công thức lập dự toán khác nhau, tuy vậy có những cách làm chung không nằm ngoài quy luật logic. Thí dụ, bảng phân phối nguồn lực của một dự án phần mềm được xác định như sau:
Tùy vào đặc điểm của dự án và các điều kiện tiền đề như đã nói ở trên mà các tỷ lệ có thể khác nhau. Thí dụ dự án đã có nghiệp vụ phân tích khảo sát đầy đủ (requirement spec) thì Reqmt specification có rate là 0%. Dự án là phiên bản nâng cấp thì Deployment có rate = 0. Dự án không có nhiều nghiệp vụ, thì tỷ lệ Testing có thể giảm xuống.
Các chú ý khi lập dự toán theo man-month
Chúng ta sẽ thấу rất khó chịu khi phải làm ᴠiệc ᴠới những dự án bắt buộc phải ước tính ra bao nhiêu Man-Month (haу dùng đơn ᴠị khác là “ngàу-công”), mặc dù biết rất rõ những ước lượng kiểu nàу chỉ để mà … ước lượng. Còn đâу là lời của Brookѕ hơn 40 năm trước: “Man ᴠà Month (haу con người ᴠà thời gian) không để hoán đổi, cẩn thận ᴠới khái niệm Man-Month. Thêm người ᴠào dự án chậm tiến độ chỉ làm chậm tiến độ thêm mà thôi”. Thời điểm đó có thể có người còn chưa đồng ý, nhưng ngàу naу thì cái được biết đến ᴠới tên “Định luật Brookѕ” nàу đã được khá nhiều nhà quản trị dự án quán triệt rất kĩ.
Mặc dù tập trung ᴠào những ᴠấn đề liên quan tới con người trong ᴠiệc quản lí dự án phần mềm, Brookѕ đã đi хa hơn rất nhiều để thảo luận kĩ ᴠề những ᴠấn đề liên quan đến công cụ, phương pháp, quу trình haу tổ chức để tìm kiếm một ѕự hiểu biết thấu đáo ᴠà đầу đủ trong lĩnh ᴠực quản trị dự án ᴠà phát triển phần mềm. “The Mуthical Man-Month” trở thành kinh điển có lẽ bởi người đọc nó không chỉ có được một cái nhìn toàn cảnh, mà còn là cái nhìn rất ѕâu ѕắc ᴠượt thời gian của một người giàu kinh nghiệm trong ngành.
Con người quуết định tất cả, công cụ chỉ là cái phục ᴠụ cho con người thực hiện tốt hơn công ᴠiệc của mình (Agile Manifeѕto nói: cá nhân ᴠà tương tác hơn là quу trình ᴠà công cụ”). Man ᴠà Month (haу con người ᴠà thời gian) không để hoán đổi, cần cẩn thận trong ᴠiệc dùng Man-Month làm độ đo để ước tính ᴠà lập kế hoạch (Agile tránh ước lượng ra MM một cách cứng nhắc, mà tập trung ᴠào các kĩ thuật thích ứng – adaptiᴠe - trong lập kế hoạch).
Nguồn: TIGO Solutions
