title: "Xây dựng văn hóa hợp tác: Biến đội ngũ kỹ thuật và đội ngũ khách hàng thành một team"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 3 — Tư duy Chiến lược & Tầm nhìn"
skill_number: 41
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "11 phút"
tags: ["văn hóa hợp tác", "shared goal", "stakeholder management", "vendor management", "one team", "BA skills", "PO skills"]

Xây dựng văn hóa hợp tác: Biến đội ngũ kỹ thuật và đội ngũ khách hàng thành một team

Có một câu hỏi mà bất kỳ BA/PM nào từng làm dự án outsource hay triển khai hệ thống lâu dài đều gặp phải: khi sự cố xảy ra lúc 2 giờ sáng, phản xạ đầu tiên của hai đội là gì — cùng nhau tìm nguyên nhân, hay tìm xem lỗi thuộc về "bên nào"? Nếu câu trả lời là vế sau, dự án của bạn đang có một đường ranh giới vô hình chia đôi phòng họp, và không công cụ quản lý dự án nào xóa được nó — chỉ có cách thiết kế lại văn hóa làm việc mới làm được.

🎯 Kỹ thuật cốt lõi: Shared Goal + Ritual — xóa ranh giới "chúng tôi vs họ"

Bản chất của tâm lý "us vs. them" (chúng tôi vs họ) là mỗi đội đang tối ưu cho một mục tiêu khác nhau: đội kỹ thuật (nhà cung cấp) tối ưu cho "nghiệm thu đúng hợp đồng, đóng ticket, tránh bị phạt SLA"; đội vận hành phía khách hàng tối ưu cho "hệ thống chạy êm, không bị sếp hỏi tội, không phải xử lý hậu quả của lỗi người khác". Hai mục tiêu này không đối nghịch nhau về bản chất, nhưng khi không ai nói ra, mỗi bên tự suy diễn động cơ của bên kia — và suy diễn luôn tệ hơn sự thật.

Kỹ thuật cốt lõi để xử lý việc này gồm hai cấu phần, phải làm cùng nhau, thiếu một cấu phần thì cấu phần kia không bền:

1. Shared Goal (mục tiêu chung) — một mục tiêu duy nhất, đo lường được, mà CẢ HAI đội cùng chịu trách nhiệm, không thể tách ra "phần của tôi" và "phần của anh". Ba tiêu chí để một mục tiêu là "shared" thật sự chứ không phải khẩu hiệu:

Đo bằng kết quả cuối, không đo bằng đầu việc từng bên. Ví dụ sai: "đội dev sửa xong X ticket, đội vận hành đóng Y ticket" (vẫn là hai KPI riêng). Ví dụ đúng: "uptime hệ thống ≥ 99.5%/tháng" hoặc "thời gian từ lúc phát hiện sự cố đến lúc khôi phục (MTTR) ≤ 2 giờ" — một con số mà cả hai đội cùng nhìn vào, cùng thắng hoặc cùng thua.
Cả hai bên đều có đòn bẩy thật để tác động tới con số đó. Nếu mục tiêu phụ thuộc 100% vào một bên, bên còn lại sẽ vô cảm với nó. MTTR phụ thuộc cả vào tốc độ dev vá lỗi lẫn tốc độ vận hành phát hiện — nên cả hai đều có phần.
Được nhắc lại định kỳ, công khai, không chỉ nằm trong hợp đồng. Một chỉ số chỉ tồn tại trong SLA mà không ai nhắc trong họp hàng tuần thì không phải shared goal, đó là điều khoản pháp lý nằm im.

2. Ritual (nghi thức chung) — một hoạt động lặp lại đều đặn mà đại diện cả hai đội cùng tham gia, với vai trò ngang nhau (không phải một bên báo cáo, một bên chấm điểm). Ritual hiệu quả có ba đặc điểm:

Tần suất đủ để tạo thói quen, đủ ngắn để không thành gánh nặng — ví dụ 15-30 phút/tuần, không phải họp 2 tiếng/tháng.
Có nghi thức nhỏ mang tính biểu tượng — một hành động lặp lại tạo cảm giác "đây là team của chúng ta", không phải "cuộc họp giữa hai công ty". Có thể đơn giản như luân phiên người dẫn họp giữa hai đội, dùng chung một kênh chat không phân biệt "kênh nội bộ nhà cung cấp" và "kênh gửi khách hàng", hoặc một buổi retro chung sau mỗi sự cố lớn mà không quy trách nhiệm cá nhân.
Nói được cả tin xấu, không chỉ báo cáo tiến độ đẹp. Ritual chỉ để khoe thành tích sẽ chết yểu; ritual sống được là ritual nơi rủi ro, lỗi, và nghi ngờ được nói ra sớm mà không ai bị "đấu tố".

Khi có shared goal, hai đội có lý do chung để tồn tại cùng nhau. Khi có ritual, hai đội có không gian đều đặn để nuôi dưỡng lý do đó thành thói quen. Thiếu ritual, shared goal chỉ là một dòng chữ trong slide kickoff rồi bị quên. Thiếu shared goal, ritual chỉ là một cuộc họp thêm vào lịch, không ai muốn tham dự.

Bối cảnh (Situation)

Tình huống dưới đây là minh họa tổng hợp từ các dự án triển khai hệ thống dài hạn tại Việt Nam, không phải case cụ thể của một công ty nào.

Một công ty tư vấn công nghệ (gọi là "đội kỹ thuật" hoặc "nhà cung cấp" — NCC) trúng thầu triển khai và vận hành một hệ thống quản lý nội bộ cho một doanh nghiệp sản xuất quy mô vừa (gọi là "khách hàng"). Hợp đồng gồm hai giai đoạn: triển khai 4 tháng, sau đó là hợp đồng bảo trì — vận hành 12 tháng với SLA rõ ràng về thời gian phản hồi và thời gian khắc phục sự cố.

Giai đoạn triển khai suôn sẻ. Nhưng bước sang giai đoạn vận hành, mọi thứ đổi khác. Phía khách hàng có một đội vận hành nội bộ (Ops) gồm 3 người, chịu trách nhiệm giám sát hệ thống hàng ngày, ghi nhận sự cố từ người dùng cuối và báo cho NCC xử lý. Phía NCC có một đội hỗ trợ kỹ thuật 4 người, làm việc theo ticket qua hệ thống helpdesk.

Sau khoảng hai tháng vận hành, chị H. — BA/PM phụ trách dự án phía NCC — bắt đầu nhận thấy mỗi lần có sự cố (hệ thống chậm, một module báo lỗi, dữ liệu không đồng bộ), cuộc trò chuyện trong ticket luôn theo một khuôn mẫu: đội Ops khách hàng viết "hệ thống lỗi từ hôm qua, sao chưa ai xử lý", đội kỹ thuật NCC trả lời "đã kiểm tra, log cho thấy lỗi do dữ liệu đầu vào từ phía khách hàng nhập sai định dạng, không phải lỗi hệ thống". Rồi im lặng vài giờ, rồi khách hàng leo thang lên sếp, sếp gọi cho chị H., chị H. lại phải làm trung gian giải thích lại từ đầu.

Thách thức (Task)

Vấn đề không nằm ở kỹ thuật — hầu hết sự cố đều được khắc phục trong SLA cam kết. Vấn đề nằm ở cách hai đội nhìn nhau. Chị H. nhận ra ba dấu hiệu rõ ràng của một "chiến tuyến" đang hình thành:

Mỗi ticket sự cố trở thành một cuộc điều tra "lỗi tại ai" trước khi trở thành một nỗ lực khắc phục. Thời gian tranh luận trách nhiệm nhiều khi dài hơn thời gian sửa lỗi thực tế.
Hai đội gần như không nói chuyện với nhau ngoài ticket. Không ai biết mặt ai ngoài những dòng chữ trong hệ thống helpdesk. Đội Ops khách hàng gọi đội kỹ thuật NCC là "bên vendor"; đội kỹ thuật gọi đội Ops là "khách hàng khó tính".
Khi một sự cố lớn xảy ra (một lần hệ thống báo cáo tài chính bị sai số liệu do lỗi đồng bộ dữ liệu), phản xạ đầu tiên của cả hai bên là thu thập bằng chứng để chứng minh mình không có lỗi, thay vì cùng ngồi xuống tìm nguyên nhân gốc.

Nếu tình trạng này kéo dài, hậu quả không chỉ là quan hệ căng thẳng. Về mặt kinh doanh, khách hàng nhiều khả năng sẽ không gia hạn hợp đồng bảo trì khi hết hạn 12 tháng — không phải vì chất lượng kỹ thuật kém, mà vì trải nghiệm hợp tác mệt mỏi. Về mặt vận hành, tâm lý phòng thủ khiến cả hai bên giấu bớt thông tin của nhau ("không nói hết vì sợ bị quy trách nhiệm"), làm chậm quá trình chẩn đoán sự cố thật sự — rủi ro lớn nhất trong bất kỳ hệ thống nào đang chạy production.

Cái khó của chị H. là: chị không phải sếp của cả hai đội. Chị không thể ra lệnh cho ai phải hợp tác. Chị chỉ có thể thiết kế lại cách hai đội làm việc cùng nhau để hợp tác trở thành lựa chọn tự nhiên nhất, chứ không phải một mệnh lệnh gượng ép.

Hành động (Action)

Chị H. tiếp cận vấn đề bằng đúng hai cấu phần của kỹ thuật cốt lõi: dựng một mục tiêu chung, và thiết kế một vài nghi thức chung. Chị làm theo trình tự sau, trải qua khoảng ba tuần.

Bước 1 — Đặt tên đúng cho vấn đề, với cả hai bên, không đổ lỗi cho ai.
Chị H. đề nghị một buổi họp riêng (không phải họp sự cố) với trưởng nhóm Ops phía khách hàng và trưởng nhóm kỹ thuật phía NCC. Chị mở đầu bằng quan sát trung lập: "Em để ý ba tháng qua, mỗi ticket đều mất trung bình 40 phút tranh luận ai chịu trách nhiệm trước khi bắt tay sửa. Đây không phải lỗi của riêng bên nào — là do cách hai đội đang làm việc khiến ai cũng phải tự vệ trước." Cách đặt vấn đề này quan trọng: nó không hỏi "ai sai", nó hỏi "cơ chế nào đang tạo ra hành vi này". Cả hai trưởng nhóm đều đồng ý — vì không ai bị chỉ trích, cả hai dễ dàng thừa nhận thực trạng.

Bước 2 — Thiết kế một shared goal thay cho hai KPI tách rời.
Trước đó, SLA hợp đồng chỉ đo một chỉ số: thời gian NCC phản hồi ticket. Đây là KPI một chiều — chỉ đo NCC, khiến Ops khách hàng đứng ngoài như người chấm điểm, không phải người cùng chơi. Chị H. đề xuất thêm một chỉ số chung, đo cả quy trình từ đầu đến cuối: Thời gian từ lúc sự cố phát sinh thực tế đến lúc hệ thống khôi phục hoàn toàn (gọi tắt là MTTR — Mean Time To Recovery), mục tiêu ≤ 3 giờ cho sự cố mức trung bình.

Điểm mấu chốt: con số này phụ thuộc vào CẢ HAI bên — Ops khách hàng phát hiện và báo sự cố nhanh hay chậm, cung cấp thông tin đầy đủ hay thiếu; đội kỹ thuật NCC chẩn đoán và vá lỗi nhanh hay chậm. Chị H. trình bày rõ với cả hai trưởng nhóm: "Từ tháng sau, chỉ số này sẽ được báo cáo lên sếp hai bên hàng tháng, ký tên chung, không tách riêng phần của ai." Việc "ký tên chung" là chi tiết nhỏ nhưng quan trọng — nó biến báo cáo từ công cụ chấm điểm thành cam kết đồng sở hữu.

Bước 3 — Thiết lập ritual: buổi "Đứng chung 15 phút" (Daily Ops Sync) và "Retro không đổ lỗi" hàng tháng.
Chị H. đề xuất hai nghi thức cụ thể:

Daily Ops Sync 15 phút, diễn ra lúc 9h sáng mỗi ngày làm việc, có đại diện cả hai đội (không phải toàn đội, chỉ 1-2 người mỗi bên), nội dung cố định ba câu hỏi: "Hôm qua có gì bất thường?", "Hôm nay có thay đổi gì trên hệ thống (deploy, cập nhật dữ liệu, đổi quy trình)?", "Có rủi ro gì cần cả hai cùng để ý?". Người dẫn buổi họp luân phiên giữa hai đội theo tuần — tuần này người của NCC dẫn, tuần sau người của Ops dẫn. Việc luân phiên phá vỡ cảm giác "một bên báo cáo cho bên kia".
Retro hàng tháng, quy tắc "không hỏi ai, chỉ hỏi cái gì". Sau mỗi sự cố đáng kể trong tháng, cả hai đội cùng ngồi lại, nhưng luật chơi được nói rõ từ đầu: câu hỏi hợp lệ là "điều gì trong quy trình khiến sự cố này xảy ra/khó phát hiện/khó xử lý", câu hỏi không hợp lệ là "ai đã làm sai". Chị H. đóng vai người giữ luật (facilitator) trong vài buổi đầu để đảm bảo không ai trượt về thói quen cũ, sau đó để hai trưởng nhóm tự luân phiên dẫn.

Bước 4 — Tạo một kênh giao tiếp chung, xóa bỏ ranh giới "kênh nội bộ" và "kênh khách hàng".
Trước đó, đội kỹ thuật NCC có một nhóm chat riêng để bàn bạc trước khi trả lời khách hàng — điều này bình thường ở nhiều dự án, nhưng nó vô tình củng cố cảm giác "có một cuộc trò chuyện thật diễn ra ở chỗ khác, còn ticket chỉ là bản tóm tắt đã qua chỉnh sửa". Chị H. đề xuất mở thêm một kênh chat chung (ngoài ticket chính thức) chỉ dành cho trao đổi nhanh, không mang tính ràng buộc hợp đồng — dùng để hỏi nhanh, xác nhận thông tin, hoặc đơn giản là chào hỏi. Chị lưu ý rõ với cả hai đội: kênh này không thay thế ticket (ticket vẫn là hồ sơ chính thức để tính SLA), nhưng nó tạo không gian phi chính thức để hai đội quen mặt nhau như đồng nghiệp.

Bước 5 — Đưa một "thắng lợi chung" sớm để ritual có bằng chứng sống, không chỉ lý thuyết.
Trong tuần thứ hai áp dụng Daily Sync, đội Ops khách hàng phát hiện sớm một dấu hiệu bất thường (tốc độ tải trang chậm dần) và báo ngay trong buổi sync, trước khi nó trở thành sự cố lớn. Đội kỹ thuật NCC xử lý trong vòng 40 phút. Chị H. chủ động ghi lại việc này thành một dòng ngắn trong báo cáo tháng, gọi đích danh là "một ví dụ MTTR được rút ngắn nhờ phát hiện sớm từ đội Ops" — không tô vẽ, chỉ nêu sự thật, nhưng đặt đúng chỗ để cả hai đội thấy ritual mới đang tạo ra giá trị thật, không phải chỉ thêm việc.

Kết quả (Result)

Sau ba tháng áp dụng, MTTR trung bình giảm từ khoảng 5.5 giờ xuống còn 2.8 giờ — đạt mục tiêu shared goal đề ra. Số lượt leo thang lên cấp quản lý giảm rõ rệt, vì phần lớn bất đồng nhỏ được giải quyết ngay trong buổi Daily Sync hoặc retro tháng, trước khi kịp trở thành xung đột.

Một thay đổi định tính đáng chú ý: trong các ticket sự cố, ngôn ngữ dùng cũng thay đổi. Thay vì "hệ thống của các anh lỗi", các bên bắt đầu dùng "hệ thống của chúng ta". Đây là chi tiết nhỏ nhưng chị H. coi là tín hiệu quan trọng nhất — nó cho thấy ranh giới tâm lý đã dịch chuyển, không chỉ là con số KPI đẹp lên.

Không phải mọi thứ đều hoàn hảo. Ritual Daily Sync trong tháng đầu có lúc bị bỏ vì cả hai đội bận việc khác, chị H. phải chủ động nhắc và có tuần phải tự đứng ra dẫn dù không phải lượt của mình. Retro "không đổ lỗi" cũng có một lần suýt đổ vỡ khi một thành viên kỹ thuật phía NCC vô tình dùng câu "do bên chị nhập liệu sai" — chị H. phải can thiệp ngay tại chỗ, nhắc lại luật chơi, chuyển câu hỏi về "quy trình nhập liệu hiện tại có điểm nào dễ gây lỗi". Ngoài ra, việc thêm kênh chat chung ban đầu bị một số thành viên coi là kênh "để phàn nàn không chính thức", chị H. phải làm rõ lại ranh giới giữa kênh này và ticket chính thức sau vài tuần đầu lộn xộn. Khi hợp đồng bảo trì đến hạn gia hạn, khách hàng đồng ý ký tiếp 12 tháng, và lần đầu tiên chủ động đề xuất mở rộng phạm vi hợp tác sang một module mới — điều gần như không tưởng tượng được ở thời điểm ba tháng trước đó.

📋 Áp dụng ngay

Rà soát lại các KPI/SLA hiện tại của dự án: có chỉ số nào đo được kết quả cuối cùng mà cả hai đội cùng ảnh hưởng, thay vì chỉ đo riêng từng bên, hay không? Nếu chưa có, đề xuất thêm một chỉ số như vậy.
Thiết lập một ritual ngắn (10-20 phút), tần suất cố định, có đại diện cả hai bên tham gia ngang vai — và luân phiên vai trò dẫn dắt giữa hai đội để tránh cảm giác "báo cáo một chiều".
Với mọi buổi retro sau sự cố, đặt luật chơi rõ ràng ngay từ đầu: chỉ hỏi "cái gì trong quy trình", không hỏi "ai đã làm sai" — và người điều phối phải sẵn sàng ngắt lời khi ai đó lỡ trượt về thói quen đổ lỗi.
Tìm và công khai hóa một "thắng lợi chung" sớm nhất có thể sau khi ritual mới bắt đầu — bằng chứng sống luôn thuyết phục hơn lý thuyết về lợi ích hợp tác.
Rà soát ngôn ngữ giao tiếp hàng ngày trong dự án: nếu tài liệu, ticket, họp hành vẫn dùng cách gọi "bên vendor"/"bên khách hàng" phân biệt rạch ròi, đó là tín hiệu cần chỉnh — không phải chuyện chữ nghĩa, mà là chuyện tâm lý.

💡 Bài học đúc rút (Key Takeaway): Hai đội không đổ lỗi cho nhau vì họ xấu tính — họ đổ lỗi vì cơ chế làm việc đang buộc mỗi bên phải tự vệ trước khi được phép hợp tác. Muốn biến "chúng tôi vs họ" thành "chúng ta", đừng yêu cầu con người thay đổi thái độ — hãy thiết kế lại mục tiêu chung và nghi thức chung để hợp tác trở thành lựa chọn tự nhiên nhất, dễ dàng nhất trong ngày làm việc của họ.

🔗 Kỹ năng liên quan

Cách xử lý các bên liên quan (Stakeholder Management) — nền tảng để nhận diện và cân bằng lợi ích của nhiều nhóm liên quan trong cùng một dự án.
Quản lý sự thay đổi (Change Management) — kỹ thuật giúp một thay đổi về cách làm việc (như ritual mới) được đội ngũ chấp nhận thay vì chống đối.
Nghệ thuật họp (Facilitation Skills) — kỹ năng điều phối cần thiết để giữ cho ritual chung (đặc biệt là retro "không đổ lỗi") không trượt về thói quen cũ.

Bài trước: Tư duy về trải nghiệm người dùng (UX) · Bài tiếp theo: Kỹ năng Coaching khách hàng