Gia công phần mềm là gì? Định nghĩa, mô hình và khi nào nên chọn

Gia công phần mềm là việc giao một phần hoặc toàn bộ công việc phát triển phần mềm cho đơn vị bên ngoài theo phạm vi đã thống nhất, rồi nhận lại sản phẩm chạy được cùng mã nguồn. Bạn giữ quyền quyết định sản phẩm; đối tác chịu trách nhiệm về kỹ thuật và tiến độ.

Tóm tắt nhanh

• Gia công phần mềm chuyển phần thực thi kỹ thuật ra bên ngoài, không chuyển quyền quyết định sản phẩm.
• Có năm mô hình phổ biến. Chúng khác nhau ở chỗ ai chịu rủi ro phạm vi, ai giữ mã nguồn và chi phí thay đổi được tính cho ai.
• Giá trị thật của một hợp đồng nằm ở định nghĩa "hoàn thành" và điều khoản chuyển giao quyền sở hữu, không nằm ở con số tổng.
• Gia công không tự động rẻ hơn làm nội bộ. Nó đổi cấu trúc chi phí, không xoá chi phí.
• Bàn giao đúng nghĩa gồm mã nguồn, tài liệu, môi trường chạy, quyền truy cập và khả năng để đội của bạn tự vận hành.

Gia công phần mềm là gì?

Gia công phần mềm là một quan hệ hợp đồng trong đó một bên đặt hàng và một bên nhận làm. Bên đặt hàng mô tả bài toán, quyết định sản phẩm phải làm gì, nghiệm thu kết quả và sở hữu sản phẩm. Bên nhận làm chịu trách nhiệm biến mô tả đó thành hệ thống chạy được: chọn kiến trúc, viết mã, kiểm thử, triển khai và bảo trì trong phạm vi đã cam kết.

Ba thứ thực sự được trao đổi trong một hợp đồng gia công:

1. Công việc. Ai làm, làm trong bao lâu, làm ra cái gì.
2. Rủi ro. Ai chịu khi phạm vi thay đổi, khi tiến độ trượt, khi hệ thống không đạt tiêu chí.
3. Quyền sở hữu. Mã nguồn, tài liệu, dữ liệu và quyền sử dụng thương mại thuộc về ai, vào thời điểm nào.

Ba thứ này thường không được viết rõ trong hợp đồng, và đó là lý do phần lớn tranh chấp phát sinh không phải vì kỹ thuật kém mà vì hai bên hiểu khác nhau về một trong ba điểm trên.

Gia công không phải là mua một gói phần mềm

Mua phần mềm đóng gói là mua quyền dùng một sản phẩm đã có: bạn chấp nhận cách sản phẩm đó mô hình hoá nghiệp vụ và chỉ cấu hình được trong giới hạn nhà cung cấp cho phép. Gia công là xây một sản phẩm chưa tồn tại, theo quy trình nghiệp vụ của bạn. Hệ quả khác nhau rất lớn:

• Với phần mềm đóng gói, chi phí thay đổi nằm ở nhà cung cấp và bạn chờ họ phát hành phiên bản.
• Với gia công, chi phí thay đổi do bạn và đối tác thoả thuận, và bạn có quyền mang mã nguồn đi nơi khác nếu hợp đồng cho phép.

Gia công không phải là thuê người

Có một kiểu hợp tác dễ bị gọi nhầm là gia công: trả tiền theo đầu người mỗi tháng để có vài lập trình viên làm việc bạn giao từng ngày. Đó là tăng cường nhân sự, không phải gia công theo kết quả. Khác biệt nằm ở ai định nghĩa "xong": gia công cam kết một kết quả; tăng cường nhân sự để bạn tự quản lý công việc và tự chịu rủi ro năng suất.

Ranh giới quyết định: sản phẩm so với kỹ thuật

Một nguyên tắc giúp hợp tác êm: bạn quyết định sản phẩm, đối tác quyết định cách làm. Bạn nói "đơn hàng phải duyệt được theo ba cấp và ghi lại ai duyệt"; đối tác nói "chúng tôi lưu lịch sử duyệt bằng bảng riêng, có chỉ mục theo đơn hàng". Nếu bạn bắt đầu chỉ định bảng nào, cột nào, thư viện nào thì bạn đã nhận lại rủi ro kỹ thuật mà không nhận lại năng lực tương ứng. Ngược lại, nếu đối tác tự quyết định luồng nghiệp vụ thay bạn, sản phẩm sẽ phục vụ quy trình của họ.

Phần việc không nhìn thấy trong một dự án gia công

Người mua thường chỉ hình dung phần "viết code". Trong thực tế, một dự án phần mềm có bốn nhóm việc, và nhóm nào cũng tiêu tốn thời gian:

Một dự án chỉ có phần "xây dựng" mà thiếu ba nhóm còn lại sẽ tạo ra hệ thống chạy được nhưng không ai dám sửa. Đây là dạng thất bại phổ biến nhất của gia công phần mềm, và nó không xuất hiện trong báo giá ban đầu.

Bốn thuật ngữ người mua hay dùng lẫn

Trên thị trường Việt Nam, bốn cụm từ dưới đây được dùng gần như thay thế cho nhau. Chúng không giống nhau, và mỗi cụm kéo theo một kiểu hợp đồng khác nhau.

Gia công phần mềm là cách nói nghiêng về quan hệ đặt – nhận. Trọng tâm là "làm cho tôi cái này, đúng tiêu chí này". Outsourcing phần mềm là cách nói nghiêng về tổ chức: bạn thuê ngoài một phần hoạt động, có thể là cả bộ phận kỹ thuật, và đo bằng cam kết vận hành. Thuê ngoài phát triển nhấn vào năng lực con người nhiều hơn sản phẩm. Xây dựng theo yêu cầu nhấn vào tính may đo: không có sản phẩm đóng gói nào vừa với quy trình của bạn.

Với người mua, khác biệt thực dụng là: nếu bạn cần một kết quả và mô tả được nó, hãy ký theo kết quả. Nếu bạn cần một năng lực để tự điều phối, hãy ký theo thời gian nhưng phải tự có người quản lý kỹ thuật. Trộn hai kiểu trong một hợp đồng là công thức của tranh chấp.

Hai bài viết đi sâu vào hai cách gọi phổ biến nhất: outsource phần mềm là gì và outsourcing software là gì, bao gồm cách đọc hợp đồng outsourcing lần đầu.

Năm mô hình gia công và cái giá phải trả

Không có mô hình nào tốt cho mọi trường hợp. Mỗi mô hình phân bổ rủi ro theo một cách khác nhau, và cái giá của nó xuất hiện ở một chỗ khác với chỗ bạn nhìn.

Mô hình 1: Đội nội bộ

Bạn tuyển và tự quản lý đội kỹ thuật. Đây là mô hình duy nhất cho phép học hỏi tổ chức tích luỹ trong dài hạn: kiến thức về nghiệp vụ ở lại công ty, không phụ thuộc vào một nhà cung cấp. Cái giá là chi phí cố định: tuyển dụng, đào tạo, giữ người, và thời gian để một đội mới đạt năng suất. Với doanh nghiệp vừa và nhỏ, chi phí này thường không chia sẻ được cho nhiều dự án, nên mỗi đồng lương phải gánh một hệ thống duy nhất.

Mô hình này phù hợp khi phần mềm chính là sản phẩm kinh doanh, hoặc khi quy trình nghiệp vụ là tài sản không thể mô tả hết cho người ngoài.

Mô hình 2: Đội dự án chuyên trách

Một nhóm người của đối tác làm việc dành riêng cho bạn trong một khoảng thời gian, thường có một quản lý dự án của họ và một đầu mối của bạn. Hợp đồng tính theo thời gian nhưng có cam kết đầu ra theo từng giai đoạn: hết giai đoạn khám phá phải có tài liệu khám phá, hết giai đoạn đặc tả phải có bản đặc tả được bạn ký xác nhận.

Đây là mô hình linh hoạt nhất cho dự án chưa rõ phạm vi, nhưng nó chỉ tốt khi bạn có người đủ gần để ra quyết định hằng tuần. Nếu người đại diện của bạn họp mỗi tháng một lần, mô hình này sẽ trôi thành một dự án không có đích.

Mô hình 3: Dự án trọn gói, phạm vi cố định

Đối tác cam kết một phạm vi và một mức giá. Rủi ro phạm vi chuyển sang họ, và họ sẽ định giá cho rủi ro đó. Đây là mô hình dễ mua nhất về mặt hành chính và cũng là mô hình dễ sinh ra sản phẩm tối thiểu nhất: khi phạm vi bị hiểu hẹp hơn thực tế, đối tác có động cơ làm đúng chữ trong hợp đồng thay vì làm đúng nhu cầu.

Để mô hình này hoạt động, ba thứ phải có trước khi ký: đặc tả đủ chi tiết để nghiệm thu, tiêu chí nghiệm thu đo được, và cơ chế xử lý thay đổi có đơn giá rõ ràng. Thiếu một trong ba, bạn đang mua một cuộc tranh luận.

Mô hình 4: Tăng cường nhân sự

Bạn thuê người của đối tác làm trong đội của bạn, theo lệnh công việc của bạn. Mô hình này hữu ích khi bạn đã có kiến trúc, có quy trình và chỉ thiếu năng lực thực thi. Nó cũng là mô hình rẻ nhất trên giấy và đắt nhất trên thực tế nếu bạn không có người quản lý kỹ thuật: không ai chịu trách nhiệm về kết quả cuối cùng ngoài bạn.

Một dấu hiệu cần kiểm tra: nếu đối tác không nói được ai review mã và ai chịu trách nhiệm khi hệ thống không đạt yêu cầu hiệu năng, đó không phải tăng cường nhân sự có quản trị.

Mô hình 5: Dịch vụ vận hành

Bạn không sở hữu đội, không sở hữu mã nguồn, chỉ trả tiền để hệ thống chạy và được cập nhật. Với hệ thống phụ trợ như cổng thanh toán hay đồng bộ dữ liệu, đây thường là lựa chọn hợp lý. Với hệ thống lõi, đây là lựa chọn nguy hiểm: khi muốn đổi nhà cung cấp, bạn không có gì để bàn giao.

Mô hình nào hợp với ràng buộc nào

Thay vì chọn theo cảm giác, hãy bắt đầu từ ràng buộc cứng nhất của bạn. Bảng dưới đây là một lối đi nhanh.

Một lưu ý thực dụng: bạn có thể dùng hai mô hình cùng lúc — ký trọn gói cho phần lõi đã rõ phạm vi, tăng cường nhân sự cho phần tích hợp còn thay đổi. Điều cần tránh là trộn hai mô hình 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.

Điều gì thực sự được bàn giao

"Bàn giao" là từ bị lạm dụng nhất trong hợp đồng phần mềm. Một buổi demo không phải bàn giao. Một tài khoản quản trị không phải bàn giao. Bàn giao là trạng thái mà ở đó đội của bạn có thể tự chạy, tự sửa và tự triển khai hệ thống mà không cần gọi cho đối tác.

Hai hạng mục hay bị bỏ nhất là tài khoản hạ tầng và quy trình phục hồi dữ liệu; cả hai chỉ lộ ra khi có sự cố, lúc đó bạn không còn vị thế thương lượng.

Hợp đồng quyết định quyền của bạn

Một hợp đồng phát triển phần mềm tốt không cần dài. Nó cần trả lời được tám câu hỏi. Nếu một câu không có câu trả lời, đó là điểm rủi ro bạn đang giữ mà không biết.

Vì sao điều khoản sở hữu trí tuệ quan trọng hơn giá

Có hai cách viết điều khoản sở hữu. Cách thứ nhất: mã nguồn thuộc về đối tác cho đến khi thanh toán đủ, sau đó chuyển giao toàn bộ. Cách thứ hai: chuyển giao từng phần theo từng đợt thanh toán. Cả hai đều hợp lý, nhưng hệ quả khác nhau khi dự án dừng giữa đường. Với cách thứ nhất, nếu bạn dừng ở đợt hai, bạn có thể không có quyền dùng phần đã làm. Với cách thứ hai, bạn luôn có quyền với phần đã trả tiền.

Điều khoản cũng phải nói rõ thư viện mã nguồn mở được dùng theo giấy phép nào. Một thư viện có giấy phép copyleft có thể buộc bạn phải công bố mã của mình khi phân phối sản phẩm. Đây là rủi ro pháp lý, không phải rủi ro kỹ thuật, và nó chỉ được phát hiện khi đã quá muộn.

Chi tiết từng điều khoản được phân tích trong bài hợp đồng phát triển phần mềm.

Tiêu chí nghiệm thu phải viết được thành câu kiểm tra

Một tiêu chí nghiệm thu tốt có dạng: "Khi nhân viên kho tạo phiếu xuất có số lượng lớn hơn tồn kho, hệ thống chặn và hiển thị số tồn hiện tại". Nó có đối tượng, hành động, điều kiện và kết quả quan sát được. Một tiêu chí nghiệm thu kém có dạng: "Chức năng quản lý kho hoạt động tốt".

Nếu bạn không viết được tiêu chí thành câu kiểm tra, bạn chưa hiểu đủ nghiệp vụ để mua. Đó là lúc nên dành thêm thời gian cho giai đoạn đặc tả, thay vì ký sớm để "chạy tiến độ".

Chi phí: cấu trúc chứ không phải con số

Không thể nói một dự án phần mềm giá bao nhiêu mà không nói phạm vi. Nhưng có thể nói cái gì làm giá tăng. Sáu yếu tố dưới đây giải thích phần lớn chênh lệch giữa hai báo giá cho cùng một bản mô tả.

Hai yếu tố cuối là nguồn gốc của phần lớn dự án vượt ngân sách. Thay đổi yêu cầu ở giai đoạn khám phá gần như miễn phí; thay đổi sau khi đã kiểm thử là làm lại một phần hệ thống.

Theo thời gian hay theo kết quả

Hợp đồng theo thời gian minh bạch về đơn giá nhưng đẩy rủi ro phạm vi về phía bạn. Hợp đồng theo kết quả đẩy rủi ro về phía đối tác, và đối tác sẽ tính một khoản bù cho rủi ro đó. Không có lựa chọn nào rẻ hơn tuyệt đối; chỉ có lựa chọn phù hợp với việc ai kiểm soát được phạm vi tốt hơn.

Nếu bạn chưa mô tả được phạm vi, ký theo kết quả sẽ khiến đối tác phải đoán, và họ sẽ đoán theo hướng an toàn cho họ. Nếu bạn đã mô tả rõ, ký theo thời gian sẽ khiến bạn trả tiền cho sự thiếu hiệu quả mà không có cơ chế ràng buộc.

Chi phí sở hữu không dừng ở ngày bàn giao

Một hệ thống đang chạy phát sinh chi phí vận hành: hạ tầng, giám sát, sao lưu, cập nhật bảo mật, sửa lỗi và bổ sung tính năng. Tỷ lệ chi phí này so với chi phí xây dựng ban đầu phụ thuộc vào số tích hợp, mức độ thay đổi nghiệp vụ và chất lượng kiến trúc ban đầu. Một kiến trúc tệ làm chi phí vận hành tăng dần theo thời gian, và đó là khoản không xuất hiện trong bất kỳ báo giá nào.

Cách phân rã chi phí chi tiết hơn nằm trong bài chi phí phát triển phần mềm.

Khi nào nên chọn gia công, khi nào không nên

Gia công phần mềm là lựa chọn hợp lý khi hội đủ các điều kiện sau:

• Bạn mô tả được kết quả mong muốn bằng ngôn ngữ nghiệp vụ, kể cả các ngoại lệ.
• Có một người đại diện sản phẩm đủ thẩm quyền ra quyết định hằng tuần.
• Có quy trình nghiệm thu dựa trên tiêu chí đã viết, không dựa trên cảm nhận.
• Có người đọc được mã hoặc thuê được người kiểm tra độc lập trước khi nghiệm thu.
• Dữ liệu được phép ra khỏi tổ chức hoặc có thoả thuận xử lý dữ liệu rõ ràng.
• Bạn chấp nhận rằng phần mềm may đo cần bảo trì, không phải mua một lần là xong.

Ngược lại, gia công là lựa chọn tệ khi:

• Kiến thức nghiệp vụ cốt lõi chỉ nằm trong đầu vài người và không thể viết ra. Khi đó, đối tác sẽ xây một hệ thống theo cách hiểu của họ.
• Yêu cầu thay đổi liên tục theo bối cảnh ngầm mà bạn không giải thích được. Mô hình đội chuyên trách phù hợp hơn, hoặc phải chấp nhận khám phá dài hơn.
• Không có ai trong doanh nghiệp chịu trách nhiệm tiếp nhận. Hệ thống sẽ được bàn giao cho một người không có thời gian, và ba tháng sau không ai nhớ nó chạy thế nào.
• Phần mềm chỉ để dùng nội bộ trong vài tháng. Khi đó, một công cụ có sẵn hoặc bảng tính được cấu trúc tốt rẻ hơn nhiều.

Quy trình bốn giai đoạn: Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường

Một quy trình có tên gọi rõ ràng giúp bạn biết mình đang ở đâu và phải đòi gì ở mỗi bước. WinSell dùng bốn giai đoạn sau cho mọi dự án xây dựng phần mềm theo yêu cầu.

Giai đoạn 1: Khám phá

Mục tiêu là hiểu bài toán trước khi nói đến giải pháp. Đầu ra gồm bản đồ quy trình hiện tại, danh sách bên liên quan, các điểm nghẽn và tiêu chí thành công. Giai đoạn này kết thúc bằng một quyết định: 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ì.

Điều bạn nên đòi: một bản tóm tắt vấn đề bằng ngôn ngữ của bạn, không phải bằng ngôn ngữ kỹ thuật.

Giai đoạn 2: Đặc tả

Mục tiêu là 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 (hiệu năng, bảo mật, khả năng mở rộng), mô hình dữ liệu và tiêu chí nghiệm thu cho từng luồng chính.

Điều bạn nên đòi: mỗi yêu cầu chức năng có ít nhất một tiêu chí nghiệm thu đo được, và mỗi yêu cầu phi chức năng có một ngưỡng cụ thể. "Nhanh" không phải yêu cầu; "trang danh sách trả kết quả dưới hai giây với mười nghìn bản ghi" là yêu cầu.

Giai đoạn 3: Xây dựng

Mục tiêu là tạo ra phần mềm chạy được theo từng vòng ngắn, có kiểm thử và có môi trường thử nghiệm để bạn xem tiến độ bằng sản phẩm thật, không bằng báo cáo. Đầu ra gồm mã nguồn, bộ kiểm thử tự động, môi trường staging và bản dựng có thể triển khai.

Điều bạn nên đòi: quyền truy cập vào môi trường staging và một buổi demo theo lịch cố định, có bản ghi. Nếu bạn chỉ thấy tiến độ qua tin nhắn, bạn đang không quản lý được dự án.

Giai đoạn 4: Bàn giao và đo lường

Mục tiêu là chuyển hệ thống sang trạng thái bạn tự vận hành được, và đo xem nó có giải quyết bài toán ban đầu hay không. Đầu ra 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.

Điều bạn nên đòi: một buổi chạy thử quy trình phục hồi dữ liệu do đội của bạn thực hiện, không phải do đối tác thực hiện. Nếu bạn chưa từng tự phục hồi, bạn chưa thực sự sở hữu hệ thống.

Bảy sai lầm thường gặp khi gia công phần mềm

1. Chọn theo báo giá thấp nhất. Hai báo giá chênh nhau thường vì phạm vi khác nhau, không vì năng lực khác nhau. Hãy chuẩn hoá phạm vi trước khi so giá.
2. Đặc tả bằng lời. Một cuộc họp không phải đặc tả. Nếu không có văn bản được hai bên xác nhận, phạm vi sẽ được nhớ khác nhau.
3. Không định nghĩa "hoàn thành". Không có tiêu chí nghiệm thu, nghiệm thu trở thành cuộc thương lượng về cảm nhận.
4. Không thoả thuận sở hữu trí tuệ trước. Đàm phán điều khoản sở hữu sau khi hệ thống đã chạy là đàm phán từ vị thế yếu.
5. Không nắm tài khoản hạ tầng. Tên miền, chứng chỉ và khoá truy cập phải đứng tên doanh nghiệp bạn ngay từ ngày đầu.
6. Chỉ nghiệm thu một lần ở cuối. Nghiệm thu theo vòng giúp phát hiện lệch hướng khi chi phí sửa còn thấp.
7. Không có kế hoạch vận hành sau bàn giao. Một hệ thống không có người giám sát sẽ hỏng âm thầm, và thường hỏng đúng vào lúc quan trọng nhất.

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

Gia công phần mềm khác gì thuê nhân viên IT?

Khác ở chỗ ai cam kết kết quả. Khi gia công, đối tác cam kết một sản phẩm đúng phạm vi và chịu trách nhiệm về chất lượng bàn giao. Khi thuê nhân viên, bạn trả tiền theo thời gian làm việc và tự chịu trách nhiệm về năng suất, cách làm và kết quả cuối cùng của đội.

Chi phí gia công phần mềm được tính theo cách nào?

Chi phí được tính từ phạm vi, không từ một bảng giá cố định. Các yếu tố quyết định gồm số luồng nghiệp vụ, số tích hợp bên thứ ba, chất lượng dữ liệu cũ, độ sâu kiểm thử, yêu cầu tuân thủ và tốc độ thay đổi yêu cầu. Vì vậy báo giá chỉ có ý nghĩa sau khi phạm vi được chốt bằng văn bản.

Tôi có được sở hữu mã nguồn sau khi bàn giao không?

Điều này phụ thuộc hoàn toàn vào điều khoản sở hữu trí tuệ trong hợp đồng, không phụ thuộc vào việc bạn đã trả tiền hay chưa. Hãy yêu cầu ghi rõ thời điểm chuyển giao quyền, phạm vi tài sản được chuyển giao và cách xử lý thư viện mã nguồn mở trước khi ký.

Gia công phần mềm có phù hợp với doanh nghiệp nhỏ không?

Có, nếu doanh nghiệp có một người đại diện đủ thẩm quyền và mô tả được kết quả mong muốn. Doanh nghiệp nhỏ thường phù hợp với phạm vi hẹp, làm theo giai đoạn và nghiệm thu sớm. Điều cần tránh là ký phạm vi lớn khi chưa ai trong doanh nghiệp dành được thời gian cho dự án.

Làm sao kiểm tra đối tác có năng lực thật?

Hãy yêu cầu quy trình làm việc cụ thể thay vì danh sách khách hàng: ai viết đặc tả, ai review mã, kiểm thử được làm ở mức nào, môi trường staging do ai quản lý, và khi có sự cố thì quy trình xử lý ra sao. Một đối tác trả lời được các câu này bằng quy trình thường đáng tin hơn một đối tác trả lời bằng ảnh dự á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 và quy trình bàn giao hiện hành.

Nếu bạn đang cần một hệ thống may đo thay vì một gói có sẵn, WinSell xây dựng phần mềm theo yêu cầu và vận hành sau bàn giao theo đúng bốn giai đoạn ở trên — xem cách chúng tôi làm việc tại dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.