Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi một PM giàu kinh nghiệm rằng công việc khó nhất trong nghề là gì, phần lớn sẽ không nói về Gantt chart hay công thức EVM. Họ sẽ nói về con người — cụ thể là những xung đột giữa con người với nhau. Xung đột (conflict) là điều không thể tránh khỏi trong mọi dự án: developer và tester cãi nhau về định nghĩa "done", sponsor muốn cắt scope còn khách hàng thì không chịu, hai team lead giành nhau một kỹ sư giỏi, hay đơn giản là hai người bất đồng về cách đặt tên biến trong code. PMBOK và bài thi PMP xem năng lực giải quyết xung đột là một kỹ năng lãnh đạo cốt lõi của người PM hiện đại — người đóng vai trò servant leader chứ không phải "sếp" ra lệnh.
Điều quan trọng bạn cần khắc sâu ngay từ đầu: xung đột không phải lúc nào cũng xấu. Xung đột lành mạnh về ý tưởng, về cách tiếp cận kỹ thuật, về ưu tiên — thường tạo ra quyết định tốt hơn. Một team im lặng tuyệt đối, không ai phản biện ai, thường là dấu hiệu của "groupthink" (tư duy bầy đàn) hoặc sợ hãi, chứ không phải của sự hòa hợp. Vai trò của PM không phải là dập tắt mọi xung đột, mà là điều hướng nó về phía xây dựng. Và công cụ kinh điển nhất để làm việc này — xuất hiện gần như chắc chắn trong đề thi PMP — chính là mô hình Thomas-Kilmann với 5 modes (chế độ) giải quyết xung đột. Bài này sẽ giúp bạn hiểu sâu 5 modes đó, biết khi nào dùng cái nào, và tránh những cái bẫy mà thí sinh Việt Nam thường mắc.
Khái niệm cốt lõi
Hai trục của mô hình Thomas-Kilmann
Thomas-Kilmann Instrument (TKI) do Kenneth Thomas và Ralph Kilmann xây dựng, mô tả hành vi con người khi đối mặt xung đột dựa trên hai chiều đo (dimension):
- Assertiveness (Tính quyết đoán) — mức độ bạn theo đuổi để đạt được lợi ích/quan tâm của chính mình (hoặc của bên bạn đại diện).
- Cooperativeness (Tính hợp tác) — mức độ bạn cố gắng thỏa mãn lợi ích/quan tâm của người khác.
| Mode (tên PMBOK) | Assertive | Cooperative | Bản chất | Khi dùng phù hợp |
|---|---|---|---|---|
| Withdraw / Avoid (Rút lui/Né tránh) | Thấp | Thấp | Lose-Lose | Vấn đề nhỏ; cần thời gian hạ nhiệt; thu thập thêm thông tin; người khác giải quyết tốt hơn |
| Smooth / Accommodate (Xoa dịu/Nhượng bộ) | Thấp | Cao | Yield-Lose (bạn nhường) | Giữ hòa khí quan trọng hơn vấn đề; bạn nhận ra mình sai; xây dựng thiện chí cho lần sau |
| Compromise / Reconcile (Thỏa hiệp/Dàn xếp) | Vừa | Vừa | Cả hai nhường một phần | Hai bên ngang sức; cần giải pháp tạm thời nhanh; deadline gấp |
| Force / Direct (Áp đặt/Cưỡng chế) | Cao | Thấp | Win-Lose | Khẩn cấp; vấn đề an toàn/pháp lý/đạo đức; quyết định không được lòng nhưng đúng |
| Collaborate / Problem-Solve (Cộng tác/Giải quyết vấn đề) | Cao | Cao | Win-Win | Vấn đề quan trọng cho cả hai; có thời gian; cần cam kết thật sự và giải pháp bền |
Đi sâu vào từng mode
1. Withdraw / Avoid (Né tránh). Bạn lùi ra khỏi xung đột, hoãn lại hoặc rút khỏi tình huống. Đây thường bị coi là mode "tệ" nhất vì nó không giải quyết gốc rễ — nên PMBOK gọi nó là lose-lose. Nhưng dùng đúng lúc nó lại rất khôn ngoan: khi cảm xúc đang nóng, tạm hoãn 24 giờ để mọi người bình tĩnh là điều tốt; khi vấn đề tầm phào không đáng để "đốt" vốn quan hệ; hoặc khi bạn cần thêm dữ liệu trước khi bàn tiếp.
2. Smooth / Accommodate (Xoa dịu). Bạn nhấn mạnh điểm chung, gạt bớt điểm khác biệt, và chấp nhận nhường lợi ích của mình để làm hài lòng bên kia. Nó giữ hòa khí trước mắt nhưng vấn đề gốc thường vẫn còn đó. Dùng tốt khi mối quan hệ dài hạn quan trọng hơn kết quả cụ thể lần này, hoặc khi bạn nhận ra mình thực sự sai.
3. Compromise / Reconcile (Thỏa hiệp). Mỗi bên nhường một phần để đạt một điểm giữa mà cả hai "chấp nhận được nhưng không ai thật sự hài lòng hoàn toàn". Đây là mode nhanh, thực dụng, hay dùng khi hai bên có quyền lực ngang nhau và thời gian gấp. Cạm bẫy: nhiều người nhầm compromise là "tốt nhất". Thực ra trong tư duy PMBOK 7, collaborate mới là lý tưởng; compromise chỉ là giải pháp khá tốt khi không đủ thời gian hoặc nguồn lực để collaborate.
4. Force / Direct (Áp đặt). Bạn dùng quyền lực, vị thế để áp đặt quan điểm — thắng bằng cái giá là bên kia thua. Win-lose. Nghe tiêu cực, nhưng có những tình huống bắt buộc phải force: khi an toàn lao động bị đe dọa, khi vi phạm pháp luật/đạo đức, khi khủng hoảng cần quyết định tức thì. Nhược điểm là nó có thể để lại oán giận và làm xói mòn tinh thần team nếu lạm dụng.
5. Collaborate / Problem-Solve (Cộng tác). Cả hai bên cùng ngồi lại, mổ xẻ nguyên nhân sâu xa, tìm giải pháp mà cả hai đều thắng. Đây là mode được PMBOK và tư duy servant leadership đề cao nhất vì nó tạo cam kết thật và giải pháp bền vững. Nhưng nó "đắt": tốn thời gian, đòi hỏi sự tin tưởng, và cần cả hai bên thực sự muốn hợp tác. Trong đề thi PMP, khi tình huống cho thấy vấn đề quan trọng và còn thời gian, đáp án đúng gần như luôn là collaborate/problem-solve.
Tình huống thực tế
Ví dụ 1 — Xung đột về "định nghĩa Done" tại một công ty fintech ở TP.HCM
Công ty giả định VíSốPay (một startup fintech ~80 nhân sự tại Quận 1) đang chạy Scrum. Trong sprint review, anh Tùng (Dev Lead) tuyên bố tính năng "chuyển tiền liên ngân hàng" đã hoàn thành. Chị Mai (QA Lead) phản đối gay gắt: "Chưa test edge case số tiền âm, chưa test timeout khi ngân hàng phản hồi chậm — sao gọi là done?". Không khí căng thẳng, hai người bắt đầu công kích cá nhân trước mặt cả team và cả sponsor đang dự họp.
Diễn giải cách xử lý. PM là chị Hương. Bước một, chị dùng Withdraw có chủ đích ngay tại chỗ: "Đây là điểm quan trọng, nhưng mình không giải quyết tốt khi đang nóng và giữa buổi review. Mai và Tùng ở lại sau họp 30 phút với mình nhé." Đây không phải né tránh vĩnh viễn — chỉ là hoãn để hạ nhiệt và tách khỏi khán giả. Sau đó, chị Hương chuyển sang Collaborate: đặt câu hỏi gốc rễ — "Vấn đề thật sự là gì? Là chúng ta chưa có một Definition of Done chung." Cả ba cùng ngồi viết ra DoD rõ ràng, có cả tiêu chí test edge case. Kết quả win-win: tính năng được test đầy đủ, và team có DoD dùng cho mọi sprint sau.
Bài học rút ra. Trong một tình huống có thể dùng nhiều mode nối tiếp nhau: né tránh ngắn hạn để hạ nhiệt, rồi cộng tác để giải quyết gốc. Xung đột này thực chất là xung đột lành mạnh về quy trình — và nó dẫn tới một cải tiến (DoD) mà trước đó team chưa có.
Ví dụ 2 — Deadline gấp và quyền lực ngang nhau tại một agency ở Hà Nội
Agency FPT-style (giả định) nhận một dự án website cho khách hàng lớn, deadline demo là 9h sáng thứ Hai, không thể dời. Chiều thứ Sáu, hai trưởng nhóm — anh Nam (Frontend) và anh Long (Backend) — bất đồng về việc dành 2 người cuối cùng còn rảnh cho phần nào: Nam muốn hoàn thiện giao diện, Long muốn vá lỗi API. Cả hai đều có lý, quyền lực ngang nhau, và chỉ còn vài giờ.
Diễn giải cách xử lý. PM biết rằng collaborate cần thời gian mà giờ không có. Anh chọn Compromise: một người sang phụ frontend làm nốt phần giao diện quan trọng nhất mà khách sẽ nhìn thấy đầu tiên, người kia sang backend vá hai lỗi API nghiêm trọng nhất. Không ai được 100% điều mình muốn, nhưng cả hai chấp nhận được và demo kịp giờ. Sau khi demo xong, PM tổ chức một buổi collaborate đúng nghĩa để lập kế hoạch nguồn lực tốt hơn cho sprint sau.
Bài học rút ra. Khi thời gian là ràng buộc cứng và hai bên ngang sức, compromise là lựa chọn thực dụng đúng đắn — đừng cố ép collaborate khi đồng hồ không cho phép. Nhưng đừng để compromise trở thành thói quen vĩnh viễn; hãy quay lại collaborate khi có điều kiện.
Ví dụ 3 — Vấn đề an toàn/tuân thủ tại một dự án xây dựng ở Bình Dương
Một dự án lắp đặt nhà máy tại khu công nghiệp VSIP Bình Dương. Nhà thầu phụ đề nghị bỏ qua một bước kiểm tra an toàn điện để kịp tiến độ, và một số kỹ sư trong team đồng tình vì áp lực deadline. PM là anh Đức.
Diễn giải cách xử lý. Đây không phải lúc để thương lượng hay xoa dịu. Anh Đức dùng Force / Direct dứt khoát: "Bước kiểm tra an toàn điện là bắt buộc theo quy định. Chúng ta không bỏ. Không thảo luận thêm." Anh áp đặt quyết định bất chấp việc nó không được lòng số đông đang chịu áp lực.
Bài học rút ra. Khi liên quan đến an toàn con người, pháp luật, hoặc đạo đức (gắn với nguyên tắc Stewardship trong PMBOK 7), force là mode đúng — dù nó win-lose. Đây chính là kiểu tình huống đề PMP hay gài: nếu đáp án collaborate/compromise xuất hiện, chúng vẫn SAI vì an toàn không phải thứ để mặc cả.
Hướng dẫn từng bước
Khi đối mặt một xung đột trong dự án (hoặc một câu hỏi tình huống trong đề thi), hãy đi theo quy trình sau:
- Nhận diện và không né tránh mãi mãi. Thừa nhận có xung đột. Đừng giả vờ nó không tồn tại — xung đột chưa được xử lý sẽ leo thang.
- Đọc bối cảnh theo 3 câu hỏi lọc:
- Chọn mode phù hợp dựa trên bộ lọc:
- Đi tìm nguyên nhân gốc, không phải triệu chứng. Xung đột bề mặt (ai làm task gì) thường che giấu nguyên nhân sâu (thiếu quy trình, thiếu thông tin, mục tiêu không rõ). Hỏi "tại sao" nhiều lần.
- Ưu tiên đối thoại trực tiếp và riêng tư. Với người liên quan, nói chuyện 1-1 trước, tách khỏi đám đông để tránh mất mặt (rất quan trọng trong văn hóa Việt Nam, nơi "giữ thể diện" có trọng lượng lớn).
- Theo dõi và ghi lại. Sau khi giải quyết, xác nhận các bên đã đồng thuận, cập nhật vào issue log/lessons learned nếu là bài học có giá trị lâu dài.
Lỗi thường gặp & mẹo
- Lỗi: mặc định chọn Compromise là đáp án đúng. Rất nhiều thí sinh Việt Nam thấy compromise nghe "hòa hợp, đôi bên cùng có lợi" nên chọn. Sai. Trong tư duy PMBOK, Collaborate/Problem-Solve mới là mode lý tưởng khi có thời gian. Compromise chỉ tốt khi gấp hoặc ngang sức.
- Lỗi: nhầm Force với "lãnh đạo độc đoán xấu". Force không phải luôn xấu. Khi khủng hoảng, an toàn hay đạo đức, force là đúng. Hãy đọc kỹ bối cảnh câu hỏi.
- Lỗi: coi Withdraw luôn là sai. Withdraw có chủ đích (hoãn để hạ nhiệt, thu thập thông tin) là hợp lệ. Chỉ sai khi bạn né tránh vĩnh viễn một vấn đề quan trọng.
- Mẹo nhớ tên gọi song song: PMBOK dùng cặp từ khác nhau cho cùng một mode. Nhớ cả hai để không bị đánh lừa trong đề: Avoid = Withdraw; Accommodate = Smooth; Reconcile = Compromise; Direct = Force; Problem-Solve = Confront = Collaborate. Đặc biệt lưu ý: "Confronting" trong ngữ cảnh PMBOK KHÔNG có nghĩa "đối đầu gây hấn" — nó nghĩa là "đối diện thẳng vấn đề để cùng giải quyết", tức là Collaborate. Đây là bẫy ngôn ngữ kinh điển.
- Mẹo văn hóa VN/ĐNA: Yếu tố "giữ thể diện" khiến nhiều PM Việt né tránh xung đột công khai. Hãy tận dụng đối thoại 1-1 riêng tư — vừa hợp văn hóa, vừa hiệu quả — nhưng đừng để "ngại va chạm" biến thành né tránh mãi mãi.
Bài tập thực hành
- Xác định mode. Với mỗi tình huống, ghi ra mode Thomas-Kilmann phù hợp nhất và giải thích trong 1-2 câu:
- Phân tích chính mình. Nhớ lại lần xung đột gần nhất bạn gặp ở công việc. Bạn đã dùng mode nào? Đó có phải mode tối ưu cho bối cảnh không? Nếu làm lại, bạn chọn khác không?
- Viết kịch bản collaborate. Chọn một xung đột thật trong dự án hiện tại, viết ra 3 câu hỏi mở bạn sẽ dùng để dẫn dắt buổi problem-solving nhằm tìm nguyên nhân gốc.
Tóm tắt
- Xung đột là điều tất yếu và không hẳn xấu; vai trò PM là điều hướng nó về phía xây dựng, không phải dập tắt mọi bất đồng.
- Mô hình Thomas-Kilmann đặt trên hai trục Assertiveness (theo đuổi lợi ích của mình) và Cooperativeness (thỏa mãn lợi ích người khác), tạo ra 5 modes: Withdraw/Avoid, Smooth/Accommodate, Compromise/Reconcile, Force/Direct, Collaborate/Problem-Solve.
- Collaborate/Problem-Solve là mode lý tưởng (win-win) khi vấn đề quan trọng và còn thời gian — đây thường là đáp án đúng trong đề PMP.
- Compromise thực dụng khi gấp/ngang sức; Force đúng khi an toàn-pháp lý-đạo đức; Withdraw hợp lệ khi cần hạ nhiệt; Smooth dùng khi quan hệ quan trọng hơn hoặc bạn sai.
- Lọc quyết định bằng 3 câu hỏi: mức độ quan trọng, thời gian còn lại, quan hệ quyền lực.
- Cảnh giác bẫy ngôn ngữ: "Confronting" trong PMBOK nghĩa là Collaborate, không phải đối đầu gây hấn.