Tóm tắt: Chi phí làm phần mềm riêng thường bằng số người-tháng nhân đơn giá từng vai trò, cộng hạ tầng và dịch vụ bên thứ ba. Chi phí phình ra chủ yếu vì yêu cầu không được viết ra và thay đổi không qua duyệt. Tài liệu đặc tả và quản lý thay đổi giữ báo giá sát thực tế.
Mục lục
- Chi phí làm phần mềm riêng được tính từ những gì?
- Nhà nước hướng dẫn tính chi phí phần mềm thế nào?
- Giá cố định hay tính theo thời gian: chọn cách nào?
- Vì sao chi phí thường phình ra so với báo giá ban đầu?
- Tài liệu đặc tả phần mềm cần viết những gì?
- Quản lý thay đổi giữ chi phí ổn định bằng cách nào?
- Khi nào không nên làm phần mềm quản lý theo yêu cầu?
- Chi phí sau bàn giao gồm những gì?
- Chọn công ty phát triển phần mềm ở Hà Nội cần hỏi gì?
1. Chi phí làm phần mềm riêng được tính từ những gì?
Phần lớn báo giá phần mềm riêng quy về một công thức: số người-tháng của từng vai trò, nhân đơn giá của vai trò đó, cộng các khoản ngoài nhân công. Người-tháng là khối lượng công việc một người làm trong một tháng. Mười hai người-tháng có thể là 3 người làm 4 tháng, hoặc 6 người làm 2 tháng.
Các thành phần thường gặp:
- Nhân công theo vai trò: phân tích nghiệp vụ, thiết kế, lập trình, kiểm thử, quản lý dự án, mỗi vai trò một đơn giá.
- Ngoài nhân công: hạ tầng, dịch vụ bên thứ ba (gửi SMS, thanh toán, bản đồ), công cụ.
- Dự phòng: khoản hai bên thoả thuận cho rủi ro đã biết.
Ví dụ dưới đây là giả định để minh hoạ cách tính, không phải bảng giá của VAON hay mức giá thị trường. Giả sử dự án cần 1 người phân tích nghiệp vụ trong 1 tháng và 3 lập trình viên trong 3 tháng. Thêm 1 người kiểm thử trong 2 tháng, 1 quản lý dự án làm nửa thời gian trong 3 tháng:
| Vai trò | Người-tháng |
|---|---|
| Phân tích nghiệp vụ | 1 |
| Lập trình | 9 |
| Kiểm thử | 2 |
| Quản lý dự án (nửa thời gian) | 1,5 |
| Tổng | 13,5 |
Với đơn giá bình quân giả định 40 triệu đồng mỗi người-tháng, nhân công là 13,5 × 40 = 540 triệu đồng, chưa kể hạ tầng và dự phòng. Đổi một giả định, con số đổi theo. Thêm một tháng lập trình cho 3 người là thêm 3 người-tháng, tức 120 triệu theo cùng đơn giá.
Vì vậy, câu hỏi đầu tiên với mọi báo giá là: bao nhiêu người-tháng, cho vai trò nào, dựa trên phạm vi nào? Báo giá chỉ có một dòng tổng thì bạn không có gì để so.
2. Nhà nước hướng dẫn tính chi phí phần mềm thế nào?
Với dự án dùng ngân sách nhà nước, Bộ Thông tin và Truyền thông có Hướng dẫn xác định chi phí phần mềm nội bộ năm 2024 (ban hành kèm Quyết định 671/QĐ-BTTTT). Doanh nghiệp tư nhân không bắt buộc theo văn bản này. Đọc nó vẫn có ích, vì nó cho thấy một báo giá nghiêm túc bắt đầu từ danh sách chức năng.
Hướng dẫn tính chi phí theo điểm trường hợp sử dụng (use case: một việc người dùng làm với phần mềm, như "tạo đơn hàng"). Trình tự bắt đầu bằng danh sách tác nhân và danh sách yêu cầu chức năng, rồi chuyển từng yêu cầu thành use case. Sau đó mới chấm hệ số độ phức tạp kỹ thuật và năng lực đội làm. Không có danh sách chức năng thì không có gì để đếm.
Ba chi tiết trong văn bản đáng để ý khi bạn đọc báo giá của bất kỳ bên nào:
| Chi tiết trong hướng dẫn | Ý nghĩa khi bạn đọc báo giá |
|---|---|
| Chi phí trực tiếp nhân với hệ số 1,4 "cho điều chỉnh, sửa lỗi" | Sửa và chỉnh là một phần thật của công việc, không phải chuyện bất thường |
| Cộng chi phí chung bằng 65% chi phí trực tiếp, rồi thu nhập chịu thuế tính trước 6% | Đơn giá người-tháng của công ty luôn cao hơn lương kỹ sư, vì gánh cả quản lý, văn phòng, công cụ |
| Không bao gồm tạo lập và chuyển đổi dữ liệu, cài đặt, đào tạo, vận hành trước nghiệm thu | Những khoản này dễ bị bỏ sót nếu báo giá không ghi rõ có hay không |
Dòng cuối đáng hỏi kỹ nhất. Chuyển dữ liệu từ Excel hay phần mềm cũ sang hệ thống mới có thể là một hạng mục riêng, không nằm trong phần "làm chức năng".
3. Giá cố định hay tính theo thời gian: chọn cách nào?
Chọn theo độ rõ của yêu cầu: yêu cầu đã chốt thì giá cố định hợp lý, chưa chốt thì tính theo thời gian hợp lý hơn. Mỗi cách chuyển rủi ro sang một bên khác nhau.
| Giá cố định | Tính theo thời gian (time and material) | |
|---|---|---|
| Bạn trả | Một khoản đã thống nhất cho phạm vi đã viết | Theo số người-tháng thực tế |
| Ai chịu rủi ro tăng khối lượng | Bên làm, trong phạm vi đã chốt | Bạn |
| Khi yêu cầu đổi | Báo giá lại phần thay đổi | Tính thêm theo thời gian thực |
| Hợp với | Phạm vi rõ, đã có đặc tả | Phạm vi còn mở, cần thử và học dần |
| Rủi ro hay gặp | Giá thấp lúc ký, tranh cãi "cái này có trong phạm vi không" | Hoá đơn tăng mà khó biết còn bao lâu |
Giá cố định chỉ đáng tin khi phạm vi được viết đủ chi tiết để hai bên hiểu cùng một thứ. Thiếu tài liệu đó, tranh cãi không biến mất. Nó chỉ dời sang giữa dự án, lúc đổi bên làm đã tốn kém.
4. Vì sao chi phí thường phình ra so với báo giá ban đầu?
Chi phí phình ra chủ yếu vì phạm vi chưa được viết ra, nên hai bên hiểu khác nhau mà không ai biết cho đến khi gần bàn giao. Có bốn nguồn hay gặp:
- Yêu cầu nói miệng. "Có báo cáo doanh thu" nghe như một việc. Thực tế là báo cáo theo ngày, theo chi nhánh, xuất Excel, phân quyền ai được xem.
- Thay đổi không qua duyệt. Mỗi yêu cầu nhỏ "làm luôn cho nhanh" đều tốn công mà không ai ghi lại, đến cuối mới cộng dồn.
- Phần ẩn. Chuyển dữ liệu từ hệ thống cũ, kết nối hệ thống khác, quy tắc chỉ nhân viên lâu năm biết.
- Tri thức ở một người. Người đó nghỉ thì người mới phải đọc lại và làm lại.
Tại VAON, một trong ba câu khách hỏi nhiều nhất năm 2026 là "chưa có đặc tả thì có hỏi được không". Hỏi được. Bước đầu tiên khi đó là chốt yêu cầu bằng văn bản, rồi mới đến báo giá xây dựng.
5. Tài liệu đặc tả phần mềm cần viết những gì?
Một tài liệu đặc tả đủ dùng trả lời được câu "hệ thống làm gì, cho ai, và thế nào là xong". Viết tài liệu đặc tả phần mềm không cần dài, nhưng cần đủ tám mục:
- Mục tiêu và người dùng: ai dùng, dùng để làm việc gì, đo thành công bằng gì.
- Luồng nghiệp vụ: từng bước, kể cả ngoại lệ ("khách huỷ đơn sau khi đã xuất kho thì sao").
- Màn hình: danh sách màn hình và wireframe, mỗi màn hình có trường dữ liệu và hành động.
- Quy tắc nghiệp vụ: công thức tính, điều kiện duyệt, phân quyền.
- Dữ liệu: thiết kế cơ sở dữ liệu, dữ liệu cần chuyển từ hệ thống cũ.
- Kết nối: hệ thống bên ngoài nào, theo cách nào.
- Tiêu chí nghiệm thu: điều kiện để bạn nói "xong".
- Ngoài phạm vi: những gì chủ động không làm ở đợt này.
Mục cuối hay bị bỏ quên, nhưng tránh được nhiều tranh cãi nhất. Mỗi dòng "không làm" là một khoản không xuất hiện trên báo giá.
Một ví dụ từ dự án thật. VAON làm Seminar Navi cho Đại học Công nghệ Kochi (高知工科大学, Nhật Bản). Hai bên cùng đi từ sắp xếp yêu cầu đến vận hành trong khoảng 5 tuần, chạy chính thức từ 01/10/2026. Hệ thống gồm app trên LINE (LIFF), PWA và màn hình quản trị. Hai quyết định phạm vi đáng chú ý: không thu họ tên sinh viên, và gợi ý bằng luật thay vì dùng AI tạo sinh. Sinh viên bắt đầu dùng sau 4 bước, khoảng 1 phút.
Với VAON, việc viết đặc tả nằm trong 仕様確定フェーズ (Giai đoạn chốt đặc tả, Spec Lock Phase). Giai đoạn này mất 1 đến 2 tuần, dự án lớn 2 đến 4 tuần, giá cố định báo trước. Đầu ra gồm tài liệu yêu cầu, wireframe từng màn hình, thiết kế CSDL, kiến trúc hệ thống và báo giá cố định cho giai đoạn xây dựng. Bạn được dừng sau giai đoạn này. Thời gian và chi phí riêng cho bước này có ở bài định nghĩa yêu cầu phần mềm mất bao lâu, tốn bao nhiêu.
6. Quản lý thay đổi giữ chi phí ổn định bằng cách nào?
Quản lý thay đổi giữ chi phí ổn định bằng một quy tắc: mọi yêu cầu ngoài phạm vi đều được viết ra, báo giá, duyệt rồi mới làm. Yêu cầu sẽ đổi, chuyện bình thường. Vấn đề là đổi mà không ai biết giá.
Quy trình ở VAON gồm bốn bước:
- Việc ngoài phạm vi được lập thành yêu cầu thay đổi.
- VAON báo giá và ảnh hưởng tiến độ bằng văn bản.
- Bạn duyệt thì mới làm.
- Không duyệt là không làm, không tính tiền.
Một chỗ hay gãy là tin nhắn. Một câu trên chat lúc 10 giờ tối, "thêm cho anh nút xuất PDF nhé", rất dễ bị làm luôn mà không ai ghi. Ở VAON, yêu cầu gửi qua chat được ghi vào file quản lý feedback hoặc chuyển thành task trong backlog. Sau đó VAON gửi lại bạn xác nhận, kèm giá và tác động nếu việc đó nằm ngoài phạm vi.
Hai bên cũng thống nhất từ đầu một đầu mối, ai họp khi nào và thế nào là xong. Báo cáo hằng tuần nêu tiến độ, rủi ro và việc cần bạn quyết. Kết quả: không khoản nào xuất hiện trên hoá đơn mà bạn chưa đồng ý bằng văn bản. Cách VAON nói trước phạm vi và giới hạn có ở bài nói trước điều không làm khi làm phần mềm B2B.
7. Khi nào không nên làm phần mềm quản lý theo yêu cầu?
Không nên làm phần mềm quản lý theo yêu cầu khi một sản phẩm có sẵn đã đáp ứng phần lớn quy trình của bạn. Thuê hoặc mua khi đó thường rẻ và nhanh hơn. Làm riêng đáng cân nhắc khi:
- quy trình của bạn là lợi thế cạnh tranh và phần mềm có sẵn buộc bạn đổi cách làm;
- bạn đang ghép nhiều công cụ rời rạc bằng Excel và thao tác tay;
- quy tắc nghiệp vụ đặc thù mà sản phẩm có sẵn không cấu hình được;
- bạn cần sở hữu và kiểm soát mã nguồn, dữ liệu.
Thêm một trường hợp nên chờ: chưa có ai bên bạn dành được thời gian trả lời câu hỏi nghiệp vụ. Đặc tả cần người hiểu việc ngồi cùng. Thiếu người đó, bên làm sẽ đoán, và mỗi lần đoán sai là một lần làm lại.
VAON cũng có giới hạn. VAON không nhận tự huấn luyện mô hình ngôn ngữ lớn, phần cứng hoặc hệ nhúng, blockchain. VAON không coi làm riêng là lựa chọn mặc định.
8. Chi phí sau bàn giao gồm những gì?
Chi phí sau bàn giao là phần nhiều người quên khi so báo giá, nên cần ghi rõ trong hợp đồng. Bốn khoản thường gặp:
- Sửa lỗi sau bàn giao: bảo hành tính từ ngày nào, loại lỗi nào được sửa miễn phí.
- Hạ tầng và dịch vụ bên thứ ba: máy chủ, tên miền, SMS, bản đồ, trả hằng tháng.
- Cập nhật và vá bảo mật: thư viện và hệ điều hành cũ dần, cần nâng cấp định kỳ.
- Tính năng mới: đi theo quy trình thay đổi như lúc xây dựng.
Hỏi thêm một câu: tài liệu bàn giao có đủ để một đội khác tiếp quản không? Tài liệu của VAON ghi cả lý do các quyết định kỹ thuật và luôn được cập nhật. Nếu sau này bạn đổi bên làm, đội mới không phải đoán vì sao hệ thống được xây như vậy.
9. Chọn công ty phát triển phần mềm ở Hà Nội cần hỏi gì?
Chọn công ty phát triển phần mềm ở Hà Nội nên bắt đầu từ những thứ kiểm chứng được, trước khi so giá. Năm câu đáng hỏi:
- Ai thực sự làm dự án, và nếu người đó nghỉ thì ai tiếp quản?
- Có bước chốt yêu cầu bằng văn bản trước khi báo giá xây dựng không?
- Việc ngoài phạm vi được báo giá và duyệt thế nào?
- Trước mỗi lần phát hành, ai đọc lại mã và có kịch bản kiểm thử không? Cho tôi xem hồ sơ.
- Mã nguồn và dữ liệu thuộc về ai sau khi kết thúc?
VAON là Công ty TNHH VAON Việt Nam, đặt tại Hà Nội, thành lập 01/2026, 15 nhân sự chính thức. Mọi dự án lưu hồ sơ review và test mà khách xem được. Trước mỗi lần phát hành, mã có người khác đọc lại, có kịch bản kiểm thử và danh sách kiểm tra.
Đội nhỏ có giới hạn. Dự án cần vài chục người trong thời gian ngắn thì 15 người có thể không nhận được, và năm 2026 VAON đã vài lần từ chối dự án.
Việc làm được ngay hôm nay: viết ra 5 việc phần mềm của bạn phải làm và 3 việc chưa làm ở đợt đầu. Hai danh sách đó là nền của mọi báo giá. Có chúng trong tay, bạn so được các báo giá với nhau.
Nếu muốn có người đọc cùng và chỉ ra chỗ còn thiếu, đặt lịch trao đổi 60 phút miễn phí. CEO tham dự, không cần chuẩn bị tài liệu, không ràng buộc.
Đọc thêm
- Offshore development thất bại vì đặc tả, không vì code
- Cách nhận biết công ty phần mềm không phát sinh chi phí ẩn
Tác giả: Đặng Văn Luân, Founder & CEO, VAON. Tốt nghiệp HEDSPI (Đại học Bách khoa Hà Nội), từng làm tại FPT Software, 5 năm tại Digital Plus (Tokyo) với hệ thống 10 triệu người dùng, 8 năm làm COO một công ty ITO 120 nhân sự và xây hệ thống quản lý theo ISO 9001, ISO 27001. 15 năm làm nghề.
