# Getting to Yes: cuốn sách đàm phán dạy FDE hỏi "vì sao" trước khi chốt phạm vi hay nhận offer

> Ra mắt lần đầu năm 1981 và được Penguin cập nhật năm 2011, cuốn sách của Fisher, Ury và Patton giúp kỹ sư thôi mặc cả tính năng với khách hàng để bắt đầu đàm phán về vấn đề thật.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-getting-to-yes-dam-phan-offer-va-pham-vi/

Một khách hàng nói: "Chúng tôi cần dashboard này trong hai tuần." Một FDE non tay sẽ cãi về con số hai tuần. Một FDE đã đọc *Getting to Yes* sẽ hỏi vì sao lại là hai tuần, và câu trả lời thường làm thay đổi cả dự án.

Cuốn sách của Roger Fisher, William L. Ury và Bruce Patton không viết cho kỹ sư. Nhưng công việc của FDE là đàm phán liên tục: phạm vi, thời hạn, định nghĩa "xong", và trước hết là offer của chính bạn.

## Một cuốn sách cũ, vẫn được in lại

Bản đầu tiên ra mắt năm 1981 tại Houghton Mifflin, chỉ có Fisher và Ury đứng tên. Patton tham gia ở các bản sau, gồm bản 1991 và bản 2011 do Penguin phát hành. Bản bạn nên tìm là bản cập nhật Penguin Books phát hành ngày 3/5/2011, ISBN 9780143118756, dài 240 trang.

Nhà xuất bản giới thiệu đây là phương pháp đàm phán từng bước, áp dụng được cho mọi tình huống để đạt thỏa thuận làm cả hai bên hài lòng. Lời quảng cáo nghe to tát, nhưng phần lõi của sách thực ra rất gọn: ba ý dưới đây là đủ để bạn đổi cách làm việc ngay tuần tới.

## Ý thứ nhất: đừng mặc cả trên lập trường

Chương mở đầu, "Don't Bargain Over Positions", lập luận rằng mặc cả theo lập trường cho kết quả kém khôn ngoan và kém hiệu quả. Khi hai bên mỗi người giữ một con số, cuộc nói chuyện thành cuộc kéo co: ai nhượng ít hơn là thắng, còn vấn đề thật không ai chạm tới.

Thử hình dung cuộc kéo co về hai tuần kia. Bạn đề xuất bốn tuần, khách ép ba, hai bên chốt ba tuần rưỡi. Không ai hỏi dashboard để làm gì, nên rất có thể bạn giao đúng hạn một thứ không ai mở. Đó chính là "kết quả kém khôn ngoan" mà sách cảnh báo.

## Ý thứ hai: lợi ích nằm dưới yêu cầu

Câu cốt lõi của sách phân biệt rất rõ: lập trường là điều bạn đã quyết định, còn lợi ích là lý do khiến bạn quyết định như vậy.

Tập trung vào lợi ích thay vì lập trường là một trong bốn nguyên tắc của phương pháp mà các tác giả gọi là principled negotiation. Chương trình Đàm phán của Harvard diễn giải thêm: lợi ích là nhu cầu, động cơ và mối quan tâm nằm dưới các yêu cầu bề mặt.

Quay lại ví dụ. Bạn hỏi vì sao là hai tuần, và giả sử khách đáp: giám đốc cần một con số churn cho buổi họp hội đồng quản trị. Lợi ích là một con số đáng tin, không phải một dashboard đầy đủ. Một truy vấn sạch cộng một biểu đồ có thể xong trong ba ngày, còn dashboard trọn vẹn để sang giai đoạn sau.

**Điểm mấu chốt:** Khách hàng nói ra lập trường; việc của bạn là tìm lý do khiến họ chọn nó.

Sổ tay FDE của PostHog nói cùng điều đó bằng ngôn ngữ kỹ sư: nước đi mạnh nhất thường là sửa mô hình tư duy của khách hàng, chứ không phải xây đúng thứ họ yêu cầu. Bạn chỉ sửa được mô hình đó khi đã hiểu lợi ích phía sau.

## Ý thứ ba: biết phương án thay thế trước khi ngồi xuống

Sách đưa ra khái niệm BATNA, phương án tốt nhất khi không đạt được thỏa thuận. Lý lẽ rất đơn giản: người ta đàm phán để tạo ra kết quả tốt hơn những gì có được khi không đàm phán. Vì thế, bất cứ đề nghị nào tệ hơn phương án thay thế của bạn đều nên bị từ chối.

Với offer FDE, điều này có nghĩa bạn phải biết rõ mình đang có gì: công việc hiện tại, một offer khác, hay cơ hội ở lại nhóm cũ với vai trò gần khách hàng hơn.

Thử hình dung một trường hợp. Bạn là backend engineer ở một công ty ổn định và nhận offer FDE kèm yêu cầu có mặt tại site khách hàng phần lớn thời gian trong tháng. BATNA của bạn là ở lại công việc hiện tại, vốn ổn nhưng không cho bạn gặp khách hàng.

Lập trường dễ bật ra nhất là "tôi không muốn đi công tác nhiều". Khi viết ra lợi ích thật, bạn có thể thấy hai điều: bạn cần vài ngày cố định mỗi tuần ở nhà, và bạn muốn sau một thời gian được đưa bài học từ khách hàng vào sản phẩm.

Hai lợi ích này mở ra thứ để trao đổi, còn câu "không đi công tác" chỉ mở ra cuộc kéo co.

Vậy bạn có thể đề nghị nhận lịch on-site như mô tả nhưng chốt những ngày làm từ xa cố định, và xin một lộ trình rõ để tham gia vào nhóm sản phẩm. Nếu công ty không đáp ứng được điều nào và offer cuối cùng vẫn tệ hơn công việc hiện tại, BATNA cho bạn lý do rõ ràng để từ chối mà không phải áy náy.

Với phạm vi dự án, BATNA của FDE thường là không nhận phần việc mập mờ. PostHog yêu cầu mỗi engagement có kết quả đo được, mốc thời gian sơ bộ và định nghĩa chung về "xong" trước khi bắt đầu triển khai.

Hãng còn khuyên giữ phạm vi nhỏ, vì mở rộng một phạm vi chặt rẻ hơn gỡ một phạm vi lỏng, và gửi brief ngắn để khách xác nhận trước khi cam kết.

## Áp dụng sai thì trông thế nào?

Lỗi đầu tiên là đoán lợi ích thay khách. Bạn tự kết luận "chắc họ chỉ cần con số churn" rồi cắt phạm vi mà không hỏi lại. Lợi ích chưa được khách xác nhận vẫn chỉ là giả thuyết của bạn, và nó dễ biến thành một lập trường mới, lần này là của bạn.

Lỗi thứ hai là hỏi "vì sao" như thẩm vấn. Câu hỏi nên mở đường cho khách kể về áp lực của họ, kiểu "con số này sẽ được dùng ở đâu?", chứ không phải bắt họ bảo vệ yêu cầu của mình.

Lỗi thứ ba là hiểu lợi ích rồi lại ôm thêm việc. Biết khách lo gì không có nghĩa phải giải mọi nỗi lo trong một engagement. Lời khuyên của PostHog về phạm vi nhỏ chính là chiếc phanh cho lỗi này. Lỗi cuối cùng là bước vào đàm phán offer mà chưa viết ra BATNA, rồi nhượng dần chỉ vì ngại làm mất lòng.

## Ai nên đọc, đọc theo thứ tự nào

Nếu bạn là kỹ sư 2-8 năm kinh nghiệm sắp chuyển sang FDE, hoặc vừa nhận dự án đầu tiên, cuốn này đáng đọc trước mọi sách bán hàng. Đọc chương "Don't Bargain Over Positions" trước để thấy cái bẫy, rồi phần nói về lợi ích, rồi phần BATNA. Cả cuốn chỉ 240 trang, đọc xong trong một cuối tuần.

Nhưng đừng đọc để gạch chân. Sau mỗi phần, mở lại một yêu cầu thật của khách và viết lại nó theo hai cột: lập trường và lợi ích. Bạn sẽ thấy phần lớn tranh cãi về phạm vi biến mất khi cột thứ hai được điền đúng.

Về nghề nghiệp, hãy cho kỹ năng này hiện ra trong CV và buổi phỏng vấn. Thay vì ghi "làm việc với khách hàng", hãy viết một câu cụ thể: đã thu hẹp một yêu cầu ban đầu thành phạm vi nhỏ hơn mà vẫn giải đúng nhu cầu, kèm kết quả đo được.

Khi đọc job description FDE, hãy tìm những dòng nói về việc chốt phạm vi hay thống nhất kỳ vọng với khách hàng, và chuẩn bị sẵn đúng một câu chuyện như thế để kể khi được hỏi.

Hơn bốn mươi năm sau lần in đầu, câu hỏi Fisher và Ury đặt ra vẫn là câu hỏi đáng giá nhất trong buổi họp đầu tiên với khách hàng: "Vì sao?"

**Thử ngay tuần này:**

- Lấy yêu cầu gần nhất của khách hàng, viết một dòng lập trường và ba dòng lợi ích có thể nằm sau nó, rồi hỏi khách để kiểm chứng.
- Gửi khách một brief nửa trang gồm kết quả đo được, mốc thời gian và định nghĩa 'xong' trước khi bắt tay vào làm.
- Nếu đang tìm việc FDE, viết ra phương án thay thế tốt nhất của bạn trước buổi nói chuyện offer kế tiếp.

## Nguồn

- [Getting to Yes by Roger Fisher, William L. Ury, Bruce Patton: 9780143118756](https://www.penguinrandomhouse.com/books/324551/getting-to-yes-by-roger-fisher-and-william-ury/)

- [Getting to Yes - Wikipedia](https://en.wikipedia.org/wiki/Getting_to_Yes)

- [Summary of "Getting to Yes: Negotiating Agreement Without Giving In"](https://www.beyondintractability.org/bksum/fisher-getting)

- [Principled Negotiation: Focus on Interests to Create Value](https://www.pon.harvard.edu/daily/negotiation-skills-daily/principled-negotiation)

- [How forward deployed engineers work - PostHog Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)