评审会不是批斗会，我让开发提前看文档

那是第三年的一个周三下午。我把改到第七版的 PRD 甩进评审群，定在两点半开会。到场十一人：甲方两位、研发五个、测试两个，加上我和项目经理。我开场讲了八分钟背景，然后说"大家看下文档"，会议室安静了五秒——研发组长问了一句："这版和上一版改了啥？我还没来得及看。"

那一天我们开了两个半小时。前四十分钟在确认"需求到底要做什么"，中间一小时在争论一个我早就和甲方对齐过的字段口径，最后半小时测试才开口："按这个逻辑，我造不出来覆盖全的用例。"散会时我记了十七条待确认，其中十一条本该在会前就闭环。

我刚入行那几年，把这种会当成"我的文档接受审判"。每次评审前都紧张，怕被怼。后来才明白，怕也没用，因为问题从来不在我会不会被怼，在于没人会前读过文档。PRD 十二页，写得再清楚，一个没读的人坐进会议室，就是来听你念、来找茬的。而"找茬"心态一旦上来，评审就从"一起把需求磨对"变成了"挑产品的错"。那天的十七条待确认，十一条是会上现翻文档才发现的——它们压根不该占用十一双耳朵的时间。

我做的第一个改变，是把"发文档"提前到评审前三天，而且不再甩一个压缩包。我把 PRD 拆成三块：背景与目标（一页）、这次变更点（一页，用红色标出相对上版的差异）、待拍板的三个决策（半页）。发群时我只说一句话："周三评审，重点看第三块三个决策，前两块扫一眼即可，不用全读。"——给一个"只读重点"的指引，比发十二页全本有用十倍。

第二个改变，是评审前开一个十五分钟的"预对齐"。只有研发组长、测试组长和我。我不讲文档，只讲三件事：这个需求甲方为什么急（上线 deadline 是月底）、哪两个点历史上最容易扯皮、我希望会上能拍板哪三个决策。我明确说："今天不解决对错，只把疑问捞出来，会上我们直接拍。"那次之后我发现，研发最怕的不是评审，是"会上被当众问住"。预对齐给了他们一个安全的提问口，疑问在会前就冒出来了。

第三个改变，是我把评审会的开场从"我来讲"改成"我来问"。第一句话变成："大家会前扫了文档，三个决策里哪个你们觉得有坑？"——把主动权交出去，开发反而愿意说话。有次研发当场指出第三个决策有个边界没写清，会导致接口返工两天。要是在老流程里，这个坑得等到开发阶段才炸。

举个具体的。那个数据治理项目里，第三个决策是"客户主数据以哪个系统为准"。会前我把它单独拎出来，预对齐时研发组长说："如果以旧 CRM 为准，我们得写一套增量同步，大概三天；如果以新中台为准，旧系统要反向推，得五天。"我转头问甲方，甲方说新中台刚上线数据不全，先用旧 CRM 过渡半年。这个决定要是在会上才吵，至少拖一天。会前十五分钟，它就被拍死了。

当然也有翻车。有次我忙忘了发预对齐邀请，评审又回到了老样子，研发当场质疑一个字段的枚举值，吵了二十分钟。我那天下班写了条铁律贴显示器上：预对齐不是可选项，是评审的前置条件。忘一次，代价就是一场批斗会。

这套流程跑了半年，覆盖我手上的十一个 B 端项目。对比最明显的是评审时长：平均从两小时十分钟压到四十八分钟；会上冒出来的"会前本可闭环"的问题，从平均十一条降到两点三个；最关键的，研发对需求的理解偏差，在 UAT 阶段暴露的返工，从平均每项目四点七人日降到一点九人日。

我印象最深的是其中一个国企客户的数据治理项目。第一次评审我按老办法，两小时四十分钟，甲方当场质疑"你们研发到底懂不懂我们要什么"。三个月后同样规模的模块，用新流程，评审三十分钟结束，研发组长会后跟我说："你提前把差异标出来，我省了至少半天排查。"——他省的是半天，我省的是和甲方解释"为什么又改"的半个下午。

现在我有个硬指标：评审前，研发和测试必须在文档里至少留一条评论。一条都没有，评审延期。听起来强势，但留评论等于真读了。有次研发组长嫌麻烦，我直接把会挪到第二天，他当天下午就留了五条。从那以后没人敢空着进会场。

十年下来，我把"让开发愿意提前看文档"总结成四条，不玄乎：

第一，文档发出去不等于被读。 给一个"只读重点"的指引，比发十二页全本有用。

第二，评审前十五分钟预对齐，是性价比最高的会议。 它把"找茬"前置成了"捞疑问"。

第三，开场别讲，先问。 把"我来讲"换成"你们觉得哪有坑"，开发才开口。

第四，批注要可见。 我要求研发在文档里直接留评论，而不是会上口头说——白纸黑字的疑问，比会上的临时起意更靠谱。

评审会不是用来证明产品错了，是用来让一群人提前站到同一张图上的——而这张图，得在开会之前就摊开。