Outsourcing software là gì? Cách đọc hợp đồng outsourcing lần đầu
Cách đọc hợp đồng outsourcing software lần đầu: ba nhóm rủi ro tiền, quyền, vận hành, bằng chứng phải có trong hồ sơ và những dấu hiệu cần đàm phán lại.
Mục lục bài viết
Trả lời nhanh
Outsourcing software là thuê ngoài phát triển phần mềm theo hợp đồng có phạm vi, nghiệm thu và chuyển giao. Đọc hợp đồng theo thứ tự rủi ro, không theo trang.
Outsourcing software là việc thuê đơn vị bên ngoài phát triển phần mềm theo hợp đồng có phạm vi, tiêu chí nghiệm thu và điều khoản chuyển giao rõ ràng. Giá trị hợp đồng nằm ở chỗ nó trả lời được ai chịu rủi ro khi phạm vi thay đổi và ai sở hữu mã nguồn sau bàn giao.
Tóm tắt nhanh
- Hợp đồng outsourcing software là hợp đồng theo kết quả, không phải hợp đồng mua quyền dùng phần mềm.
- Đọc theo ba nhóm rủi ro: tiền, quyền và vận hành. Mỗi nhóm có một câu hỏi kiểm tra và một loại bằng chứng phải có trong hồ sơ.
- Ba câu hỏi quyết định giá trị hợp đồng: "xong" nghĩa là gì, ai đo, và khi dừng thì bàn giao cái gì.
- Một hợp đồng tốt có thể ngắn. Một hợp đồng dài mà thiếu tiêu chí nghiệm thu vẫn là hợp đồng rủi ro.
Outsourcing software là gì trong một hợp đồng cụ thể
Trong hợp đồng, outsourcing software xuất hiện dưới dạng một bên đặt hàng và một bên nhận làm, với ba nhóm nghĩa vụ. Bên đặt hàng mô tả bài toán, cung cấp người ra quyết định, nghiệm thu và thanh toán theo mốc. Bên nhận làm chịu trách nhiệm về đặc tả kỹ thuật, mã nguồn, kiểm thử, triển khai và bảo hành trong phạm vi đã ký.
Điều dễ bỏ qua: hợp đồng không chỉ mô tả công việc mà còn phân bổ rủi ro. Hai hợp đồng có cùng danh sách tính năng vẫn có thể chênh nhau rất nhiều về tổng chi phí thực tế, vì một bên đặt rủi ro phạm vi lên đối tác và bên kia đặt lên chính doanh nghiệp.
Hợp đồng outsourcing không phải hợp đồng mua phần mềm
Mua phần mềm đóng gói là mua quyền dùng một sản phẩm đã tồn tại. Hợp đồng outsourcing là mua công sức tạo ra một sản phẩm chưa tồn tại. Hệ quả pháp lý và vận hành khác nhau ở ba điểm:
- Nghiệm thu dựa trên tiêu chí, không dựa trên việc sản phẩm có sẵn hay không.
- Quyền sở hữu phải được chuyển giao, vì sản phẩm do một bên tạo ra theo đặt hàng.
- Bảo hành là nghĩa vụ sửa lỗi, không phải nghĩa vụ đổi sản phẩm hay hoàn tiền.
Ba điểm này là lý do bạn không thể dùng một hợp đồng mua bán phần mềm đóng gói cho một dự án phát triển theo yêu cầu.
Ba nhóm rủi ro và bằng chứng phải có trong hồ sơ
Đừng đọc từ trang đầu đến cuối. Hãy gom điều khoản vào ba nhóm — tiền, quyền, vận hành — rồi kiểm tra mỗi nhóm bằng một câu hỏi và một loại bằng chứng.
| Nhóm rủi ro | Câu hỏi kiểm tra | Bằng chứng phải có | Thiệt hại nếu thiếu |
|---|---|---|---|
| Tiền | Mốc thanh toán gắn với đầu ra nào? | Danh sách mốc kèm đầu ra kiểm chứng được | Trả trước quá nhiều, mất đòn bẩy |
| Tiền | Yêu cầu thay đổi được tính giá thế nào? | Mẫu yêu cầu và cách tính nỗ lực | Phạm vi trôi, mỗi thay đổi thành một cuộc mặc cả |
| Quyền | Tài sản nào chuyển giao, khi nào? | Danh mục tài sản kèm thời điểm chuyển | Trả tiền nhưng không dùng được phần đã làm |
| Quyền | Thư viện bên thứ ba đã liệt kê chưa? | Danh sách phụ thuộc kèm giấy phép | Rủi ro pháp lý khi phân phối |
| Vận hành | Ai đứng tên tài khoản hạ tầng? | Danh sách tài khoản và chủ sở hữu | Không truy cập được hệ thống của mình |
| Vận hành | Khi dừng, bàn giao gì, trong bao lâu? | Điều khoản bàn giao kèm thời hạn | Bị khoá vào nhà cung cấp |
| Vận hành | Sự cố ngoài giờ do ai xử lý? | Cam kết thời gian phản hồi theo mức | Hệ thống hỏng im lặng qua đêm |
Nhóm tiền: phạm vi, nghiệm thu và cách tính thay đổi
Một dòng phạm vi dùng được phải chạy được bởi người không tham gia dự án. Ví dụ với một trung tâm đào tạo: "Khi học viên đăng ký lớp đã đủ sĩ số, hệ thống đưa vào danh sách chờ, hiện thứ tự chờ và không trừ học phí". Người kiểm thử đọc câu này là biết cần chuẩn bị lớp đầy và một học viên mới.
Ngược lại, "chức năng đăng ký hoạt động tốt" không phải phạm vi. Nếu người ngoài dự án không dựng được ca kiểm thử từ câu bạn viết, câu đó chưa đủ để ký.
Về thay đổi, hãy đòi ba thứ: mẫu yêu cầu, thời hạn phản hồi và cách tính nỗ lực. Cách tính nên tách phần mới, phần kiểm thử lại và phần làm lại. Thiếu phần thứ ba, mỗi thay đổi thành một cuộc đàm phán riêng khi bạn đã cam kết tiến độ.
Cách kiểm tra nhanh: hỏi "nếu thêm một báo cáo cùng độ phức tạp với báo cáo số 3, các anh xử lý thế nào". Nếu câu trả lời là "cứ gửi yêu cầu rồi báo giá sau", điều khoản thay đổi chưa tồn tại.
Nhóm quyền: sở hữu trí tuệ là một danh mục, không phải một câu
Điều khoản sở hữu thường chỉ nói "mã nguồn thuộc về bên đặt hàng". Câu đó chưa đủ để bàn giao. Hãy đòi một danh mục tài sản kèm thời điểm chuyển giao cho từng dòng.
Danh mục tối thiểu: kho mã có lịch sử thay đổi, tài liệu thiết kế, lược đồ dữ liệu, kịch bản triển khai, tên miền và chứng chỉ, cùng danh sách thư viện bên thứ ba kèm giấy phép. Mỗi dòng ghi rõ thuộc về ai và chuyển lúc nào — khi thanh toán đủ, theo từng đợt, hay ngay khi ký.
Cách kiểm tra: yêu cầu một buổi kiểm kê trước khi ký, đối chiếu danh mục với những gì đang có trên môi trường thật. Dòng nào không tìm được thì sẽ không xuất hiện sau này.
Nhóm vận hành: chấm dứt là điều khoản bị đọc muộn nhất
Điều khoản chấm dứt thường nằm ở cuối hợp đồng và chỉ được đọc khi đã có vấn đề. Nó cần trả lời ba câu: thông báo trước bao lâu, bàn giao gồm những gì, và thời hạn bàn giao là bao lâu. Một điều khoản chấm dứt không có nghĩa vụ bàn giao biến quyền chấm dứt thành quyền mất toàn bộ phần đã làm.
Song song, kiểm tra danh sách tài khoản hạ tầng: tên miền, chứng chỉ, khoá truy cập đám mây và tài khoản email giao dịch. Nếu chúng đứng tên đối tác, bạn không vào được hệ thống của mình khi đổi nhà cung cấp.
Ba câu hỏi phải hỏi trước khi ký
Ba câu này không nằm trong hợp đồng nhưng quyết định hợp đồng có hiệu lực hay không.
- Ai là người đại diện sản phẩm phía chúng tôi, và người đó dành bao nhiêu thời gian mỗi tuần? Nếu câu trả lời là "khi nào cần", dự án sẽ trượt vì không ai ra quyết định.
- Chúng tôi sẽ thấy tiến độ ở đâu? Câu trả lời đúng là một môi trường thử có bản dựng mới theo lịch, không phải ảnh chụp màn hình trong tin nhắn.
- Khi dừng hợp đồng, chúng tôi nhận lại chính xác những gì? Câu trả lời phải là danh sách: kho mã, tài liệu, tài khoản hạ tầng, dữ liệu, và một buổi chuyển giao có bản ghi.
Nếu cả ba câu đều có câu trả lời cụ thể bằng văn bản, phần lớn rủi ro vận hành đã được xử lý trước khi luật sư đọc hợp đồng.
Dấu hiệu cần đàm phán lại
| Dấu hiệu trong hợp đồng | Vấn đề thực sự | Cách xử lý |
|---|---|---|
| Không có mục tiêu chí nghiệm thu | Nghiệm thu sẽ dựa trên cảm nhận | Yêu cầu phụ lục tiêu chí trước khi ký |
| Sở hữu trí tuệ chuyển sau khi thanh toán toàn bộ | Mất quyền nếu dừng giữa đường | Đề nghị chuyển theo từng đợt |
| Thanh toán trước phần lớn giá trị | Mất đòn bẩy khi chất lượng kém | Gắn mốc thanh toán với đầu ra kiểm chứng được |
| Không nêu giấy phép mã nguồn mở | Rủi ro pháp lý khi phân phối | Yêu cầu danh sách thư viện và giấy phép |
| Bảo hành chỉ ghi "sửa lỗi" | Không rõ lỗi nào, trong bao lâu | Định nghĩa mức nghiêm trọng và thời hạn phản hồi |
| Không có điều khoản bàn giao khi chấm dứt | Bị khoá vào nhà cung cấp | Bổ sung danh sách bàn giao và thời hạn |
Một lưu ý về thứ tự đàm phán: hãy chốt phạm vi và tiêu chí nghiệm thu trước khi thương lượng giá. Làm ngược lại, bạn sẽ thương lượng giá cho một phạm vi chưa tồn tại.
Nếu bạn cần một bản mô tả phạm vi đầy đủ hơn, bài gia công phần mềm theo yêu cầu trình bày cách chia phạm vi theo giai đoạn. Bài dịch vụ gia công phần mềm là gì giải thích cách tách một gói dịch vụ thành các đơn vị bàn giao, còn bài gia công phần mềm là gì giúp bạn chọn đúng mô hình trước khi mở hợp đồng ra đọc.
Câu hỏi thường gặp
Hợp đồng outsourcing software có cần công chứng không?
Không bắt buộc với hợp đồng dịch vụ phát triển phần mềm thông thường. Điều quan trọng hơn là hợp đồng phải có phụ lục phạm vi, tiêu chí nghiệm thu và biên bản nghiệm thu theo từng mốc, vì đó là bằng chứng khi có tranh chấp. Với hợp đồng có yếu tố chuyển giao công nghệ hoặc giá trị lớn, nên hỏi ý kiến luật sư về hình thức phù hợp.
Nên ký theo kết quả hay theo thời gian?
Ký theo kết quả khi bạn mô tả được phạm vi và tiêu chí nghiệm thu bằng văn bản. Ký theo thời gian khi phạm vi còn thay đổi và bạn có người quản lý kỹ thuật đủ gần để ra quyết định hằng tuần. Trộn hai kiểu trong một hợp đồng mà không nói rõ phần nào theo kết quả, phần nào theo thời gian là công thức của tranh chấp.
Ai nên giữ tài khoản hạ tầng trong hợp đồng outsourcing?
Doanh nghiệp đặt hàng nên đứng tên tên miền, chứng chỉ và tài khoản dịch vụ đám mây, kể cả khi đối tác vận hành hằng ngày. Đối tác có thể có quyền truy cập theo vai trò, nhưng quyền sở hữu tài khoản phải thuộc về bạn. Nếu mọi tài khoản đứng tên đối tác, bạn không có quyền truy cập vào chính hệ thống của mình khi cần đổi nhà cung cấp.
Bảo hành phần mềm thường gồm những gì?
Bảo hành thường gồm việc sửa các lỗi làm hệ thống sai lệch so với phạm vi đã ký, trong một thời hạn nhất định sau nghiệm thu. Bảo hành không bao gồm yêu cầu mới hoặc thay đổi nghiệp vụ. Hợp đồng nên định nghĩa mức nghiêm trọng của lỗi, thời hạn phản hồi cho từng mức và cách xử lý khi lỗi lặp lại nhiều lần.
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ệ hợp đồng phát triển phần mềm hiện hành và không phải tư vấn pháp lý.
Nếu bạn đang chuẩn bị ký hợp đồng phát triển đầu tiên, WinSell xây dựng phần mềm theo yêu cầu với phạm vi và tiêu chí nghiệm thu được chốt trước khi triển khai — xem dịch vụ của WinSell để biết từng giai đoạn bàn giao gì. Báo giá sau khi chốt phạm vi.
Cần một hệ thống chạy được, không chỉ một bài viết?
WinSell xây phần mềm theo yêu cầu và làm SEO/GEO cho chính sản phẩm đó. Phạm vi và báo giá được chốt sau bước khám phá.
