Bạn đã tìm được một agency. Portfolio họ ổn, báo giá hợp lý, buổi trao đổi đầu tiên diễn ra thuận lợi. Và bây giờ, họ gửi hợp đồng.
Hầu hết khách hàng sẽ đọc qua phạm vi công việc, kiểm tra con số, liếc qua tiến độ, rồi ký.
Đó là một sai lầm — và là sai lầm chúng tôi đã chứng kiến dẫn đến hậu quả xấu nhiều lần hơn mức muốn kể.
Những điều khoản gây hại nhất không phải là những điều hiển nhiên. Chúng nằm ở những phần mà phần lớn mọi người bỏ qua: sở hữu trí tuệ, danh sách deliverable, và chuyện gì xảy ra khi hợp tác kết thúc. Ba phần này có thể tạo ra sự khác biệt giữa một đối tác làm ăn tốt và một tình huống mà bạn đã trả hàng trăm triệu cho một đoạn code không thuộc sở hữu của mình, trong một hệ thống không ai ghi lại tài liệu.
Đây là những gì cần đàm phán trước khi ký.
1. Quyền Sở Hữu Code: Thực Ra Bạn Đang Trả Tiền Để Mua Gì?
Trong một hợp tác công bằng, khách hàng sở hữu code. Nhưng "công bằng" không phải là mặc định — nó phải được ghi vào hợp đồng.
Nhiều hợp đồng agency có điều khoản chuyển giao quyền sở hữu trí tuệ cho khách hàng chỉ sau khi thanh toán cuối cùng. Nghe có vẻ hợp lý — cho đến khi bạn hiểu điều đó thực sự nghĩa là gì: nếu dự án đang chạy được một nửa và bạn muốn đổi agency, đưa công việc về nội bộ, hoặc tranh chấp hóa đơn cuối, agency vẫn là chủ sở hữu hợp pháp của codebase. Bạn không thể lấy nó và rời đi.
Những điều cần đàm phán:
- Quyền sở hữu chuyển giao theo từng milestone, không chỉ khi thanh toán xong toàn bộ. Khi deliverable được nghiệm thu và hóa đơn được thanh toán, quyền sở hữu trí tuệ chuyển theo.
- Quyền truy cập repo từ ngày đầu tiên. Bạn phải có quyền admin trên hệ thống quản lý mã nguồn — GitHub, GitLab, Bitbucket — không phải chỉ quyền đọc, và không phải đến cuối dự án mới được cấp. Nếu họ phản đối điều này, hãy hỏi tại sao.
- Khai báo thành phần bên thứ ba. Mọi thư viện mã nguồn mở, SDK có bản quyền, hoặc thành phần từ nhà cung cấp ngoài cần được liệt kê. Bạn cần biết nếu phần mềm "tùy chỉnh" của mình phụ thuộc vào một component có giấy phép hạn chế.
- Điều khoản work-for-hire. Trong hầu hết các hệ thống pháp lý, phần mềm được xây dựng cho khách hàng theo hợp đồng đủ điều kiện là work-for-hire. Đảm bảo hợp đồng nêu rõ điều này, không để mơ hồ cho cách hiểu.
Agency làm việc đúng chuẩn sẽ không có vấn đề gì với những điều khoản này. Agency nào phản đối đang nói với bạn điều gì đó.
2. Điều Khoản Bàn Giao: Thực Ra Bạn Nhận Được Gì Khi Dự Án Kết Thúc?
Nhiều agency coi bàn giao là phần phụ — cái gì đó sẽ tính sau khi dự án "hoàn thành". Nhưng nếu việc bàn giao không được định nghĩa trong hợp đồng, bạn đang dựa vào thiện chí thay vì nghĩa vụ.
Chúng tôi từng gặp những founder nhận lại một ứng dụng sẵn sàng lên production mà không có bất kỳ tài liệu nào. Không README, không hướng dẫn triển khai, không giải thích về cấu trúc hạ tầng hay lý do của các quyết định kiến trúc. Về kỹ thuật, agency đã giao — họ chỉ không giao thứ gì có ích cho việc vận hành dài hạn.
Một buổi bàn giao đúng nghĩa cần bao gồm — và phải được ghi vào hợp đồng như một deliverable chính thức:
- README và hướng dẫn cài đặt — Cách chạy project ở môi trường local, cách cấu hình các environment, danh sách dependencies.
- Tài liệu kiến trúc — Tổng quan hệ thống: các thành phần chính, cách chúng kết nối, mỗi service làm gì. Không cần viết dài — chỉ cần đủ để một developer mới hiểu được hệ thống trong một buổi chiều.
- Deployment runbook — Hướng dẫn từng bước để triển khai lên staging và production. Cách rollback. Hệ thống monitoring đang dùng là gì.
- Hướng dẫn cấu hình environment — Những biến môi trường nào đang tồn tại, chúng kiểm soát gì, secret được lưu ở đâu và cách xoay vòng.
- Buổi knowledge transfer — Ít nhất một buổi làm việc thực tế, nơi lead developer của agency hướng dẫn team của bạn (hoặc agency tiếp theo) qua codebase.
Đây không phải những phần thêm vào cho đẹp. Nếu một agency tự hào về sản phẩm họ đã xây dựng, họ sẽ không ngại ghi lại tài liệu. Nếu họ coi documentation là phần tốn công không cần thiết, điều đó nói lên văn hóa kỹ thuật của họ.
3. Điều Khoản Thoát: Chuyện Gì Xảy Ra Khi Hai Bên Chia Tay?
Mọi hợp tác đều kết thúc — thuận lợi, sớm hơn dự kiến, hay ở đâu đó giữa hai trường hợp. Những gì xảy ra sau đó nên được định nghĩa ngay từ đầu, không phải thương lượng dưới áp lực.
Đây là phần mà hầu hết hợp đồng xử lý kém nhất. Điều khoản thoát mơ hồ không phải ngẫu nhiên — chúng trao cho agency quyền lực mặc cả. Nếu quy trình để lấy lại dữ liệu, repo, và quyền truy cập của bạn không được xác định, bạn phụ thuộc vào sự hợp tác của agency. Đó là một vị thế không tốt.
Những điều cần đàm phán:
- SLA chuyển giao repo. Nếu bạn muốn chuyển repo về tổ chức của mình, mất bao lâu? 48 giờ là hợp lý. "Khi nào chúng tôi sắp xếp được" thì không. Ghi một con số cụ thể vào hợp đồng.
- Export dữ liệu. Agency đang nắm giữ dữ liệu gì? Database, backup, analytics, dữ liệu người dùng. Xác định rõ bạn được nhận lại những gì và ở định dạng nào.
- Timeline thu hồi quyền truy cập. Khi hợp tác kết thúc, tất cả quyền truy cập của thành viên agency vào hệ thống, repo, và môi trường cloud của bạn phải được thu hồi trong một khoảng thời gian xác định. Nếu không có điều khoản này, nhân viên cũ của agency có thể vẫn giữ quyền truy cập vào hệ thống production của bạn vô thời hạn.
- Hỗ trợ sau khi thoát. Có khoảng thời gian nào agency sẵn sàng trả lời câu hỏi không? Chi phí là bao nhiêu? Định nghĩa 30 ngày hỗ trợ Q&A có trả phí trong hợp đồng gốc sẽ dễ xử lý hơn rất nhiều so với việc thương lượng sau khi đã kết thúc.
- Điều khoản còn hiệu lực sau khi chấm dứt hợp đồng. Nghĩa vụ bảo mật và chuyển giao IP phải tiếp tục có hiệu lực sau khi hợp đồng kết thúc — đảm bảo hợp đồng nêu rõ điều này.
Dấu hiệu cần cảnh giác: Agency trở nên phòng thủ khi nhắc đến điều khoản thoát, dùng ngôn ngữ như "thông lệ thông thường" để tránh nói cụ thể, hoặc có điều khoản yêu cầu thời gian thông báo dài trước khi có thể chuyển giao quyền truy cập repo. Tự bảo vệ mình khi kết thúc là điều hợp lý. Một agency phản đối điều đó đang bảo vệ lợi thế của họ, không phải lợi ích của bạn.
Cách Chúng Tôi Nghĩ Về Điều Này
Tại TMNSolutions, chúng tôi đưa những điều khoản này vào hợp đồng theo mặc định — không phải vì khách hàng yêu cầu, mà vì chúng tôi tin rằng khách hàng xứng đáng được có chúng. Quyền sở hữu code chuyển giao theo từng milestone. Bàn giao là một deliverable được định nghĩa rõ. Điều khoản thoát rõ ràng và công bằng.
Nếu bạn đang đánh giá các agency và những chủ đề này khiến bất kỳ ứng viên nào tỏ ra khó chịu, hãy chú ý đến sự khó chịu đó. Một đối tác agency tốt không cần lợi thế mặc cả từ codebase của bạn để duy trì mối quan hệ.
Một hợp đồng viết tốt sẽ khiến bạn không bao giờ cần phải dùng đến nó. Nhưng khi mọi thứ đi sai hướng, bạn sẽ vui vì nó đã ở đó.
