Chi phí phát triển phần mềm: 6 yếu tố quyết định giá

Chi phí phát triển phần mềm được quyết định bởi sáu yếu tố: số luồng nghiệp vụ, số tích hợp, chất lượng dữ liệu, độ sâu kiểm thử, yêu cầu tuân thủ và tốc độ thay đổi. Mỗi yếu tố nhân lên khối lượng nỗ lực, nên không có con số trung bình dùng được cho mọi dự án.

Tóm tắt nhanh

• Giá phần mềm là hàm của phạm vi, không phải một bảng giá theo loại sản phẩm.
• Sáu yếu tố chi phí không cộng vào nhau mà nhân với nhau; đó là lý do hai dự án cùng số tính năng vẫn chênh nhau nhiều lần.
• Ước lượng có ba phương pháp với ba mức sai số khác nhau; dùng sai phương pháp ở sai giai đoạn là nguồn gốc của thất vọng.
• Chi phí sở hữu sau bàn giao thường bị bỏ khỏi quyết định mua, dù nó tích luỹ theo thời gian.
• Cách duy nhất để so sánh hai báo giá là chuẩn hoá chúng về cùng một phạm vi và cùng một bộ giả định.

Chi phí phát triển phần mềm được cấu thành từ đâu

Chi phí phát triển phần mềm là tổng khối lượng nỗ lực cần thiết để biến một phạm vi đã mô tả thành hệ thống chạy được, cộng với chi phí quản lý và chi phí rủi ro mà bên nhận việc phải gánh. Ba thành phần này xuất hiện trong mọi báo giá, nhưng thường chỉ thành phần thứ nhất được nhìn thấy.

Thành phần thứ nhất là nỗ lực xây dựng: phân tích, viết mã, kiểm thử, tài liệu. Đây là phần dễ hình dung nhất và cũng là phần bị ước lượng thấp nhất, vì người mua thường chỉ đếm số màn hình.

Thành phần thứ hai là chi phí quản lý: điều phối, họp, rà soát, quản lý thay đổi, báo cáo. Phần này thường chiếm một tỷ lệ đáng kể trong dự án có nhiều bên liên quan, và nó tăng khi phía doanh nghiệp không có một người đại diện đủ thẩm quyền.

Thành phần thứ ba là chi phí rủi ro: khoản dự phòng cho những điều chưa biết. Trong hợp đồng theo kết quả, khoản này do bên nhận việc giữ và được tính vào giá. Trong hợp đồng theo thời gian, khoản này do doanh nghiệp giữ dưới dạng phát sinh.

Hiểu ba thành phần này giúp bạn đọc một báo giá đúng cách: một báo giá chỉ có phần thứ nhất thường là báo giá chưa tính đủ, và phần thiếu sẽ quay lại dưới dạng thay đổi phạm vi.

Vì sao không có "giá trung bình" cho một ứng dụng

Câu hỏi "làm một ứng dụng quản lý bán hàng tốn bao nhiêu" không trả lời được vì nó thiếu ba thông tin: quy trình nào phải thay đổi, dữ liệu hiện có ở đâu và ai sẽ dùng hệ thống. Cùng một câu mô tả có thể dẫn tới hai dự án chênh nhau nhiều lần về khối lượng nỗ lực, và cả hai đều có thể đúng với phạm vi của nó.

Đây là lý do các bài viết đưa ra một con số duy nhất cho "chi phí làm app" thường chỉ có giá trị tham khảo rất thấp. Con số đó không nói gì về sáu yếu tố dưới đây, và chính sáu yếu tố này mới là thứ bạn kiểm soát được.

Sáu yếu tố quyết định giá

Bảng dưới đây tóm tắt sáu yếu tố, cách mỗi yếu tố đẩy chi phí lên, và dấu hiệu nhận ra nó trong một báo giá.

1. Số luồng nghiệp vụ và số ngoại lệ

Một luồng nghiệp vụ là một chuỗi hành động có điểm bắt đầu, điểm kết thúc và các điều kiện rẽ nhánh. Chi phí không tỷ lệ với số luồng mà tỷ lệ với số nhánh trạng thái trong mỗi luồng.

Ví dụ, "tạo đơn hàng" nghe như một chức năng. Nhưng nếu đơn hàng có thể ở trạng thái nháp, chờ duyệt, đã duyệt, đang giao, đã giao, huỷ một phần và trả hàng, thì đó là bảy trạng thái với hàng chục đường chuyển hợp lệ và không hợp lệ. Mỗi đường chuyển cần được xử lý, phân quyền và kiểm thử.

Cách kiểm soát thực dụng: với mỗi luồng, liệt kê các trạng thái và đánh dấu trạng thái nào thực sự xảy ra trong một tháng bình thường. Các trạng thái hiếm dùng nên được đưa vào phiên bản sau. Việc cắt này thường giảm đáng kể khối lượng mà không ảnh hưởng tới vận hành hằng ngày.

2. Số tích hợp bên thứ ba

Mỗi tích hợp không chỉ là một lời gọi kỹ thuật. Nó gồm xác thực, xử lý lỗi, thử lại, ghi log, đối soát dữ liệu hai chiều và một kịch bản khi bên thứ ba ngừng hoạt động. Một tích hợp thanh toán có thể tốn nỗ lực tương đương vài luồng nghiệp vụ thông thường, vì nó phải xử lý các trường hợp giao dịch treo và hoàn tiền.

Cách kiểm soát: chốt danh sách hệ thống phải tích hợp trước khi ký, kèm theo việc bên nào cung cấp tài liệu kỹ thuật và tài khoản thử. Một tích hợp chưa có tài liệu là một rủi ro chưa đo được, và nó thường xuất hiện dưới dạng phát sinh.

3. Chất lượng dữ liệu cũ

Nếu hệ thống mới phải dùng dữ liệu từ hệ thống cũ, chất lượng dữ liệu trở thành yếu tố chi phí lớn. Dữ liệu trùng lặp, thiếu trường bắt buộc, sai định dạng hoặc không có khoá duy nhất đều phải xử lý trước khi di trú, và mỗi loại lỗi cần một quy tắc riêng.

Cách kiểm soát: khảo sát dữ liệu trước khi báo giá. Một bước khảo sát tốt trả lời được bốn câu: có bao nhiêu bản ghi, bao nhiêu bản ghi thiếu trường bắt buộc, có khoá duy nhất không, và ai trong doanh nghiệp xác nhận dữ liệu nào là đúng. Không có câu trả lời cho câu cuối, dự án sẽ dừng ở bước di trú.

4. Độ sâu kiểm thử và yêu cầu phi chức năng

Kiểm thử tự động tốn nỗ lực ở giai đoạn đầu và tiết kiệm ở giai đoạn sau. Với hệ thống ít thay đổi, kiểm thử thủ công có thể đủ. Với hệ thống thay đổi hằng tuần, thiếu kiểm thử tự động khiến mỗi lần sửa là một lần rủi ro, và chi phí kiểm thử lại tăng dần.

Yêu cầu phi chức năng cũng là yếu tố chi phí: ngưỡng thời gian phản hồi, số người dùng đồng thời, khả năng chạy ngoại tuyến, yêu cầu về sao lưu và phục hồi. Mỗi ngưỡng cụ thể đều kéo theo công việc đo lường và tối ưu. Một yêu cầu ghi "hệ thống phải nhanh" không tốn gì vì nó không đo được; một yêu cầu ghi "trang danh sách trả kết quả dưới hai giây với mười nghìn bản ghi" tốn nỗ lực thật.

5. Yêu cầu tuân thủ và bảo mật

Nếu hệ thống xử lý dữ liệu cá nhân, dữ liệu thanh toán hoặc dữ liệu thuộc ngành được quản lý, sẽ có thêm công việc: phân quyền chi tiết, ghi vết truy cập, mã hoá dữ liệu nhạy cảm, chính sách lưu trữ và xoá, và báo cáo cho người có trách nhiệm. Phần này thường bị bỏ khỏi báo giá ban đầu vì nó không nằm trong danh sách tính năng.

Cách kiểm soát: phân loại yêu cầu thành hai nhóm ngay từ giai đoạn khám phá. Nhóm bắt buộc là những gì pháp luật hoặc hợp đồng với khách hàng yêu cầu. Nhóm mong muốn là những gì tốt cho vận hành nhưng có thể làm sau. Trộn hai nhóm này làm chi phí tăng mà không rõ vì sao.

6. Tốc độ thay đổi yêu cầu

Đây là yếu tố ít được đưa vào báo giá nhất và ảnh hưởng nhiều nhất. Cùng một yêu cầu, nếu đặt ở giai đoạn khám phá thì gần như miễn phí, nếu đặt sau khi đã kiểm thử thì là một vòng làm lại, và nếu đặt sau khi bàn giao thì là một dự án nhỏ.

Cách kiểm soát không phải là cấm thay đổi, mà là làm cho chi phí thay đổi nhìn thấy được. Ba công cụ: cổng phê duyệt theo giai đoạn, mẫu yêu cầu thay đổi có phần ước lượng nỗ lực, và một buổi rà soát phạm vi định kỳ để gom các thay đổi nhỏ thành một đợt.

Một mô hình minh hoạ: từ phạm vi ra khối lượng nỗ lực

Phần này là một mô hình minh hoạ để bạn thấy cách các yếu tố nhân lên. Nó không phải báo giá và không dùng đơn vị tiền tệ; mọi con số là đơn vị nỗ lực tương đối.

Giả sử bạn cần một hệ thống quản lý bán hàng nội bộ với các thành phần sau: 8 luồng nghiệp vụ cơ bản, 2 luồng có bước duyệt nhiều cấp, 3 tích hợp bên thứ ba, 6 báo cáo, và 3 nhóm vai trò người dùng.

Bước một là ước lượng khối lượng gốc theo từng loại thành phần:

Bước hai là áp các hệ số điều chỉnh theo bốn yếu tố còn lại. Mỗi hệ số phản ánh mức độ phức tạp so với một dự án "sạch" có dữ liệu tốt, kiểm thử cơ bản và phạm vi ổn định.

Khối lượng điều chỉnh được tính bằng phép nhân, không phải phép cộng: 140 × 1,15 × 1,20 × 1,10 × 1,20 ≈ 255 đơn vị nỗ lực. Con số này gần gấp đôi khối lượng gốc, và đó chính là điểm mà phần lớn ước lượng ban đầu bỏ sót.

Đọc kết quả mô hình đúng cách

Mô hình trên không nói dự án tốn bao nhiêu tiền. Nó nói ba điều hữu ích hơn.

Thứ nhất, giảm một hệ số hiệu quả hơn giảm một thành phần. Bỏ một báo cáo giảm 4 đơn vị; đưa dữ liệu cũ về trạng thái sạch trước khi bắt đầu có thể đưa hệ số 1,15 về 1,00 và giảm hơn 30 đơn vị trên tổng.

Thứ hai, các hệ số nhân với nhau, nên một dự án có ba yếu tố phức tạp cùng lúc không khó gấp ba mà khó hơn nhiều. Đây là lý do các dự án "vừa tích hợp thanh toán, vừa di trú dữ liệu cũ, vừa phải tuân thủ" thường vượt dự toán nhiều hơn các dự án đơn giản.

Thứ ba, ước lượng chỉ đúng khi phạm vi đứng yên. Nếu phạm vi thay đổi trong lúc xây dựng, hệ số cuối cùng sẽ khác 1,20. Đây là lý do hợp đồng cần một cơ chế tính lại khối lượng khi phạm vi thay đổi, thay vì một con số cố định được hiểu là bất biến.

Nếu bạn muốn thấy mô hình này áp cho từng loại sản phẩm, bài chi phí phát triển ứng dụng so sánh ba nhóm ứng dụng web, di động và nội bộ theo cùng bộ yếu tố.

Ba phương pháp ước lượng và sai số thật của chúng

Không có phương pháp ước lượng nào đúng tuyệt đối. Mỗi phương pháp có một mức sai số điển hình, và sai số đó phụ thuộc vào việc bạn đang ở giai đoạn nào của dự án.

Ba điều cần nhớ khi đọc một con số ước lượng.

Một là, sai số không đối xứng. Ước lượng thiếu phổ biến hơn ước lượng thừa, vì các trường hợp ngoại lệ và việc phối hợp thường không được tính. Khi một báo giá trông rất hấp dẫn, câu hỏi đúng là "phần nào chưa được tính", không phải "vì sao rẻ thế".

Hai là, sai số giảm khi phạm vi rõ. Cùng một đơn vị làm, ước lượng ở giai đoạn chưa có đặc tả và ước lượng sau khi đặc tả xong là hai con số khác nhau về bản chất. So sánh chúng với nhau là so sánh hai mức độ hiểu biết khác nhau, không phải hai năng lực khác nhau.

Ba là, một ước lượng không kèm giả định thì không kiểm tra được. Một ước lượng tốt ghi rõ: giả định bao nhiêu luồng, bao nhiêu tích hợp, dữ liệu ở mức nào, kiểm thử ở mức nào. Khi giả định sai, bạn biết ngay phần nào cần tính lại.

Đọc một báo giá: cái gì phải xuất hiện

Một báo giá dùng được không cần dài, nhưng phải có đủ các mục dưới đây. Nếu thiếu ba mục trở lên, bạn đang so sánh những lời chào hàng.

Điều đáng chú ý là ba mục cuối thường nằm ngoài báo giá nhưng lại là chi phí thật của năm đầu tiên. Một báo giá chỉ có phần xây dựng sẽ khiến bạn so sánh sai, vì nó bỏ qua phần vận hành.

Chi phí sở hữu sau bàn giao

Một hệ thống đang chạy phát sinh chi phí liên tục. Những chi phí này không xuất hiện trong báo giá ban đầu và thường bị đánh giá thấp khi quyết định mua.

Một cách nhìn hữu ích: chi phí sở hữu là chỉ số phản ánh chất lượng của quyết định kiến trúc ban đầu. Một kiến trúc tệ không làm dự án đắt hơn ngày hôm nay, nhưng làm mỗi thay đổi sau này đắt hơn. Đây là lý do các quyết định kỹ thuật không chỉ là chuyện của đội phát triển.

Năm cách làm chi phí tăng mà không ai thấy

1. Đếm màn hình thay vì đếm trạng thái. Một màn hình có bảy trạng thái không phải một màn hình.
2. Bỏ qua khảo sát dữ liệu. Chi phí làm sạch dữ liệu xuất hiện sau khi phần lớn ngân sách đã dùng.
3. Để phạm vi mở trong giai đoạn xây dựng. Mỗi yêu cầu nhỏ được thêm mà không tính lại khối lượng.
4. Không có người đại diện sản phẩm. Quyết định bị trì hoãn, đội phát triển chờ, và thời gian chờ vẫn tính vào tiến độ.
5. Không tính chi phí vận hành vào quyết định mua. Hệ thống chạy được nhưng không ai trả cho việc giám sát và sao lưu.

Năm điểm này không phải lỗi kỹ thuật. Chúng là lỗi trong cách mô tả phạm vi và cách ra quyết định, và chúng có thể sửa được trước khi ký hợp đồng.

Nếu bạn cần bóc tách chi phí theo từng giai đoạn thay vì theo yếu tố, bài chi phí làm phần mềm trình bày cách chia ngân sách theo bốn giai đoạn và cách đặt cổng kiểm soát. Phần thuế và cách xác định loại hàng hoá của dịch vụ phần mềm được trình bày trong bài thuế GTGT của phần mềm là bao nhiêu, vì thuế làm thay đổi tổng chi phí thực tế của dự án.

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

Vì sao hai báo giá cho cùng một mô tả lại chênh nhau nhiều?

Thường vì hai báo giá không cùng phạm vi. Một bên tính cả đặc tả, kiểm thử và bàn giao; bên kia chỉ tính phần viết mã. Ngoài ra, khác biệt về giả định dữ liệu, mức kiểm thử và cách xử lý thay đổi cũng tạo ra chênh lệch lớn. Muốn so sánh, phải chuẩn hoá hai báo giá về cùng danh sách hạng mục và cùng bộ giả định.

Chi phí phát triển phần mềm có giảm nếu dùng AI không?

AI có thể giảm nỗ lực ở một số loại việc như viết mã mẫu, viết kiểm thử và tra cứu tài liệu, nhưng không giảm nỗ lực ở phần hiểu nghiệp vụ, quyết định kiến trúc và nghiệm thu. Nó cũng thêm một khoản chi phí mới là rà soát đầu ra. Tác động thực tế phụ thuộc vào quy trình rà soát, không phụ thuộc vào công cụ.

Nên dự phòng bao nhiêu phần trăm cho phát sinh?

Không có tỷ lệ chung đúng cho mọi dự án. Mức dự phòng hợp lý phụ thuộc vào độ rõ của phạm vi, số tích hợp và chất lượng dữ liệu. Cách làm thực dụng là ước lượng theo từng yếu tố như mô hình ở trên, rồi ghi rõ giả định nào chưa được kiểm chứng; phần dự phòng nên gắn với các giả định đó chứ không phải một con số áp đặt.

Ước lượng ở giai đoạn nào là đáng tin nhất?

Đáng tin nhất là sau khi có đặc tả và tiêu chí nghiệm thu, vì khi đó khối lượng công việc đã được chia tới mức kiểm tra được. Trước giai đoạn đặc tả, mọi con số chỉ nên dùng để quyết định có nên tiếp tục khám phá hay không, không nên dùng để chốt ngân sách.

Chi phí phát triển phần mềm có bao gồm chi phí vận hành không?

Thông thường không. Báo giá phát triển chỉ gồm việc tạo ra hệ thống và bàn giao. Chi phí vận hành gồm hạ tầng, giám sát, sao lưu, cập nhật bảo mật và sửa lỗi là một hạng mục riêng. Hãy hỏi rõ chi phí này trước khi ký, vì nó là khoản chi đều đặn trong suốt thời gian hệ thống còn chạy.

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

Cập nhật tháng 10/2026. Nội dung được rà soát theo thông lệ ước lượng và cấu trúc chi phí phát triển phần mềm hiện hành; mọi con số trong bài là mô hình minh hoạ, không phải báo giá.

Nếu bạn đang cần một ước lượng dựa trên phạm vi thật thay vì một con số tham khảo, WinSell xây dựng phần mềm theo yêu cầu và chốt phạm vi trước khi báo giá — xem dịch vụ của WinSell để biết từng giai đoạn tạo ra đầu ra gì. Báo giá sau khi chốt phạm vi.