Mở đầu — vì sao bài này quan trọng
Khi còn làm Designer, bạn thường được bảo vệ khỏi những cuộc "đấu tranh" chính trị trong dự án. Có ai đó — Product Manager, team lead, hoặc chính người BA — đứng ra hứng những mâu thuẫn về phạm vi, ngân sách, deadline, rồi mới đưa xuống cho bạn một bản brief tương đối gọn gàng. Khi chuyển sang vai BA, bạn mất tấm khiên đó. Bạn chính là người đứng giữa. Stakeholder kinh doanh muốn nhiều tính năng hơn, đội dev nói không kịp, sếp tài chính muốn cắt ngân sách, và tất cả đều nhìn về phía bạn để tìm câu trả lời.
Đây là lý do vì sao negotiation (thương lượng) và conflict resolution (giải quyết xung đột) không phải là "kỹ năng mềm nice-to-have" mà là công cụ lõi trong bộ đồ nghề của BA. Theo IIBA, phần lớn dự án phần mềm thất bại không phải vì yêu cầu sai về kỹ thuật, mà vì các bên không đạt được sự đồng thuận (alignment) về cái gì thực sự quan trọng. Một BA giỏi elicitation nhưng dở thương lượng cuối cùng chỉ tạo ra những tài liệu đẹp mà không ai chịu cam kết.
Tin tốt cho người có nền Design: bạn đã có sẵn hai tài sản quý. Thứ nhất là empathy — khả năng hiểu người khác thực sự cần gì đằng sau lời họ nói. Thứ hai là thói quen facilitation từ các buổi design critique. Bài này sẽ giúp bạn chuyển hóa hai tài sản đó thành năng lực thương lượng có phương pháp.
Khái niệm cốt lõi
Position vs Interest — phân biệt "đòi hỏi" và "nhu cầu"
Nền tảng của mọi cuộc thương lượng hiệu quả nằm ở việc phân biệt position (lập trường: cái người ta nói họ muốn) và interest (lợi ích: lý do thực sự đằng sau). Đây là ý tưởng trung tâm của phương pháp Principled Negotiation trong cuốn "Getting to Yes" (Fisher & Ury, Harvard).
Ví dụ: stakeholder nói "Tôi cần tính năng xuất báo cáo Excel trong sprint này" — đó là position. Interest thật có thể là "Sếp tôi họp hội đồng vào thứ Sáu và cần số liệu để bảo vệ ngân sách team". Khi bạn hiểu interest, không gian giải pháp rộng ra: có thể một bảng số liệu tạm trên dashboard đã đủ, không cần build cả tính năng export phức tạp.
Với Designer, đây chính là kỹ năng bạn dùng khi phân biệt "user nói muốn nút to hơn" với "user thực ra không tìm thấy chức năng thanh toán". Bạn chỉ cần áp cùng tư duy đó lên stakeholder.
BATNA — biết mình có gì trong tay
BATNA (Best Alternative To a Negotiated Agreement) là phương án tốt nhất bạn có nếu cuộc thương lượng thất bại. Trước mỗi cuộc thương lượng khó, hãy tự hỏi: "Nếu không đạt thỏa thuận, chuyện gì xảy ra?". Biết BATNA của mình — và ước lượng BATNA của bên kia — giúp bạn không nhượng bộ vì sợ hãi mù quáng, cũng không cứng đầu đến mức phá vỡ quan hệ.
Ví dụ, nếu dev nói không kịp làm cả 5 tính năng, BATNA của bạn có thể là: "release 3 tính năng cốt lõi đúng hạn, 2 tính năng còn lại đẩy sang sprint sau". Khi bạn có một BATNA rõ ràng và chấp nhận được, bạn thương lượng từ vị thế bình tĩnh.
ZOPA — vùng có thể đạt thỏa thuận
ZOPA (Zone of Possible Agreement) là khoảng giao nhau giữa những gì bạn chấp nhận được và những gì bên kia chấp nhận được. Nhiệm vụ của BA là mở rộng vùng này, thường bằng cách đưa thêm biến số vào bàn đàm phán (thời gian, phạm vi, chất lượng, nguồn lực) thay vì đấu tranh trên một biến số duy nhất.
Bốn nguyên tắc của thương lượng có nguyên tắc
- Tách con người khỏi vấn đề — công kích vấn đề, không công kích người. "Yêu cầu này có mâu thuẫn" chứ không phải "Anh làm yêu cầu này sai".
- Tập trung vào interest, không vào position.
- Tạo nhiều phương án cùng có lợi (win-win) trước khi quyết.
- Dựa trên tiêu chí khách quan — dữ liệu, KPI, chuẩn ngành — thay vì ý chí ai to hơn.
Năm kiểu xử lý xung đột (Thomas-Kilmann)
Mô hình TKI phân loại cách ứng xử với xung đột theo hai trục: quyết đoán (theo đuổi lợi ích của mình) và hợp tác (quan tâm lợi ích bên kia):
- Competing (thắng-thua): quyết đoán cao, hợp tác thấp. Dùng khi khẩn cấp, cần quyết nhanh.
- Accommodating (nhường): dùng khi vấn đề với bạn nhỏ nhưng với họ lớn.
- Avoiding (né): dùng khi vấn đề không đáng, hoặc cần thời gian hạ nhiệt.
- Compromising (thỏa hiệp): mỗi bên nhường một nửa. Nhanh nhưng ít khi tối ưu.
- Collaborating (hợp tác): tốn công nhất nhưng cho kết quả tốt nhất — đây là mục tiêu của BA giỏi.
Tình huống thực tế
Tình huống 1: Hai stakeholder, một sprint — cuộc chiến ưu tiên tại một sàn TMĐT
Bối cảnh: Bạn là BA tại một công ty thương mại điện tử tầm trung ở TP.HCM (giả định là "ChợNhanh"). Trong sprint kế tiếp, team dev có năng lực (velocity) khoảng 40 story point. Giám đốc Marketing muốn tính năng "flash sale countdown" (ước tính 25 điểm) để kịp chiến dịch 6/6. Giám đốc Vận hành muốn tính năng "cảnh báo tồn kho thấp" (ước tính 22 điểm) vì tuần trước đã bán vượt 300 đơn hàng không có hàng, gây hoàn tiền và mất uy tín. Cả hai đều nói "của tôi là ưu tiên số 1".
Diễn giải: Đây là kinh điển của xung đột position. Nếu bạn xử lý kiểu compromising — mỗi tính năng làm một nửa — cả hai đều ra sản phẩm dở. Thay vào đó, bạn đào interest. Interest của Marketing là doanh thu chiến dịch 6/6. Interest của Vận hành là tránh mất tiền hoàn đơn và bảo vệ uy tín. Bạn đưa cả hai vào một buổi họp 45 phút, đặt lên bàn một tiêu chí khách quan chung: tác động tài chính ước tính.
Bạn trình bày con số: flash sale countdown dự kiến tăng ~8% conversion trong 3 ngày sale, tương đương khoảng 400 triệu doanh thu tăng thêm. Cảnh báo tồn kho ngăn được khoản hoàn tiền + chi phí xử lý ~150 triệu/tháng và rủi ro mất khách lặp lại. Khi có số, cuộc tranh cãi chuyển từ "ai to hơn" sang "cái nào ROI cao hơn trong khung thời gian nào".
Kết quả: bạn mở rộng ZOPA bằng cách bổ sung biến số phạm vi. Bạn đề xuất làm phiên bản MVP của cảnh báo tồn kho (12 điểm — chỉ hiển thị cảnh báo, chưa tự động khóa bán) đủ để chặn thiệt hại lớn nhất, cộng với flash sale countdown đầy đủ (25 điểm). Tổng 37 điểm, vừa velocity. Cả hai stakeholder đều đạt được interest cốt lõi.
Bài học: khi bị kẹt giữa hai bên, đừng để họ ép bạn chọn phe. Kéo họ ngồi cùng bàn, thay biến "position" bằng biến "tiêu chí khách quan", và tìm cách chia nhỏ phạm vi để mở rộng vùng thỏa thuận.
Tình huống 2: Dev nói "không kịp" — thương lượng nội bộ
Bối cảnh: Tại một startup fintech ở Hà Nội, bạn đã cam kết với khách hàng B2B rằng tính năng đối soát giao dịch tự động sẽ lên production trong 3 tuần. Đến buổi refinement, tech lead nói thẳng: "Không kịp. Phần tích hợp với cổng thanh toán phức tạp hơn dự kiến, cần ít nhất 5 tuần." PM thì đang nghỉ phép. Bạn đứng giữa lời hứa với khách và thực tế kỹ thuật.
Diễn giải: Sai lầm phổ biến ở đây là BA chọn kiểu competing — ép dev "phải làm cho kịp" — dẫn đến dev burnout, code ẩu, hoặc âm thầm chống đối. Cách đúng là collaborating. Đầu tiên, tách con người khỏi vấn đề: bạn không nghi ngờ năng lực dev, bạn cùng dev nhìn vào vấn đề chung là lời hứa với khách.
Bạn hỏi những câu mở rộng phương án: "Phần nào của tích hợp cổng thanh toán là bắt buộc cho lần release đầu, phần nào có thể làm thủ công tạm thời?". Hóa ra 80% giá trị nằm ở đối soát cho một cổng thanh toán chính (VNPay), còn hai cổng phụ chỉ chiếm 20% lượng giao dịch. Bạn đề xuất release đối soát tự động cho VNPay trong 3 tuần, hai cổng còn lại xử lý bán tự động (export CSV) tạm trong 2 tuần đầu, rồi hoàn thiện ở tuần thứ 5.
Trước khi báo khách, bạn chuẩn bị BATNA: nếu khách không chấp nhận giải pháp từng phần, phương án dự phòng là lùi 2 tuần với lời giải thích minh bạch về rủi ro chất lượng nếu ép tiến độ. Khi gặp khách, bạn không nói "dev làm không kịp" (đổ lỗi), mà trình bày lựa chọn: "Chúng tôi có thể giao đúng hạn giá trị cốt lõi bao phủ 80% giao dịch của anh, phần còn lại theo lộ trình 2 tuần". Khách chấp nhận, vì họ quan tâm interest — đối soát được giao dịch — chứ không phải position "đủ 3 cổng ngày đầu".
Bài học: "không kịp" hiếm khi là câu trả lời nhị phân. Vai trò BA là biến một ràng buộc cứng thành nhiều phương án phạm vi, và luôn bước vào cuộc nói chuyện với khách bằng một BATNA đã chuẩn bị sẵn.
Tình huống 3: Xung đột cá nhân âm ỉ trong team
Bối cảnh: Trong một dự án ngân hàng số, một senior dev và bạn liên tục căng thẳng. Anh ấy cho rằng tài liệu yêu cầu của bạn "thay đổi liên tục, làm mất thời gian". Mỗi buổi họp anh ấy nói kháy, khiến không khí ngột ngạt và cả team khó chịu.
Diễn giải: Đây không phải xung đột về nội dung mà về quan hệ, cần cách tiếp cận khác. Bạn không giải quyết chuyện này giữa cuộc họp đông người (sẽ đẩy anh ấy vào thế phòng thủ). Bạn xin một buổi 1-1 riêng, dùng công thức phản hồi phi bạo lực: quan sát — cảm nhận — nhu cầu — đề nghị. "Em để ý mấy buổi họp gần đây có sự căng thẳng giữa hai anh em (quan sát). Em thấy hơi khó phối hợp (cảm nhận). Em muốn hiểu góc nhìn của anh về tài liệu để tụi mình làm việc trơn tru hơn (nhu cầu). Anh chia sẻ giúp em được không (đề nghị)?".
Khi lắng nghe, bạn phát hiện interest thật của anh ấy: anh ấy đã bị "cháy" nhiều lần vì requirement đổi sau khi đã code xong, và cảm giác công sức bị phí phạm. Đây là interest chính đáng. Giải pháp không phải là bạn "cứng rắn hơn", mà là hai bên thống nhất một quy trình: mọi thay đổi yêu cầu sau khi đã lock sprint sẽ được ghi nhận qua change request và bạn sẽ chủ động cảnh báo tác động trước.
Bài học: nhiều xung đột trông có vẻ về công việc thực chất là về cảm giác bị coi thường công sức. Tách con người khỏi vấn đề, tìm interest cảm xúc, và biến giải pháp thành một cam kết quy trình chung — đó là cách xung đột quan hệ được hóa giải bền vững.
Hướng dẫn từng bước
Đây là quy trình 6 bước bạn có thể áp dụng cho gần như mọi cuộc thương lượng BA:
- Chuẩn bị (Prepare). Trước cuộc họp, viết ra: interest của mình, interest phỏng đoán của các bên, BATNA của mình, và ít nhất hai phương án win-win. Đừng bao giờ bước vào thương lượng quan trọng mà chưa chuẩn bị.
- Thiết lập không khí hợp tác (Frame). Mở đầu bằng mục tiêu chung: "Hôm nay tụi mình cùng tìm cách để dự án thành công, chứ không phải để xem yêu cầu của ai thắng". Ngôn ngữ "chúng ta cùng phía" giảm phòng thủ.
- Đào interest (Explore). Dùng câu hỏi mở: "Điều gì khiến việc này quan trọng với anh/chị?", "Nếu không có tính năng này, hậu quả cụ thể là gì?". Lắng nghe chủ động, ghi chép, phản chiếu lại để xác nhận đã hiểu đúng.
- Đưa tiêu chí khách quan lên bàn (Anchor on data). Chuyển tranh luận sang dữ liệu: ROI, số liệu người dùng, chi phí rủi ro, chuẩn ngành. Đây là nơi kỹ năng data từ những bài trước phát huy tác dụng.
- Tạo và đánh giá phương án (Generate & evaluate). Đặt lên bàn nhiều lựa chọn, chơi với các biến số phạm vi–thời gian–nguồn lực–chất lượng. Ưu tiên chia nhỏ (MVP) để mở rộng ZOPA.
- Chốt và ghi nhận (Commit & document). Thỏa thuận miệng dễ bị hiểu sai. Ngay sau cuộc họp, gửi email/Confluence tóm tắt: đã đồng ý gì, ai làm gì, khi nào. Đây vừa là kỹ năng documentation, vừa là "hợp đồng xã hội" giữ các bên có trách nhiệm.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm thương lượng với chiến thắng. Người mới nghĩ thương lượng giỏi là "ép được bên kia theo ý mình". Sai. Mục tiêu là thỏa thuận bền vững mà các bên đều cam kết thực hiện. Thắng một trận cãi nhưng để lại oán giận sẽ khiến bạn thua cả chục sprint sau.
Lỗi 2 — Nhân nhượng quá nhanh để tránh khó xử. Nhiều Designer chuyển BA vốn ngại xung đột, nên gật đầu với mọi yêu cầu rồi ôm hết áp lực về đội dev. Đây là con đường ngắn nhất tới scope creep và mất uy tín. Mẹo: luôn hỏi "để làm được X, chúng ta cần bỏ đi Y nào?" — buộc mọi yêu cầu phải có cái giá của nó.
Lỗi 3 — Đổ lỗi thay vì trình bày lựa chọn. "Dev làm không kịp" là đổ lỗi. "Chúng ta có ba phương án với đánh đổi khác nhau" là thương lượng chuyên nghiệp. Đừng bao giờ đưa một bên ra làm "kẻ có tội" trước bên khác.
Lỗi 4 — Thương lượng khi đang nóng. Khi cảm xúc lên cao, khả năng tìm giải pháp sáng tạo tụt xuống. Mẹo: nếu thấy không khí căng, dùng chiến thuật avoiding tạm thời — "Ý này hay, cho tụi mình 1 ngày suy nghĩ rồi họp lại nhé". Hạ nhiệt trước, quyết sau.
Mẹo vàng — Ghi biên bản là vũ khí. Người kiểm soát bản tóm tắt cuộc họp kiểm soát cả cách mọi người nhớ về thỏa thuận. Luôn là người chủ động viết và gửi tóm tắt. Đây là siêu năng lực thầm lặng của BA.
Mẹo — Dùng ngôn ngữ "yes, and" thay vì "no, but". Thay vì "Không, nhưng cái đó không làm được", hãy nói "Được, và nếu muốn thêm cái đó thì chúng ta cần dời deadline một tuần". Nghe hợp tác hơn nhiều mà vẫn giữ nguyên thông điệp ràng buộc.
Bài tập thực hành
Bài tập 1 — Bóc tách position/interest. Lấy 3 yêu cầu mà stakeholder từng nói với bạn (hoặc dùng từ 3 tình huống trong bài). Với mỗi yêu cầu, viết ra position (họ nói gì) và ít nhất 2 interest có thể có (vì sao họ muốn). Mục tiêu là luyện phản xạ luôn hỏi "tại sao".
Bài tập 2 — Đóng vai xung đột ưu tiên. Rủ một người bạn cùng học. Bạn đóng vai BA, họ đóng vai hai stakeholder có yêu cầu xung đột trong cùng một sprint 40 điểm. Trong 20 phút, hãy áp dụng quy trình 6 bước để đạt một thỏa thuận có ghi biên bản. Sau đó đổi vai.
Bài tập 3 — Viết BATNA. Nghĩ về một tình huống công việc thực tế bạn đang hoặc sắp đối mặt. Viết ra: interest của bạn, BATNA của bạn, phỏng đoán interest và BATNA của bên kia, và ZOPA. Chỉ cần làm bài này bạn đã tự tin hơn hẳn khi bước vào cuộc nói chuyện.
Bài tập 4 — Viết lại một câu "no, but" thành "yes, and". Lấy 5 câu từ chối thẳng thừng bạn hay dùng và viết lại theo cấu trúc hợp tác. Tập nói to cho quen miệng.
Tóm tắt
Negotiation và conflict resolution không phải là năng khiếu bẩm sinh mà là kỹ năng có phương pháp mà bất kỳ BA nào cũng học được. Nền tảng nằm ở việc phân biệt position và interest, luôn chuẩn bị BATNA, và chủ động mở rộng ZOPA bằng cách chia nhỏ phạm vi và đưa thêm biến số lên bàn. Bốn nguyên tắc của thương lượng có nguyên tắc — tách người khỏi vấn đề, tập trung interest, tạo phương án win-win, dựa trên tiêu chí khách quan — kết hợp với sự linh hoạt chọn kiểu xử lý xung đột theo mô hình Thomas-Kilmann, tạo nên bộ khung xử lý mọi tình huống.
Với người có nền Design, đây là mảnh ghép chuyển hóa empathy và facilitation sẵn có thành ảnh hưởng thực sự trong tổ chức. Khi hai stakeholder tranh nhau một sprint, khi dev nói "không kịp", hay khi có xung đột cá nhân âm ỉ — bạn không còn là người đứng nhìn hay bị ép chọn phe. Bạn là người kéo mọi người về cùng một bàn, biến ràng buộc thành lựa chọn, và chốt lại bằng một biên bản rõ ràng. Đó chính là lúc bạn không còn "làm BA" mà thực sự là một BA.