title: "Quản trị xung đột giữa Stakeholders: Khi yêu cầu của kinh doanh "đá" với khả năng của kỹ thuật"
series: "BA 4.0: Từ Phân tích đến Giải pháp"
part: "Phần 3 — Kỹ năng "Cầu nối" (Bridge Skills)"
order: 10
audience: "Business Analyst (BA) mới vào nghề & đang phát triển"
reading_time: "13 phút"
tags: ["stakeholder conflict", "risk management", "negotiation", "scope management", "BA skills", "Reso case study"]

Quản trị xung đột giữa Stakeholders: Khi yêu cầu của kinh doanh "đá" với khả năng của kỹ thuật

Cuộc gọi bắt đầu lúc 4 giờ chiều thứ Ba, và Minh biết ngay từ câu mở đầu rằng đây không phải một cuộc họp bình thường. Chị Lan Anh vào thẳng vấn đề: "Ban giám đốc vừa họp xong, chị cần tính năng đặt tour đối tác có trong bản ra mắt đầu tiên. Không thể để phase 2 nữa — mình đã trễ với thị trường quá lâu rồi." Đây chính là tính năng mà ba tuần trước, ở bài viết về Scope Management, Minh và đội đã thuyết phục chị hoãn sang phase 2 để giữ đúng deadline ra mắt phần lõi: đặt phòng, thanh toán, xác nhận tự động.

Huy vào cuộc muộn hơn năm phút, và phản ứng của anh cũng dứt khoát không kém: "Không thể làm được trong thời gian còn lại. Đặt tour nghĩa là tích hợp thanh toán với hệ thống của bên thứ ba — đối tác tour. Chúng ta chưa từng kiểm thử luồng thanh toán đó, chưa có thời gian pentest, và nếu có lỗ hổng bảo mật thanh toán lộ ra ngay tuần ra mắt, thiệt hại uy tín sẽ lớn hơn nhiều so với việc chậm một tính năng." Hai người, hai lập luận đều đúng theo cách riêng, và không ai chịu nhường. Minh ngồi giữa, với vai trò mà không ai giao cho mình bằng văn bản nhưng ai cũng mặc định mình phải làm: giải quyết cái này.

Đây là tình huống mọi BA rồi sẽ gặp không dưới một lần trong sự nghiệp — không phải "khách hàng sai" hay "kỹ thuật cứng nhắc", mà là hai người có lý đang đứng ở hai đầu của cùng một sợi dây, và sợi dây đó sắp đứt nếu không ai hiểu đúng bản chất của cái đang kéo.

Sự thật cơ bản (First Principle)

Xung đột giữa kinh doanh và kỹ thuật hầu như luôn xuất phát từ việc hai bên đang tối ưu hóa cho hai thứ khác nhau — không phải vì một bên "sai" và bên kia "đúng".

Chị Lan Anh đang tối ưu hóa cho tốc độ ra thị trường (time-to-market). Với chị, mỗi tháng Reso chưa có tính năng đặt tour là một tháng Serene Hotels tiếp tục chảy máu 15-20% doanh thu qua hoa hồng OTA, và ban giám đốc đang đếm từng quý xem chiến lược giảm phụ thuộc OTA có hiệu quả không. Từ vị trí của chị, "chờ phase 2" không phải một quyết định kỹ thuật trung lập — nó là một khoản chi phí cơ hội thực, tính bằng tiền, mà chị là người phải giải trình.

Huy đang tối ưu hóa cho rủi ro và chất lượng (risk & quality). Với anh, một luồng thanh toán chưa kiểm thử kỹ đưa ra thị trường không phải một tính năng "còn thiếu polish" — nó là một cánh cửa mở cho gian lận, sai lệch số tiền, hoặc rò rỉ thông tin thẻ của khách, những thứ mà một khi xảy ra sẽ đốt sạch chính uy tín mà chị Lan Anh đang cố xây bằng direct booking.

Cả hai đều đang bảo vệ đúng phần việc của mình, và cả hai đều đúng trong hệ quy chiếu của mình. Nếu Minh coi đây là một cuộc tranh cãi cần phân xử ai thắng ai thua, Minh đã hiểu sai bản chất vấn đề — vì không có "thắng thua" ở đây, chỉ có hai tập rủi ro khác nhau đang chưa được đặt lên cùng một mặt bàn để so sánh.

Phân tích

Cái sai phổ biến nhất mà BA thiếu kinh nghiệm mắc phải trong tình huống này là chọn phe. Có hai kiểu chọn phe, và cả hai đều phá hỏng vai trò của BA về lâu dài.

Chọn phe kinh doanh: Minh có thể nói với Huy "thôi cố làm cho chị Lan Anh, sếp cần thì mình ráng." Đây là con đường của một BA muốn được lòng người trả tiền cho dự án. Nhưng nó biến Minh thành cái loa truyền lệnh của sponsor xuống đội kỹ thuật, chứ không phải người phân tích. Nếu sự cố bảo mật thật sự xảy ra sau đó, câu hỏi đầu tiên sẽ là "ai đã đánh giá rủi ro trước khi quyết định làm gấp?" — và câu trả lời "không ai, Minh chỉ chuyển lời sếp" là câu trả lời tệ nhất một BA có thể đưa ra.

Chọn phe kỹ thuật: Ngược lại, Minh có thể đứng về phía Huy và nói với chị Lan Anh "kỹ thuật bảo không kịp thì chắc là không kịp thật, mình chờ phase 2 vậy." Đây có vẻ là lựa chọn "an toàn" vì rủi ro kỹ thuật nghe có vẻ nghiêm trọng và khó cãi. Nhưng nó bỏ qua một sự thật: Huy đánh giá rủi ro kỹ thuật rất giỏi, nhưng Huy không phải người chịu trách nhiệm về áp lực kinh doanh mà chị Lan Anh đang gánh — và một BA chỉ lặp lại "không kịp" mà không tìm phương án nào khác cũng đang từ bỏ đúng phần việc khiến vai trò BA có giá trị.

Vai trò đúng của BA ở đây không phải trọng tài phán xử ai đúng ai sai, mà là người dịch rủi ro sang ngôn ngữ cả hai bên cùng hiểu, rồi đứng cùng cả hai để tìm phương án mà cả hai tập rủi ro đều được xử lý ở mức chấp nhận được. Cụ thể, việc Minh cần làm là tách vấn đề "làm hay không làm tính năng đặt tour" — vốn là một câu hỏi nhị phân dễ gây bế tắc — thành một câu hỏi khác: "làm ở phạm vi và mức rủi ro nào thì cả hai bên đều chấp nhận được?"

Với case Reso, câu trả lời không nằm ở hai cực "làm toàn bộ ngay" (rủi ro bảo mật thanh toán chưa kiểm thử với mọi đối tác tour) hay "không làm gì cả, đợi phase 2" (mất áp lực thời gian mà ban giám đốc đang đặt lên chị Lan Anh). Nó nằm ở một phương án trung gian: ra mắt tính năng đặt tour ở chế độ giới hạn — chỉ với 1-2 đối tác tour đã được kiểm thử luồng thanh toán kỹ, thay vì mở toàn bộ mạng lưới đối tác ngay từ ngày đầu. Đây không phải một thỏa hiệp "cho có" để làm hài lòng cả hai — nó là một phương án thực sự giảm đúng loại rủi ro mà Huy lo ngại (diện tích tấn công nhỏ hơn, số luồng thanh toán cần giám sát chặt ít hơn), trong khi vẫn đáp ứng đúng nhu cầu thực của chị Lan Anh (có tính năng đặt tour trong bản ra mắt đầu tiên, chứng minh được với ban giám đốc rằng Reso đang đi đúng hướng giảm phụ thuộc OTA).

Giải pháp

Để đi từ một cuộc xung đột "đá nhau" sang một phương án thỏa hiệp có cơ sở, BA cần một quy trình bốn bước — áp dụng được cho bất kỳ dự án nào, không riêng Reso:

Bước 1 — Tách "lập trường" (position) khỏi "lợi ích thật" (interest). Lập trường của chị Lan Anh là "phải có tính năng đặt tour ngay". Lợi ích thật đằng sau là "chứng minh với ban giám đốc rằng dự án đang giải quyết đúng bài toán giảm phụ thuộc OTA, trong một khung thời gian cụ thể". Lập trường của Huy là "không làm được". Lợi ích thật là "không muốn đội chịu trách nhiệm cho một lỗ hổng bảo mật thanh toán chưa kiểm thử". Khi BA hỏi đúng câu "vì sao anh/chị cần điều này?" thay vì chỉ ghi nhận yêu cầu bề mặt, không gian thỏa hiệp mới lộ ra — vì lợi ích thật của hai bên, khác với lập trường, không hề loại trừ nhau.

Bước 2 — Định lượng rủi ro thực tế của từng phương án bằng ngôn ngữ trung lập. Đừng để cuộc thảo luận dừng ở mức cảm tính ("rủi ro cao" / "chậm quá lâu"). Với mỗi phương án, làm rõ: rủi ro là gì cụ thể, xác suất xảy ra ở mức nào, và nếu xảy ra thì hậu quả nặng đến đâu. Việc này giúp chuyển cuộc tranh luận từ "ai nói to hơn" sang "nhìn cùng một bảng dữ liệu".

Bước 3 — Tìm phương án nằm giữa hai cực, xử lý đúng rủi ro cốt lõi của mỗi bên. Phương án trung gian tốt không phải "làm ít hơn một chút" một cách chung chung — nó phải nhắm trúng đúng biến số gây rủi ro. Với Reso, biến số đó là "số lượng đối tác tour tích hợp cùng lúc chưa qua kiểm thử kỹ" — nên phương án giới hạn ở 1-2 đối tác đã kiểm thử là đúng trọng tâm, chứ không phải các phương án khác như "giảm số tính năng phụ" (không giải quyết đúng rủi ro bảo mật) hay "làm toàn bộ nhưng bớt UI đẹp" (cũng không giải quyết đúng vấn đề).

Bước 4 — Đưa phương án ra như một đề xuất có cơ sở, không phải một quyết định đã áp đặt sẵn. BA trình bày phương án thỏa hiệp cùng với dữ liệu rủi ro ở bước 2, để cả chị Lan Anh và Huy cùng nhìn thấy đây là kết quả của phân tích, không phải một sự nhượng bộ tùy tiện của BA. Điều này giữ cho cả hai bên cảm thấy được lắng nghe — quan trọng không kém bản thân giải pháp, vì một xung đột được giải quyết trên giấy nhưng để lại cảm giác "bị gạt qua một bên" ở một trong hai bên sẽ tái phát ở lần xung đột tiếp theo.

📎 Actionable Template

Ma trận Xung đột Stakeholder — dùng khi hai bên có yêu cầu/mối lo mâu thuẫn trực tiếp, cần đưa ra phương án thỏa hiệp có cơ sở thay vì chọn phe.

🧠 Tư duy phản biện: Khi hai stakeholder "đá nhau", câu hỏi đầu tiên không nên là "ai đúng" — mà là: liệu cả hai có đang cùng nhìn vào MỘT rủi ro thực tế, hay mỗi người chỉ đang nhìn thấy rủi ro của riêng mình và tưởng đó là toàn bộ bức tranh?

🔗 Case Study & Bài viết liên quan

Đây là một chương trong hành trình xuyên suốt 12 bài về dự án Reso của Serene Hotels — xung đột này là hệ quả trực tiếp của áp lực scope creep đã xuất hiện từ Quản trị phạm vi (Scope Management), khi tính năng đặt tour đối tác lần đầu được chị Lan Anh đề xuất và đội quyết định hoãn sang phase 2. Kỹ năng dịch rủi ro và thuyết phục bằng ngôn ngữ kinh doanh ở bài này cũng dựa trên nền tảng đã xây ở Kỹ năng giao tiếp & Thuyết phục.

Xung đột giữa chị Lan Anh và Huy lần này được giải quyết bằng một phương án thỏa hiệp có cơ sở — nhưng nó cũng để lại một câu hỏi mở cho cả đội: làm sao đảm bảo những quyết định đánh đổi rủi ro như thế này được ra đúng lúc, đúng nhịp, thay vì luôn là một cuộc họp khẩn cấp lúc 4 giờ chiều? Câu trả lời nằm ở cách đội tổ chức công việc theo sprint — và đó cũng chính là chủ đề của bài tiếp theo, khi Minh nhìn lại vai trò của BA trong nhịp độ Agile/Scrum mà đội của Huy đang vận hành.

Bài trước: Kỹ năng giao tiếp & Thuyết phục · Bài tiếp theo: BA trong dự án Agile/Scrum