Thuê ngoài đội phát triển phần mềm: mô hình hợp tác, bàn giao và quyền sở hữu mã nguồn

Thuê ngoài phát triển phần mềm là một quyết định về tốc độ và về năng lực nội bộ. Doanh nghiệp chọn phương án này khi cần ra thị trường nhanh hơn khả năng tuyển dụng cho phép, khi cần một kỹ năng chỉ dùng trong một giai đoạn, hoặc khi muốn thử một hướng sản phẩm mà chưa muốn xây đội cố định.

Rủi ro của phương án này ít khi nằm ở chỗ mọi người tưởng. Chất lượng code không phải vấn đề lớn nhất, vì nó kiểm tra được. Vấn đề lớn nhất thường là kiến thức về hệ thống nằm hết ở bên ngoài, tài liệu không tồn tại, và khi hợp đồng kết thúc thì doanh nghiệp có mã nguồn nhưng không có khả năng phát triển tiếp.

Bài viết này bàn về ba phần quyết định kết quả của một hợp đồng phát triển thuê ngoài: chọn mô hình hợp tác phù hợp với mức độ rõ ràng của yêu cầu, thiết kế việc bàn giao thành một quá trình liên tục, và làm rõ quyền sở hữu mã nguồn cùng các ràng buộc giấy phép trước khi bắt đầu.

Ba mô hình hợp tác

Phạm vi cố định, giá cố định

Hai bên thống nhất một đặc tả và một mức giá. Mô hình này chỉ tốt khi yêu cầu thực sự ổn định và mô tả được đầy đủ trước khi bắt đầu, ví dụ khi xây lại một hệ thống đã tồn tại với hành vi đã biết.

Mô hình này chuyển rủi ro sang phía nhà cung cấp, và bên nhận rủi ro sẽ định giá cho nó. Hệ quả là quy trình quản lý thay đổi trở nên chặt: mọi điều chỉnh ngoài đặc tả đều thành một yêu cầu thay đổi có giá riêng. Nếu yêu cầu nhiều khả năng sẽ thay đổi trong quá trình làm, mô hình này tạo ra ma sát thay vì sự chắc chắn.

Đội chuyên trách, tính theo thời gian

Khách hàng thuê một đội với thành phần đã thống nhất, làm việc theo chu kỳ ngắn và ưu tiên công việc theo backlog do khách hàng quyết định. Mô hình này linh hoạt với yêu cầu thay đổi và phù hợp với phát triển sản phẩm dài hạn. Đổi lại, rủi ro về phạm vi nằm ở phía khách hàng, nên nó chỉ hiệu quả nếu phía khách hàng có người thực sự đóng vai trò chủ sản phẩm, có quyền quyết định và có thời gian dành cho việc đó.

Trung tâm phát triển mở rộng

Nhà cung cấp xây dựng một đội chuyên biệt cho khách hàng, có thể kèm lộ trình chuyển giao đội đó thành đơn vị thuộc khách hàng sau một thời gian. Phù hợp với khối lượng công việc lớn và dài hạn, đặc biệt khi mục tiêu cuối cùng là hình thành năng lực nội bộ. Điều cần thoả thuận trước là điều kiện, thời điểm và chi phí của việc chuyển giao nhân sự, vì đây là phần thường bị để mở và trở thành điểm mắc kẹt về sau.

Chọn mô hình theo mức độ rõ ràng của yêu cầu

Tình huống	Mô hình thường phù hợp	Điều cần kiểm soát chặt
Yêu cầu ổn định, có tài liệu đầy đủ	Phạm vi cố định	Định nghĩa hoàn thành và quy trình yêu cầu thay đổi
Sản phẩm mới, yêu cầu còn tiến hoá	Đội chuyên trách	Chất lượng của backlog và sự sẵn sàng của chủ sản phẩm
Khối lượng lớn, dài hạn, muốn hình thành đội nội bộ	Trung tâm phát triển mở rộng	Điều khoản chuyển giao nhân sự và kế hoạch chuyển giao tri thức
Cần bổ sung một vài kỹ năng thiếu	Bổ sung nhân sự vào đội hiện có	Quy trình onboarding và chuẩn mã nguồn chung

Quyền sở hữu mã nguồn

Đây là phần cần được xử lý trong hợp đồng chứ không phải bằng giả định. Quyền đối với sản phẩm được tạo ra theo hợp đồng phụ thuộc vào điều khoản hai bên ký và pháp luật áp dụng; đừng cho rằng việc trả tiền tự động đồng nghĩa với việc sở hữu mọi thứ. Hãy để luật sư rà soát các điều khoản này trước khi ký, và đặc biệt làm rõ các điểm sau:

• Quyền đối với mã nguồn được viết riêng cho dự án thuộc về ai, và chuyển giao vào thời điểm nào. Nếu quyền chỉ chuyển sau khi thanh toán đầy đủ thì điều đó cần được nêu rõ.
• Nhà cung cấp có sử dụng thư viện, khung hoặc thành phần nội bộ của họ trong sản phẩm hay không. Nếu có, bạn nhận được quyền sử dụng theo hình thức nào, có giới hạn về thời gian, số lượng người dùng hay phạm vi triển khai không, và điều gì xảy ra nếu hai bên chấm dứt hợp tác.
• Quyền của bạn có bao gồm việc sửa đổi, phát triển tiếp và chuyển nhượng cho bên thứ ba hay không.
• Ai sở hữu các tài sản đi kèm mã nguồn: tệp thiết kế, mã hạ tầng, script tự động hoá, bộ kiểm thử, tài liệu kiến trúc, mô hình dữ liệu.
• Điều khoản về việc nhà cung cấp tái sử dụng những gì học được. Kinh nghiệm chung của kỹ sư khó có thể bị cấm; nhưng việc tái sử dụng chính mã nguồn hoặc thiết kế của bạn là chuyện khác và cần được nói rõ.
• Điều khoản bảo đảm rằng sản phẩm không xâm phạm quyền của bên thứ ba, cùng cơ chế xử lý nếu phát sinh khiếu nại.

Nguồn mở và giấy phép bên thứ ba

Mọi dự án phần mềm hiện đại đều dựng trên hàng trăm thư viện nguồn mở, và mỗi thư viện đi kèm một giấy phép với điều kiện riêng. Một số giấy phép rất dễ dãi; một số khác đặt ra nghĩa vụ đáng kể nếu bạn phân phối phần mềm ra bên ngoài. Vấn đề hiếm khi được phát hiện trong lúc phát triển và thường lộ ra khi doanh nghiệp chuẩn bị bán sản phẩm, gọi vốn hoặc bị mua lại.

Hai việc nên yêu cầu ngay từ đầu: nhà cung cấp duy trì một danh mục thành phần phần mềm liệt kê mọi phụ thuộc kèm phiên bản và giấy phép, cập nhật tự động trong pipeline; và hai bên thống nhất trước danh sách các loại giấy phép được phép sử dụng, những loại cần xin phê duyệt riêng, và những loại không được dùng. Việc gỡ một thư viện ra khỏi hệ thống sau hai năm tốn kém hơn nhiều so với việc chặn nó ngay từ ngày đầu.

Bàn giao là một quá trình, không phải một sự kiện

Bàn giao ở cuối dự án là mô hình dễ thất bại nhất, vì nó dồn toàn bộ việc chuyển giao tri thức vào giai đoạn mà đội phát triển đã bắt đầu chuyển sang dự án khác. Cách bền vững hơn là coi mọi thứ cần cho việc bàn giao là điều kiện thường trực của công việc:

• Mã nguồn nằm trong kho do khách hàng sở hữu ngay từ commit đầu tiên, không phải trong hạ tầng của nhà cung cấp rồi copy sang sau.
• Pipeline tích hợp và triển khai chạy trên tài khoản của khách hàng, với quyền quản trị thuộc về khách hàng.
• Hạ tầng được mô tả bằng mã nguồn và nằm cùng kho, thay vì được cấu hình thủ công qua giao diện quản trị.
• Biến môi trường và bí mật được quản lý bằng công cụ quản lý bí mật mà khách hàng truy cập được, không nằm trong tệp cấu hình cục bộ của một kỹ sư.
• Tài liệu kiến trúc, sơ đồ luồng dữ liệu và các quyết định thiết kế quan trọng được ghi lại ngay khi ra quyết định, kèm lý do lựa chọn và các phương án đã cân nhắc.
• Runbook cho các việc vận hành thường gặp: triển khai, rollback, khôi phục dữ liệu, xoay vòng khoá, xử lý các lỗi đã biết.
• Bộ kiểm thử tự động đủ để đội tiếp nhận dám thay đổi mã nguồn mà không phải kiểm thử thủ công toàn bộ.

Một cách kiểm chứng đơn giản và rất hiệu quả: định kỳ vài tháng một lần, yêu cầu một kỹ sư chưa từng tham gia dự án dựng lại toàn bộ hệ thống trong môi trường mới chỉ dựa vào tài liệu và kho mã nguồn. Thời gian người đó cần và số lần phải hỏi đội phát triển là thước đo thực tế nhất về mức độ sẵn sàng bàn giao.

Định nghĩa hoàn thành

Nguồn tranh cãi phổ biến nhất trong các dự án thuê ngoài không phải là chất lượng mà là ý nghĩa của từ xong. Hãy thống nhất bằng văn bản một định nghĩa áp dụng cho mọi hạng mục công việc, chẳng hạn: code đã qua review; kiểm thử tự động đã viết và chạy qua; tài liệu liên quan đã cập nhật; đã triển khai lên môi trường staging và được nghiệm thu theo tiêu chí chấp nhận; đã bổ sung log và metric cần thiết; và các cân nhắc bảo mật đã được xem xét. Định nghĩa này nên nằm trong hợp đồng hoặc phụ lục, không phải trong một cuộc trao đổi miệng.

Bảo mật khi làm việc với đội bên ngoài

• Đội phát triển bên ngoài không nên có quyền truy cập dữ liệu sản xuất theo mặc định. Nếu cần dữ liệu để kiểm thử, hãy dùng dữ liệu đã làm sạch hoặc dữ liệu sinh tổng hợp.
• Quyền truy cập cấp cho từng cá nhân, có thời hạn, và được thu hồi ngay khi người đó rời dự án. Cần một quy trình rõ ràng để nhà cung cấp thông báo mọi thay đổi nhân sự.
• Thoả thuận bảo mật thông tin nên áp dụng cho cả pháp nhân và từng cá nhân tham gia.
• Quy định về thiết bị làm việc, mã hoá ổ đĩa, sử dụng dịch vụ đám mây cá nhân và việc sao chép mã nguồn ra ngoài môi trường được phê duyệt.
• Quét phụ thuộc và quét bí mật lẫn trong mã nguồn chạy tự động trong pipeline, không phụ thuộc vào việc ai đó nhớ kiểm tra.

Bảo hành và giai đoạn sau bàn giao

Hợp đồng nên quy định rõ thời gian bảo hành, phạm vi được coi là lỗi sửa miễn phí so với yêu cầu thay đổi có tính phí, thời gian phản hồi trong giai đoạn này, và hình thức hỗ trợ đội tiếp nhận. Một giai đoạn chuyển tiếp trong đó đội cũ và đội mới cùng làm việc thường tạo ra giá trị lớn hơn chi phí của nó.

Những dấu hiệu cần chú ý

• Nhà cung cấp giữ mã nguồn trên hạ tầng của họ và chỉ bàn giao khi kết thúc.
• Không có kiểm thử tự động, hoặc kiểm thử chỉ được viết vào cuối dự án.
• Tài liệu được hứa sẽ viết ở giai đoạn cuối.
• Không có danh mục thành phần phần mềm và không ai trả lời được câu hỏi dự án đang dùng những giấy phép nào.
• Chỉ một cá nhân hiểu được một phần quan trọng của hệ thống.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt tại Việt Nam. Ở mảng phát triển phần mềm, đội ngũ có thể làm việc theo các mô hình nêu trên, bao gồm phát triển sản phẩm mới, mở rộng đội cho một hệ thống đang chạy, hiện đại hoá ứng dụng cũ, và xây dựng pipeline tích hợp, triển khai cùng hạ tầng mô tả bằng mã nguồn.

Về bàn giao và quyền sở hữu, các thực hành nêu trong bài có thể được đưa vào thoả thuận cụ thể: kho mã nguồn thuộc sở hữu của khách hàng ngay từ đầu, tài liệu và runbook được cập nhật liên tục, danh mục thành phần phần mềm và chính sách giấy phép được thống nhất trước. Điều khoản thương mại và điều khoản về quyền sở hữu được ghi trong hợp đồng cho từng dự án, và nên được luật sư của doanh nghiệp rà soát trước khi ký.