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

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

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

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

回到门店报表那个例子。方案叫“一键导出周报”。你脑子里是：把三个页面的数据合起来，生成一张能直接贴进汇报的表。研发脑子里可能是：把当前页面的数据导出成 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。

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

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

回到链条上

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

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