Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như mọi người làm dự án đều gặp ít nhất một lần: "Sếp muốn xong sớm hơn hai tuần, thêm ba tính năng nữa, mà không tuyển thêm ai — làm được không?". Nếu bạn gật đầu vì ngại từ chối, bạn đang tự đặt bẫy cho chính mình. Nếu bạn lắc đầu thẳng thừng, bạn bị dán nhãn "khó tính, không hợp tác". Cả hai đều thua.
Đàm phán phạm vi dự án (project scope negotiation) không phải chuyện của riêng project manager. Nó là kỹ năng sống còn của bất kỳ ai nhận việc từ người khác — developer nhận task từ team lead, designer nhận brief từ client, marketer nhận KPI từ giám đốc. Bản chất của mọi lời hứa về dự án đều là một cuộc đàm phán ngầm về ba biến số: làm cái gì, xong khi nào, dùng bao nhiêu nguồn lực. Vấn đề là hầu hết mọi người chỉ đàm phán một biến (thường là deadline) mà quên rằng ba biến này ràng buộc lẫn nhau. Bạn không thể ép một biến mà không đụng tới hai biến còn lại.
Bài này dạy bạn cách nhìn phạm vi dự án như một hệ ba ràng buộc, và cách dùng chính cấu trúc đó làm công cụ đàm phán. Khi bạn hiểu Iron Triangle (Tam giác Sắt), bạn không còn phải nói "không" một cách thô. Bạn nói: "Được, nhưng khi đó ta phải hy sinh cái gì?" — và chuyển gánh nặng quyết định về đúng người có quyền quyết.
Khái niệm cốt lõi
Triple Constraint — Tam giác Sắt (Iron Triangle)
Mọi dự án đều bị chi phối bởi ba ràng buộc, thường được vẽ thành ba cạnh của một tam giác:
- Scope (Phạm vi) — chúng ta xây dựng CÁI GÌ. Bao nhiêu tính năng, mức độ hoàn thiện, số lượng đầu việc.
- Time (Thời gian) — xong VÀO LÚC NÀO. Deadline, số tuần/tháng, mốc bàn giao.
- Resources (Nguồn lực) — dùng BAO NHIÊU. Số người, ngân sách, công cụ. (Nhiều tài liệu tách "Cost/chi phí" ra thành cạnh thứ ba, nhưng bản chất tiền và người là một họ nguồn lực.)
Nguyên tắc bất biến: "Pick two" — bạn chỉ được chọn cố định hai cạnh, cạnh thứ ba phải linh hoạt. Nếu ai đó muốn cố định cả ba, họ đang yêu cầu điều bất khả thi, và người gánh hậu quả là bạn.
- Muốn nhiều tính năng + deadline cố định? → Phải thêm người/tiền (resources co giãn).
- Muốn deadline cố định + nguồn lực cố định? → Phải cắt bớt tính năng (scope co giãn).
- Muốn đủ tính năng + nguồn lực cố định? → Phải lùi deadline (time co giãn).
Vì sao scope là biến dễ đàm phán nhất
Trong ba biến, thời gian và nguồn lực thường bị khóa cứng bởi yếu tố bên ngoài: hợp đồng đã ký deadline, ngân sách đã duyệt cả năm, headcount bị phòng nhân sự đóng băng. Còn scope lại mềm hơn nhiều so với người ta tưởng — vì phần lớn scope được viết ra bởi những người không biết chắc mình cần gì.
Nghiên cứu kinh điển của Standish Group (báo cáo CHAOS) cho thấy khoảng 45% tính năng trong phần mềm gần như không bao giờ được dùng đến, và chỉ khoảng 20% tính năng được dùng thường xuyên. Điều này nghĩa là: trong mọi bản scope bạn nhận, luôn có một lượng lớn "mỡ thừa" có thể cắt mà không ai nhớ tới. Nhiệm vụ của người đàm phán giỏi là tìm ra 20% tạo ra 80% giá trị — và đàm phán để phần còn lại được đẩy sang giai đoạn sau (phase 2) hoặc bỏ hẳn.
MoSCoW — công cụ chia hạng scope
Để đàm phán scope một cách có cấu trúc, dùng phương pháp MoSCoW phân loại từng đầu việc:
- Must have — không có thì dự án vô nghĩa, không thể ship.
- Should have — quan trọng nhưng có thể trì hoãn ngắn hạn.
- Could have — tốt nếu có, dễ dàng cắt khi thiếu thời gian.
- Won't have (this time) — thống nhất rõ là KHÔNG làm lần này, tránh cãi nhau sau.
Scope creep — kẻ thù âm thầm
Scope creep là hiện tượng phạm vi phình to dần bằng những yêu cầu nhỏ "tiện thể làm luôn" mà không ai điều chỉnh lại deadline hay nguồn lực. Mỗi yêu cầu lẻ nghe có vẻ vô hại ("chỉ thêm một nút thôi mà"), nhưng cộng dồn 20 lần "chỉ một nút" là toàn bộ dự án trễ hạn. Đàm phán scope giỏi không chỉ là đàm phán lúc đầu, mà là bảo vệ đường biên liên tục trong suốt dự án.
Tình huống thực tế
Ví dụ 1 — App giao đồ ăn của một startup TP.HCM: cắt scope để cứu deadline
Một startup food-tech ở Quận 1 (gọi là FoodNow) hứa với nhà đầu tư sẽ ra mắt app đặt món trong 3 tháng để kịp vòng gọi vốn Series A. Bản scope ban đầu có 14 tính năng: đặt món, thanh toán, theo dõi tài xế real-time, chương trình khách hàng thân thiết, chat với nhà hàng, đánh giá sao, gợi ý bằng AI, ví điện tử nội bộ...
Trưởng nhóm kỹ thuật, anh Tuấn, biết rõ đội 4 engineer không thể xong 14 tính năng trong 3 tháng. Thay vì báo "không kịp" (khiến CEO hoảng), anh dùng Iron Triangle. Anh trình bày với CEO: "Deadline 3 tháng là bất di bất dịch vì gắn với vòng gọi vốn — ta khóa Time. Đội hiện chỉ 4 người, tuyển thêm mất 6 tuần onboarding nên không kịp giúp gì — ta khóa Resources. Vậy biến duy nhất còn lại là Scope."
Anh trải MoSCoW: Must have là 5 tính năng lõi (đặt món, thanh toán, theo dõi tài xế, đánh giá, đăng nhập). Nhóm gợi ý AI, ví nội bộ, loyalty program bị đẩy sang phase 2 sau khi gọi vốn. CEO ban đầu tiếc chương trình loyalty, nhưng Tuấn phản biện bằng dữ liệu: "Nhà đầu tư muốn thấy giao dịch thật và tài xế chạy thật, không phải điểm thưởng. Loyalty ship sau, khi có tiền tuyển thêm người."
Kết quả: App ra mắt đúng 3 tháng với 5 tính năng chạy mượt. Vòng Series A thành công. Bài học: Khi hai cạnh bị khóa cứng vì lý do khách quan (deadline gọi vốn, headcount), scope BẮT BUỘC phải là biến co giãn — và người đàm phán giỏi biết dùng chính mục tiêu của đối phương (gây ấn tượng với nhà đầu tư) để biện minh cho việc cắt scope.
Ví dụ 2 — Agency và khách hàng: đàm phán change request thay vì làm miễn phí
Một agency thiết kế ở Hà Nội ký hợp đồng làm website cho một chuỗi spa với scope rõ ràng: 8 trang, 2 vòng chỉnh sửa, giao trong 6 tuần. Đến tuần thứ 4, khách hàng liên tục thêm yêu cầu: "thêm trang blog", "làm thêm phiên bản tiếng Anh", "tích hợp đặt lịch online". Đây là scope creep điển hình.
Account manager, chị Hương, không nói "không" cũng không âm thầm gánh. Chị đưa ra change request có định giá: "Chị ơi, trang blog, bản tiếng Anh và tích hợp đặt lịch nằm ngoài scope hợp đồng gốc. Em rất muốn làm cho chị vì nó tốt cho spa. Ba hạng mục này em báo giá thêm 18 triệu và cần lùi bàn giao thêm 2 tuần. Hoặc nếu chị muốn giữ đúng ngân sách và deadline cũ, ta giữ nguyên 8 trang như hợp đồng, ba mục kia làm ở giai đoạn 2. Chị chọn phương án nào ạ?"
Chị Hương làm ba việc cùng lúc: (1) công nhận yêu cầu là hợp lý — không tạo đối đầu; (2) gắn mỗi thay đổi scope với chi phí + thời gian cụ thể — làm rõ Iron Triangle; (3) trả quyền quyết định về cho khách. Khách chọn thêm bản tiếng Anh (trả thêm tiền) nhưng hoãn blog và đặt lịch.
Bài học: Scope creep không được chặn bằng cách nói "không", mà bằng cách luôn gắn thay đổi scope với thay đổi giá và thời gian. Khi mỗi yêu cầu thêm đều có "giá niêm yết" rõ ràng, khách hàng tự động lọc bớt những thứ họ không thực sự cần. Một câu "được ạ, nhưng…" đáng giá hơn mười câu "không được".
Ví dụ 3 — Nội bộ: khi Sếp muốn cả ba cạnh
Minh là team lead tại một công ty fintech ở Singapore có văn phòng ở Việt Nam. Giám đốc sản phẩm yêu cầu: ra mắt tính năng thanh toán QR trong 4 tuần, đầy đủ như kế hoạch, với đúng đội hiện tại. Cả ba cạnh đều bị đóng cứng — điều bất khả thi.
Thay vì phản đối, Minh vẽ tam giác lên bảng ngay trong cuộc họp và nói thật ôn hòa: "Em muốn giao đúng chất lượng, nên em phải minh bạch. Nếu khóa cả ba, cạnh duy nhất còn co giãn được là chất lượng — nghĩa là bug, nợ kỹ thuật, và rủi ro bảo mật cho một tính năng thanh toán. Với sản phẩm tài chính, đó là rủi ro em không dám ký tên. Vậy em đề xuất: hoặc lùi 2 tuần, hoặc mượn một engineer từ team khác 3 tuần, hoặc cắt phần QR liên ngân hàng sang tháng sau. Anh giúp em chọn một hướng?"
Bài học: Khi ai đó cố khóa cả ba cạnh, đừng để chất lượng trở thành nạn nhân âm thầm — hãy nêu tên nó ra. Việc đặt "rủi ro bảo mật thanh toán" lên bàn khiến sếp buộc phải chọn một cạnh để nới. Minh được cấp thêm một engineer trong 3 tuần. Nêu tên cái giá vô hình (chất lượng) chính là đòn bẩy mạnh nhất trong đàm phán scope nội bộ.
Hướng dẫn từng bước
Bước 1 — Xác định cạnh nào đã bị khóa thật sự. Trước khi đàm phán, hỏi rõ: deadline này khóa vì lý do gì (hợp đồng, sự kiện, gọi vốn) hay chỉ là mong muốn? Ngân sách/headcount có thật sự cố định? Thường bạn sẽ phát hiện có cạnh chỉ "tưởng là khóa" mà thực ra co giãn được. Đây là bước quan trọng nhất — đừng nhượng bộ một cạnh mà bên kia sẵn sàng nới.
Bước 2 — Liệt kê và phân hạng scope bằng MoSCoW. Chia mọi đầu việc thành Must / Should / Could / Won't. Việc này biến một khối scope mơ hồ thành danh sách rõ ràng để trao đổi từng phần.
Bước 3 — Ước lượng chi phí mỗi phần theo thời gian và nguồn lực. Với mỗi nhóm Should/Could, ghi rõ "làm cái này tốn thêm bao nhiêu ngày/người". Con số cụ thể là vũ khí thuyết phục mạnh hơn mọi lời than "nhiều việc quá".
Bước 4 — Trình bày dưới dạng lựa chọn, không phải từ chối. Công thức: "Ta có thể làm X trong điều kiện Y. Nếu muốn thêm Z, ta cần đổi lấy A hoặc B. Anh/chị chọn hướng nào?" Luôn đưa 2–3 phương án để đối phương cảm thấy mình là người quyết, không phải bị ép.
Bước 5 — Chốt bằng văn bản và định nghĩa "Won't have". Ghi rõ những gì KHÔNG làm lần này. Phần "Won't" quan trọng ngang phần "Must" vì nó ngăn tranh cãi và scope creep về sau.
Bước 6 — Thiết lập cơ chế change request. Thống nhất trước: mọi yêu cầu mới sau khi chốt scope sẽ được đánh giá lại về thời gian + nguồn lực. Đây là "hàng rào" bảo vệ dự án suốt quá trình.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ đàm phán deadline, quên hai cạnh còn lại. Nhiều người dồn hết sức xin lùi deadline mà không nghĩ tới việc cắt scope hoặc xin thêm người. Luôn nhớ: bạn có ba quân bài, đừng chỉ chơi một.
Lỗi 2 — Nói "không" trần trụi. "Không kịp đâu" tạo đối đầu và khiến bạn thành người tiêu cực. Thay bằng "Được, với điều kiện…". Bạn giữ được quan hệ mà vẫn bảo vệ được ranh giới.
Lỗi 3 — Gật đầu với scope creep vì ngại. Mỗi "tiện thể làm luôn" không được tính lại là một khoản nợ. Mẹo: tạo phản xạ "yêu cầu mới = đánh giá lại thời gian". Ngay cả khi cuối cùng bạn đồng ý làm miễn phí, hãy nói rõ "lần này em làm thêm, nhưng nó tốn thêm 2 ngày nhé" để giá trị công sức được ghi nhận.
Lỗi 4 — Để chất lượng làm nạn nhân âm thầm. Khi bị ép cả ba cạnh, người ta thường im lặng rồi giao hàng đầy lỗi. Hãy nêu tên chất lượng như một cạnh có thật và có cái giá của nó.
Mẹo — Dùng ngôn ngữ "chúng ta" thay vì "anh chống lại tôi". "Làm sao để CHÚNG TA vừa kịp deadline vừa đảm bảo chất lượng?" biến cuộc đàm phán thành giải bài toán chung, không phải cuộc giằng co.
Mẹo — Neo bằng phương án Must-have trước. Trình bày nhóm Must trước để đối phương thấy phần chắc chắn giao được, rồi mới đàm phán phần co giãn. Điều này tạo cảm giác an tâm và thiện chí.
Bài tập thực hành
Bài 1 — Vẽ tam giác của chính bạn. Chọn một dự án/task bạn đang làm. Viết ra ba cạnh: Scope hiện tại gồm gì, Time là bao lâu, Resources là ai/bao nhiêu. Xác định: cạnh nào đang thực sự bị khóa, cạnh nào bạn tưởng bị khóa nhưng thực ra co giãn được?
Bài 2 — Phân hạng MoSCoW. Lấy danh sách đầu việc của dự án đó, gán mỗi việc vào Must / Should / Could / Won't. Bạn có bất ngờ vì bao nhiêu thứ thực ra chỉ là "Could" không?
Bài 3 — Soạn kịch bản change request. Tưởng tượng sếp/khách vừa thêm một yêu cầu ngoài scope. Viết ra một câu trả lời theo công thức "Được, với điều kiện…" kèm 2 phương án đánh đổi cụ thể (thời gian hoặc nguồn lực).
Bài 4 — Tập nêu tên chất lượng. Viết một câu bạn sẽ nói khi bị ép cả ba cạnh, trong đó bạn chỉ ra rõ chất lượng sẽ bị ảnh hưởng thế nào, kèm một đề xuất nới một cạnh.
Tóm tắt
- Mọi dự án bị chi phối bởi Iron Triangle: Scope (làm gì) – Time (khi nào) – Resources (bao nhiêu), với Quality ở trung tâm.
- Nguyên tắc bất biến: "Pick two" — chỉ được cố định hai cạnh, cạnh thứ ba phải linh hoạt. Ai muốn khóa cả ba đang ép chất lượng làm nạn nhân âm thầm.
- Trong ba biến, Scope thường mềm nhất — phần lớn tính năng ít được dùng, nên luôn có "mỡ thừa" để cắt. Dùng MoSCoW để phân hạng và đàm phán từng phần.
- Đừng nói "không", hãy nói "Được, với điều kiện…" và trình bày dưới dạng menu lựa chọn có đánh đổi rõ ràng về thời gian/nguồn lực.
- Chống scope creep bằng cách luôn gắn mỗi yêu cầu mới với thay đổi thời gian và chi phí, và định nghĩa rõ phần "Won't have" ngay từ đầu.
- Đàm phán scope giỏi không phải là thắng đối phương, mà là chuyển quyết định về đúng người có quyền quyết — và bảo vệ cả dự án lẫn mối quan hệ.