Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month
Last updated: April 19, 2024 Xem trên toàn màn hình
Recommended for you
- 01 Jul 2023
Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 922 - 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 774
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 676
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 667
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 631
- 01 Jun 2021 Bản thiết kế sơ bộ (Brief) là gì? 544
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 536
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 495
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 483
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 466
- 14 Aug 2022 Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 465
- 03 May 2022 Mô hình Hybrid Agile là gì? 451
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 446
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 400
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 392
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 378
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 373
- 12 May 2021 Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 358
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 352
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 319
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 297
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 275
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 243
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 232
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 231
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 216
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 216
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 206
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 205
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 192
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 186
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 162
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 160
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 160
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 151
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 147
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 140
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 138
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 123
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 93
- 14 Sep 2021 COQ (Cost of quality) áp dụng cho chất lượng phần mềm như thế nào? 88
- 11 Apr 2025 Dữ liệu sống – nền tảng cốt lõi cho sự sinh tồn và phát triển trong kỷ nguyên số 31
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:
Bảng phân phối tỷ lệ nguồn lực tham gia dự án phần mềm
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).
Tổng hợp
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Link copied!
Mới cập nhật