Mở đầu — vì sao bài này quan trọng
Nếu bạn làm Project Manager đủ lâu ở Việt Nam, sớm muộn gì bạn cũng đụng tới hai chữ "outsourcing". Hoặc công ty bạn là bên nhận gia công cho khách Mỹ, Nhật, Singapore (mô hình ODC — Offshore Development Center cực phổ biến ở TP.HCM, Hà Nội, Đà Nẵng). Hoặc công ty bạn thuê ngoài một đối tác để làm phần việc mình không đủ người. Dù ở phía nào, bạn sẽ nhanh chóng phát hiện ra một nghịch lý khó chịu: Agile đề cao sự cộng tác, lòng tin, thay đổi linh hoạt — nhưng quan hệ vendor lại thường được đóng khung bằng hợp đồng cứng nhắc, giá cố định (fixed-price), và một bức tường vô hình giữa "chúng tôi" và "họ".
Đây chính là một trong những vùng đất khó nhất của nghề PM. Bạn có thể vận hành Scrum hoàn hảo trong nội bộ, nhưng khi một nửa đội ngũ ngồi ở công ty khác, múi giờ khác, ăn lương theo hợp đồng khác — mọi nguyên tắc Agile bạn học đều bị thử thách. Bài này không dạy lại Scrum hay Kanban (bạn đã học ở các bài trước), mà tập trung vào một câu hỏi rất cụ thể: làm sao để giữ được tinh thần Agile khi một phần hoặc toàn bộ công việc được thực hiện bởi một bên thứ ba có lợi ích thương mại riêng? Đây là kỹ năng phân biệt một PM giỏi với một người chỉ biết chạy ceremony.
Khái niệm cốt lõi
Vì sao outsourcing và Agile vốn "kỵ" nhau
Agile sinh ra trong bối cảnh một đội ngũ ngồi cùng phòng, cùng công ty, cùng mục tiêu. Outsourcing thì ngược lại: nó được thiết kế để chuyển rủi ro và chi phí sang bên khác thông qua hợp đồng. Hai logic này va chạm ở ba điểm chí mạng:
1. Hợp đồng Fixed-Price mang tư duy Waterfall. Khi khách hàng muốn một con số cố định ("làm app này hết bao nhiêu tiền, ký hợp đồng"), họ buộc bên gia công phải ước lượng toàn bộ scope từ đầu. Nhưng ước lượng toàn bộ scope từ đầu chính là thứ Agile cố gắng tránh, vì chúng ta biết yêu cầu sẽ thay đổi. Kết quả: bên vendor "khóa" scope để bảo vệ lợi nhuận, mọi thay đổi đều biến thành change request kèm hóa đơn, và sự linh hoạt — giá trị cốt lõi của Agile — bị giết chết ngay từ chữ ký đầu tiên.
2. Communication overhead — chi phí giao tiếp. Daily Scrum 15 phút trở nên vô nghĩa khi đội ở Hà Nội thức dậy lúc khách ở California chuẩn bị đi ngủ. Múi giờ, rào cản ngôn ngữ (tiếng Anh không phải tiếng mẹ đẻ của cả hai bên trong nhiều dự án Việt–Nhật), và sự khác biệt văn hóa làm việc khiến mỗi vòng phản hồi (feedback loop) bị kéo dài. Agile sống nhờ feedback loop ngắn; outsourcing thường kéo dài nó ra.
3. IP, bảo mật và lòng tin. Khi bạn để một công ty ngoài chạm vào source code, dữ liệu khách hàng, business logic cốt lõi — câu hỏi về quyền sở hữu trí tuệ (Intellectual Property), NDA (thỏa thuận bảo mật), và mức độ truy cập trở nên gay gắt. Khách hàng càng siết bảo mật, vendor càng bị hạn chế truy cập thông tin — mà thiếu thông tin thì không thể tự chủ ra quyết định, một điều kiện cốt lõi của đội Agile.
Ba mô hình hợp đồng và mức độ tương thích với Agile
Hiểu mô hình hợp đồng là chìa khóa, vì hợp đồng quyết định hành vi nhiều hơn bất kỳ buổi training nào.
- Fixed-Price (giá cố định): Scope, thời gian, chi phí đều cố định. An toàn cho khách về ngân sách nhưng "độc hại" với Agile. Mọi thay đổi đều là cuộc chiến thương lượng.
- Time & Materials — T&M (tính theo thời gian + nguồn lực): Khách trả theo số giờ/ngày thực tế. Linh hoạt nhất, hợp Agile nhất, nhưng đòi hỏi lòng tin cao và khách hay sợ "chi phí không kiểm soát".
- Capped T&M / Money for Nothing, Change for Free: Đây là các mô hình lai. Capped T&M là T&M nhưng có trần ngân sách. "Money for Nothing" (do Jeff Sutherland đề xuất) cho phép khách dừng dự án sớm khi đã nhận đủ giá trị và trả một khoản phí nhỏ; "Change for Free" cho phép đổi feature có cùng story points mà không tính thêm tiền. Đây là cách thông minh để giữ tính linh hoạt mà vẫn cho khách cảm giác kiểm soát ngân sách.
Hai cấu trúc đội ngũ thường gặp
- Dedicated Team / ODC: Vendor cung cấp một đội chuyên trách, làm việc gần như nhân viên của khách. Đây là mô hình dễ Agile hóa nhất vì đội ổn định, học domain theo thời gian.
- Staff Augmentation: Khách "mượn" vài kỹ sư từ vendor để bổ sung vào đội nội bộ. Người outsourced trở thành thành viên của Scrum team khách. Cũng khá tương thích Agile nếu đối xử công bằng.
- Project-based / Turnkey: Vendor nhận trọn gói một dự án và giao "chìa khóa trao tay". Khó Agile nhất vì ranh giới "chúng tôi/họ" rõ rệt nhất.
Tình huống thực tế
Tình huống 1 — Cái bẫy Fixed-Price của một startup Singapore và ODC Đà Nẵng
Một startup fintech ở Singapore thuê một ODC khoảng 12 người ở Đà Nẵng làm ứng dụng ví điện tử, ký hợp đồng fixed-price 280.000 USD cho "toàn bộ MVP" trong 6 tháng. Ngay tháng thứ hai, đội Singapore nhận ra luồng KYC (xác minh danh tính) phải làm lại hoàn toàn vì quy định MAS (cơ quan quản lý Singapore) thay đổi. Đây là thay đổi không lường trước được — đúng kiểu tình huống Agile sinh ra để xử lý.
Nhưng vì là fixed-price, vendor Đà Nẵng phản ứng đúng như hợp đồng buộc họ: "Cái này nằm ngoài scope ban đầu, đây là change request, thêm 45.000 USD và 6 tuần." Đội Singapore tức giận, cảm thấy bị "chặt chém". Vendor thì thấy oan vì họ đã báo giá dựa trên scope cũ. Quan hệ rạn nứt, hai bên bắt đầu soi từng dòng email để tìm bằng chứng "ai sai", và dự án trễ 4 tháng.
Bài học: Vấn đề không nằm ở con người mà ở cấu trúc hợp đồng. Fixed-price ép cả hai bên vào thế đối đầu khi yêu cầu thay đổi. Nếu họ dùng Capped T&M với một backlog được ưu tiên rõ ràng, thay đổi KYC chỉ đơn giản là kéo một item lên đầu backlog và đẩy một item ưu tiên thấp ra ngoài — không drama, không hóa đơn bất ngờ. PM giỏi phải tham gia từ khâu chọn mô hình hợp đồng, chứ không chỉ nhận dự án rồi chạy.
Tình huống 2 — Đội Việt–Nhật và bức tường múi giờ + ngôn ngữ
Một công ty gia công phần mềm ở Hà Nội (giả định tên FSoft-style, khoảng 20 dev) làm cho một khách hàng Nhật trong ngành bảo hiểm. Khách Nhật yêu cầu Scrum, Sprint 2 tuần. Vấn đề: mọi yêu cầu đều viết bằng tiếng Nhật, đi qua một BrSE (Bridge System Engineer — kỹ sư cầu nối) rồi mới tới dev Việt. Daily Scrum diễn ra lúc 9h sáng giờ Việt Nam, nhưng Product Owner phía Nhật chỉ rảnh sau 16h giờ Nhật (14h giờ Việt). Mỗi câu hỏi của dev phải chờ gần một ngày mới có câu trả lời.
Hệ quả: dev Việt, vì sợ trễ, tự đoán ý yêu cầu mơ hồ. Đến Sprint Review thì 30% công việc làm sai hướng, phải làm lại. Velocity tụt, niềm tin của khách Nhật giảm, và họ bắt đầu yêu cầu báo cáo chi tiết hơn — vô tình tạo thêm overhead, làm mọi thứ chậm hơn nữa. Vòng xoáy tiêu cực.
Cách họ tháo gỡ: thứ nhất, thiết lập 2–3 giờ overlap bắt buộc mỗi ngày (14h–17h giờ Việt = 16h–19h giờ Nhật) để hỏi–đáp trực tiếp. Thứ hai, nâng cấp vai trò BrSE thành Proxy Product Owner thực thụ, được trao quyền quyết định các chi tiết nhỏ thay vì chỉ dịch. Thứ ba, áp dụng nguyên tắc "khi nghi ngờ, hỏi ngay trong giờ overlap, đừng đoán". Sau 3 Sprint, tỷ lệ làm lại giảm từ 30% xuống dưới 8%.
Bài học: Trong outsourcing xuyên biên giới, overlap time và một Proxy PO có thực quyền quan trọng hơn bất kỳ công cụ nào. Đừng cố ép cả hai bên ngồi họp lúc nửa đêm — hãy thiết kế quy trình quanh thực tế múi giờ. Và rào cản ngôn ngữ không chỉ là dịch thuật; nó là độ trễ trong việc làm rõ ý nghĩa.
Tình huống 3 — Vấn đề IP và bảo mật trong một dự án ngân hàng
Một ngân hàng tầm trung ở Việt Nam thuê một vendor làm module tính điểm tín dụng. Vì là dữ liệu tài chính nhạy cảm, đội bảo mật ngân hàng cấm vendor truy cập dữ liệu khách hàng thật, cấm mang code ra khỏi mạng nội bộ, và yêu cầu mọi commit phải qua review của nhân viên ngân hàng. Nghe rất hợp lý về mặt bảo mật.
Nhưng hệ quả với Agile: vendor không có dữ liệu thật để test, nên model tính điểm chạy tốt trên dữ liệu giả nhưng sai bét trên dữ liệu thật. Việc mọi commit phải chờ review của một nhân viên ngân hàng (vốn đã quá tải) tạo ra bottleneck khổng lồ — có PR chờ 5 ngày mới được duyệt. Đội vendor mất khả năng tự chủ, một điều kiện sống còn của Agile.
Giải pháp cân bằng: ngân hàng tạo một bộ dữ liệu đã ẩn danh (anonymized/masked data) đủ thật để test mà không lộ thông tin khách hàng; lập một môi trường sandbox riêng cho vendor; và cử một kỹ sư ngân hàng làm thành viên embedded trong đội vendor để review code real-time thay vì làm cổng gác bất đồng bộ. NDA và điều khoản IP (toàn bộ code thuộc về ngân hàng) được ký rõ từ đầu để tạo nền tảng tin cậy.
Bài học: Bảo mật và Agile không nhất thiết loại trừ nhau, nhưng cần đầu tư chủ động (dữ liệu ẩn danh, sandbox, người embedded) thay vì chỉ dựng tường cấm. PM phải là người ngồi giữa, dịch nhu cầu bảo mật thành quy trình không giết chết sự tự chủ của đội.
Hướng dẫn từng bước
Đây là quy trình thực dụng để thiết lập một quan hệ outsourcing theo tinh thần Agile:
- Chọn mô hình hợp đồng trước khi viết một dòng code. Ưu tiên T&M hoặc Capped T&M cho công việc có yêu cầu chưa rõ. Chỉ dùng fixed-price cho phần scope thực sự ổn định (ví dụ: phase tích hợp một API đã được định nghĩa hoàn toàn). Đưa các điều khoản Agile-friendly như "Change for Free" vào hợp đồng.
- Định nghĩa Definition of Done chung ngay từ đầu. Vendor và khách phải thống nhất "xong" nghĩa là gì: có test chưa, đạt coverage bao nhiêu, qua security scan chưa. Tránh tình trạng vendor giao "xong theo họ" còn khách bảo "chưa xong theo tôi".
- Thiết lập overlap time bắt buộc. Xác định 2–4 giờ trong ngày mà cả hai bên đều online. Đặt mọi ceremony cần tương tác (Daily, Review, Planning) vào khung này.
- Trao quyền cho một Proxy Product Owner. Nếu PO thật ở xa, hãy có một người phía vendor (BrSE, Business Analyst) được trao quyền quyết định chi tiết nhỏ, tránh để dev chờ hoặc tự đoán.
- Coi vendor là thành viên đội, không phải nhà cung cấp. Mời họ vào Retrospective, chia sẻ context kinh doanh, công nhận đóng góp. "One team" về mặt tinh thần dù khác công ty.
- Xử lý IP và bảo mật chủ động. Ký NDA và điều khoản IP rõ ràng từ đầu. Đầu tư vào dữ liệu ẩn danh, môi trường sandbox, và quy trình review real-time thay vì tường cấm bất đồng bộ.
- Đo bằng giá trị giao được, không phải số giờ hay số dòng báo cáo. Tập trung vào working software mỗi Sprint. Giữ feedback loop ngắn nhất có thể trong giới hạn múi giờ.
Lỗi thường gặp & mẹo
Lỗi 1: Dùng fixed-price cho dự án có yêu cầu chưa rõ. Đây là sai lầm phổ biến nhất và gây tổn hại nhất. Mẹo: nếu khách khăng khăng đòi con số cố định, hãy đề xuất Capped T&M — cho họ trần ngân sách (cảm giác an toàn) nhưng giữ linh hoạt về scope.
Lỗi 2: Đối xử với vendor như "người ngoài". Khi bạn loại vendor khỏi Retrospective, giấu context kinh doanh, hoặc chỉ giao task mà không giải thích "tại sao", bạn biến họ thành cỗ máy code thụ động — đúng thứ Agile ghét. Mẹo: chia sẻ "why" hào phóng; một dev hiểu mục tiêu kinh doanh sẽ ra quyết định tốt hơn gấp nhiều lần.
Lỗi 3: Đẩy hết ceremony vào khung giờ một bên. Bắt đội Việt họp lúc 11h đêm để chiều khách Mỹ là cách nhanh nhất để burnout và mất người. Mẹo: thiết kế quy trình async (bất đồng bộ) cho phần lớn công việc, chỉ giữ overlap time cho những gì thực sự cần đồng bộ.
Lỗi 4: Coi NDA và IP là việc của phòng pháp lý, không phải của PM. Khi tranh chấp IP nổ ra giữa dự án, nó có thể đóng băng toàn bộ tiến độ. Mẹo: PM cần hiểu và xác nhận các điều khoản IP/bảo mật từ ngày đầu, đảm bảo chúng không vô tình giết chết sự tự chủ của đội.
Lỗi 5: Đo lường sai. Yêu cầu vendor báo cáo số giờ, số dòng code, số task — tạo overhead và khuyến khích hành vi sai (viết nhiều code thừa để "đẹp báo cáo"). Mẹo: đo bằng working software demo được mỗi Sprint và sự hài lòng của khách thật.
Bài tập thực hành
Bài tập 1 — Phân tích hợp đồng: Hãy lấy một dự án outsourcing bạn từng tham gia (hoặc tưởng tượng). Xác định nó dùng mô hình hợp đồng nào (Fixed-Price / T&M / Capped T&M). Viết ra 3 hành vi cụ thể mà mô hình đó đã gây ra (ví dụ: "mọi thay đổi đều thành change request"). Sau đó đề xuất một mô hình thay thế và dự đoán hành vi sẽ thay đổi ra sao.
Bài tập 2 — Thiết kế overlap time: Giả sử đội bạn ở Việt Nam (GMT+7) làm cho khách ở Đức (GMT+1) và một thành viên khác ở Mỹ (GMT-5). Hãy vẽ ra khung giờ làm việc của cả ba và tìm ra khoảng overlap khả thi. Quyết định ceremony nào đặt vào overlap, ceremony nào chuyển sang async.
Bài tập 3 — Tình huống IP: Viết một đoạn email (5–7 câu) gửi đội bảo mật của khách, thuyết phục họ cung cấp dữ liệu ẩn danh cho vendor để test, đồng thời trấn an họ về rủi ro bảo mật. Đây là bài tập thực tế bạn sẽ làm thật khi đi làm.
Tóm tắt
Outsourcing và Agile vốn căng thẳng với nhau vì hợp đồng thường mang tư duy Waterfall, giao tiếp bị kéo dài bởi múi giờ và ngôn ngữ, còn bảo mật và IP tạo ra rào cản tin cậy. Nhưng căng thẳng này có thể hóa giải nếu bạn xử lý đúng từ gốc.
Ba điều quan trọng nhất cần nhớ: Thứ nhất, hợp đồng quyết định hành vi — chọn T&M hoặc Capped T&M thay vì fixed-price cho công việc có yêu cầu chưa rõ, và đưa điều khoản Agile-friendly vào hợp đồng. Thứ hai, thiết kế quy trình quanh thực tế múi giờ và ngôn ngữ — overlap time bắt buộc và một Proxy Product Owner có thực quyền giải quyết phần lớn vấn đề giao tiếp. Thứ ba, xử lý IP và bảo mật chủ động bằng dữ liệu ẩn danh, sandbox và người embedded, thay vì dựng tường cấm giết chết sự tự chủ của đội.
Và xuyên suốt tất cả là một tư duy nền tảng: coi vendor là thành viên đội, không phải nhà cung cấp. Một PM giỏi không quản lý outsourcing bằng cách soi hợp đồng và đếm giờ, mà bằng cách xây dựng một "one team" thật sự — nơi cả hai bên cùng thắng khi sản phẩm thành công. Đó mới là Agile đích thực, vượt qua ranh giới công ty.