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 phần khó nhất của công việc là gì, câu trả lời hiếm khi là "viết user story" hay "cấu hình Jira". Câu trả lời thường là: "Ai cũng muốn thứ của họ được làm trước, và tôi chỉ có một backlog."
Backlog trong Jira nhìn bề ngoài chỉ là một danh sách sắp xếp từ trên xuống dưới. Nhưng thực chất, mỗi vị trí trên backlog là kết quả của một cuộc thương lượng. Khi bạn kéo một item lên trên, một item khác — cùng với người đang chờ nó — bị đẩy xuống. Sales muốn tính năng cho deal đang chốt. Marketing muốn thứ để tung chiến dịch quý sau. Engineering muốn thời gian trả nợ kỹ thuật (tech debt). CEO vừa gặp một khách hàng lớn và về với "một ý tưởng nhỏ". Tất cả đều đang nhìn vào cùng một backlog của bạn.
Bài này không nói về cách cấu hình Jira, mà nói về kỹ năng con người quan trọng nhất mà một PM phải rèn: quản lý xung đột ưu tiên và thương lượng trên backlog. Đây là kỹ năng phân biệt một PM "nhận yêu cầu và ghi vào Jira" với một PM thật sự dẫn dắt sản phẩm. Nếu bạn làm tốt, backlog trở thành công cụ tạo sự đồng thuận. Nếu làm dở, backlog trở thành chiến trường và bạn là người hứng đạn từ mọi phía.
Khái niệm cốt lõi
Xung đột backlog là gì và vì sao nó không thể tránh
Xung đột backlog xảy ra khi có nhiều nhu cầu chính đáng cạnh tranh cùng một nguồn lực khan hiếm: thời gian của đội phát triển. Điểm mấu chốt cần hiểu là hầu hết các xung đột này không phải do ai đó sai. Sales đúng khi nói tính năng X giúp chốt deal 2 tỷ. Engineering cũng đúng khi nói không trả tech debt thì tháng sau hệ thống sập. Cả hai đều đúng, và đó chính là lý do nó khó. Xung đột không phải là dấu hiệu tổ chức có vấn đề — nó là dấu hiệu tổ chức có nhiều cơ hội hơn năng lực thực thi, điều này gần như luôn đúng.
Vai trò của PM không phải là làm hài lòng tất cả, mà là đưa ra quyết định đánh đổi (trade-off) một cách minh bạch và có thể bảo vệ được.
Bốn nguồn xung đột phổ biến nhất
1. Nhiều stakeholder cùng đòi ưu tiên cao nhất. Ai cũng nghĩ việc của mình là P1 (Priority 1). Khi mọi thứ đều là P1, thực chất không có gì là P1 cả. Đây là dấu hiệu backlog thiếu một khung ưu tiên (prioritization framework) chung.
2. Engineering pushback về scope. Đội dev cho rằng phạm vi quá lớn, ước lượng bị nén, hoặc yêu cầu bỏ qua chất lượng. Đây là loại xung đột lành mạnh nhất nếu được xử lý đúng, vì nó dựa trên thực tế kỹ thuật.
3. Sales cần tính năng để chốt deal. Áp lực doanh thu là loại áp lực khó cưỡng nhất vì nó gắn với con số cụ thể và thường có deadline gắt. Rủi ro lớn là biến sản phẩm thành "sản phẩm của một khách hàng" (feature cho một deal mà 99% khách còn lại không cần).
4. Marketing cần "câu chuyện" để ra mắt. Marketing thường cần một tính năng đủ nổi bật cho chiến dịch, một mốc ra mắt cụ thể. Xung đột xảy ra khi lịch marketing áp lên lịch phát triển thay vì ngược lại.
Ba trụ cột để thương lượng thắng
- Khung ưu tiên khách quan: Dùng một framework như RICE (Reach, Impact, Confidence, Effort) hoặc WSJF (Weighted Shortest Job First) để chuyển tranh cãi cảm tính thành so sánh có căn cứ.
- Sự minh bạch của backlog: Khi mọi người thấy backlog và lý do sắp xếp, tranh cãi chuyển từ "tại sao anh không làm việc của tôi" sang "việc của tôi đứng trước hay sau việc kia, và vì sao".
- Tách con người khỏi vấn đề: Nguyên tắc kinh điển của thương lượng — bạn không đối đầu với người của Sales, cả hai cùng đối đầu với bài toán nguồn lực hữu hạn.
Interest vs Position — trái tim của thương lượng
Đây là khái niệm quan trọng nhất bài này. Position (lập trường) là thứ người ta nói họ muốn: "Tôi cần tính năng export PDF trong sprint này." Interest (lợi ích thật) là lý do sâu xa đằng sau: "Khách hàng lớn của tôi phàn nàn họ không lấy được báo cáo ra ngoài để trình sếp." Khi bạn hiểu interest thay vì chỉ nghe position, bạn thường tìm được giải pháp thứ ba rẻ hơn nhiều — ví dụ export CSV mở bằng Excel, làm trong 2 ngày thay vì export PDF làm mất 2 tuần. PM giỏi luôn hỏi "để làm gì?" trước khi đồng ý hay từ chối.
Tình huống thực tế
Tình huống 1 — Sales vs Roadmap tại một fintech Việt Nam
Một công ty fintech ở TP.HCM (khoảng 40 người, sản phẩm ví điện tử cho doanh nghiệp) đang trong sprint tập trung hoàn thiện tính năng đối soát giao dịch. Giữa sprint, Giám đốc Sales lao vào và nói: "Có một chuỗi F&B 60 cửa hàng sắp ký hợp đồng 1,8 tỷ/năm, nhưng họ yêu cầu tích hợp với phần mềm kế toán MISA. Nếu không có trong 3 tuần, mất deal."
PM đầu tiên phản xạ muốn nói "không, sprint đã full". Nhưng thay vào đó, cô hỏi về interest: "Deal này chốt là chắc chắn, hay MISA chỉ là một trong nhiều điều kiện?" Hóa ra khách hàng còn đang so sánh hai nhà cung cấp và MISA là điểm quyết định. Cô hỏi tiếp: "Họ cần đồng bộ hai chiều real-time, hay chỉ cần xuất file để nhập vào MISA thủ công cuối ngày?" — Khách chỉ cần xuất file.
Kết quả: thay vì tích hợp API đầy đủ (ước lượng 4 tuần), đội làm một tính năng xuất file định dạng MISA (5 ngày). PM đưa item này lên đầu backlog nhưng công khai với cả team trong buổi refinement rằng tính năng đối soát sẽ lùi 1 sprint, kèm lý do doanh thu cụ thể. Trong Jira, cô tạo issue mới, gắn label sales-committed, link tới Epic doanh thu, và ghi rõ trong phần mô tả: "Cam kết với khách CHUỖI-F&B, deadline hợp đồng 21/03, phạm vi rút gọn: export file, KHÔNG phải full API."
Bài học: Đừng phản ứng với position ("cần MISA"). Đào tới interest ("cần chốt deal", "cần xuất dữ liệu"). Giải pháp rút gọn thường thỏa mãn 90% giá trị với 20% công sức. Và luôn ghi lại cam kết trong Jira để sau này không ai chối bỏ trade-off đã đồng thuận.
Tình huống 2 — Nhiều phòng ban cùng đòi P1
Một công ty SaaS logistics (giả định tên "GiaoNhanh", đội sản phẩm 3 squad) bước vào kỳ lập kế hoạch quý và nhận được 11 yêu cầu, tất cả đều gắn nhãn "khẩn cấp": Marketing cần tính năng tracking cho chiến dịch Tết, CSKH cần dashboard giảm ticket, Vận hành cần tối ưu thuật toán chia đơn, CEO cần "phần AI gì đó cho kịp đối thủ".
Sai lầm thường thấy là PM cố nhét hết vào một quý và rồi trượt tiến độ toàn bộ. PM ở đây làm khác: cô tổ chức một buổi prioritization workshop và bắt mỗi phòng ban chấm điểm yêu cầu của mình theo RICE trước mặt nhau. Điều kỳ diệu xảy ra khi mọi thứ lên bảng: yêu cầu "AI" của CEO có Reach cao nhưng Confidence rất thấp và Effort khổng lồ, nên điểm RICE tụt xuống nhóm giữa. Tính năng tracking Tết có Reach lớn, Effort nhỏ, deadline cứng — leo lên top một cách thuyết phục mà không cần ai phải "chiến đấu".
Khi mọi người thấy điểm số công khai, tranh cãi chuyển từ "quyền lực ai to hơn" sang "con số nói gì". CEO tự rút yêu cầu AI xuống, đề nghị làm một spike nghiên cứu nhỏ trước.
Bài học: Khi mọi thứ đều là P1, hãy dùng một khung khách quan để buộc sự đánh đổi lộ ra. Framework không đưa ra quyết định thay bạn, nhưng nó biến cuộc họp chính trị thành cuộc thảo luận dữ liệu. Sự minh bạch của điểm số làm giảm nhu cầu đối đầu cá nhân.
Tình huống 3 — Engineering pushback về tech debt
Tại một công ty thương mại điện tử ở Hà Nội, Tech Lead nhắn PM: "Ba sprint liền chúng ta chỉ đẩy tính năng mới, code phần thanh toán đã chắp vá đến mức mỗi lần sửa là một lần cầu nguyện. Tôi cần một sprint để refactor, nếu không sẽ có sự cố nghiêm trọng dịp sale lớn."
PM cảm thấy áp lực vì phía business không "nhìn thấy" giá trị của refactor. Thay vì chọn phe, cô làm hai việc. Một, cô yêu cầu Tech Lead lượng hóa rủi ro: "Nếu không làm, xác suất sự cố ngày sale là bao nhiêu, thiệt hại ước tính bao nhiêu?" — câu trả lời: khoảng 30% sập, mỗi giờ downtime ngày sale mất ~150 triệu doanh thu. Hai, cô không xin nguyên một sprint refactor (điều business sẽ phản đối), mà đề xuất phân bổ 20% mỗi sprint cho tech debt — một chính sách bền vững, ghi rõ bằng một Epic "Ổn định hệ thống thanh toán" với các sub-task nhỏ chèn đều vào mỗi sprint.
Cô trình bày với business bằng ngôn ngữ tiền và rủi ro, không phải ngôn ngữ kỹ thuật. Business đồng ý ngay khi thấy con số 150 triệu/giờ.
Bài học: Engineering pushback thường là món quà — nó cảnh báo rủi ro business chưa thấy. Nhiệm vụ PM là dịch rủi ro kỹ thuật sang ngôn ngữ business (tiền, xác suất, khách hàng). Và thay vì trận đánh "một sprint refactor" gây đối đầu, hãy thương lượng một chính sách phân bổ đều đặn — dễ được chấp nhận hơn nhiều.
Hướng dẫn từng bước
Đây là quy trình xử lý một xung đột backlog khi nó phát sinh:
Bước 1 — Không quyết định ngay tại chỗ. Khi ai đó đến với "việc này phải làm ngay", đừng gật cũng đừng lắc. Câu nói an toàn: "Tôi hiểu tầm quan trọng. Để tôi đưa vào so sánh với những gì đang trong backlog rồi phản hồi anh trước cuối ngày." Điều này bảo vệ bạn khỏi cam kết theo cảm xúc và giữ quyền quyết định dựa trên bức tranh tổng thể.
Bước 2 — Đào tới interest. Hỏi ít nhất ba câu: "Việc này để giải quyết vấn đề gì?", "Nếu chậm hai tuần thì hậu quả cụ thể là gì?", "Phiên bản tối giản nào cũng giải quyết được 80% vấn đề?". Ghi lại câu trả lời.
Bước 3 — Lượng hóa bằng framework. Chấm điểm yêu cầu bằng RICE hoặc WSJF, đặt cạnh các item đang cạnh tranh. Nếu chưa có framework chung, đây là lúc thiết lập nó — đừng thương lượng bằng cảm tính.
Bước 4 — Làm cho trade-off hữu hình. Không bao giờ nói "được, tôi sẽ thêm vào". Luôn nói: "Nếu thêm việc này lên đầu, thì việc Y sẽ lùi sang sprint sau. Anh chấp nhận đánh đổi đó chứ?" Trong Jira, thể hiện điều này bằng cách kéo item xuống và để chủ item đó biết.
Bước 5 — Ghi quyết định vào Jira. Cập nhật thứ tự backlog, thêm comment giải thích lý do sắp xếp, gắn label (sales-committed, tech-debt, deferred-Q3) và link tới Epic tương ứng. Backlog phải là nguồn sự thật duy nhất (single source of truth) mà ai cũng xem được.
Bước 6 — Truyền đạt rộng. Sau buổi refinement, gửi tóm tắt ngắn: cái gì lên, cái gì xuống, vì sao. Sự minh bạch chủ động ngăn 90% khiếu nại về sau.
Bước 7 — Leo thang đúng cách nếu bế tắc. Nếu hai stakeholder ngang quyền không thống nhất, đừng tự gánh. Đưa vấn đề (đã kèm dữ liệu và phương án) lên cấp có thẩm quyền quyết định để họ "chọn giùm", nhưng bạn là người trình bày trung lập.
Lỗi thường gặp & mẹo
Lỗi 1 — Nói "có" với tất cả. PM mới thường sợ làm mất lòng nên nhận hết. Kết quả là mọi thứ đều dở dang, mọi người đều thất vọng, và bạn mất uy tín. Nhớ: mỗi lần nói "có" với một việc là nói "không/chậm" với việc khác — chỉ là bạn không nói ra.
Lỗi 2 — Từ chối mà không giải thích. "Không làm được" là câu trả lời của một cái máy. "Việc này chưa lên được vì đang đứng sau ba item có RICE cao hơn, đây là chúng" mới là câu trả lời của một PM. Luôn kèm lý do và dữ liệu.
Lỗi 3 — Để cảm xúc dẫn dắt trong phòng họp. Khi Sales lớn tiếng, phản xạ là phòng thủ hoặc nhượng bộ. Mẹo: hạ nhịp bằng cách hỏi câu hỏi thay vì bảo vệ. "Anh chia sẻ thêm về deadline này giúp tôi được không?" vừa câu giờ vừa lấy thông tin.
Lỗi 4 — Quyết định trong hành lang, không ghi lại. Những "deal" thỏa thuận miệng ngoài Jira là mầm mống của mọi tranh cãi sau này. Quy tắc vàng: nếu không có trong Jira, nó không tồn tại. Mọi cam kết ưu tiên phải để lại dấu vết.
Mẹo 1 — Xây "ngân sách ưu tiên" trước, không phải từng vụ. Thay vì đánh nhau từng item, hãy thỏa thuận trước tỷ lệ phân bổ: ví dụ 60% tính năng mới, 20% tech debt, 20% cho các yêu cầu khẩn phát sinh. Khi khung này đã được duyệt, mỗi xung đột chỉ còn là "việc này thuộc ngân sách nào", nhẹ hơn nhiều.
Mẹo 2 — Dùng "parking lot" cho ý tưởng của sếp. Khi CEO ném một ý tưởng, đừng bác cũng đừng nhét ngay vào sprint. Ghi vào một khu vực chờ (một filter/label riêng trong Jira) và định kỳ đưa ra chấm điểm cùng mọi thứ khác. Ý tưởng được tôn trọng nhưng không phá vỡ hệ thống.
Mẹo 3 — Biến "không" thành "chưa, và đây là điều kiện để có". Câu này giữ quan hệ và trao quyền cho người đề xuất: "Việc này chưa lên top vì thiếu bằng chứng về nhu cầu. Nếu anh cho tôi ba khách hàng xác nhận cần nó, nó sẽ vượt lên."
Bài tập thực hành
- Phân tích interest vs position. Lấy ba yêu cầu gần nhất bạn nhận được (hoặc giả định). Với mỗi yêu cầu, viết ra Position (điều họ nói muốn) và Interest (vấn đề thật đằng sau). Nghĩ một giải pháp tối giản khác thỏa mãn interest với ít công sức hơn.
- Chấm điểm RICE. Tạo một bảng với 5 item backlog giả định. Chấm mỗi item theo Reach, Impact, Confidence, Effort và tính điểm RICE. Sắp xếp lại thứ tự. Item nào bạn nghĩ là P1 ban đầu nhưng tụt hạng sau khi chấm? Vì sao?
- Viết câu trả lời trade-off. Tình huống: Sales yêu cầu một tính năng cho deal, nhưng sprint đã đầy. Viết ra đúng lời bạn sẽ nói — theo mẫu "Nếu thêm X thì Y sẽ lùi, anh chấp nhận không?" — sao cho vừa chuyên nghiệp vừa giữ quyền quyết định.
- Thiết lập nhãn trong Jira. Thiết kế một bộ label và quy ước comment để ghi lại quyết định ưu tiên (ví dụ khi nào dùng
sales-committed,deferred,tech-debt). Viết một comment mẫu giải thích lý do một item bị lùi lịch.
- Đóng vai leo thang. Viết một email hoặc tin nhắn ngắn (dưới 150 từ) trình bày một xung đột bế tắc lên cấp trên để họ quyết định, giữ giọng trung lập và kèm đủ dữ liệu cho hai phương án.
Tóm tắt
Backlog không phải một danh sách vô tri — nó là bản ghi những cuộc thương lượng và đánh đổi mà một PM đưa ra mỗi ngày. Xung đột ưu tiên là điều không thể tránh, vì tổ chức nào cũng có nhiều cơ hội hơn năng lực. Nhiệm vụ của bạn không phải làm hài lòng tất cả, mà là quyết định trade-off một cách minh bạch, có căn cứ và có thể bảo vệ được.
Ba nguyên tắc cần khắc cốt: Thứ nhất, luôn đào tới interest thật thay vì phản ứng với position — giải pháp thứ ba rẻ hơn thường nằm ở đó. Thứ hai, dùng một khung ưu tiên khách quan (RICE, WSJF) để biến tranh cãi cảm tính thành thảo luận dữ liệu và giảm đối đầu cá nhân. Thứ ba, làm mọi trade-off trở nên hữu hình và ghi lại trong Jira — nếu không có trong Jira, nó không tồn tại.
Khi bạn xử lý xung đột backlog một cách bình tĩnh, minh bạch và dựa trên dữ liệu, bạn không chỉ sắp xếp được công việc — bạn xây dựng được thứ quý giá nhất của một PM: sự tin tưởng rằng những quyết định của bạn là công bằng và vì lợi ích chung của sản phẩm.