# 评审不是批准：把方案交给团队时，真正要谈的是什么

用“评审评的是理解是否一致”这条线，讲清“做不了”的四种情况怎么分辨、范围谈判为什么要把手段交出去，以及评审之后哪三件事补不回来

> 团队协作 · 需求评审 · 范围管理 · 估算 · 约 7 分钟 · 10 月 14 日

## 本篇要点

1. 需求评审评的不是“这个功能该不该做”，那是排序阶段的事；它评的是双方对同一件事的理解是否一致，产出应该是取舍清单和不做清单，而不是一句“通过”。
2. 方案里大量决定是隐含的，过了评审，写代码的人会自己补上没写清的部分，补法不一定是你想要的；评审是这些隐含决定最后一次被摆上桌面的机会。
3. 评审能谈出什么，取决于之前有没有让做的人参与；否则取舍只能等到时间最紧的那一刻做。
4. “做不了”至少包含四种情况：真的做不到、代价不匹配、理解偏差、不认同方案能解决问题。它们的应对方式相反，追问“做不了的是哪一部分”才能分辨。
5. 把需求降级成约束（法律、财务、销售、合同），能给工程留下更多解题自由度；需求锁死做法，约束只锁边界。
6. 谈范围时守住目的、放开手段，并且让对方提议砍哪一半，因为成本信息在他手里；边界线是砍完之后用户还能不能自己把这件事做完，不能就说明这一版不该上。
7. 估算是区间不是数字，早期误差可达数倍，只有减少项目本身的变量才会收窄，中途改需求会让它重新变宽。
8. 验收标准和埋点必须进开发范围：前者要能被判断并直接变成测试用例，后者决定上线后有没有数据可看——漏埋了就只能等下一版重来。

---

上一篇结束时，方案已经被拆成几条假设，也挑出了最该先验的那条。假设验完、方案定下来，接下来是把它交到真正动手的人手里。多数人以为这一步就是“过个评审”，但接下来两三个月会发生什么，很大程度在这场会上就定了。

## 评审评的不是“要不要做”

这个功能该不该做，在排优先级那一步就定了；有哪几个方案可选、为什么选这个，在发散那一步就定了。评审再把这两件事翻出来重吵，等于用时间最紧的时候，推翻时间最宽裕时做过的判断。

评审真正要评的只有一件事：**我们对同一件事的理解是不是一致的。**

回到门店报表那个例子。方案叫“一键导出周报”。你脑子里是：把三个页面的数据合起来，生成一张能直接贴进汇报的表。研发脑子里可能是：把当前页面的数据导出成 CSV。两个人都说“一键导出”，都点了头，到提测那天才发现做出来的是两样东西。

这不是谁的错，而是方案本身的属性：一份方案里，绝大部分决定是隐含的。讲 PRD 那篇里那句话在这里同样成立——成品上看不出来的决定才值得写下来。评审就是这些隐含决定最后一次被摆到桌面上的机会。过了这道门，写代码的人会自己把没写的地方补上，补法有很多种，他补的那种不一定是你要的。

所以评审有个实用的自检：开完会，你能不能说出一两件“团队现在明白了、而一小时前还不明白”的事？一条都说不出，那这场会只是通知。

Cagan 描述过一种反面剧本：PRD 写完扔过墙，等排期时才发现时间比需要的多出几个月，于是开始吵估算、砍功能、压缩测试时间[1]。换句话说，**评审能谈出什么，取决于评审之前你有没有让做的人参与**；否则所有取舍都会被推迟到时间最紧的那一刻[2]。

## “做不了”不是一个答案，是四种情况

评审桌上最卡的一刻，是研发说“这个做不了”。这三个字没有信息量，它至少涵盖四种情况，而应对方式彼此相反：

**一、技术上真的做不到。** 依赖的接口没开放、老系统结构撑不住、合规不允许。这一类没有谈判空间，只能回到问题那一层改目标或换路径——不是把方案改小，是承认这条路走不通。

**二、能做，但代价和这件事的价值不匹配。** “要两周”不是理由，理由永远是“这两周花在这里，就不能花在别处”。这时要问的不是“能不能快一点”，而是“这两周换回来的东西值不值”。这就是讲优先级时的机会成本，只是单位从“需求”换成了“工时”。

**三、他理解错了你要什么。** 这一类占比最高，也最好解决，前提是你把话题从方案挪回问题：店长准备材料太慢这件事还在不在？在的话，界面长什么样我不在乎。

**四、他不认同这个方案能解决问题。** 这一类最容易被当成态度问题顶回去，其实最值钱——他是在评审你的假设。他也许没做过用户访谈，但有别的经验。别急着否定，问一句“你觉得哪一步会不成立”。

区分这四类，动作很小：**别接受“做不了”这三个字，追问“做不了的是哪一部分”。**

Cagan 还有一个提醒：公司里不少人会热心地给工程“需求”，而大部分需求并不是真的必须。产品经理该做的是找出底下的约束——法律、财务、销售、合同——把约束交给工程；约束给得越少，工程解决问题的自由度越大[3]。需求锁死做法，约束只锁住边界。

## 谈范围：把手段交出去，把问题留下来

如果卡住的是范围，谈判有一个基本动作：**把目的和手段分开。** 目的是店长周一早上不用手工抄数、核对，手段是那个“一键导出”按钮。目的要扛住，手段随时可以换。

具体怎么谈？不要问“能不能做”，要问“如果只能做一半，你想砍哪一半”。

道理在于：谁最清楚哪部分贵，谁才应该提出砍法。研发手里的成本信息比你多得多，让他提议，砍掉的会落在真正便宜的地方。反过来，你从“哪部分对用户最不重要”出发去砍，很容易砍掉那个最便宜、却恰好解决不了问题的部分。

砍下去还要有一条边界线：**砍完之后，用户还能不能自己把这件事做完。** 砍成“先支持导出 CSV，格式你自己调”，店长还是能完成汇报，可以；砍成“先只导出最常用的那个页面”，他还要手工合并另外两个，那这件事等于没解决——这时正确的回答是这一版先不做，而不是上一个半成品。Cagan 那句话就是这个意思：已经砍到最小可用了，再砍一条腿，这狗就跑不动了[1]。

Shape Up 里有两个做法值得借。一是把时间预算叫 **appetite**，它和估算方向相反：估算从一个设计出发算出一个数字，appetite 从一个数字出发逼出一个设计[4]——先定这件事值得花两周还是六周，再让方案缩进这个框里，“时间够不够”的争论就提前到了方案设计阶段。二是把这份预算和一组 **no-gos**（明确不做的东西）一起写出来，因为一份方案同时也在告诉团队“做到哪里就停”[5]。

还有一个信号值得留意：对方说的“不行”，不一定是不行在时间上。Shape Up 给的反问是“如果我们两周就能做完，你觉得怎么样？”——有时得到的回答是“我不想在那个模块里再引入一个依赖”，那就压根不是时间问题[6]。问出这句话，你才知道自己在谈什么。

## 评审之后：三件补不回来的事

**一、那个“两周”本来就不是一个数。** 估算研究里有个说法叫不确定锥：在最初的概念阶段，估算误差可以是高 4 倍、低 4 倍，也就是上下相差 16 倍；它只在“做决定、消掉变量”时才收窄，而且收窄主要发生在前 20%–30% 的时间里[7]。它有个反直觉的推论：多给估算员一周，估算不会因此更准——不确定来自项目本身，只有把定义做细才能真正收窄。需要说明的是，这是熟练估算者在“最好情况”下能达到的精度，那几个倍数是历史项目统计出来的经验值，不是精确常数。

这条规律解释了为什么开发中途改需求代价那么大：每改一次，不只是多花改动的时间，还会把已经收窄的估算重新推回宽的那一端。所以 Cagan 讲工程开工之后产品经理的首要任务，是尽快回答他们的问题、把需求变动压到最低[1]。

**二、验收标准。** 什么情况算做完了，必须是一句能被判断的话，而且它要能直接变成测试用例。如果没人能判断“这算过还是没算过”，它就不是标准，只是愿望。

**三、埋点。** 成功的指标和判断规则要在动手前定好，这一条已经讲过；还有后半句：这些数从哪里来，要跟着这一版一起做出来。上线之后才发现少埋了一个事件，这段时间的数据就永远拿不回来，只能等下一版重来一轮，中间这几周等于白跑。所以埋点不是上线前的检查项，而是开发范围的一部分。

## 回到链条上

从问题到上线是三段动作：先把方案发散成几条依赖不同假设的路，选出最该先验的那条；再把选中的方案和团队对齐一次，把误解、成本和取舍摆到台面上；然后在开发期间守住问题、放开手段，把补不回来的那几件事一起做进去。

评审之所以重要，是因为它是这三段里唯一一次能让“我理解的”和“他理解的”对上的机会。所以它的产出不是“通过了”，而是一份写下来的取舍清单，加一份明确的不做清单。

## 术语表

- 需求评审：方案交给团队前的一次对齐，目标是暴露“双方理解不一致”的地方；产出是取舍清单和不做清单，不是“通过”。
- 隐含决定：方案里没写出来、却会决定成品长相的选择；过了评审，写代码的人会替你补上，补法未必是你想要的那种。
- 约束与需求的区别：需求锁定了做法，约束只锁定边界；给工程约束而不是需求，能留下更多解题空间。
- appetite（时间胃口）：先定这件事值得花多少时间，再让方案缩进这个框里；方向和“估算”正好相反。
- no-gos：写下来明确不做的东西，给团队一个“做到哪里就停”的边界。
- 不确定锥：早期估算误差可达数倍，只有消掉项目本身的变量才会收窄；中途改需求会让它重新变宽。

## 来源

1. [SVPG: That Dog Won't Hunt — Cagan 描述“PRD 扔过墙、排期时才谈判”的失败剧本，以及最小可用产品不能再砍腿的主张](https://www.svpg.com/that-dog-wont-hunt/)
2. [SVPG: The Most Important Thing — “工程师第一次看到产品想法是在排期会上，就是 feature team”这句判据的出处](https://www.svpg.com/the-most-important-thing/)
3. [SVPG: Customer Inspired; Technology Enabled — 把“需求”降级为底层约束、给工程师更多自由度的论述](https://www.svpg.com/customer-inspired-technology-enabled/)
4. [Shape Up: Set Boundaries — appetite 与估算方向相反、“固定时间、可变范围”的原始说明](https://basecamp.com/shapeup/1.2-chapter-03)
5. [Shape Up: Write the Pitch — pitch 的五个成分，其中 no-gos 用来告诉团队明确不做什么](https://basecamp.com/shapeup/1.5-chapter-06)
6. [Shape Up: Place Your Bets — “如果两周能做完，你觉得怎么样”这个反问，用来分辨对方到底在反对时间还是别的](https://basecamp.com/shapeup/2.3-chapter-09)
7. [Construx: The Cone of Uncertainty — 不确定锥的误差倍数、收窄时机，以及“多给估算时间不会更准”的解释](https://www.construx.com/books/the-cone-of-uncertainty/)

---

原文：https://pangzhengboyin.com/articles/what-requirement-review-really-checks-7c7e18b8

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com