# 别争两周工期，先问为什么是两周

> 这本 1981 年的谈判经典告诉 FDE：谈范围、工期和自己的 offer，都该谈利益，不谈立场。

原文: https://fdetimes.net/zh/books-courses/getting-to-yes-negotiation-for-fdes/

客户说：“这个看板两周内要。”缺乏经验的前线部署工程师（FDE）会跟客户争这两周。读过《Getting to Yes》的 FDE 会问：为什么一定是两周？答案常常会改变整个项目。

这本书的作者是 Roger Fisher、William L. Ury 和 Bruce Patton，原本不是写给工程师的。但 FDE 的工作就是不停地谈判：谈范围，谈工期，谈“完成”的定义，而在这一切之前，还要谈自己的 offer。

## 一本至今仍在印的老书

第一版于 1981 年由 Houghton Mifflin 出版，署名作者只有 Fisher 和 Ury。Patton 从后来的版本开始加入，包括 1991 年版和 2011 年 Penguin 出版的版本。值得找来读的是 Penguin Books 于 2011 年 5 月 3 日推出的更新版，ISBN 9780143118756，共 240 页。

出版方把它介绍为一套循序渐进的谈判方法，适用于任何场景，能达成让双方都满意的协议。宣传语听起来很宏大，但书的核心很紧凑：下面三个观点，就足以改变你下周的工作方式。

## 观点一：不要围绕立场讨价还价

开篇一章“Don't Bargain Over Positions”（不要在立场上讨价还价）指出，立场式谈判会带来不明智、低效率的结果。双方各自死守一个数字，对话就变成拔河：谁让步少谁赢，没有人去碰真正的问题。

想象一下围绕那两周的拔河。你提四周，客户压到三周，最后定在三周半。没有人问这个看板用来做什么，所以你很可能按时交付了一个没人打开的东西。这正是书中警告的“不明智的结果”。

## 观点二：需求之下是利益

书中最核心的一句话划出了清晰的界线：立场是你已经做出的决定，利益是促使你做出这个决定的原因。

关注利益而非立场，是作者所说的“原则式谈判”的四条原则之一。哈佛大学谈判项目（Program on Negotiation）补充说，利益是藏在表面诉求之下的需求、动机和顾虑。

回到那个例子。你问为什么是两周，假设客户回答：总监要在董事会上用一个流失率数字。利益是一个可信的数字，而不是一个完整的看板。一条干净的查询加一张图，三天就能做完，完整的看板挪到后续阶段。

**要点:** 客户说出的是立场；你的工作是找出他们选择这个立场的原因。

PostHog 的 FDE 手册用工程语言讲了同样的道理：最有力的一步，往往是纠正客户的认知模型，而不是照单全收。只有理解了背后的利益，才能纠正这个模型。

## 观点三：坐下之前先清楚自己的替代方案

书中提出了 BATNA，即谈判协议的最佳替代方案（Best Alternative to a Negotiated Agreement）。逻辑很简单：谈判是为了得到比不谈判更好的结果。所以，任何不如替代方案的 offer 都应该拒绝。

放到 FDE offer 上，这意味着清楚自己手里已经有什么：现在的工作、另一份 offer，或者留在原团队、换一个更贴近客户的角色。

看一个例子。你是一家稳定公司的后端工程师，收到一份 FDE offer，要求每月大部分时间驻场在客户那里。你的 BATNA 是留在现在的岗位：还不错，但离客户很远。

最容易脱口而出的立场是“我不想经常出差”。把真正的利益写下来，你可能会发现有两条：每周需要固定几天在家；干一段时间后，想把从客户那里学到的东西带回产品。

这两条利益打开了可以交换的空间；“不出差”只会打开一场拔河。

于是你可以接受 offer 里描述的驻场安排，但把远程办公的日子固定下来，并要求一条进入产品团队的明确路径。如果公司两条都满足不了，最终 offer 仍然不如现在的工作，你的 BATNA 就给了你一个清楚的理由，可以毫无负担地拒绝。

在项目范围上，FDE 的 BATNA 通常是拒绝含糊不清的工作。PostHog 要求每个项目在开始实施前，都要有可衡量的成果、大致的时间线，以及双方共同认可的“完成”定义。

它还建议把范围控制得小一些，因为扩大一个收紧的范围，比收拾一个松散的范围成本低；在做出承诺之前，先发一份简短的说明请客户确认。

## 用错了是什么样子？

第一个错误是替客户猜测利益。你断定“他们大概只需要流失率数字”，没有确认就砍掉范围。客户没有确认过的利益，仍然只是你的假设，很容易变成一个新的立场，只不过这次是你的立场。

第二个错误是把“为什么”问成审讯。这个问题应该邀请客户谈谈他们面临的压力，比如“这个数字会用在哪里？”，而不是逼他们为自己的需求辩护。

第三个错误是理解了利益之后，反而揽下更多工作。知道客户担心什么，不等于要在一个项目里解决所有担心。PostHog 关于小范围的建议就是这里的刹车。最后一个错误是没写下自己的 BATNA 就去谈 offer，然后只为了不得罪人而一步步让步。

## 谁该读，按什么顺序读

如果你是有两到八年经验、即将转岗 FDE 的工程师，或者刚接手第一个项目，那么在读任何销售类书籍之前，先读这本。先读“Don't Bargain Over Positions”认清陷阱，再读关于利益的部分，然后是 BATNA 的部分。240 页，一个周末就能读完。

但不要只为了划线而读。每读完一部分，就打开一个真实的客户需求，按两栏重写：立场和利益。你会发现，第二栏填对之后，大多数范围之争就消失了。

在职业发展上，让这项能力体现在简历和面试里。与其写“与客户合作”，不如写一句具体的话：把最初的需求收窄到更小、但仍满足需要的范围，并取得可衡量的结果。

阅读 FDE 岗位描述时，留意关于商定范围或与客户对齐预期的句子，并准备好一个这样的故事，被问到时就讲出来。

第一版问世四十多年后，Fisher 和 Ury 提出的那个问题，仍然是第一次客户会议上最有价值的问题：“为什么？”

**本周动手试试:**

- 拿出最近一个客户需求，用一行写下立场，用三行写下背后可能的利益，然后请客户核对。
- 开始工作前，给客户发一份半页的说明，写明可衡量的成果、时间线和“完成”的定义。
- 如果你在找 FDE 工作，下一次谈 offer 之前，先写下自己的最佳替代方案。

## 信源

- [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)