Ước lượng chi phí dự án phần mềm: 3 phương pháp và sai số

Ước lượng chi phí dự án phần mềm là việc đưa ra một khoảng giá trị kèm mức tin cậy, dựa trên ba nguồn độc lập và một nhật ký hiệu chuẩn. Một con số đơn lẻ không phải ước lượng; đó là một lời hứa chưa được kiểm chứng.

Tóm tắt nhanh

• Ước lượng phải là một khoảng, kèm giả định và mức tin cậy; con số đơn lẻ là cam kết trá hình.
• Ba nguồn độc lập: tương tự, tham số, và phân rã chi tiết. Tam giác hoá ba nguồn cho biết ước lượng có đáng tin không.
• Nón bất định hẹp dần theo giai đoạn; độ rộng của nón là thông tin, không phải điểm yếu.
• Hiệu chuẩn hệ số từ dữ liệu của chính bạn quan trọng hơn mọi bảng tham chiếu bên ngoài.
• Cam kết cần mức tin cậy, bộ đệm và dự phòng được ghi thành ba dòng riêng.

Ước lượng, mục tiêu, cam kết và công suất

Bốn từ này thường bị dùng lẫn, và việc lẫn lộn chúng là nguyên nhân phổ biến nhất khiến dự án phần mềm trễ.

Ước lượng là một dự báo dựa trên thông tin hiện có. Nó có thể sai, và nó phải nói rõ sai bao nhiêu.

Mục tiêu là con số bạn muốn đạt. Mục tiêu có thể do ngân sách hoặc thị trường quyết định, không do phân tích nỗ lực quyết định.

Cam kết là lời hứa có ràng buộc. Cam kết chỉ nên đưa ra khi mức tin cậy đủ cao và giả định đã được ghi lại.

Công suất là khả năng thực tế của đội trong một khoảng thời gian. Đây là giới hạn vật lý, không phải mục tiêu.

Lỗi điển hình là biến mục tiêu thành ước lượng: ngân sách có 60 đơn vị nên ước lượng được viết thành 58 đơn vị. Khi đó ước lượng không còn là dự báo mà là cách trình bày mục tiêu cho giống phân tích.

Cách tránh: viết hai dòng riêng — "ước lượng hiện tại với thông tin hiện có" và "mục tiêu cần đạt". Nếu hai dòng khác nhau, đó là thông tin cần thiết cho người ra quyết định.

Ba nguồn ước lượng và cách tam giác hoá

Ba nguồn dưới đây độc lập tương đối với nhau, nghĩa là sai số của nguồn này không tự động lặp lại ở nguồn khác. Khi ba nguồn cho kết quả gần nhau, ước lượng đáng tin hơn. Khi chúng lệch xa, chỗ lệch chính là chỗ cần điều tra.

Nguồn tương tự

Chọn hai đến ba dự án đã hoàn thành, ghi rõ khác biệt về quy mô, số tích hợp, số người dùng và mức độ quen thuộc của đội với công nghệ. Sau đó điều chỉnh theo từng khác biệt, không điều chỉnh một lần theo cảm nhận.

Giá trị của nguồn này nằm ở chỗ nó bắt bạn nhớ lại chi phí thật, không phải chi phí đã báo giá. Hai con số này thường khác nhau, và chỉ con số thứ nhất dùng được để ước lượng.

Nguồn tham số

Nguồn tham số dùng một biến đo được nhân với một hệ số. Ví dụ: số màn hình nhân với nỗ lực trung bình mỗi màn hình, hoặc số tích hợp nhân với nỗ lực trung bình mỗi tích hợp.

Điểm mạnh là tốc độ và tính nhất quán. Điểm yếu là hệ số dễ trở thành hộp đen. Một hệ số chỉ đáng tin khi bạn biết nó được tính từ bao nhiêu quan sát, trong điều kiện nào, và có còn đúng với đội hiện tại không.

Nguồn phân rã chi tiết

Chia phạm vi thành các việc nhỏ, ước lượng từng việc, rồi cộng lại. Nguồn này cho nhiều thông tin nhất nhưng cũng tốn thời gian nhất và dễ tạo cảm giác chính xác giả.

Cảm giác chính xác giả xuất hiện khi bạn cộng ba mươi con số nhỏ và tin vào tổng. Sai số của từng việc không triệt tiêu; chúng thường tương quan cùng chiều vì cùng chịu ảnh hưởng của những yếu tố như mức độ quen công nghệ hay chất lượng đặc tả.

Tam giác hoá

Sau khi có ba con số, đừng lấy trung bình. Hãy trả lời ba câu hỏi.

Câu thứ nhất: nguồn nào dựa trên dữ liệu thật gần nhất với dự án này? Câu thứ hai: nguồn nào bỏ sót hạng mục lớn nhất, và hạng mục đó là gì? Câu thứ ba: nếu chỉ dùng nguồn thấp nhất, điều gì phải đúng để nó đúng?

Nếu ba nguồn nằm trong một khoảng hẹp, bạn có thể trình bày khoảng đó với mức tin cậy cao hơn. Nếu một nguồn lệch hẳn, thường là nó đang bỏ qua một hạng mục mà hai nguồn kia đã tính, hoặc nó đang tính một phạm vi rộng hơn. Xác định được nguyên nhân lệch quan trọng hơn việc chọn con số.

Nón bất định và độ sâu phân rã

Nón bất định là cách mô tả mức độ không chắc chắn giảm dần khi dự án tiến triển. Ở giai đoạn đầu, khoảng ước lượng rất rộng vì nhiều thứ chưa biết. Khi phạm vi và thiết kế rõ hơn, khoảng hẹp lại.

Điều quan trọng là không giả vờ nón đã hẹp. Một ước lượng ở giai đoạn khám phá mà có khoảng rất hẹp không phải là ước lượng tốt; đó là dấu hiệu các giả định chưa được nêu ra.

Bảng này mô tả hướng đi, không phải tỷ lệ cố định. Điểm cần ghi nhớ: độ rộng của khoảng phải khớp với giai đoạn. Trình bày một khoảng hẹp ở giai đoạn sớm là cách nhanh nhất để mất uy tín khi dự án tiến triển.

Vì sao nón không hẹp tuyến tính

Nhiều người giả định rằng sau khi hoàn thành một nửa khối lượng, độ bất định còn một nửa. Thực tế phức tạp hơn, vì phần còn lại thường chứa những việc khó nhất: tích hợp với hệ thống bên ngoài, di trú dữ liệu, các trường hợp biên mà người dùng chỉ phát hiện khi dùng thật.

Vì vậy, khi đọc một báo cáo tiến độ, hãy hỏi phần còn lại gồm những gì. Nếu phần còn lại là những việc đã từng làm nhiều lần, nón hẹp nhanh. Nếu phần còn lại là những việc chưa từng làm, nón hẹp chậm hơn nhiều so với tỷ lệ khối lượng đã xong.

Phân rã công việc đến độ sâu nào

Câu hỏi thực dụng là chia nhỏ đến mức nào thì dừng. Chia quá thô thì ước lượng không dùng được; chia quá mịn thì tốn thời gian và tạo cảm giác chính xác giả.

Ba quy tắc dùng được.

Quy tắc ổn định. Chia cho đến khi việc nhỏ nhất không thể chia tiếp mà không đổi bản chất ước lượng. Nếu hai người ước lượng cùng một việc và ra hai con số khác nhau hơn một khoảng nhất định, việc đó còn quá thô.

Quy tắc một người một việc. Mỗi việc nhỏ nhất nên gắn với một vai trò cụ thể. Nếu một việc cần ba vai trò, nó là một nhóm việc và cần chia tiếp hoặc cần một dòng phối hợp riêng.

Quy tắc phần còn lại. Việc nhỏ nhất nên đủ nhỏ để có thể hoàn thành trong một nhịp báo cáo của đội. Nếu đội báo cáo theo tuần, việc lớn hơn một tuần sẽ không cho tín hiệu tiến độ đáng tin.

Điều cần tránh là phân rã thành danh sách giả định. Ví dụ: "màn hình danh sách đơn hàng — 2 đơn vị" mà không nói màn hình đó có bộ lọc, phân trang, xuất dữ liệu hay không. Một dòng như vậy không phải phân rã mà là một cách đặt tên cho phỏng đoán.

Hiệu chuẩn hệ số từ dữ liệu của chính bạn

Đây là phần tạo ra khác biệt lớn nhất giữa một ước lượng dùng được và một ước lượng chỉ để trình bày.

Bắt đầu bằng một nhật ký hiệu chuẩn. Với mỗi dự án hoặc mỗi nhóm việc đã xong, ghi bốn thứ: ước lượng ban đầu, thực tế, nguyên nhân chênh lệch chính, và loại việc. Nhật ký này chỉ cần một bảng, nhưng phải được cập nhật đều.

Sau vài dự án, bạn có thể tính tỷ lệ thực tế trên ước lượng cho từng loại việc. Nếu tỷ lệ này ổn định quanh một giá trị, bạn có một hệ số dùng được. Nếu tỷ lệ dao động rất rộng, nguyên nhân thường là cách phân loại chưa nhất quán hoặc phạm vi chưa được mô tả đủ rõ.

Ba lưu ý khi dùng hệ số tự hiệu chuẩn.

Thứ nhất, đừng hiệu chuẩn trên quá ít quan sát. Với hai ba dự án, bạn đang hiệu chuẩn theo may mắn.

Thứ hai, đừng hiệu chuẩn bằng cách nhân đôi mọi con số. Nếu mọi ước lượng đều thiếu theo cùng một tỷ lệ, vấn đề có thể nằm ở định nghĩa phạm vi chứ không ở nỗ lực.

Thứ ba, ghi lại điều kiện của từng quan sát. Một hệ số tính trong điều kiện đội quen công nghệ sẽ không đúng khi đội vừa chuyển sang nền tảng mới.

Từ ước lượng đến cam kết

Ước lượng trả lời câu hỏi "sẽ tốn bao nhiêu". Cam kết trả lời câu hỏi "chúng ta hứa giao khi nào". Hai câu này cần hai cách trình bày khác nhau.

Mức tin cậy

Mỗi cam kết nên kèm một mức tin cậy. Cách nói thực dụng: "với các giả định đã ghi, chúng ta có khoảng tám phần mười khả năng hoàn thành trong khoảng này". Con số cụ thể không quan trọng bằng việc có nêu ra và có nhất quán giữa các dự án.

Khi không có dữ liệu hiệu chuẩn, hãy dùng ngôn ngữ định tính có ba mức: khả năng cao, khả năng trung bình, chưa đủ thông tin để nói. Tránh trình bày một con số duy nhất như thể nó đã được kiểm chứng.

Bộ đệm và dự phòng

Ba khái niệm thường bị gộp, và việc gộp chúng làm mất khả năng kiểm soát.

Bộ đệm là phần cộng thêm vào từng việc để bù sai số ước lượng thông thường. Bộ đệm nên dựa trên nhật ký hiệu chuẩn.

Dự phòng là phần dành cho những rủi ro đã được nêu tên nhưng chưa biết có xảy ra hay không, ví dụ một tích hợp có thể không có môi trường thử. Dự phòng nên gắn với từng rủi ro, không phải một tỷ lệ chung.

Độn là phần cộng thêm không có căn cứ, thường xuất hiện khi người ước lượng bị áp lực phải hứa một con số thấp hơn thực tế. Độn là dấu hiệu của một quy trình ước lượng đang hỏng, không phải một kỹ năng.

Cách trình bày tốt là ba dòng riêng trong bảng ngân sách: nỗ lực cơ sở, bộ đệm, dự phòng theo rủi ro. Người ra quyết định nhìn thấy từng phần và biết mình đang quyết định điều gì.

Điều kiện để cam kết có hiệu lực

Một cam kết chỉ có hiệu lực khi ba điều kiện đúng: phạm vi đã được đặc tả ở mức kiểm chứng được, giả định đã được ghi thành văn bản, và có cơ chế xử lý khi giả định sai.

Nếu thiếu điều kiện thứ ba, cam kết sẽ trở thành tranh chấp. Cơ chế xử lý nên ghi rõ: ai phát hiện, ai phê duyệt điều chỉnh, thời hạn phản hồi, và cách tính phần phát sinh.

Chi phí ngoài nỗ lực phát triển

Ước lượng nỗ lực phát triển chưa phải ước lượng chi phí dự án. Có những hạng mục không nằm trong nỗ lực của đội nhưng vẫn là tiền bạn phải trả.

Về dòng cuối, đây là điểm thường bị bỏ qua khi lập ngân sách. Phần mềm thuộc nhóm hàng hoá dịch vụ không chịu thuế giá trị gia tăng, nên thuế đầu vào của hoạt động phát triển thường không được khấu trừ và trở thành chi phí thật. Cách xác định và hệ quả được trình bày trong thuế GTGT của phần mềm là bao nhiêu; bài viết này không phải tư vấn thuế.

Một ước lượng tốt có thể mở lại được

Ước lượng không phải bản án. Nó là một kết luận dựa trên giả định, và khi giả định thay đổi, kết luận phải được xem lại.

Ba dấu hiệu của một ước lượng mở lại được.

Giả định được viết thành danh sách. Mỗi giả định có thể kiểm tra đúng sai. "Hệ thống cũ có tài liệu API" là một giả định kiểm tra được; "mọi thứ suôn sẻ" thì không.

Có điều kiện kích hoạt xem lại. Ghi rõ sự kiện nào buộc phải ước lượng lại: phạm vi tăng quá một ngưỡng, một tích hợp không có môi trường thử, dữ liệu có quá nhiều bản ghi trùng.

Có bản ghi lịch sử. Mỗi lần ước lượng lại, giữ lại bản cũ kèm lý do thay đổi. Không có lịch sử, bạn không hiệu chuẩn được và cũng không giải thích được với người ra quyết định.

Điều này quan trọng vì ước lượng phần mềm gắn chặt với thông tin. Khi thông tin tăng, ước lượng đổi là dấu hiệu của quy trình tốt, không phải dấu hiệu của đội yếu. Vấn đề chỉ xuất hiện khi ước lượng đổi mà không ai biết vì sao.

Năm lỗi làm ước lượng mất giá trị

1. Ước lượng sau khi đã có mục tiêu. Khi con số mục tiêu được biết trước, ước lượng có xu hướng hội tụ về đó. Cách tránh là yêu cầu ước lượng độc lập trước khi công bố ngân sách, hoặc ít nhất ghi lại cả hai con số.
2. Bỏ qua chi phí phối hợp. Ước lượng chỉ tính thời gian viết code, không tính thời gian họp, làm rõ, chờ phê duyệt, sửa lại. Với dự án có nhiều bên, phần này có thể lớn hơn dự kiến.
3. Dùng hệ số ngoài không hiệu chuẩn. Hệ số từ một báo cáo ngành không phản ánh đội của bạn, công nghệ của bạn và khách hàng của bạn.
4. Cộng dồn sai số như thể chúng triệt tiêu. Sai số của các việc nhỏ thường cùng chiều, nên tổng sai số lớn hơn cảm giác khi cộng từng dòng.
5. Không ghi lại thực tế. Không có số thực tế thì không có hiệu chuẩn, và mọi ước lượng sau vẫn là phỏng đoán có hình thức đẹp.

Nếu bạn muốn hiểu rõ hơn các khái niệm nền, bài ước lượng phần mềm là gì trình bày định nghĩa và các thành phần của một ước lượng, còn ước lượng giá thành phần mềm đi vào cách hình thành giá từ nỗ lực. Bức tranh tổng thể về các hạng mục chi phí nằm trong chi phí phát triển phần mềm, và phần thuế được trình bày trong thuế GTGT của phần mềm là bao nhiêu.

Câu hỏi thường gặp

Ước lượng nên do ai thực hiện?

Do người trực tiếp làm việc, không phải quản lý dự án làm thay: người làm biết chi tiết quyết định nỗ lực, và việc tự ước lượng tạo trách nhiệm với con số. Quản lý dự án tổng hợp, kiểm tra tính nhất quán và ghi lại giả định.

Có nên dùng điểm chức năng hay story point không?

Cả hai đều là cách đo tương đối và dùng được nếu nhất quán. Điều quan trọng không phải đơn vị mà là hiệu chuẩn đơn vị đó với thời gian thực tế của đội bạn: một đơn vị phức tạp nhưng không hiệu chuẩn kém chính xác hơn một đơn vị đơn giản có nhật ký.

Bao nhiêu dự án thì hiệu chuẩn được?

Cần đủ quan sát để phân biệt sai số hệ thống với may mắn, và điều đó phụ thuộc vào mức độ đa dạng của công việc. Với công việc lặp lại tương tự, vài dự án có thể đủ để thấy xu hướng. Với công việc đa dạng, cần nhiều hơn, và nên hiệu chuẩn theo loại việc thay vì theo toàn bộ dự án.

Khi nào nên ước lượng lại?

Khi một giả định lớn bị sai, khi phạm vi thay đổi quá ngưỡng đã thoả thuận, hoặc khi phát hiện một hạng mục chưa được tính. Không nên ước lượng lại chỉ vì tiến độ chậm; chậm tiến độ là dữ liệu để hiệu chuẩn, không phải lý do đổi con số.

Ước lượng chênh lệch bao nhiêu là bình thường?

Không có con số chung đúng cho mọi dự án. Điều nên theo dõi là xu hướng: ước lượng của bạn có lệch cùng một hướng qua nhiều dự án không, và mức lệch có ổn định không. Một mức lệch ổn định có thể hiệu chuẩn được; một mức lệch dao động rộng cho thấy vấn đề nằm ở cách mô tả phạm vi.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo thông lệ ước lượng và quản trị dự án phần mềm hiện hành; bài viết không sử dụng số liệu thống kê bên ngoài và không đưa ra con số tiền cụ thể cho bất kỳ dự án nào.

Nếu bạn cần một ước lượng có giả định rõ ràng và có thể mở lại, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.