Mở đầu — vì sao bài này quan trọng
Khi bạn chuyển từ một team Scrum đơn lẻ lên môi trường scaled (nhiều team cùng làm trên một sản phẩm), có một thứ âm thầm bào mòn tốc độ giao hàng nhiều hơn bất kỳ điều gì khác: phụ thuộc chéo giữa các team (cross-team dependencies). Đó là khi team A không thể hoàn thành công việc của mình cho đến khi team B làm xong một phần nào đó — một API, một thư viện dùng chung, một quyết định kiến trúc, hay đơn giản là một người duy nhất biết về một module cũ.
Phản xạ tự nhiên của hầu hết các tổ chức khi gặp vấn đề này là quản lý phụ thuộc cho thật chặt: lập dashboard theo dõi hàng chục dependency, mở các cuộc họp điều phối liên team hằng tuần, gán "dependency owner", tạo Jira ticket liên kết chằng chịt. Nghe có vẻ chuyên nghiệp. Nhưng đây chính là cái bẫy. Càng quản lý phụ thuộc, bạn càng hợp thức hóa sự tồn tại của chúng, và càng tạo ra một bộ máy hành chính khổng lồ chỉ để giữ cho các team không giẫm chân nhau.
Triết lý cốt lõi của bài này — và cũng là tư duy mà PSPO II kỳ vọng ở một Product Owner cấp cao — gói gọn trong một câu: "Minimize, don't manage" (Giảm thiểu, đừng đi quản lý). Mục tiêu không phải là quản lý phụ thuộc cho giỏi hơn, mà là thiết kế để phụ thuộc không cần tồn tại ngay từ đầu. Một PO giỏi không tự hào vì có dashboard dependency đẹp; họ tự hào vì dashboard đó gần như trống rỗng.
Khái niệm cốt lõi
Phụ thuộc là một dạng lãng phí (waste), không phải một thực thể cần chăm sóc
Trong tư duy Lean, mỗi phụ thuộc chéo là một điểm chờ (wait state) tiềm năng. Team A xong việc nhưng phải chờ team B → công việc nằm im trong WIP → giá trị bị giam giữ, T2M (Time to Market) kéo dài, và rủi ro tích hợp dồn về cuối. Phụ thuộc không tạo ra giá trị; nó chỉ tạo ra phối hợp. Và phối hợp tốn chi phí: chi phí giao tiếp, chi phí đồng bộ lịch, chi phí khi một bên trễ.
Đây là điểm tư duy quan trọng: dependency management là một anti-pattern. Khi bạn đầu tư công sức để quản lý phụ thuộc giỏi hơn, bạn đang tối ưu cho một hoạt động đáng lẽ nên bị loại bỏ. Giống như bạn thuê thêm người để khuân vác đồ qua một bức tường, thay vì đặt câu hỏi tại sao bức tường lại ở đó.
Phân loại phụ thuộc để biết cách xử lý
Không phải phụ thuộc nào cũng giống nhau. Hãy phân biệt:
- Knowledge dependency (phụ thuộc kiến thức): Team A cần biết điều gì đó mà chỉ team B biết. Giải pháp thường là chia sẻ kiến thức, không phải chuyển giao công việc.
- Technical / code dependency: Team A cần một thành phần kỹ thuật do team B sở hữu. Đây là loại nguy hiểm nhất và là mục tiêu chính của việc giảm thiểu.
- Resource / people dependency: Cùng cần một con người (kiến trúc sư, DBA, chuyên gia bảo mật). Thường giải quyết bằng cách nhân rộng năng lực, không "đặt lịch" con người đó.
- Business / decision dependency: Cần một quyết định từ một stakeholder hoặc một PO khác.
Định luật Conway: gốc rễ của phần lớn phụ thuộc
> "Tổ chức thiết kế hệ thống sẽ tạo ra thiết kế phản chiếu cấu trúc giao tiếp của chính tổ chức đó." — Melvin Conway
Nếu bạn chia team theo lớp kỹ thuật (team Frontend, team Backend, team Mobile, team Database), thì bất kỳ tính năng nào hướng tới người dùng cũng sẽ cắt ngang qua nhiều team — và lập tức sinh ra phụ thuộc. Ngược lại, nếu bạn chia theo Feature Team (mỗi team đủ năng lực end-to-end để giao một lát giá trị hoàn chỉnh cho khách hàng), phụ thuộc sẽ co lại đáng kể. Đây chính là lý do Bài 29 phân biệt Component Team vs Feature Team — và tại sao đây là đòn bẩy mạnh nhất để giảm phụ thuộc.
Hệ quả thực hành: Cách hiệu quả nhất để giảm phụ thuộc không phải là điều phối tốt hơn, mà là tái cấu trúc team. Đây là một quyết định mang tính tổ chức, và một PO cấp cao phải biết đẩy cuộc đối thoại này lên với leadership thay vì cam chịu sống chung với phụ thuộc.
Bốn chiến lược giảm thiểu (theo thứ tự ưu tiên)
- Loại bỏ (Eliminate): Tái cấu trúc team thành Feature Team để phụ thuộc biến mất hoàn toàn.
- Nội bộ hóa (Internalize): Đưa năng lực còn thiếu vào trong team (ví dụ: thêm một backend dev vào team frontend) để team tự chủ.
- Tách rời (Decouple): Dùng kiến trúc — API ổn định có version, contract testing, feature flags — để hai team có thể tiến độc lập mà không chờ nhau.
- Sắp xếp (Sequence): Khi không thể loại bỏ, hãy lập kế hoạch để công việc phụ thuộc nằm trên cùng một dòng thời gian, làm sớm và làm rõ phần "contract" trước.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam và "dashboard 47 dependency"
Một sàn thương mại điện tử lớn tại TP.HCM (tạm gọi ShopViet) mở rộng từ 3 lên 9 team Scrum trong vòng một năm. Các team được chia theo lớp: 2 team Mobile, 2 team Web Frontend, 3 team Backend (theo service), 1 team Payment, 1 team Search. Để giao một tính năng "mua trước trả sau" (BNPL), cần tới 5 team phối hợp.
PMO dựng một dashboard Jira theo dõi dependency. Sau ba tháng, dashboard có 47 dependency đang mở. Một Scrum Master dành gần 40% thời gian chỉ để cập nhật trạng thái và đi "đòi" các team. Tệ hơn, nhiều phụ thuộc chỉ lộ ra ở Sprint Review khi tích hợp thất bại — đúng kiểu late discovery (phát hiện muộn) mà bài này cảnh báo. Tính năng BNPL trễ 2 quý so với cam kết với ban điều hành.
Diễn giải: Vấn đề của ShopViet không phải là họ quản lý dependency kém, mà là họ đang quản lý một thứ đáng lẽ phải bị xóa bỏ. Dashboard 47 dòng là triệu chứng của cấu trúc team sai (theo Conway), không phải giải pháp.
Hành động khắc phục: Họ tổ chức lại quanh các "value stream" — gom thành 2 Feature Team đầy đủ năng lực cho luồng Checkout & Payment (mỗi team có cả mobile, web, backend, một chuyên gia thanh toán). Sau một quý, số dependency liên team trong luồng này giảm từ 47 xuống còn 6 (chủ yếu là phụ thuộc vào team Search dùng chung). Dashboard gần như tự nghỉ hưu.
Bài học: Khi dashboard dependency phình to, đừng tối ưu dashboard — hãy đặt câu hỏi về ranh giới team.
Ví dụ 2 — Một fintech Đông Nam Á tách rời bằng API contract
Một công ty ví điện tử ở Singapore có một team "Core Ledger" sở hữu sổ cái giao dịch, và 6 team sản phẩm liên tục phải chờ Core Ledger thêm field, sửa endpoint. Core Ledger trở thành nút cổ chai: backlog của họ chứa toàn yêu cầu của team khác, mỗi Sprint chỉ phục vụ được 2-3 team.
Họ không thể gộp Core Ledger vào mọi team (vì lý do bảo mật và tính nhất quán dữ liệu). Thay vì quản lý hàng đợi yêu cầu, họ chọn chiến lược Decouple: Core Ledger công bố một API có version rõ ràng với cam kết backward-compatible, kèm consumer-driven contract testing (mỗi team tiêu thụ viết test mô tả kỳ vọng của mình, chạy tự động trong CI của Core Ledger). Họ cũng mở một cơ chế "inner source": team khác được phép gửi pull request vào codebase của Core Ledger, Core Ledger chỉ review chứ không tự code mọi thứ.
Kết quả: Số yêu cầu chờ Core Ledger giảm khoảng 70%. Các team tiêu thụ tự thêm field mình cần qua PR và phát hành độc lập sau API. Thời gian chờ trung bình cho một thay đổi liên quan ledger giảm từ ~3 Sprint xuống dưới 1 Sprint.
Bài học: Khi không thể xóa phụ thuộc, hãy biến nó thành một contract ổn định để hai bên tiến độc lập. Phụ thuộc vào một API có version ổn định khác xa với phụ thuộc vào lịch làm việc của một team khác.
Ví dụ 3 — Cái bẫy "phụ thuộc giả" do quy trình tạo ra
Một startup SaaS B2B tại Hà Nội có hai team: team Product và team Platform. Mọi thay đổi schema database đều phải qua team Platform "duyệt" — một quy tắc đặt ra từ thời công ty chỉ có 8 người. Giờ công ty 60 người, quy tắc này biến mỗi tính năng cần đổi DB thành một dependency phải chờ.
Khi PO ngồi rà lại, hóa ra 80% phụ thuộc này là phụ thuộc giả (artificial dependency) — sinh ra bởi một chính sách lỗi thời, không phải bởi nhu cầu kỹ thuật thực sự. Họ thay "duyệt thủ công" bằng một bộ guardrail tự động: migration phải qua linter schema, review tự động bằng bot, và chỉ những thay đổi rủi ro cao (xóa cột, đổi index lớn) mới cần con người duyệt. Phụ thuộc còn lại đúng nghĩa giảm xuống còn ~15% so với trước.
Bài học: Trước khi tìm cách xử lý một phụ thuộc, hãy hỏi: "Phụ thuộc này có thật không, hay do quy trình của chính ta tạo ra?" Rất nhiều phụ thuộc là di sản của những quy tắc từng hợp lý ở quy mô nhỏ.
Hướng dẫn từng bước
Đây là quy trình một PO/PO cấp cao có thể áp dụng để chuyển từ "manage" sang "minimize":
Bước 1 — Làm cho phụ thuộc trở nên hữu hình (nhưng đừng dừng ở đó). Trong buổi planning liên team (ví dụ Nexus Sprint Planning), dùng một bảng đơn giản để vẽ ra phụ thuộc: ai chờ ai, vì cái gì. Mục tiêu của bước này không phải là để theo dõi lâu dài, mà là để chẩn đoán nguồn gốc.
Bước 2 — Phân loại từng phụ thuộc. Với mỗi mục, dán nhãn: Thật hay Giả? Kiến thức / Kỹ thuật / Con người / Quyết định? Bước này giúp bạn loại ngay những "phụ thuộc giả" do quy trình.
Bước 3 — Truy ngược về cấu trúc team (lăng kính Conway). Hỏi: phụ thuộc này có lặp đi lặp lại không? Nếu một cặp team liên tục phụ thuộc nhau qua nhiều Sprint, đó là tín hiệu ranh giới team sai — ứng viên cho tái cấu trúc thành Feature Team.
Bước 4 — Chọn chiến lược theo thứ tự ưu tiên: Eliminate → Internalize → Decouple → Sequence. Luôn cố leo lên bậc cao nhất khả thi. Đừng vội nhảy xuống "Sequence" (lập lịch phối hợp) chỉ vì nó dễ trong ngắn hạn.
Bước 5 — Với phụ thuộc kỹ thuật còn lại, đầu tư vào tách rời. Thúc đẩy API có version, contract testing, feature flags, inner source. Đây là việc PO phải đưa vào backlog như công việc có giá trị thật, không phải "việc kỹ thuật phụ".
Bước 6 — Chỉ những phụ thuộc thực sự không thể tránh mới đưa vào điều phối nhẹ. Dùng các sự kiện có sẵn của framework (Nexus Daily Scrum, Scrum of Scrums) thay vì dựng thêm bộ máy. Mục tiêu là phối hợp just-in-time, không phải dashboard thường trực.
Bước 7 — Theo dõi xu hướng, không theo dõi danh sách. Chỉ số bạn quan tâm là số lượng phụ thuộc đang giảm dần theo thời gian hay không. Một dashboard dependency lành mạnh là một dashboard đang co lại.
Lỗi thường gặp & mẹo
Lỗi 1 — Tự hào vì quản lý phụ thuộc giỏi. Nếu bạn thấy mình đang khoe dashboard dependency hoành tráng, đó là dấu hiệu bạn đang tối ưu nhầm chỗ. Mẹo: đặt mục tiêu cho mỗi quý là giảm số phụ thuộc, không phải theo dõi chúng đẹp hơn.
Lỗi 2 — Coi tái cấu trúc team là "việc của HR/leadership, không phải việc của PO". Sai. Cấu trúc team quyết định trực tiếp tốc độ giao giá trị, nên đó là mối quan tâm chính đáng của PO. Mẹo: mang dữ liệu (số dependency, T2M bị kéo dài) ra để vận động leadership — đây là lúc kỹ năng đàm phán với executive (Bài 16) phát huy.
Lỗi 3 — Nhầm "phụ thuộc kiến thức" thành "phụ thuộc công việc". Đôi khi team A không cần team B làm hộ, mà chỉ cần biết cách làm. Mẹo: ưu tiên pairing, chia sẻ tài liệu, hoặc luân chuyển người ngắn hạn thay vì chuyển ticket qua lại.
Lỗi 4 — Để một "team nền tảng" trở thành nút cổ chai vĩnh viễn. Nếu mọi team đều chờ một team dùng chung, hãy nghĩ đến inner source và self-service platform thay vì xếp hàng yêu cầu.
Lỗi 5 — Phát hiện phụ thuộc quá muộn (chỉ thấy ở tích hợp cuối Sprint). Mẹo: đẩy "contract" lên sớm. Hai team thống nhất giao diện/API trước khi cùng bắt tay code, và tích hợp liên tục thay vì gộp vào cuối.
Mẹo vàng: Mỗi khi sắp thêm một cơ chế quản lý phụ thuộc mới (một cuộc họp, một dashboard, một vai trò điều phối), hãy tự hỏi: "Mình đang làm cho phụ thuộc dễ sống hơn, hay đang làm cho nó biến mất?" Nếu là vế đầu, hãy dừng lại và quay về thang Eliminate–Internalize–Decouple.
Bài tập thực hành
- Audit phụ thuộc: Liệt kê tất cả phụ thuộc liên team mà sản phẩm của bạn (hoặc một sản phẩm bạn biết) đang gặp trong Sprint gần nhất. Với mỗi cái, dán nhãn Thật/Giả và loại (Kiến thức/Kỹ thuật/Con người/Quyết định).
- Soi qua lăng kính Conway: Chọn 3 phụ thuộc kỹ thuật lặp lại nhiều nhất. Vẽ sơ đồ team hiện tại và đề xuất một cách chia team lại (Feature Team) sao cho ít nhất 2 trong 3 phụ thuộc biến mất. Ghi rõ team mới cần những vai trò gì.
- Thiết kế tách rời: Chọn một phụ thuộc kỹ thuật không thể xóa bằng tái cấu trúc. Phác thảo một giải pháp Decouple cụ thể (API có version, contract test, feature flag hoặc inner source) cho phép hai team tiến độc lập.
- Săn phụ thuộc giả: Tìm một quy tắc/quy trình trong tổ chức của bạn đang tạo ra phụ thuộc nhưng có lẽ đã lỗi thời. Đề xuất cách thay thế bằng guardrail tự động.
- Pitch cho leadership (viết 1 trang): Giả định bạn cần thuyết phục ban giám đốc tái cấu trúc 2 team. Viết lập luận dựa trên dữ liệu: phụ thuộc đang làm chậm T2M bao nhiêu, chi phí điều phối hiện tại, và bức tranh sau khi tái cấu trúc.
Tóm tắt
- Phụ thuộc chéo giữa các team là một dạng lãng phí, không phải một thực thể cần được chăm sóc cẩn thận. Mục tiêu là giảm thiểu, không phải quản lý ("minimize, don't manage").
- Dependency management — dashboard hàng chục dependency, họp điều phối, vai trò điều phối — là một anti-pattern: nó tạo gánh nặng hành chính và thường khiến phụ thuộc bị phát hiện muộn ở khâu tích hợp.
- Gốc rễ của phần lớn phụ thuộc kỹ thuật là cấu trúc team sai (định luật Conway). Đòn bẩy mạnh nhất là tái cấu trúc thành Feature Team đủ năng lực end-to-end.
- Thứ tự ưu tiên xử lý: Eliminate → Internalize → Decouple → Sequence. Chỉ quản lý phụ thuộc khi tất cả đều bất khả thi, và xem đó là giải pháp tạm.
- Hãy phân biệt phụ thuộc thật và giả; rất nhiều phụ thuộc chỉ là di sản của quy trình lỗi thời.
- Với phụ thuộc kỹ thuật còn lại, tách rời bằng kiến trúc (API có version, contract testing, feature flags, inner source) cho phép các team tiến độc lập.
- Một PO cấp cao đo lường thành công bằng việc số phụ thuộc đang co lại theo thời gian, chứ không phải bằng độ đẹp của dashboard theo dõi chúng.