Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi làm trong ngành tech đủ lâu, chắc chắn bạn từng ngồi trong một buổi planning mà PM nói: "Feature này chắc làm nhanh thôi, tuần sau ship được không?" — và trong đầu bạn hét lên "Không đời nào!" nhưng miệng thì lại lí nhí "Ừm... để em xem." Cái khoảng cách giữa điều PM tin và điều engineer biết chính là chiến trường của bài học hôm nay.
Đàm phán scope (phạm vi công việc) là một trong những kỹ năng giao tiếp bị đánh giá thấp nhất nhưng lại có sức ảnh hưởng lớn nhất đến sự nghiệp của một engineer. Vì sao? Vì nó quyết định ba thứ cùng lúc: chất lượng sản phẩm bạn giao, độ tin cậy mà PM và stakeholder đặt vào bạn, và mức độ burnout của chính bạn. Một engineer giỏi code nhưng không biết đàm phán scope sẽ liên tục rơi vào vòng xoáy: nhận việc quá tải, làm ẩu vì gấp, sinh bug, mất uy tín, rồi lại bị ép deadline chặt hơn.
Điều quan trọng cần nắm ngay từ đầu: đàm phán scope không phải là cuộc chiến giữa engineer và PM. Nó là cuộc hợp tác giữa hai người có thông tin bất đối xứng. PM nắm rõ giá trị kinh doanh, thị trường, khách hàng. Engineer nắm rõ chi phí kỹ thuật, rủi ro, nợ kỹ thuật (tech debt). Đàm phán tốt là quá trình hai bên trao đổi thông tin để cùng tìm ra điểm tối ưu — chứ không phải kéo co để xem ai thắng. Sự căng thẳng (tension) giữa hai vai trò này là lành mạnh, miễn là nó được giao tiếp đúng cách.
Khái niệm cốt lõi
Điệu nhảy bất tận: PM muốn ship, Eng biết chi phí thật
Hãy hình dung mối quan hệ Eng ↔ PM như một điệu nhảy. PM có động lực tự nhiên là đẩy nhanh, thêm tính năng, ship sớm để chiếm thị trường. Engineer có động lực tự nhiên là làm chắc, giảm rủi ro, tránh nợ kỹ thuật. Cả hai đều đúng theo góc nhìn của mình. Vấn đề không nằm ở việc ai sai, mà ở việc thông tin không được đặt lên bàn.
Sai lầm phổ biến nhất là engineer giữ kín "chi phí thật" trong đầu và chỉ nói ra kết luận ("làm không kịp đâu"), còn PM giữ kín "giá trị thật" và chỉ nói ra yêu cầu ("cần có tính năng này"). Khi cả hai chỉ trao đổi kết luận mà không trao đổi lý do, cuộc đàm phán biến thành mặc cả kiểu chợ búa. Ngược lại, khi engineer nói rõ "phần A tốn 2 ngày, phần B tốn 8 ngày vì phải xử lý edge case X" và PM nói rõ "khách hàng chỉ thực sự cần phần A cho lần demo tuần sau", thì lời giải xuất hiện gần như tự động.
Ba đòn bẩy của mọi cuộc đàm phán: Scope – Time – Quality
Đây là bộ khung nền tảng bạn phải thuộc lòng. Mọi dự án phần mềm đều bị ràng buộc bởi ba biến số:
- Scope (làm bao nhiêu tính năng, sâu đến đâu)
- Time (bao lâu thì xong)
- Quality/Resources (chất lượng, số người, nợ kỹ thuật chấp nhận được)
Cái hay của cách nói này là bạn không từ chối, không đối đầu. Bạn chỉ đưa quyền quyết định — kèm hậu quả rõ ràng — về đúng người có thẩm quyền là PM. Đây gọi là "đàm phán bằng lựa chọn, không phải bằng lời từ chối".
Các mẫu câu (patterns) đàm phán scope
Mẫu "MVP thật sự": Khi PM muốn nhồi nhiều thứ vào một lần ship, hãy kéo cuộc trò chuyện về câu hỏi gốc: "Nếu chỉ được giữ lại một thứ để bản này vẫn có giá trị, đó là gì?" MVP (Minimum Viable Product) thật sự không phải là "phiên bản rút gọn của mọi thứ", mà là "phiên bản đầy đủ của thứ quan trọng nhất". Câu hỏi này buộc PM ưu tiên hoá thay vì đòi hỏi tất cả.
Mẫu "Now / Next / Later": Thay vì tranh cãi có làm hay không, hãy chia tính năng thành ba giỏ: làm ngay, làm ở sprint kế, làm sau. Điều này giúp PM cảm thấy không có gì bị "vứt đi", chỉ là được sắp xếp lại thứ tự. Về mặt tâm lý, con người dễ chấp nhận "hoãn" hơn là "loại bỏ".
Mẫu "Spike trước khi cam kết": Với tính năng có độ bất định cao, đừng vội đưa con số. Hãy đề xuất một "spike" — một khoảng thời gian giới hạn (ví dụ 1 ngày) để nghiên cứu trước khi ước lượng. Điều này bảo vệ bạn khỏi việc cam kết một con số bịa ra rồi bị nó ám ảnh suốt sprint.
Mẫu "Đánh đổi tường minh": Luôn diễn đạt yêu cầu mới bằng công thức "Có, và..." thay vì "Không". Ví dụ: "Có, mình có thể thêm tính năng export PDF. Và để làm vậy trong sprint này, mình cần dời tính năng notification sang sprint sau. Anh ok chứ?" Câu "Có, và..." biến bạn từ người cản trở thành đối tác giải quyết vấn đề.
Tình huống thực tế
Tình huống 1: Startup fintech Việt Nam và cái deadline "chốt với nhà đầu tư"
Tại một startup fintech ở TP.HCM (gọi là VíXanh), PM tên Linh chạy vào chỗ team engineer bốn ngày trước cuối sprint: "Bên investor muốn xem demo tính năng chuyển tiền liên ngân hàng vào thứ Sáu. Team làm kịp không?" Engineer lead tên Tuấn theo phản xạ cũ đã suýt gật đầu, vì sợ làm mất lòng và sợ ảnh hưởng đến vòng gọi vốn.
Nhưng Tuấn đã dừng lại và hỏi hai câu quan trọng: "Investor cần thấy nó chạy hay cần nó chạy thật với tiền thật?" và "Demo này thành công thì kết quả cụ thể là gì?" Hoá ra investor chỉ cần thấy luồng hoạt động mượt trên môi trường demo, không cần tích hợp thật với cổng ngân hàng — vốn là phần tốn 90% công sức vì phải xử lý bảo mật, đối soát và xử lý lỗi giao dịch.
Tuấn đề xuất: "Thứ Sáu em sẽ có demo chạy đầy đủ luồng UI với dữ liệu giả lập, trông y như thật. Phần tích hợp cổng ngân hàng thật cần thêm 3 tuần vì liên quan bảo mật và đối soát — nếu ép làm trong 4 ngày, rủi ro là demo bị lỗi ngay trước mặt investor, tệ hơn nhiều so với dùng mock data." Linh đồng ý ngay.
Bài học: Đàm phán scope bắt đầu bằng việc đào sâu vào mục tiêu thật đằng sau yêu cầu. Rất nhiều lần, thứ PM xin không phải thứ PM cần. Một demo giả lập mượt mà đánh bại một tích hợp thật đầy bug. Câu hỏi "cần thấy hay cần chạy thật" đã tiết kiệm cho team 3 tuần làm ẩu.
Tình huống 2: Team e-commerce và trận "nhồi 8 tính năng vào một sprint"
Tại một công ty thương mại điện tử ở Singapore phục vụ thị trường Đông Nam Á, PM đưa ra một sprint plan với 8 tính năng cho trang giỏ hàng, tất cả đều gắn nhãn "high priority". Engineer tên Minh biết rõ nếu nhận hết, team sẽ làm ẩu và trang thanh toán — vốn nhạy cảm về doanh thu — sẽ đầy lỗi.
Thay vì phản đối kiểu "nhiều quá làm sao kịp", Minh mở một buổi họp 30 phút và làm bài tập ưu tiên hoá công khai. Anh vẽ ba cột lên bảng: Now / Next / Later, rồi hỏi PM từng tính năng một: "Nếu bản này ship mà thiếu cái này, doanh thu có tụt không?" Kết quả: chỉ 3 trong 8 tính năng thực sự ảnh hưởng doanh thu trực tiếp. Minh cũng chỉ ra rằng 2 trong 8 tính năng đang cùng chạm vào một module thanh toán, nên làm chung sẽ tiết kiệm hơn làm rời.
Kết quả sprint: team ship 3 tính năng "Now" với chất lượng cao, 3 tính năng "Next" đã có bản thiết kế sẵn để sprint sau chạy nhanh, và 2 tính năng "Later" được PM tự nguyện gạt xuống sau khi thấy chúng ít tác động.
Bài học: Khi mọi thứ đều "high priority" thì không có gì là priority. Công cụ Now/Next/Later biến một cuộc tranh cãi cảm tính thành một bài tập ra quyết định dựa trên dữ liệu (doanh thu). Và quan trọng: chính PM là người tự gạt tính năng xuống — engineer chỉ cung cấp khung để PM tự thấy. Đó là đàm phán ở đẳng cấp cao: bạn thắng mà đối phương không cảm thấy thua.
Tình huống 3: Cú "estimate bịa" và bài học về spike
Một bạn engineer junior tại một agency phần mềm ở Hà Nội bị PM hỏi giữa cuộc họp: "Tính năng đăng nhập bằng Face ID mất bao lâu?" Áp lực đám đông khiến bạn buột miệng "Chắc 2 ngày ạ." Con số này lập tức bị ghi vào kế hoạch và cam kết với khách hàng.
Thực tế, Face ID trên nhiều dòng máy Android có hành vi khác nhau, thư viện của bên thứ ba có vấn đề tương thích, và việc xử lý fallback khi nhận diện thất bại phức tạp hơn nhiều. Sau 2 ngày, tính năng mới xong 30%. Bạn engineer mất uy tín, còn PM mất mặt với khách hàng.
Lẽ ra, câu trả lời đúng là: "Em chưa chắc vì phụ thuộc thư viện bên thứ ba và độ tương thích thiết bị. Cho em một spike nửa ngày để dựng thử proof-of-concept, chiều nay em sẽ đưa con số đáng tin." Nửa ngày spike đó sẽ tiết kiệm hàng tuần trễ hạn và giữ được uy tín.
Bài học: Không bao giờ để áp lực khoảnh khắc ép bạn đưa một con số bạn không tin. "Em cần nghiên cứu thêm rồi trả lời chính xác" là một câu trả lời chuyên nghiệp, không phải dấu hiệu yếu kém. Một estimate bịa ra là một lời hứa bạn sẽ phải trả bằng những đêm thức khuya và uy tín bị bào mòn.
Hướng dẫn từng bước
Đây là quy trình sáu bước để đàm phán scope một cách bài bản, dùng được ngay trong buổi họp tới của bạn:
Bước 1 — Đào mục tiêu, đừng phản ứng với yêu cầu. Khi nhận yêu cầu, đừng vội trả lời "làm được / không làm được". Hãy hỏi: "Vấn đề của người dùng mà tính năng này giải quyết là gì?" và "Thành công của bản này trông như thế nào?" Bạn cần hiểu why trước khi bàn how much.
Bước 2 — Chia nhỏ và ước lượng minh bạch. Bẻ yêu cầu thành các phần nhỏ. Với mỗi phần, đưa ước lượng kèm lý do và độ bất định. Ví dụ: "Phần UI: 2 ngày, khá chắc. Phần tích hợp API bên thứ ba: 3–6 ngày, chưa chắc vì chưa rõ tài liệu của họ." Việc bày ra "chưa chắc" giúp PM hiểu rủi ro.
Bước 3 — Đặt ba biến Scope/Time/Quality lên bàn. Nói rõ với PM rằng ba thứ này ràng buộc nhau và không thể cố định cả ba. Hỏi thẳng: "Trong sprint này, thứ nào là bất di bất dịch — ngày ship, số tính năng, hay chất lượng?"
Bước 4 — Đề xuất lựa chọn, không đưa tối hậu thư. Luôn đưa ít nhất hai phương án kèm hậu quả rõ ràng. "Phương án A: giữ deadline, cắt tính năng X. Phương án B: giữ đủ tính năng, lùi 1 tuần." Để PM chọn — họ có thẩm quyền, bạn có thông tin.
Bước 5 — Chốt bằng văn bản. Sau khi thống nhất, viết lại rõ ràng vào ticket, Slack hoặc email: "Như đã thống nhất, sprint này ship A, B, C; tính năng D dời sang sprint 12; chấp nhận rủi ro chưa test kỹ phần E." Việc ghi lại tránh việc "tôi nhớ khác" về sau và bảo vệ cả hai bên.
Bước 6 — Theo dõi và cập nhật sớm. Nếu giữa chừng phát hiện estimate sai, báo ngay chứ đừng đợi đến deadline. Đàm phán scope không kết thúc ở buổi planning; nó là một cuộc đối thoại liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Gật đầu vì sợ mất lòng. Đây là cái bẫy phổ biến nhất, đặc biệt với engineer Việt Nam do văn hoá ngại từ chối cấp trên. Nhưng một lời "vâng" giả tạo hôm nay sẽ thành một cú trễ hạn thật ngày mai, gây thiệt hại lớn hơn nhiều. Mẹo: thay vì "không", hãy dùng "Có, và đây là cái giá phải trả".
Lỗi 2 — Nói "khó lắm" mà không đưa con số và lý do. Câu "cái này khó/phức tạp lắm" là vô nghĩa với PM vì nó không giúp họ ra quyết định. Mẹo: luôn dịch "khó" thành thời gian và rủi ro cụ thể: "Phần này tốn thêm 4 ngày vì phải xử lý 3 edge case về đồng bộ dữ liệu."
Lỗi 3 — Giấu nợ kỹ thuật (tech debt) để làm nhanh mà không nói. Đôi khi bạn buộc phải cắt góc để kịp deadline, điều đó ổn — nhưng phải nói ra. Nợ kỹ thuật im lặng là loại nợ tệ nhất. Mẹo: "Em sẽ dùng giải pháp tạm để kịp thứ Sáu, nhưng cần ghi nợ 2 ngày refactor ở sprint sau, nếu không phần này sẽ khó mở rộng."
Lỗi 4 — Đàm phán trong lúc nóng. Khi bị dồn ép giữa cuộc họp đông người, cảm xúc dễ lấn át. Mẹo: xin thời gian — "Cho em 30 phút chia nhỏ task rồi em đưa con số đáng tin" — luôn tốt hơn một cam kết vội vàng.
Mẹo vàng — Xây dựng uy tín trước khi cần đàm phán. Sức mạnh đàm phán của bạn đến từ lịch sử ước lượng chính xác. Nếu bạn từng nói "3 ngày" và giao đúng 3 ngày nhiều lần, PM sẽ tin con số của bạn. Uy tín là đồng tiền của đàm phán scope — hãy tích luỹ nó từ những dự án nhỏ.
Bài tập thực hành
Bài 1 — Viết lại lời từ chối. Lấy ba câu "không" mà bạn từng nói (hoặc muốn nói) với PM, viết lại mỗi câu theo mẫu "Có, và [cái giá phải trả]". Ví dụ chuyển "Không kịp đâu" thành "Kịp được nếu mình cắt tính năng lọc nâng cao sang sprint sau."
Bài 2 — Bài tập ba biến. Chọn một task đang làm. Viết ra ba kịch bản: (a) giữ nguyên deadline thì scope co lại thế nào; (b) giữ nguyên scope thì deadline lùi bao lâu; (c) giữ cả hai thì chất lượng/nợ kỹ thuật đánh đổi ra sao. Mang ba kịch bản này ra buổi họp kế.
Bài 3 — Đóng vai. Nhờ một đồng nghiệp đóng vai PM đang ép bạn nhồi 6 tính năng vào 1 sprint. Bạn phải dùng khung Now/Next/Later để đưa xuống còn 3 tính năng mà không nói tiếng "không" nào. Ghi âm lại và tự đánh giá xem bạn có đào được "why" và đưa "trade-off" tường minh không.
Bài 4 — Nhật ký estimate. Trong hai tuần, mỗi lần đưa một estimate, hãy ghi lại con số và độ tự tin. Cuối kỳ, so với thực tế. Bài tập này giúp bạn tự hiệu chỉnh và xây uy tín — nền tảng của mọi cuộc đàm phán.
Tóm tắt
Đàm phán scope với PM/Product không phải là một trận đấu để phân thắng bại, mà là một quá trình hợp tác để trao đổi thông tin bất đối xứng: PM biết giá trị kinh doanh, engineer biết chi phí kỹ thuật. Nắm chắc bộ khung Scope – Time – Quality: bạn không thể cố định cả ba, và nhiệm vụ của bạn là làm cho sự đánh đổi hiện rõ để PM ra quyết định đúng người, đúng thông tin.
Hãy nhớ bốn mẫu công cụ: MVP thật sự (đầy đủ thứ quan trọng nhất, không phải rút gọn mọi thứ), Now/Next/Later (hoãn dễ chấp nhận hơn loại bỏ), Spike trước khi cam kết (đừng bịa con số dưới áp lực), và "Có, và..." (biến bản thân thành đối tác giải quyết vấn đề thay vì người cản trở). Luôn đào mục tiêu thật trước khi phản ứng với yêu cầu, đưa lựa chọn kèm hậu quả thay vì tối hậu thư, và chốt mọi thoả thuận bằng văn bản.
Cuối cùng, sức mạnh đàm phán lớn nhất của bạn là uy tín được xây từ những estimate chính xác. Đàm phán scope giỏi không chỉ giúp bạn tránh burnout — nó biến bạn từ một người viết code thụ động thành một đối tác kỹ thuật mà PM và cả tổ chức tin cậy khi cần ra những quyết định quan trọng.