Chi phí làm phần mềm: bóc tách theo giai đoạn thay vì một con số

Chi phí làm phần mềm nên bóc tách theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường thay vì gộp thành một con số. Cách chia này cho biết tiền đi vào đâu, đặt cổng dừng sau mỗi giai đoạn và tránh khoá ngân sách vào một phạm vi chưa kiểm chứng.

Tóm tắt nhanh

• Một con số tổng không cho bạn biết phần nào đã chắc, phần nào còn là giả định.
• Nỗ lực phân bổ không đều: phần xây dựng thường chiếm phần lớn, nhưng phần khám phá và đặc tả quyết định phần lớn chi phí đó.
• Mỗi giai đoạn nên có một cổng ngân sách: chỉ giải ngân cho giai đoạn sau khi đầu ra của giai đoạn trước được kiểm chứng.
• Khi một giai đoạn vượt dự toán, có bốn lựa chọn; chọn sai thường dẫn tới việc tiếp tục chi cho một hướng đã sai.

Vì sao một con số tổng không dùng được

Khi hỏi "làm phần mềm này tốn bao nhiêu", câu trả lời thường là một con số duy nhất. Con số đó có ba vấn đề.

Thứ nhất, nó trộn phần đã biết với phần chưa biết. Phần khám phá gần như chắc chắn về khối lượng; phần xây dựng phụ thuộc vào kết quả đặc tả; phần vận hành phụ thuộc vào lưu lượng thực tế. Gộp ba loại rủi ro khác nhau vào một con số khiến bạn không biết nên dự phòng ở đâu.

Thứ hai, nó không có cổng dừng. Nếu toàn bộ ngân sách được cam kết từ đầu, bạn mất quyền dừng khi phát hiện hướng đi sai. Trong khi đó, quyền dừng sớm là công cụ kiểm soát chi phí mạnh nhất mà người mua có.

Thứ ba, nó không so sánh được. Hai báo giá cùng một con số tổng có thể phân bổ rất khác nhau: một bên dồn nỗ lực vào đặc tả, bên kia dồn vào viết mã. Chỉ khi nhìn theo giai đoạn, bạn mới thấy khác biệt đó.

Cách làm thay thế không phức tạp: chia ngân sách theo bốn giai đoạn, gắn mỗi giai đoạn với một đầu ra kiểm chứng được, và chỉ quyết định giải ngân giai đoạn sau khi đầu ra giai đoạn trước được xác nhận.

Phân bổ nỗ lực theo bốn giai đoạn

Tỷ lệ dưới đây là mức tham khảo từ thông lệ dự án phần mềm, không phải quy tắc cố định. Điều quan trọng không phải con số chính xác mà là thứ tự: giai đoạn nào tốn nỗ lực, và nỗ lực đó mua được gì.

Khám phá: 5–10% nhưng quyết định hướng đi

Giai đoạn khám phá tốn ít nỗ lực nhất và có đòn bẩy lớn nhất. Mục tiêu là hiểu bài toán trước khi nói tới giải pháp: quy trình hiện tại chạy thế nào, ai là người dùng, điểm nghẽn nằm ở đâu, thành công được đo bằng gì.

Đầu ra cần có: bản đồ quy trình hiện tại, danh sách bên liên quan, danh sách điểm nghẽn và tiêu chí thành công đo được. Giai đoạn này kết thúc bằng một quyết định rõ: có nên làm phần mềm hay không, và nếu có thì phạm vi phiên bản đầu là gì.

Tỷ lệ này tăng khi quy trình chưa từng được viết ra và khi có nhiều bên liên quan với mục tiêu khác nhau. Trong trường hợp đó, khám phá không chỉ là ghi lại quy trình mà còn là hoà giải các cách hiểu.

Đặc tả: 10–20% và là nơi chi phí được quyết định

Đặc tả biến hiểu biết thành thứ kiểm tra được. Đầu ra gồm yêu cầu chức năng, yêu cầu phi chức năng, mô hình dữ liệu và tiêu chí nghiệm thu cho từng luồng chính.

Đây là giai đoạn có tỷ lệ hoàn vốn cao nhất trong toàn dự án. Một lỗi phát hiện ở đặc tả tốn một buổi làm việc; cùng lỗi đó phát hiện sau khi kiểm thử tốn một vòng làm lại; phát hiện sau bàn giao tốn một dự án nhỏ. Vì vậy, cắt ngân sách đặc tả để "tiết kiệm" là cách chắc chắn nhất để chi nhiều hơn ở giai đoạn sau.

Tỷ lệ này tăng khi có nhiều ngoại lệ nghiệp vụ, khi hệ thống phải tích hợp với bên thứ ba, hoặc khi có yêu cầu tuân thủ cần ghi thành tiêu chí kiểm tra.

Xây dựng: 55–70% và là nơi dễ mất kiểm soát nhất

Đây là giai đoạn tốn nhiều nỗ lực nhất: viết mã, viết kiểm thử, dựng môi trường thử, sửa lỗi phát hiện trong quá trình làm. Tỷ lệ này phản ánh thực tế rằng phần lớn công việc kỹ thuật nằm ở đây, không phải ở tài liệu.

Điều cần kiểm soát trong giai đoạn này không phải số giờ mà là nhịp giao hàng. Một đội giao bản dựng mới mỗi hai tuần cho bạn khả năng phát hiện lệch hướng sớm. Một đội chỉ báo cáo bằng văn bản khiến bạn phát hiện lệch hướng khi phần lớn nỗ lực đã tiêu.

Tỷ lệ này tăng khi phạm vi thay đổi trong lúc xây dựng, khi dữ liệu cũ cần xử lý, hoặc khi yêu cầu hiệu năng đòi hỏi tối ưu. Ba nguyên nhân này thường xuất hiện cùng lúc, và đó là lý do giai đoạn xây dựng là nơi dự toán hay bị vượt nhất.

Bàn giao và đo lường: 10–15% nhưng quyết định chi phí dài hạn

Giai đoạn cuối gồm tài liệu vận hành, quyền truy cập hạ tầng, buổi chuyển giao tri thức và bộ chỉ số theo dõi sau ra mắt. Tỷ lệ nỗ lực không lớn, nhưng thiếu giai đoạn này thì mọi chi phí trước đó trở nên khó thu hồi, vì không ai vận hành được hệ thống.

Đầu ra cần có: tài liệu kiến trúc, hướng dẫn triển khai, quy trình sao lưu và phục hồi đã thử, tài khoản hạ tầng đứng tên doanh nghiệp, và một buổi chuyển giao có bản ghi.

Cổng ngân sách: giải ngân theo đầu ra, không theo lịch

Một cổng ngân sách là một điểm dừng có ba câu hỏi: đầu ra của giai đoạn trước có đạt không, giai đoạn sau có còn đúng hướng không, và ngân sách còn lại có đủ cho giai đoạn sau không. Chỉ khi cả ba câu trả lời là có, bạn mới giải ngân tiếp.

Cổng thứ ba, giữa giai đoạn xây dựng, thường bị bỏ. Đây là cổng quan trọng nhất về mặt chi phí, vì nó là điểm cuối cùng mà việc cắt phạm vi còn rẻ. Sau khi hệ thống đã kiểm thử toàn bộ, cắt phạm vi không còn tiết kiệm nhiều vì phần lớn nỗ lực đã tiêu.

Một ví dụ minh hoạ phân bổ ngân sách

Phần này là mô hình minh hoạ, không phải báo giá. Đơn vị là đơn vị ngân sách tương đối, không phải tiền.

Giả sử bạn có 100 đơn vị ngân sách cho một hệ thống nội bộ và áp tỷ lệ ở trên. Cách phân bổ ban đầu có thể là: 8 cho khám phá, 15 cho đặc tả, 65 cho xây dựng, 12 cho bàn giao. Nhưng cách phân bổ này chỉ đúng nếu không có gì bất ngờ.

Giả sử sau giai đoạn đặc tả, bạn phát hiện hai điều: dữ liệu cũ có nhiều bản ghi trùng, và một tích hợp bên thứ ba không có tài liệu kỹ thuật. Hai phát hiện này làm tăng nỗ lực xây dựng. Bạn có ba lựa chọn, và mỗi lựa chọn có hệ quả khác nhau.

Lựa chọn cuối là lựa chọn phổ biến nhất và cũng tệ nhất, vì nó lấy ngân sách của giai đoạn bàn giao để bù cho giai đoạn xây dựng. Kết quả là hệ thống chạy được nhưng không ai vận hành được, và chi phí đó xuất hiện sau khi hợp đồng kết thúc.

Vì sao chia đợt thường là lựa chọn tốt nhất

Chia đợt giữ được cả phạm vi lẫn ngân sách bằng cách thay đổi thứ tự. Đợt một gồm những gì chắc chắn và tạo ra giá trị sớm; đợt hai gồm những gì phụ thuộc vào kết quả đợt một. Cách này có ba lợi ích.

Một là, bạn có sản phẩm dùng được sớm hơn, nên phản hồi từ người dùng đến trước khi phần lớn ngân sách đã tiêu.

Hai là, mỗi đợt có phạm vi cố định riêng, nên ước lượng chính xác hơn một dự án lớn duy nhất.

Ba là, bạn có quyền dừng sau đợt một nếu giá trị không như kỳ vọng, và quyền đó có giá trị thực tế cao hơn một khoản dự phòng.

Khi một giai đoạn vượt dự toán

Vượt dự toán ở một giai đoạn không tự động là thất bại. Nó là thông tin: một giả định nào đó sai. Cách xử lý phụ thuộc vào việc giả định nào sai và sai ở mức nào.

Điểm chung của bốn cách xử lý sai: chúng đều chuyển chi phí sang một thời điểm muộn hơn, nơi bạn ít đòn bẩy hơn. Ép viết đặc tả nhanh hơn làm tăng rủi ro nghiệm thu. Bỏ qua làm sạch dữ liệu làm hệ thống mới mang theo lỗi cũ. Thêm yêu cầu mà không tính lại khối lượng làm mất khả năng dự báo. Ký nghiệm thu khi chưa có tài liệu làm bạn phụ thuộc vào đối tác sau khi hợp đồng kết thúc.

Chi phí chìm: khi nào nên dừng

Một trong những quyết định khó nhất là dừng một dự án đã chi một phần ngân sách. Tâm lý thường gặp là "đã đi xa rồi, cố thêm chút nữa". Nhưng phần đã chi là chi phí chìm: nó không thay đổi giá trị của phần còn lại.

Câu hỏi đúng không phải "đã chi bao nhiêu" mà là "nếu hôm nay bắt đầu từ đầu với thông tin hiện có, tôi có chọn hướng này không". Nếu câu trả lời là không, việc tiếp tục chỉ làm khoản lỗ lớn hơn.

Ba dấu hiệu nên dừng hoặc đổi hướng:

1. Bài toán ban đầu không còn đúng. Thị trường hoặc quy trình đã thay đổi tới mức sản phẩm đang xây không còn giải quyết vấn đề thật.
2. Không có người dùng sẵn sàng. Sau khám phá, không nhóm nào trong doanh nghiệp cam kết dùng hệ thống khi ra mắt.
3. Chi phí để hoàn thành lớn hơn giá trị kỳ vọng, và không có cách cắt phạm vi nào giữ được giá trị. Khi đó, một công cụ có sẵn hoặc một quy trình thủ công được chuẩn hoá có thể là lựa chọn tốt hơn.

Dừng sớm không phải là thất bại của dự án; nó là kết quả đúng của một cổng kiểm soát hoạt động đúng. Điều đáng tránh là không có cổng nào để dừng.

Nếu bạn cần hiểu sáu yếu tố đứng sau khối lượng nỗ lực, bài chi phí phát triển phần mềm trình bày mô hình đầy đủ. Bài chi phí phát triển ứng dụng so sánh ba nhóm ứng dụng theo cùng cách bóc tách, bài chi phí phát triển app liệt kê các hạng mục chi phí thường bị quên, và bài thuế GTGT của phần mềm là bao nhiêu giải thích phần thuế ảnh hưởng tới tổng chi phí.

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

Nên dành bao nhiêu phần trăm ngân sách cho giai đoạn đặc tả?

Thông lệ phổ biến là khoảng 10 đến 20 phần trăm tổng nỗ lực, cao hơn khi có nhiều ngoại lệ nghiệp vụ hoặc yêu cầu tuân thủ. Điều quan trọng hơn tỷ lệ là đầu ra: đặc tả chỉ hoàn thành khi mỗi yêu cầu viết được thành ít nhất một câu kiểm tra. Đặc tả dày nhưng không kiểm tra được thì không có giá trị.

Vì sao giai đoạn xây dựng thường vượt dự toán nhất?

Vì đó là nơi ba nguồn rủi ro gặp nhau: phạm vi thay đổi trong lúc làm, dữ liệu cũ cần xử lý và yêu cầu hiệu năng đòi hỏi tối ưu. Ngoài ra, đây là giai đoạn dài nhất nên xác suất gặp một vấn đề chưa lường trước cũng cao nhất. Cách kiểm soát là nhịp giao hàng ngắn và một cổng cắt phạm vi giữa giai đoạn.

Có nên ký trọn gói cho cả bốn giai đoạn không?

Có thể, nếu phạm vi đã được đặc tả đủ chi tiết. Nhưng ngay cả khi ký trọn gói, bạn vẫn nên yêu cầu hợp đồng có mốc thanh toán gắn với đầu ra của từng giai đoạn. Mốc thanh toán theo giai đoạn giữ lại quyền dừng và tạo động lực hoàn thành từng phần thay vì dồn toàn bộ vào cuối.

Làm sao biết một giai đoạn đã thực sự hoàn thành?

Mỗi giai đoạn cần một bằng chứng kiểm tra được, không phải một báo cáo. Khám phá hoàn thành khi có văn bản bài toán được bạn xác nhận. Đặc tả hoàn thành khi mỗi yêu cầu có câu kiểm tra. Xây dựng hoàn thành khi có bản dựng chạy được trong môi trường thử với bộ kiểm thử. Bàn giao hoàn thành khi đội của bạn tự triển khai và tự phục hồi dữ liệu thành công.

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ệ phân bổ nỗ lực và kiểm soát ngân sách trong các dự án phát triển phần mềm; mọi tỷ lệ và con số là mô hình minh hoạ, không phải báo giá.

Nếu bạn muốn chia dự án thành các giai đoạn có cổng kiểm soát thay vì một cam kết duy nhất, 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 để biết đầu ra của từng cổng. Báo giá sau khi chốt phạm vi.