Top 5 gia công phần mềm cho người mới bắt đầu không phải là danh sách năm cái tên để bạn gọi điện hỏi giá. Đây là năm nhóm mô hình đội làm việc khác nhau. Mỗi nhóm phù hợp với một kiểu dự án, một mức ngân sách và một mức rủi ro riêng.
Đội ngũ Pumacode đã ngồi lại với khá nhiều founder mới thuê ngoài lần đầu. Điều đáng nói là phần lớn trong số họ thất vọng không phải vì chọn nhầm công ty. Họ thất vọng vì chọn nhầm mô hình ngay từ bước đầu.
Người mới bắt đầu thường sai ngay từ bước chọn nhà gia công
Ba câu hỏi chúng tôi nhận nhiều nhất từ các founder và dev lần đầu thuê ngoài luôn xoay quanh ba chữ: chọn ai, giá bao nhiêu, rủi ro gì. Nghe thì đơn giản. Nhưng cách họ đi tìm câu trả lời lại thường sai hướng.
Lỗi phổ biến nhất là so sánh báo giá theo con số tổng. Bên A gửi 180 triệu, bên B gửi 120 triệu, thế là chốt bên B. Đến tháng thứ ba thì phát sinh thêm 60 triệu cho mấy hạng mục mà bên A đã ghi rõ trong phạm vi công việc. Còn bên B thì ghi chung chung kiểu “các tính năng khác theo yêu cầu”.
Gia công phần mềm hiểu đơn giản là thuê một đơn vị bên ngoài viết phần mềm cho mình thay vì tự tuyển đội. Cách làm này có một đặc điểm mà người mới hay quên. Bạn không mua một sản phẩm đóng hộp. Bạn đang mua một quá trình kéo dài nhiều tháng.
Trong quá trình đó, yêu cầu sẽ thay đổi. Cách hai bên xử lý thay đổi mới là thứ quyết định chi phí cuối cùng. Một tiêu chí chọn sai ở bước này kéo theo toàn bộ dự án đi lệch.
Chọn nhầm đội không có quy trình kiểm thử, bạn sẽ nhận một sản phẩm chạy được trên máy demo nhưng vỡ khi có 50 người dùng thật. Chọn nhầm đối tác không chịu ghi điều khoản bàn giao mã nguồn, đến lúc muốn đổi đơn vị bảo trì bạn mới biết mình không nắm gì trong tay.
Bộ tiêu chí chấm điểm trước khi xem báo giá
Thứ tự này quan trọng: chấm điểm trước, xem giá sau. Nếu xem giá trước, cái neo tâm lý sẽ kéo bạn về phía con số thấp nhất. Mọi tiêu chí khác tự nhiên bị đánh giá thấp đi.
Nhóm tiêu chí năng lực gồm những thứ kiểm chứng được. Kinh nghiệm ngành cụ thể, chứ không phải “đã làm nhiều dự án”. Đội ngũ thực tế gồm bao nhiêu người, ai là người trực tiếp viết code cho bạn, hay chỉ toàn sales đứng ra trình bày. Tài liệu bàn giao gồm những gì. Và quan trọng nhất là quy trình kiểm thử — họ chạy test tự động hay chỉ ngồi bấm tay rồi ghi “OK”.
Nhóm tiêu chí hợp tác thì ít được chấm điểm nhưng lại gây đổ vỡ nhiều nhất. Kênh liên lạc hằng ngày là gì, có phải chờ email qua lại vài ngày mới trả lời một câu hỏi không. Múi giờ lệch bao nhiêu.
Người phụ trách nói tiếng Việt, tiếng Anh hay phải qua phiên dịch. Và cách xử lý khi yêu cầu thay đổi — họ có quy trình ghi nhận thay đổi kèm báo giá bổ sung, hay cứ làm rồi cuối dự án mới đưa hóa đơn.
Để so sánh công bằng, bạn cho điểm có trọng số. Ví dụ thang 10, nhưng năng lực kỹ thuật nhân hệ số 2, khả năng hợp tác nhân hệ số 1,5, giá chỉ nhân hệ số 1. Cách này khiến bên rẻ mà yếu không tự động thắng.
Bạn có thể tham khảo thêm cách phân loại đội theo vị trí địa lý trong bài so sánh mô hình onshore, offshore và nearshore để hiểu vì sao cùng một yêu cầu, ba mô hình này cho ra ba mức chi phí rất khác nhau.
Năm nhóm nhà gia công, nhìn theo mô hình làm việc
Trước khi mất thời gian liên hệ cả chục chỗ, bạn nên khoanh vùng xem mình đang cần kiểu đội nào. Cách nhanh nhất là nhìn vào ba thứ: quy mô đội, cách họ tính tiền, và mức độ bạn phải tự quản lý dự án.
Đội nhỏ trong nước thường chỉ vài ba người, nhận dự án theo gói, khởi động rất nhanh. Công ty gia công có quy trình rõ thì đông người hơn, ký hợp đồng chặt hơn, và bạn phải chờ vài tuần cho bước làm rõ yêu cầu. Nhóm offshore giá cạnh tranh đắt hơn về thời gian chứ không chỉ về tiền.
Freelancer cá nhân là phương án nhẹ thủ tục nhất. Còn đơn vị tư vấn và gia công trọn gói thì bán cho bạn một quy trình khảo sát nghiệp vụ trước khi viết dòng code đầu tiên. Mỗi nhóm có một kiểu rủi ro riêng. Rủi ro đó không nằm ở chỗ bạn trả bao nhiêu tiền, mà nằm ở chỗ khi có chuyện, ai là người đứng ra chịu trách nhiệm.
Nhóm 1: Đội nhỏ trong nước — nhanh, rẻ, hợp dự án đầu tiên
Đây thường là lựa chọn chúng tôi khuyên các founder thử đầu tiên, vì hai lý do rất thực tế: vòng phản hồi ngắn và chi phí sai sót thấp.
Tiêu chí chọn đội nhỏ khá rõ. Quy mô 3-8 người để đủ làm được một sản phẩm hoàn chỉnh mà không quá cồng kềnh. Phải có sản phẩm mẫu chạy được, tức là bạn mở lên bấm thử được, chứ không phải chỉ nghe kể. Và phải cam kết bàn giao mã nguồn bằng văn bản — nói miệng thì hôm sau quên ngay.
Nhóm này hợp với startup đang ở giai đoạn thử nghiệm thị trường. Bạn cần ra bản MVP trong vòng hai đến ba tháng. MVP là viết tắt của minimum viable product, hiểu nôm na là phiên bản chạy được những tính năng cốt lõi nhất để đưa cho người dùng thật thử. Đưa một đội lớn vào lúc này là lãng phí.
Hạn chế thì phải nói thẳng. Khi sản phẩm bắt đầu có người dùng và bạn cần gấp thêm ba lập trình viên, đội nhỏ thường không có người để điều sang. Tài liệu kỹ thuật nhiều khi rất mỏng, vì họ quen code nhanh hơn viết tài liệu.
Rủi ro lớn nhất là phụ thuộc vào một hai cá nhân chủ chốt. Người đó nghỉ việc thì dự án của bạn cũng chững lại theo. Mẹo từ phía chúng tôi: khi làm việc với đội nhỏ, hãy yêu cầu họ commit code lên một repository mà bạn cũng có quyền truy cập, và cập nhật ít nhất mỗi tuần. Điều này khiến tình huống xấu nhất cũng không làm bạn mất trắng.
Nhóm 2: Công ty gia công có quy trình rõ — an toàn hơn cho dự án dài
Nhóm này không rẻ. Nhưng họ bán cho bạn thứ đắt hơn giá: sự ổn định.
Tiêu chí chọn gồm hợp đồng mẫu có sẵn thay vì soạn từ đầu mỗi lần, quy trình QA rõ ràng, và lịch bàn giao chia theo giai đoạn chứ không giao một cục cuối dự án. QA là viết tắt của quality assurance, hiểu đơn giản là bộ phận chuyên đi tìm lỗi trước khi khách hàng phát hiện ra.
Một công ty có QA riêng nghĩa là họ không để lập trình viên vừa viết vừa tự kiểm tra bài của mình. Đó là cách chắc chắn nhất để lỗi lọt ra ngoài. Nhóm này hợp với doanh nghiệp cần một hệ thống chạy thật, có người dùng thật, và có ít nhất một người nội bộ theo dõi được tiến độ.
Người đó không cần biết code. Chỉ cần biết đặt câu hỏi đúng và kiểm tra được sản phẩm có đúng yêu cầu ban đầu hay không. Chi phí cao hơn đội nhỏ, và thời gian đàm phán cộng với onboarding cũng lâu hơn đáng kể.
Bạn có thể mất ba đến sáu tuần trước khi dòng code đầu tiên được viết. Nghe thì sốt ruột, nhưng phần lớn thời gian đó dành cho việc làm rõ yêu cầu. Chính bước này giúp bạn tiết kiệm nhiều tháng sửa sai về sau.
Khi làm việc với nhóm này, có hai câu bạn nên hỏi thẳng. Thứ nhất, mã nguồn và tài liệu thiết kế sẽ được chuyển giao vào thời điểm nào và dưới hình thức gì. Thứ hai, sau khi hết hạn bảo hành, nếu muốn đơn vị khác tiếp nhận thì cần những gì.
Bạn có thể đọc kỹ hơn về quy trình chuyển giao mã nguồn và tài liệu sau dự án để biết danh mục giấy tờ tối thiểu cần có trong biên bản bàn giao. Ngoài ra, bên cạnh việc nắm rõ phần chuyển giao, bạn cũng nên hiểu cách một số đơn vị viết phần mềm theo yêu cầu ghi chính sách bàn giao sản phẩm trên website của họ trước khi ký.
Còn một điểm nữa mà ít người mới để ý. Khi nhà cung cấp đề nghị hai kiểu tính giá là trọn gói cố định hoặc theo thời gian thực tế bỏ ra, mỗi kiểu hợp với một loại dự án khác nhau. Nếu bạn chưa rõ nên chọn kiểu nào, bài phân tích nên chọn fixed price hay time and material sẽ giúp bạn tránh ký nhầm kiểu hợp đồng khiến hai bên tranh chấp về sau.
Nhóm 3: Đội offshore giá cạnh tranh — cẩn thận khoảng cách múi giờ
Offshore nghĩa là thuê đội ở nước khác, thường là Ấn Độ, Đông Âu hoặc một số nước Đông Nam Á. Giá nhân công thấp hơn đáng kể so với thuê trong nước. Nhưng bạn trả bằng một thứ khác: thời gian.
Điều kiện tiên quyết để nhóm này hoạt động được là có một đầu mối liên lạc tại Việt Nam. Người đó có thể là đại diện của họ hoặc một bên trung gian, nhưng phải nói tiếng Việt và trả lời được trong ngày. Nếu không có đầu mối này, mọi vấn đề nhỏ đều biến thành một vòng email dài ba ngày.
Cam kết giờ phản hồi cũng phải ghi rõ trong hợp đồng, chứ không chỉ hứa miệng. Và nên có kênh báo cáo tiến độ hàng tuần — bảng công việc đã xong, đang làm, còn tồn — để bạn không phải đoán mò.
Nhóm này hợp nhất với dự án đã có tài liệu yêu cầu rõ ràng và ít thay đổi. Khi hai bên cách nhau năm đến bảy tiếng, một thay đổi nhỏ cũng mất gần một ngày để làm rõ. Dự án càng nhiều thay đổi, chi phí giao tiếp càng lớn. Phần tiết kiệm từ giá nhân công sẽ bị ăn hết.
Hạn chế thật nằm ở chỗ lệch múi giờ làm chậm vòng phản hồi, cộng thêm rào cản ngôn ngữ khi mô tả lỗi. Một lập trình viên nhận mô tả “màn hình bị lỗi khi bấm nút” sẽ mất thêm nửa ngày để hỏi lại lỗi gì, ở màn hình nào, bấm nút nào.
Để giảm việc này, hãy quay video màn hình khi báo lỗi thay vì gõ mô tả bằng chữ. Chúng tôi từng thấy một dự án bị trễ hai tuần chỉ vì vấn đề này nằm ở nguồn: đặt máy chủ trong nước nhưng đội lại ở múi giờ khác. Mỗi lần cần kiểm tra lại phải chờ nhau gần trọn một ngày. Sau lần đó, chúng tôi thường yêu cầu bên offshore cung cấp tên và khung giờ làm việc trực tiếp của người phụ trách, không phải chỉ tên công ty.
Nhóm 4: Freelancer cá nhân — rẻ nhưng không phải lúc nào cũng đủ
Thuê một người làm là phương án nhẹ nhàng nhất về thủ tục. Đây cũng là phương án có rủi ro dừng giữa đường cao nhất.
Tiêu chí chọn khá đơn giản. Phải có portfolio thật, tức là sản phẩm họ từng làm mà bạn mở lên dùng thử được, chứ không phải ảnh chụp màn hình đẹp. Phải ký hợp đồng rõ ràng, dù chỉ một trang, ghi rõ phạm vi, thời hạn và điều kiện thanh toán. Và nên hỏi thẳng: nếu giữa dự án họ bận việc khác hoặc ốm, ai là người tiếp nhận.
Nhóm này hợp với dự án nhỏ, phạm vi cố định, và chủ dự án tự kiểm soát được tiến độ. Ví dụ một trang landing page, một công cụ nội bộ cho vài người dùng, hoặc một tính năng nhỏ gắn vào hệ thống đang có sẵn.
Vấn đề xuất hiện khi dự án vượt quá chuyên môn của một người. Một freelancer giỏi làm giao diện chưa chắc làm được phần xử lý thanh toán, và chưa chắc biết cấu hình máy chủ. Đến lúc đó họ sẽ hoặc là học trong lúc làm — nghĩa là bạn trả tiền cho thời gian học của họ — hoặc là dừng lại giữa đường.
Với nhóm này, chúng tôi thường khuyên chia thanh toán thành nhiều mốc nhỏ. Mỗi mốc gắn với một phần sản phẩm chạy được. Đừng trả trước quá ba mươi phần trăm giá trị hợp đồng. Nếu đối tác không đồng ý cách chia này, đó cũng là một tín hiệu đáng cân nhắc.
Nhóm 5: Đơn vị tư vấn thiết kế và gia công phần mềm trọn gói
Đây là mô hình đắt nhất trong năm nhóm. Nhưng nó cũng giải quyết được vấn đề mà bốn nhóm kia không giải quyết: doanh nghiệp không có ai hiểu kỹ thuật để ra quyết định.
Điểm khác biệt nằm ở bước khảo sát nghiệp vụ trước khi viết code. Đơn vị trọn gói sẽ ngồi với bạn, hỏi quy trình đang chạy thế nào, ai làm gì, chỗ nào đang tốn thời gian nhất, rồi mới đề xuất giải pháp. Với bốn nhóm trên, bạn thường phải tự mô tả yêu cầu bằng ngôn ngữ kỹ thuật. Người không chuyên rất dễ mô tả sai.
Ngoài ra, nhóm này thường bàn giao kèm tài liệu thiết kế và hướng dẫn bảo trì. Hướng dẫn bảo trì nghĩa là tài liệu mô tả hệ thống cần sao lưu ra sao, cập nhật phiên bản thế nào, khi có lỗi thì xem log ở đâu. Ít ai nghĩ tới việc này lúc ký hợp đồng. Nhưng đây chính là thứ quyết định bạn có thể tự xử lý sự cố nhỏ hay phải gọi đối tác mỗi lần.
Nhóm này hợp với doanh nghiệp chưa có đội kỹ thuật riêng và cần một đối tác đi cùng dài hạn. Đổi lại, bạn phụ thuộc vào họ nhiều hơn. Nếu chọn sai thì rất khó đổi giữa đường vì hệ thống đã gắn chặt với cách họ thiết kế.
Cách đọc báo giá và hợp đồng mà người mới hay bỏ qua
Báo giá không phải là một con số. Nó là một danh sách, và danh sách đó phải tách được từng phần thì bạn mới so sánh được.
Hãy yêu cầu báo giá chia theo giai đoạn: khảo sát và thiết kế, xây dựng tính năng cốt lõi, kiểm thử, rồi triển khai và bàn giao. Cách chia này cho bạn hai lợi ích. Bạn dễ so sánh giữa các nhà cung cấp vì biết bên nào đắt ở khâu nào. Và bạn kiểm soát được tiến độ, vì mỗi giai đoạn có sản phẩm cụ thể để nghiệm thu trước khi trả tiền.
Bốn điều khoản bạn phải soi kỹ trong hợp đồng:
- Phạm vi thay đổi: bao nhiêu lần sửa trong phạm vi giá đã chốt, vượt thì tính thế nào.
- Chi phí phát sinh: mức giá cho mỗi giờ làm thêm, và ai là người phê duyệt trước khi làm.
- Quyền sở hữu mã nguồn: ghi rõ thuộc về bên nào, thời điểm chuyển giao, hình thức chuyển giao.
- Bảo hành sau bàn giao: thời hạn bao lâu, sửa lỗi miễn phí trong phạm vi nào, hỗ trợ ngoài giờ tính ra sao.
Và có một nguyên tắc chúng tôi luôn nhắc khách hàng: những gì chưa ghi vào hợp đồng hoặc phụ lục thì coi như chưa có. Trao đổi qua điện thoại rồi hai bên gật đầu là cách chắc chắn nhất để ba tháng sau cãi nhau.
Ba cạm bẫy khiến dự án đầu tiên đội chi phí
Cạm bẫy đầu tiên là chốt giá cố định cho một phạm vi chưa rõ ràng. Nghe thì hấp dẫn vì bạn biết chính xác mình sẽ trả bao nhiêu. Nhưng khi yêu cầu thay đổi — và nó luôn thay đổi — hai bên bắt đầu tranh nhau xem thay đổi đó có nằm trong giá gốc hay không. Kết quả thường là hoặc bạn trả thêm, hoặc nhà cung cấp làm qua loa cho xong.
Chúng tôi từng chứng kiến một dự án mà hai bên mất gần sáu tuần chỉ để tranh luận xem tính năng xuất báo cáo Excel có nằm trong “chức năng quản lý báo cáo” đã ghi trong hợp đồng hay không. Sáu tuần đó không tạo ra một dòng giá trị nào.
Cạm bẫy thứ hai là không có người nội bộ theo dõi tiến độ. Dự án gia công có một đặc tính tai hại là mọi thứ nghe ổn cho tới tuần cuối. Không ai theo dõi thì bạn chỉ phát hiện ra vấn đề khi gần hạn bàn giao. Lúc đó không còn đủ thời gian để sửa. Chỉ cần một người dành ra ba mươi phút mỗi tuần đọc báo cáo và mở thử sản phẩm là đủ chặn phần lớn rủi ro.
Cạm bẫy thứ ba, và cũng là cái đắt nhất, là bỏ qua bước nghiệm thu kỹ thuật. Nhà cung cấp mở một buổi demo mượt mà, bạn thấy đúng luồng mình mô tả, thế là ký nghiệm thu và thanh toán phần lớn giá trị hợp đồng. Vài tuần sau, khi có dữ liệu thật và người dùng thật, hệ thống bắt đầu vỡ.
Nghiệm thu kỹ thuật không cần bạn biết code. Bạn chỉ cần kiểm tra vài thứ cơ bản. Dữ liệu nhập sai định dạng thì hệ thống báo lỗi hay im lặng. Hai người cùng sửa một bản ghi thì chuyện gì xảy ra. Và hệ thống chịu được bao nhiêu người truy cập cùng lúc. Những câu hỏi này nên đặt ra từ lúc đàm phán, không phải lúc chuẩn bị ký.
Câu hỏi thường gặp
Người mới bắt đầu nên chọn đội trong nước hay offshore?
Với dự án đầu tiên, chúng tôi nghiêng về đội trong nước. Khác biệt về giá không lớn bằng khác biệt về tốc độ giao tiếp. Trong dự án đầu tiên bạn sẽ có rất nhiều câu hỏi cần trả lời nhanh. Offshore hợp hơn khi bạn đã có tài liệu yêu cầu chặt chẽ và từng làm qua ít nhất một dự án tương tự.
Ngân sách tối thiểu cho dự án gia công phần mềm đầu tiên là bao nhiêu?
Một sản phẩm chạy được với vài tính năng cốt lõi thường rơi vào khoảng 80 đến 200 triệu đồng. Dưới mức này vẫn làm được, nhưng phải chấp nhận bỏ bớt tính năng hoặc dùng nền tảng có sẵn thay vì viết mới hoàn toàn. Con số này thay đổi theo độ phức tạp và số nền tảng bạn cần hỗ trợ.
Làm sao biết nhà gia công có thật sự bàn giao mã nguồn hay không?
Đừng chờ đến cuối dự án mới hỏi. Ngay từ tuần đầu, yêu cầu họ commit code lên repository mà bạn có quyền truy cập. Nếu họ từ chối, đó là câu trả lời rõ ràng nhất bạn cần.
Hợp đồng gia công phần mềm cho người mới bắt đầu cần có những mục nào?
Tối thiểu gồm phạm vi công việc, tiến độ theo giai đoạn, cách tính chi phí phát sinh, quyền sở hữu trí tuệ và mã nguồn, điều kiện bảo hành, và cơ chế giải quyết tranh chấp. Nếu hợp đồng chỉ có ba mục là giá, thời hạn và điều kiện thanh toán thì bạn nên yêu cầu bổ sung.
Có nên chia dự án thành nhiều giai đoạn nhỏ để thử đối tác trước không?
Nên, và đây là cách chúng tôi khuyên dùng nhiều nhất. Hãy bắt đầu bằng một giai đoạn nhỏ kéo dài ba đến bốn tuần với phạm vi hẹp. Qua giai đoạn đó, bạn sẽ biết họ giao tiếp thế nào, chất lượng code ra sao, có tôn trọng deadline không. Chi phí để đổi đối tác sau ba tuần thấp hơn nhiều so với sau sáu tháng.
Lời kết từ đội ngũ Pumacode
Chọn nhà gia công phần mềm cho dự án đầu tiên giống chọn người cùng đi một chặng đường dài hơn là chọn món hàng rẻ nhất. Điều chúng tôi khuyên bạn làm trước khi ký bất cứ hợp đồng nào là viết ra giấy ba thứ. Tính năng nào thật sự bắt buộc phải có trong phiên bản đầu. Số tiền tối đa bạn sẵn sàng mất nếu dự án thất bại. Và tên một người trong công ty sẽ dành thời gian theo dõi dự án mỗi tuần.
Chỉ cần ba dòng đó rõ ràng, phần lớn quyết định về sau sẽ dễ hơn rất nhiều. Đội ngũ chúng tôi đã tư vấn cho không ít doanh nghiệp lần đầu thuê ngoài. Điều khiến họ đi nhanh hơn không phải là chọn được công ty hoàn hảo. Nó là việc họ biết mình cần gì trước khi ngồi vào bàn đàm phán.