Lần đầu thuê viết phần mềm, gần như ai cũng chỉ hỏi hai câu: bao nhiêu tiền và bao lâu xong. Hai câu đó quan trọng, nhưng chúng không bảo vệ được bạn. Thứ bảo vệ bạn là hiểu quy trình làm phần mềm theo yêu cầu gồm những bước nào, mỗi bước bạn phải cầm được cái gì, và hợp đồng phải ghi gì để khi mọi chuyện không suôn sẻ, bạn vẫn giữ được sản phẩm mình đã trả tiền.
Chúng tôi làm phần mềm từ 2015, hơn 500 dự án, trong đó không ít dự án được mời vào dọn hậu quả của đơn vị trước. Rất hiếm khi nguyên nhân đổ vỡ là "code dở". Nó thường là: phạm vi chỉ viết ba dòng trong phụ lục, khách đã trả 70% trước khi có thứ gì chạy được để xem, và không dòng nào nói ai sở hữu mã nguồn.
Bốn bước dưới đây viết gọn. Phần lớn dung lượng dành cho ba thứ ít bên bán chịu nói thẳng: mốc thanh toán an toàn, bảy điều khoản hợp đồng, và cờ đỏ nhận diện đơn vị nên tránh.
Bước 1 — Tư vấn và phân tích: bên bán tử tế sẽ hỏi ngược lại bạn
Dấu hiệu của một buổi tư vấn nghiêm túc rất đơn giản: bên kia hỏi nhiều hơn nói. Họ muốn biết quy trình của bạn đang chạy trên cái gì (Excel? phần mềm cũ? sổ tay?), một tháng bao nhiêu chứng từ, ai duyệt, khâu nào sai nhiều nhất và cái sai đó tốn bao nhiêu tiền. Thiếu mấy con số này thì mọi báo giá đều là đoán.
Đầu ra của bước 1 phải là văn bản: danh sách chức năng phân theo mức ưu tiên, sơ đồ luồng nghiệp vụ chính, vai trò người dùng và quyền tương ứng, các hệ thống cần tích hợp. Tài liệu này thường gọi là SRS, và nó là thứ hợp đồng trỏ tới mỗi khi hai bên tranh luận "cái này có trong phạm vi không".
Bước này ở dự án quản lý nội bộ cỡ vừa mất một đến ba tuần. Ai gửi báo giá trọn gói sau 30 phút gọi điện thì họ đang định giá một dự án tưởng tượng, không phải dự án của bạn. Trước khi đàm phán, nên xem cách bóc tách chi phí viết phần mềm theo yêu cầu theo từng module.
Bước 2 — Thiết kế và prototype: bạn duyệt gì trước dòng code đầu tiên
Sai lầm đắt nhất của người mua lần đầu là muốn "vào code cho nhanh". Sửa một màn hình trên bản vẽ mất nửa giờ. Sửa đúng màn hình đó khi đã code xong, đã nối API thì mất vài ngày công và kéo theo cả phần kiểm thử.
Bạn cần duyệt hai lớp: wireframe (bố cục thô, bấm nút này đi đâu) và prototype bấm được — bản mô phỏng gần như thật, tự click thử được luồng "tạo đơn - duyệt - xuất kho" mà chưa cần dòng code nào. Hãy đưa nó cho đúng người sẽ dùng hằng ngày là thủ kho, kế toán, lễ tân, đừng chỉ cho ban giám đốc xem. Người dùng cuối phát hiện lỗi nghiệp vụ trong năm phút mà cả phòng họp không nhìn ra.
Lý do kinh tế đằng sau nằm ở bài prototype và wireframe: vì sao trả tiền cho bản nháp lại tiết kiệm. Nguyên tắc khi ký: chữ ký duyệt prototype phải là một mốc hợp đồng, bản đã duyệt đính kèm làm phụ lục. Từ đó câu "cái này khác với hình em duyệt" mới có sức nặng.
Bước 3 — Phát triển theo sprint: demo hai tuần một lần
Cách làm nguy hiểm nhất là ký xong rồi im lặng ba tháng, đến hẹn mới nhận sản phẩm. Ba tháng đó bạn không có cách nào biết dự án đi đúng hay đã lệch từ tuần thứ hai.
Cơ chế nên yêu cầu: chia dự án thành các sprint hai tuần, cuối mỗi sprint có buổi demo trên môi trường thật — không phải slide, không phải ảnh chụp màn hình — kèm ghi chú ba mục: sprint này xong gì, sprint sau làm gì, đang vướng gì. Kèm theo đó là tài khoản vào công cụ quản lý công việc, thay vì chỉ nhận báo cáo đã qua biên tập.
Bạn không cần biết Scrum, chỉ cần đòi buổi demo và hỏi đúng ba câu trên; bộ khung phía sau nằm ở bài quản lý dự án phần mềm theo Scrum cho người chủ không kỹ thuật. Với ứng dụng di động, tiến độ còn phụ thuộc khâu duyệt store — chúng tôi tách riêng ở bài quy trình làm app từ ý tưởng đến ngày app lên store, vì lịch của Apple và Google không thương lượng theo sprint của ai cả.
Bước 4 — Bàn giao và vận hành: nghiệm thu thế nào cho chặt
Nghiệm thu không phải là bấm thử vài nút rồi ký biên bản. Nghiệm thu chặt là chạy lại đúng các kịch bản nghiệp vụ đã thống nhất từ bước 1, bằng dữ liệu gần thật, do chính nhân viên của bạn thao tác.
Ba thứ hay bị bỏ quên và sau này rất đắt để đòi lại: tài liệu bàn giao (hướng dẫn sử dụng, tài liệu kỹ thuật, tài khoản quản trị); quyền truy cập hạ tầng — máy chủ, tên miền, kho mã nguồn, tài khoản store phải đứng tên doanh nghiệp bạn; và kế hoạch chuyển dữ liệu cũ kèm phương án quay lui. Chúng tôi có sẵn checklist nghiệm thu phần mềm để dự án không bị treo vô thời hạn để bạn áp cho bất kỳ nhà thầu nào.
Sau go-live mới lộ ra chất lượng vận hành. Cam kết chúng tôi đang áp dụng: uptime 99.9%, phản hồi sự cố P1 trong 15 phút, backup hằng ngày lưu 30 ngày, hỗ trợ 24/7. Hãy đòi con số tương đương bằng văn bản — lời hứa "hỗ trợ nhiệt tình" không có gì để đối chiếu lúc hệ thống sập 2 giờ sáng.
Mốc thanh toán an toàn cho cả hai bên
Đây là chỗ người mua lần đầu dễ mất tiền nhất. Nguyên tắc rất gọn: mỗi lần chuyển tiền, bạn phải nhận lại một thứ cầm được — tài liệu đã duyệt, bản chạy được, biên bản nghiệm thu. Không vật đối ứng thì không mốc thanh toán.
Bảng dưới là cấu trúc chúng tôi thấy hợp lý cho dự án quy mô SME. Tỷ lệ là khoảng tham khảo thị trường tại thời điểm viết (08/2026), chưa gồm VAT.
| Mốc | Thời điểm | % giá trị hợp đồng | Vật đối ứng bạn phải nhận |
|---|---|---|---|
| 1. Khởi động | Sau khi ký hợp đồng | 20 - 30% | Kế hoạch dự án, danh sách nhân sự, lịch sprint |
| 2. Duyệt thiết kế | Duyệt xong SRS và prototype | 15 - 20% | Đặc tả và prototype ký duyệt, đính kèm phụ lục |
| 3. Xong phát triển lõi | Demo nghiệp vụ chính chạy được | 20 - 25% | Bản chạy trên môi trường thử nghiệm, tài khoản truy cập |
| 4. Nghiệm thu UAT | Ký biên bản nghiệm thu | 20 - 25% | Mã nguồn, tài liệu bàn giao, chuyển giao hạ tầng |
| 5. Giữ lại (retention) | Sau 30 - 60 ngày vận hành ổn định | 5 - 10% | Biên bản kết thúc bảo hành giai đoạn đầu |
Khoản giữ lại 5-10% ở mốc cuối là công cụ mạnh nhất của bạn: nó là lý do để bên làm quay lại sửa lỗi sau go-live thay vì biến mất. Tạm ứng trên 40% ở dự án dưới 300 triệu là bất thường. Cấu trúc mốc còn phụ thuộc kiểu hợp đồng — cách chọn nằm ở bài fixed price hay time & material: kiểu hợp đồng nào hợp dự án của bạn.
7 điều khoản hợp đồng phải có
Hợp đồng mẫu tải trên mạng thường dài về thủ tục và mỏng đúng ở chỗ quan trọng. Bảy điều dưới đây nên đọc kỹ nhất, hoặc yêu cầu bổ sung nếu chưa có.
1. Phạm vi công việc gắn với tài liệu, không gắn với lời nói
Điều khoản phạm vi phải trỏ đích danh đến tài liệu đặc tả và prototype đã ký, kèm số phiên bản và ngày. Câu "phát triển phần mềm quản lý bán hàng theo yêu cầu của Bên A" vô nghĩa khi tranh chấp.
2. Quyền sở hữu mã nguồn và thời điểm chuyển giao
Ghi rõ: mã nguồn viết riêng cho dự án thuộc về bạn kể từ khi thanh toán đủ, bên làm phải bàn giao kho mã nguồn cùng tài liệu triển khai. Hỏi thẳng phần mềm dùng thư viện mở hay thành phần thương mại nào, ai trả phí duy trì. Cách viết chi tiết nằm ở bài sở hữu mã nguồn và NDA khi thuê ngoài phát triển.
3. Cơ chế xử lý phát sinh có giá và có biểu mẫu
Dự án nào cũng phát sinh; vấn đề là làm cho nó minh bạch. Hợp đồng nên quy định mọi thay đổi ngoài phạm vi phải qua phiếu yêu cầu ghi rõ ảnh hưởng tới thời gian và chi phí, có đơn giá ngày công công bố trước, chỉ làm khi bạn duyệt. Thiếu nó, chi phí đội dần theo kiểu scope creep giữa chừng.
4. Bảo hành: bao lâu, cái gì tính là lỗi, phản hồi trong bao lâu
Cả ba đều phải có số. Bảo hành phổ biến trên thị trường là 3 - 12 tháng kể từ ngày nghiệm thu. Lỗi phải phân mức (chặn nghiệp vụ, ảnh hưởng một phần, lỗi giao diện), mỗi mức có thời gian phản hồi và khắc phục riêng. Và nói rõ chiều ngược lại: thêm tính năng trong thời gian bảo hành là phát sinh có tính phí, không phải lỗi.
5. SLA vận hành sau bảo hành
Nếu bên làm cũng vận hành hệ thống, cần phụ lục riêng: cam kết uptime, kênh báo sự cố, thời gian phản hồi theo mức ưu tiên, chính sách sao lưu, và có diễn tập phục hồi hay không. Một bản backup chưa từng thử khôi phục thì chưa gọi là backup; mức cam kết tham khảo có ở dịch vụ máy chủ.
6. Điều khoản thoát: chuyện gì xảy ra nếu dừng giữa chừng
Cần ghi: điều kiện chấm dứt của mỗi bên, thời gian báo trước, cách quyết toán phần việc đã làm, và nghĩa vụ bàn giao mã nguồn trong bao nhiêu ngày. Thiếu nó, dự án dừng giữa chừng để lại con số 0: không sản phẩm, không mã nguồn, tiền đã đi.
7. Bảo mật dữ liệu và quy tắc dùng dữ liệu thật khi thử nghiệm
Ràng buộc bảo mật cho toàn bộ nhân sự tham gia, không chỉ cho pháp nhân. Quy định rõ dữ liệu thật có được mang ra môi trường thử nghiệm không, nếu có thì che trường nào, và nghĩa vụ xóa dữ liệu khi kết thúc dự án. Với y tế hay tài chính thì không thể bỏ: khi làm phần mềm quản lý phòng khám, hồ sơ bệnh nhân không được nằm trên máy cá nhân.
Cờ đỏ: dấu hiệu của đơn vị bạn nên tránh
Chúng tôi nói thẳng những gì hay gặp trong ngành. Dính một dấu hiệu chưa chắc đã xấu, từ ba trở lên thì nên dừng lại.
- Báo giá trọn gói ngay buổi đầu, không hỏi gì về nghiệp vụ. Con số đó sẽ được "điều chỉnh" sau, hoặc phạm vi bị cắt trong im lặng.
- Đòi tạm ứng 70% trở lên, hoặc thanh toán đủ trước khi nghiệm thu.
- Không cho bạn quyền vào kho mã nguồn suốt dự án, lý do thường là "quy trình nội bộ".
- Tên miền, máy chủ, tài khoản store đứng tên bên làm — cờ đỏ nặng nhất, bạn sẽ hiểu vào ngày muốn đổi nhà thầu.
- Không có ai làm kiểm thử, lập trình viên tự test sản phẩm của mình. Hỏi thẳng: đội có mấy người QA?
- Demo bằng ảnh thiết kế rồi gọi đó là "sản phẩm đang chạy".
- Người bán hàng biến mất sau khi ký, không ai làm quản lý dự án chịu trách nhiệm.
- Giá thấp hơn mặt bằng 40-50% mà không giải thích được vì sao. Chênh lệch thường đến từ kiểm thử, tài liệu và bảo hành.
- Né tránh khi bạn hỏi về điều khoản bàn giao mã nguồn.
Chiều ngược lại cũng dễ nhận: họ dám nói "phần này chúng tôi không làm", đưa người trực tiếp làm dự án ra gặp bạn, và có quy trình viết ra giấy — xem 10 dấu hiệu nhận ra một công ty phần mềm thật sự đáng tin.
Chuẩn bị gì trước khi gọi báo giá
Mang theo bốn thứ thì bạn sẽ nhận được báo giá tốt hơn: mô tả quy trình hiện tại bằng ngôn ngữ của chính bạn, số người dùng và khối lượng giao dịch mỗi tháng, danh sách hệ thống cần nối vào, và khoảng ngân sách chấp nhận được. Nói ra ngân sách không làm bạn bị hớ, nó giúp bên làm đề xuất đúng phạm vi. Bài toán kho vận thì xem báo giá phần mềm quản lý kho theo yêu cầu; ứng dụng di động thì chi phí làm app theo số màn hình và tính năng.
Bốn bước ở trên chỉ là bộ khung. Thứ thật sự bảo vệ bạn là mốc thanh toán gắn với vật đối ứng và bảy điều khoản hợp đồng — quy trình đẹp trên slide mà hợp đồng lỏng thì bạn vẫn gánh rủi ro.
Đang cầm một bản hợp đồng và không chắc chỗ nào cần sửa? Gửi chúng tôi xem qua. Đội ngũ hơn 30 kỹ sư của Microads với chứng chỉ AWS, GCP, CEH, OSCP, PMP đã đi qua hơn 500 dự án và trên 200 khách hàng, đủ để chỉ ra chỗ bất lợi cho bạn, kể cả khi bạn không làm với chúng tôi. Tư vấn buổi đầu miễn phí: gọi 0919 788 815 hoặc xem dịch vụ phát triển phần mềm của Microads.
