title: "Sử dụng dữ liệu để đàm phán: Đừng nói bằng cảm tính, hãy nói bằng con số"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 29
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "9 phút đọc"
tags: ["đàm phán", "data-driven", "ưu tiên hoá tính năng", "product analytics", "stakeholder management", "BA skills"]

Sử dụng dữ liệu để đàm phán: Đừng nói bằng cảm tính, hãy nói bằng con số

Bạn đã bao giờ ngồi trong một cuộc họp mà quyết định về sản phẩm được đưa ra chỉ vì "tôi nghĩ khách hàng cần cái này" — do một người có chức vụ cao nhất trong phòng nói ra? Khi hai ý kiến cảm tính đối đầu nhau, người thắng thường không phải là người đúng, mà là người có nhiều quyền lực hơn. Đó là lúc dữ liệu — thứ không ai cãi được nếu nó đủ tin cậy — trở thành công cụ đàm phán mạnh nhất mà một BA có trong tay.

🎯 Kỹ thuật cốt lõi: Chuẩn bị "Bộ ba dữ liệu" trước khi vào phòng họp tranh cãi

Trước bất kỳ cuộc họp nào có nguy cơ biến thành cuộc đấu ý kiến cá nhân (ai nói to hơn, ai chức cao hơn thắng), người làm BA/PO/EA giỏi chuẩn bị sẵn ba nhóm dữ liệu — gọi tắt là Bộ ba U-E-C (Usage — Effort — Cost):

Usage (Dữ liệu sử dụng thực tế) — Ai đang thực sự dùng cái gì, bao nhiêu lần, ở đâu?
- Số lượt truy cập/sử dụng tính năng trong khoảng thời gian gần nhất (7-30-90 ngày).
- Số lượng người dùng unique đã chạm vào tính năng đó, so với tổng số người dùng active.
- Tỷ lệ hoàn thành luồng (completion rate) nếu là quy trình nhiều bước.
- Nguồn: log hệ thống, Google Analytics/Mixpanel, dữ liệu support ticket, hoặc đơn giản là export từ DB nếu chưa có công cụ tracking.
Effort (Chi phí công sức) — Làm cái này tốn bao nhiêu?
- Số ngày công (man-day) ước tính của team dev/design/QA.
- Có phụ thuộc kỹ thuật nào (technical debt, refactor bắt buộc) làm effort đội lên không.
- So sánh effort của phương án A và phương án B trên cùng một thang đo.
Cost (Chi phí cơ hội và tiền bạc) — Nếu chọn cái này, ta đánh đổi cái gì?
- Tính năng nào khác bị đẩy lùi lịch nếu ưu tiên cái đang tranh cãi.
- Chi phí hạ tầng/vận hành phát sinh (nếu có) — server, license, support.
- Rủi ro về thời gian: có deadline hợp đồng nào bị ảnh hưởng không.

Nguyên tắc dùng bộ ba này trong đàm phán: không mang dữ liệu ra để "thắng" mà mang ra để "dịch chuyển trọng tâm cuộc tranh luận" — từ "ai nói đúng" sang "cái gì tạo giá trị nhiều hơn với chi phí thấp hơn". Khi trọng tâm dịch chuyển, người có ý kiến cảm tính buộc phải phản biện bằng dữ liệu khác (nếu có) thay vì bằng cảm giác — và cuộc họp trở lại đúng bản chất của nó: ra quyết định dựa trên bằng chứng.

Một lưu ý quan trọng: dữ liệu phải được chuẩn bị trước khi họp, không phải "để tôi kiểm tra lại rồi báo cáo sau". Nếu bạn mang dữ liệu vào giữa cuộc tranh cãi mà không kịp xử lý, nó sẽ bị nghi ngờ là "số liệu dựng lên để chống lại ý kiến của sếp". Dữ liệu phải đến từ một khảo sát/trích xuất có thể trưng ra nguồn, thời điểm lấy, và phương pháp tính — càng minh bạch càng khó bác bỏ.

Bối cảnh (Situation)

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

Dự án xây dựng lại một nền tảng quản lý bán hàng cho một chuỗi bán lẻ vừa và nhỏ. Sau 4 tháng triển khai, đội dự án bước vào giai đoạn lập kế hoạch cho Release 3 — release cuối cùng trước khi go-live toàn hệ thống, với ngân sách effort chỉ còn đủ cho khoảng 3 tuần phát triển.

Cuộc họp ưu tiên tính năng cho Release 3 có mặt: Giám đốc Vận hành phía khách hàng (người tài trợ dự án, gọi là "anh T."), Trưởng phòng CNTT phía khách hàng, Product Owner phía nhà cung cấp, và chị H. — BA phụ trách chính của dự án.

Anh T. mở đầu cuộc họp với một đề xuất chắc nịch: ưu tiên xây dựng tính năng "Báo cáo tồn kho theo thời gian thực đa chi nhánh" — một tính năng phức tạp, ước tính chiếm gần 70% effort còn lại của release. Lý do anh đưa ra: "Tôi đi thăm chi nhánh tuần trước, thấy quản lý kho ở đó than phiền không xem được tồn kho real-time. Cái này quan trọng, ưu tiên số 1."

Trưởng phòng CNTT phía khách hàng — người trực tiếp làm việc với đội vận hành hàng ngày — không đồng ý nhưng ngần ngại phản đối thẳng cấp trên. PO phía nhà cung cấp thì lo lắng vì tính năng này đụng tới kiến trúc đồng bộ dữ liệu giữa các chi nhánh, effort thực tế có thể vượt xa ước tính ban đầu, kéo lùi các tính năng khác đã cam kết trong hợp đồng.

Thách thức (Task)

Chị H. đối mặt với một tình huống khó xử lý gấp đôi:

Thứ nhất, đây không phải là tranh luận kỹ thuật thuần tuý — nó là tranh luận giữa cảm nhận cá nhân của một lãnh đạo cấp cao (dựa trên một chuyến thăm thực địa, một cuộc trò chuyện) và nhu cầu thực tế của phần lớn người dùng mà chưa ai kiểm chứng bằng số liệu. Nếu chị H. phản đối trực tiếp bằng câu "tôi nghĩ khác", cuộc tranh luận sẽ biến thành đấu ý kiến cá nhân với người có quyền quyết định cao nhất — và chị gần như chắc chắn thua, dù có lý.

Thứ hai, nếu răm rắp làm theo, đội dự án sẽ dồn 70% effort còn lại vào một tính năng phục vụ nhu cầu của một nhóm nhỏ (có thể chỉ 1-2 chi nhánh có vấn đề đặc thù), trong khi các tính năng nền tảng khác — vốn ảnh hưởng đến toàn bộ 15 chi nhánh — bị đẩy lùi hoặc cắt bỏ. Hậu quả nếu chọn sai: go-live với sản phẩm không đáp ứng đúng nhu cầu số đông, phát sinh khiếu nại từ nhiều chi nhánh khác, và quan trọng hơn — mất niềm tin của chính khách hàng vào năng lực tư vấn của đội dự án, vì họ sẽ nhận ra sau này rằng quyết định ưu tiên đã không dựa trên cơ sở nào cả.

Cái khó nhất: chị H. phải làm việc này mà không làm anh T. mất mặt trước đội của chính mình.

Hành động (Action)

Chị H. không phản bác ngay tại cuộc họp. Chị xin phép "để em kiểm tra lại số liệu sử dụng thực tế và effort chi tiết, rồi trình bày phương án cụ thể trong 2 ngày" — một đề nghị hợp lý mà không ai có thể từ chối.

Bước 1 — Thu thập dữ liệu Usage trong 24 giờ. Chị H. phối hợp với đội kỹ thuật trích xuất log sử dụng của module tồn kho hiện tại (bản cũ đang chạy song song) trong 30 ngày gần nhất. Kết quả: tính năng xem tồn kho được truy cập trung bình 40 lượt/ngày trên toàn hệ thống, nhưng 34 trong số 40 lượt đó đến từ đúng 2 trên 15 chi nhánh — hai chi nhánh có mô hình vận hành đặc thù (bán buôn, xoay vòng hàng nhanh). 13 chi nhánh còn lại gần như không truy cập tính năng này quá 1 lần/tuần.

Bước 2 — Đối chiếu với ticket hỗ trợ và khảo sát nhanh. Chị H. rà lại 2 tháng lịch sử ticket hỗ trợ, lọc theo từ khóa liên quan tới tồn kho. Chỉ 3/120 ticket liên quan đến "không xem được tồn kho real-time" — toàn bộ đều từ 2 chi nhánh đã xác định ở bước 1. Ngược lại, nhóm ticket lớn nhất (28 ticket) liên quan đến một tính năng khác đang bị xếp ưu tiên thấp: đồng bộ giá bán khi có khuyến mãi theo đợt — vấn đề mà 9/15 chi nhánh đều gặp phải.

Bước 3 — Lượng hoá effort và cost cho cả hai phương án. Chị H. làm việc với PO và tech lead để ra bảng so sánh đơn giản, chỉ với 3 cột: tính năng — effort ước tính (man-day) — số chi nhánh hưởng lợi trực tiếp. Bảng này cố tình không dùng ngôn ngữ kỹ thuật, để bất kỳ ai đọc cũng hiểu ngay trong 30 giây.

Bước 4 — Chọn đúng thời điểm và định dạng trình bày. Thay vì gửi email dài hoặc trình bày slide đầy chữ, chị H. xin một cuộc họp ngắn 20 phút riêng với anh T. trước khi họp lại với cả nhóm — để anh T. có không gian xem xét dữ liệu và đổi ý mà không cần "lùi bước" trước mặt cấp dưới. Trong buổi trao đổi này, chị H. mở đầu bằng việc xác nhận lại nỗi lo của anh T. là chính đáng ("Đúng là có chi nhánh gặp vấn đề thật, dữ liệu cho thấy rõ 2 chi nhánh đó"), sau đó mới đưa bức tranh toàn cảnh: "Nhưng nếu nhìn toàn bộ 15 chi nhánh, đây là nhóm nhu cầu lớn hơn nhiều, effort lại thấp hơn 3 lần."

Bước 5 — Đề xuất phương án dung hoà, không phải phương án đối đầu. Chị H. không đề xuất "bỏ hẳn" ý tưởng của anh T., mà đề xuất chia nhỏ: ưu tiên tính năng đồng bộ giá khuyến mãi (effort thấp, lợi ích rộng) cho Release 3, đồng thời đưa "báo cáo tồn kho real-time" vào Release 4 với phạm vi thu hẹp — chỉ áp dụng riêng cho 2 chi nhánh có nhu cầu thật, thay vì xây dựng kiến trúc đồng bộ toàn hệ thống tốn kém.

Kết quả (Result)

Anh T. đồng ý với phương án đề xuất sau khi xem dữ liệu — không phải vì bị thuyết phục bằng lời nói, mà vì con số cho thấy rõ ràng quyết định ban đầu chỉ dựa trên một lát cắt nhỏ của thực tế. Cuộc họp chung sau đó diễn ra suôn sẻ, không ai cảm thấy bị "bác bỏ" công khai vì phương án cuối cùng được trình bày như một sự tinh chỉnh, không phải một sự phủ định.

Release 3 hoàn thành đúng effort dự kiến, tính năng đồng bộ giá khuyến mãi giảm rõ rệt số lượng ticket hỗ trợ liên quan đến sai lệch giá — theo ước tính nội bộ, giảm khoảng 70% so với 2 tháng trước đó. Tính năng báo cáo tồn kho real-time thu hẹp phạm vi cho 2 chi nhánh cũng được triển khai đúng hẹn ở Release 4, với effort thấp hơn đáng kể so với phương án ban đầu.

Điều chưa hoàn hảo: việc trích xuất dữ liệu usage mất nhiều thời gian hơn dự kiến vì hệ thống cũ không có sẵn công cụ tracking chuẩn, đội kỹ thuật phải viết script tạm để lấy log — đây là một lỗ hổng mà lẽ ra dự án nên thiết lập từ sớm hơn (tracking cơ bản nên có ngay từ Release 1). Ngoài ra, dữ liệu 30 ngày là một cửa sổ quan sát tương đối ngắn, có thể bỏ sót yếu tố mùa vụ (ví dụ nhu cầu tồn kho tăng vọt vào mùa cao điểm) — chị H. có ghi chú rủi ro này trong tài liệu quyết định, đề nghị review lại sau 1 quý vận hành thực tế.

📋 Áp dụng ngay

Trước bất kỳ cuộc họp nào có dấu hiệu sẽ thành tranh luận cảm tính, chủ động hỏi "mình có dữ liệu sử dụng thực tế cho việc này chưa?" — nếu chưa, xin thêm thời gian trước khi họp thay vì tranh luận suông tại chỗ.
Luôn chuẩn bị bộ ba Usage — Effort — Cost ở dạng bảng đơn giản, không quá 1 trang, để bất kỳ stakeholder nào cũng đọc hiểu trong vài phút.
Khi dữ liệu mâu thuẫn với ý kiến của người có quyền lực cao, trao đổi riêng trước để họ có không gian "đổi ý" mà không mất mặt trước tập thể.
Đề xuất phương án dung hoà (thu hẹp phạm vi, dời lịch) thay vì phương án đối đầu "làm hoặc không làm" — giữ thể diện cho người đã lỡ đề xuất ý tưởng ban đầu.
Ghi chú rõ giới hạn của dữ liệu (cửa sổ thời gian ngắn, thiếu yếu tố mùa vụ...) trong tài liệu quyết định, để tránh dữ liệu bị dùng cực đoan như "chân lý tuyệt đối".

💡 Bài học đúc rút: Dữ liệu không thắng người có chức vụ cao hơn bằng cách đối đầu — nó thắng bằng cách dịch chuyển câu hỏi từ "ai đúng" sang "cái gì có bằng chứng". Người BA giỏi không mang số liệu vào để chứng minh sếp sai, mà để cho sếp một lối ra đầy thể diện: đổi quyết định dựa trên thông tin mới, chứ không phải nhượng bộ trước cấp dưới.

🔗 Kỹ năng liên quan

Bài trước: Quản lý sự thay đổi (Change Management) · Bài tiếp theo: Cách xử lý các bên liên quan (Stakeholder Management)