Chọn phát triển phần mềm in-house hay outsource không chỉ là bài toán so sánh chi phí. Quyết định này xác định quyền quyết định sản phẩm, tri thức kỹ thuật, năng lực triển khai và trách nhiệm vận hành sẽ nằm ở đâu.
Với nhiều tổ chức, câu trả lời thực tế là mô hình hybrid: giữ lại bên trong những quyết định và tri thức bắt buộc phải ở nội bộ, rồi dùng đối tác cho một năng lực hoặc một hạng mục được xác định rõ. Ranh giới phù hợp phụ thuộc vào hệ thống, đội ngũ và hậu quả khi có sự cố.
Bài viết này so sánh mô hình in-house, outsource và hybrid theo trách nhiệm vận hành, nêu năm câu hỏi quan trọng hơn đơn giá theo giờ, đưa ra trình tự ra quyết định thực tế và lập bản đồ quyền quyết định cần phân công trước khi chọn mô hình. Bài dành cho CTO và VP Engineering, những người phải bảo vệ lựa chọn của mình trước hội đồng quản trị, bộ phận tài chính và chính các kỹ sư sẽ làm việc với hệ thống đó.
Mô hình in-house thường phù hợp hơn khi phần mềm là năng lực chiến lược cốt lõi, khi tri thức nghiệp vụ liên tục thay đổi và khi tổ chức có thể tuyển dụng, dẫn dắt và giữ chân đội ngũ cần thiết. Quyền sở hữu sản phẩm và kiến trúc là trực tiếp, việc tiếp cận người dùng và bối cảnh vận hành rất gần, và tri thức ở lại trong công ty thay vì rời đi khi hợp đồng kết thúc. Đội ngũ cũng có thể đổi thứ tự ưu tiên mà không cần thay đổi hợp đồng, điều đặc biệt quan trọng khi lộ trình sản phẩm còn đang được khám phá.
Các đánh đổi cũng cụ thể không kém. Việc tuyển dụng và thiếu hụt chuyên gia có thể làm chậm tiến độ, và năng lực gần như cố định một khi đội ngũ đã hình thành. Tổ chức phải gánh toàn bộ gánh nặng quản lý và hỗ trợ, còn các kỹ năng ngách, chẳng hạn một mô hình migration hay tích hợp cụ thể, rất khó duy trì giữa các sáng kiến lớn. Một đội ngũ được định cỡ theo đỉnh của chương trình sẽ bị dư công suất sau đó, còn đội ngũ định cỡ theo trạng thái ổn định sẽ bị quá tải ở giai đoạn cao điểm.
Đối tác bên ngoài phù hợp khi tổ chức cần một đơn vị triển khai hoàn chỉnh, năng lực chuyên môn, năng lực hiện đại hóa hoặc một dự án có phạm vi rõ mà không phải xây dựng lâu dài mọi vai trò trong nội bộ. Đối tác mang đến đội ngũ đã vận hành sẵn và kỹ năng chuyên gia, năng lực có thể điều chỉnh theo một chương trình xác định, kinh nghiệm với các mẫu kỹ thuật tương tự và một lộ trình có cấu trúc cho khám phá, triển khai hoặc chuyển giao.
Rủi ro nằm ở các điểm tiếp giáp. Bối cảnh sản phẩm phải được chuyển giao rồi liên tục cập nhật. Quyền quyết định có thể mờ đi, đến mức không ai chắc một quyết định ưu tiên thuộc về trưởng nhóm của đối tác hay product owner của bên mua. Hợp đồng kém tạo ra sự phụ thuộc vào mã nguồn, hạ tầng hoặc tri thức, và quyền sở hữu vận hành sau khi ra mắt phải được thỏa thuận thay vì mặc định. Outsource hiệu quả nhất khi bên mua vẫn là chủ sở hữu sản phẩm và quản trị một cách chủ động. Nó không thay thế được trách nhiệm giải trình nội bộ.
Mô hình hybrid giữ quyền quyết định về sản phẩm, nghiệp vụ hoặc kiến trúc trong tổ chức, đồng thời giao cho đối tác một ranh giới triển khai được xác định. Mô hình này thường có vài dạng: product owner nội bộ làm việc với đội kỹ sư của đối tác; kiến trúc do nội bộ nắm giữ song song với hạng mục hiện đại hóa do đối tác dẫn dắt; vận hành nền tảng do nội bộ đảm nhiệm trong khi đối tác xây một dịch vụ mới; hoặc đối tác dẫn dắt giai đoạn khám phá và chuyển giao trước khi năng lực được đưa về nội bộ.
Hybrid có thể cân bằng giữa kiểm soát và năng lực, nhưng chỉ khi cả hai bên biết rõ ai quyết định, ai thực thi và ai vận hành. Thiếu sự rõ ràng đó, mô hình này cộng chi phí phối hợp của hai đội với các khoảng trống trách nhiệm của cả hai mô hình. Mẫu cuối cùng ở trên, khi năng lực được đối tác xây rồi chuyển về nội bộ, chính là ý tưởng của phương pháp build-operate-transfer, mà bài BOT vs. Traditional Outsourcing: Which Model is Best for Your Business? so sánh với outsource truyền thống.
Bảng dưới đây so sánh ba mô hình theo các trách nhiệm dịch chuyển giữa chúng. Bảng mô tả xu hướng, không phải bảo đảm: một đối tác được quản trị tốt có thể làm tốt hơn một đội nội bộ quản lý kém, và ngược lại cũng thường gặp.
Hạng mục quyết định
In-house
Đối tác outsource
Hybrid
Ưu tiên sản phẩm
Nội bộ
Bên mua phải giữ lại hoặc ủy quyền rõ ràng
Thường là nội bộ
Tri thức nghiệp vụ
Xây dựng trong nội bộ
Cần chuyển giao có chủ đích
Chủ sở hữu nội bộ + đối tác học hỏi
Năng lực
Phụ thuộc tuyển dụng
Phụ thuộc hợp đồng và đối tác
Linh hoạt theo từng hạng mục
Kiến trúc
Quyền quyết định nội bộ
Cần cơ chế quản trị chung
Nội bộ quyết định, có đóng góp từ đối tác
Bằng chứng chất lượng
Quy trình nội bộ
Phải được ghi trong hợp đồng và minh bạch
Tiêu chuẩn và review chung
Hỗ trợ production
Đội nội bộ
Dịch vụ và quy trình escalation được xác định
Chia theo ranh giới dịch vụ
Liên tục tri thức
Rủi ro nhân sự nghỉ việc
Rủi ro từ đối tác và bàn giao
Quản lý qua các tài liệu dùng chung
Thoát khỏi mô hình
Rủi ro tái cơ cấu hoặc tuyển dụng
Kiểm soát mã nguồn, tài khoản và chuyển giao
Chuyển giao theo từng năng lực
Cách trách nhiệm dịch chuyển giữa mô hình in-house, outsource và hybrid
Hãy đọc theo hàng thay vì theo cột. Tín hiệu hữu ích là nơi một trách nhiệm đổi chủ. Ưu tiên sản phẩm và kiến trúc ở lại nội bộ trong hầu hết cách sắp xếp, còn hỗ trợ production, liên tục tri thức và thoát khỏi mô hình là những hàng mà outsource và hybrid hay để lại khoảng trống không ai để ý, cho đến sự cố đầu tiên hoặc lần đổi nhà cung cấp đầu tiên.
Đơn giá và số lượng nhân sự dễ so sánh, nên chúng thống trị các cuộc trao đổi ban đầu. Năm câu hỏi dưới đây khó trả lời hơn và quyết định kết quả nhiều hơn hẳn.
Xác định lộ trình, chấp nhận rủi ro, quyền sở hữu dữ liệu, quyền quyết định kiến trúc và trách nhiệm production. Những thứ này không biến mất khi triển khai được outsource. Đối tác có thể tư vấn về tất cả, nhưng tổ chức vẫn là bên chịu trách nhiệm về kết quả.
Tránh giao cho đối tác một đống ticket rời rạc. Hãy xác định một sản phẩm, một năng lực nền tảng, một lát cắt hiện đại hóa hoặc một kết quả tích hợp với giao diện và tiêu chí nghiệm thu rõ ràng. Một ranh giới có thể mô tả trong một câu thường là ranh giới có thể kiểm thử, bàn giao và nếu cần thì chuyển đi nơi khác.
Thống nhất về bản demo chạy được, tiêu chí nghiệm thu, kiểm thử, bằng chứng phát hành, chỉ số vận hành và hồ sơ quyết định. Số giờ làm và phần trăm hoàn thành là chưa đủ. Với chỉ số vận hành, hướng dẫn về hiệu suất triển khai phần mềm của DORA là một tài liệu tham khảo hữu ích. Hướng dẫn này định nghĩa các chỉ số về thông lượng và độ bất ổn, gồm thời gian dẫn thay đổi (change lead time), tần suất triển khai (deployment frequency), thời gian phục hồi sau triển khai lỗi, tỷ lệ thay đổi lỗi (change fail rate) và tỷ lệ làm lại do triển khai (deployment rework rate). Hướng dẫn cũng khuyên áp dụng cho từng ứng dụng hoặc dịch vụ một, chia sẻ với mọi đội tham gia triển khai và tránh biến chúng thành mục tiêu dễ bị làm đẹp số liệu.
Dùng kho mã nguồn do bên mua kiểm soát, các quyết định kiến trúc dùng chung, runbook, pairing, demo và bàn giao có diễn tập. Tài liệu nên phục vụ hành động, không phải một bài tập tuân thủ ở phút cuối. Phép thử thực tế là một đội chưa từng gặp các tác giả ban đầu có thể triển khai, thay đổi và vận hành hệ thống từ những gì đang có hay không.
Xác định quyền sở hữu mã nguồn, tài khoản cloud, thông tin xác thực, dữ liệu, giấy phép và tài liệu kỹ thuật. Thỏa thuận hỗ trợ chuyển giao trước khi cần đến, vì các điều khoản thương lượng khi mối quan hệ còn tốt dễ đạt được hơn nhiều so với khi đã căng thẳng.
Trình tự dưới đây biến các câu hỏi thành thứ tự công việc. Trình tự được cố ý đặt nặng ở phần đầu: ba bước đầu quyết định tổ chức phải giữ lại gì, hai bước tiếp theo quyết định cách bảo vệ phần đó, và hai bước cuối ngăn một cam kết lớn được đưa ra trước khi mối quan hệ làm việc tạo ra bằng chứng.
Xác định kết quả kinh doanh và rủi ro vận hành.
Xác định tri thức và quyền quyết định phải ở lại nội bộ.
Đánh giá năng lực nội bộ và các khoảng trống chuyên môn.
So sánh các ranh giới in-house, đối tác và hybrid khả thi.
Đưa hỗ trợ, bảo mật, dữ liệu và phương án thoát khỏi mô hình vào quyết định.
Bắt đầu bằng một lát cắt khám phá hoặc triển khai có phạm vi rõ khi mức bất định còn cao.
Chỉ mở rộng khi sự hợp tác và mô hình vận hành đã tạo ra bằng chứng.
Trước khi so sánh nhà cung cấp hay số lượng nhân sự, hãy liệt kê các quyết định tổ chức phải đưa ra và vận hành. Mỗi quyết định cần một chủ sở hữu chịu trách nhiệm duy nhất, và bảng dưới đây cho thấy bằng chứng thường chứng minh quyền sở hữu đó là thật chứ không chỉ trên danh nghĩa.
Quyết định
Bằng chứng điển hình
Ưu tiên sản phẩm
Lộ trình, kết quả mong muốn và quyết định nghiệm thu
Kiến trúc
Nguyên tắc, hồ sơ quyết định và các ngoại lệ
Rủi ro dữ liệu và bảo mật
Phân loại, quyết định cấp quyền truy cập và chấp nhận rủi ro
Phạm vi triển khai / thay đổi
Ranh giới backlog, phụ thuộc và hồ sơ thay đổi
Vận hành production
Chủ sở hữu dịch vụ, giám sát, mô hình xử lý sự cố và phục hồi
Chất lượng / phát hành
Nghiệm thu, kiểm thử và phê duyệt phát hành
Tri thức / thoát khỏi mô hình
Kho mã nguồn, tài liệu, quyền truy cập và kế hoạch chuyển giao
Mỗi quyết định cần một chủ sở hữu chịu trách nhiệm, bất kể ai thực thi công việc
Chủ sở hữu chịu trách nhiệm có thể nhận tư vấn hoặc hỗ trợ triển khai từ đối tác, nhưng tổ chức cần biết thẩm quyền nằm ở đâu. "Sở hữu chung" mà không có người quyết định cuối cùng thường biến thành quyết định chậm trễ và trách nhiệm bị tranh cãi. Bảo mật là ví dụ điển hình: công trình systems security engineering của NIST coi bảo mật là mối quan tâm cần xử lý xuyên suốt vòng đời hệ thống, phù hợp với cách sắp xếp trong đó một chủ sở hữu nội bộ nắm quyết định về rủi ro thay vì để mặc cho phụ lục hợp đồng.
Hãy hình dung một công ty hiện đại hóa một nền tảng vận hành trong khi đội nội bộ vẫn chạy dịch vụ hiện tại. Một ranh giới hybrid khả thi có thể giữ ưu tiên sản phẩm, quyết định nghiệp vụ, quyền quyết định kiến trúc và việc chấp nhận rủi ro production trong công ty. Đối tác có thể sở hữu một hạng mục hiện đại hóa có phạm vi rõ, bao gồm khám phá, xây dựng, bằng chứng tự động, diễn tập migration và hỗ trợ chuyển giao. Mô hình cần các giao diện rõ ràng:
một product owner phía bên mua có quyền quyết định ưu tiên;
những người review kiến trúc và bảo mật có tên cụ thể;
một kho mã nguồn và bảng công việc dùng chung;
tiêu chí nghiệm thu và bằng chứng phát hành hiển thị cho cả hai bên;
một bước bàn giao vận hành cho từng bản phát hành, không chỉ khi kết thúc dự án;
quy trình escalation cho các quyết định và phụ thuộc bị chặn; và
một lộ trình thoát cho mã nguồn, tài khoản, dữ liệu và tri thức.
Ví dụ này là một mẫu ra quyết định, không phải mô hình hợp tác cố định. Điểm mấu chốt là một ranh giới hybrid chỉ hoạt động khi các giao diện giữa hai bên được nêu rõ.
Hãy yêu cầu mỗi phương án thể hiện cùng một phạm vi trong cùng một khoảng thời gian. Một đề xuất bỏ sót một dòng không rẻ hơn, mà là chưa đầy đủ, và khoản chi thiếu đó thường quay lại về sau dưới dạng làm lại, chậm trễ hoặc một lần tuyển dụng ngoài kế hoạch. Việc so sánh nên bao gồm:
thời gian tuyển dụng hoặc chuyển giao;
quản lý sản phẩm và kỹ thuật;
phủ chuyên môn;
triển khai, kiểm thử và môi trường;
công việc bảo mật và tuân thủ;
hạ tầng và công cụ;
hỗ trợ production và xử lý sự cố;
liên tục tri thức;
thay đổi về nhu cầu hoặc năng lực; và
thoát khỏi mô hình hoặc chuyển giao.
Tránh biến việc so sánh thành một dự báo chính xác giả tạo. Hãy ghi lại các giả định, khoảng giá trị và rủi ro. Mục đích là phơi bày nơi chi phí và trách nhiệm dịch chuyển, không phải chứng minh một mô hình luôn rẻ hơn.
In-house, outsource và hybrid không được xếp hạng từ tốt nhất đến kém nhất. Phép thử hữu ích là bạn có thể nói được, với mọi phần quan trọng của hệ thống, ai quyết định, ai thực thi và ai vận hành hay không. Nếu được, cả ba mô hình đều có thể hiệu quả. Nếu không, không mô hình nào hiệu quả, dù hợp đồng được soạn thế nào. Mô hình đúng giữ lại những quyết định và tri thức phải ở nội bộ, giao cho đối tác một ranh giới triển khai rõ ràng, và đưa hỗ trợ, bảo mật, dữ liệu cùng phương án thoát khỏi mô hình vào lựa chọn ngay từ đầu, thay vì để thành một cuộc thương lượng ở cuối.
Đọc tiếp: How to Choose a Software Development Partner
Khi ranh giới đã rõ, bước tiếp theo là kiểm chứng nó với một đối tác thực tế. Việc đánh giá công bằng bất kỳ đối tác nào, kể cả GCT Solutions, đều dùng cùng tiêu chí như với mọi lựa chọn khác: độ phù hợp kỹ thuật, triển khai minh bạch, bằng chứng, hợp tác thực tế và bàn giao có trách nhiệm, thay vì một lợi thế chi phí chung chung. Phạm vi software engineering và platform modernization mà GCT công bố hỗ trợ kiểu thảo luận về ranh giới triển khai này, kể cả với khách hàng hoạt động tại Hong Kong và trên khắp APAC. Nếu bạn đang cân nhắc ranh giới của riêng mình nên đặt ở đâu, hãy trao đổi với chúng tôi về ranh giới triển khai phù hợp.
Không nên như vậy. Bên mua có thể giữ quyền quyết định sản phẩm, quyền sở hữu dữ liệu, việc chấp nhận rủi ro và quyền quyết định kiến trúc, trong khi đối tác sở hữu một ranh giới triển khai được xác định.
Nearshore mô tả sự gần gũi về địa lý, không phải toàn bộ mô hình vận hành. Múi giờ trùng nhau có thể quan trọng, nhưng quyền sở hữu, bằng chứng, giao tiếp, hỗ trợ và phương án thoát khỏi mô hình quan trọng hơn cái nhãn.
Khi năng lực trở thành trọng tâm chiến lược, cần tiếp cận nghiệp vụ liên tục hoặc có thể vận hành hiệu quả hơn trong nội bộ. Hãy lên kế hoạch chuyển giao ngay từ đầu thông qua kho mã nguồn do bên mua kiểm soát, các tài liệu dùng chung và bàn giao theo từng bước. Bài Top Examples of Build-Operate-Transfer (BOT) Projects cho thấy kiểu chuyển giao có kế hoạch này đã được cấu trúc như thế nào trong các bối cảnh khác.
Nó nên kiểm tra cả mối quan hệ làm việc và mô hình vận hành, không chỉ sản phẩm kỹ thuật: mức độ rõ ràng của các giả định, tốc độ ra quyết định, chất lượng bằng chứng, khả năng xử lý bất định, tư duy production và chuyển giao tri thức.
DORA, Software delivery performance metrics (Các chỉ số hiệu suất triển khai phần mềm)
NIST, Systems Security Engineering Project (Dự án Systems Security Engineering)