ERP需求文档版本管理失效：一次评审事故引发的治理方案

1. 一场评审会开成“失忆现场”：他们吵的根本不是逻辑，是版本

上个月的一场ERP需求评审会，差点让我以为自己提前三十年进入老年期。讨论对象不算大，库存模块里的“可用量”计算口径，到底要不要扣减待出库数量。原计划十分钟收尾，最后从下午吵到快下班。会议室里的画风大约是这样的：A产品经理拍着桌子说，待出库数量必须扣，这是业务底线，上周评审已经全部确认了；B产品经理直接把笔记本转过来，指着需求文档里的一行字说，你自己看，这里写着“待出库数量最终不参与可用量扣减”，你让我信你的记忆还是信文档？

我当时的处境更尴尬。作为主持人，我打开最新版文档时，看到的竟然是三个月前的老规则。按说老规则长什么样，团队里几个老人都应该有印象，但真正的问题在于，新版本文档的呈现方式太正式了，正式到让人下意识怀疑自己的记忆：难道上周会上通过的结论，只是我们几个人的幻觉？

接下来两小时，整个会议室分成三派。A坚持评审结论是“扣”，B坚持文档现状是“不扣”，还有一小部分后期加入项目的人完全不敢说话。他们一直在反复刷新文档、翻聊天记录、找邮件通知，最后一位兄弟小声问了一句：我们要不要把这个需求延期，先把谁记错了弄清楚？

这句话点醒了我。问题的根源不在人的记性，而在于让“评审结论”和“文档现状”产生了分歧的整个过程。

1.1 同一套字段规则，三个不同版本在文档里“叠加态”共存

我可以把这个项目的复杂程度说清楚：这是公司内部使用的ERP系统物料模块，已经迭代了两年多，需求文档累计超过四万字，参与角色覆盖产品、开发、测试、实施顾问和客户成功。这类长周期文档和短期项目文档最大的不同，就是里面很多规则不是一次性定完的，而是被反复修改、推翻、再修正过。

可用量的计算口径恰好是最典型的那类规则。用一张简化后的版本对照表来看，问题一目了然：

很多人看到这种表，第一反应是V1.3被做了回滚。但当时文档的历史记录里没有任何“回滚”字眼，修改备注写得相当正常，看起来就像一次顺理成章的文案整理。更可怕的是，被污染后的版本看起来非常顺眼，因为它和团队早期大多数人记忆中的规则完全一致，这种“熟悉感”让很多人在第一时间放弃了警惕。

1.2 文档先开始撒谎，人才会陷入集体自我怀疑

为什么整组人没有立刻站起来说“文档写错了”？因为在一套成熟的ERP项目里，需求文档天然被当作最高信源。大家在日常协作中已经形成了条件反射：如果文档和记忆冲突，先怀疑自己的记忆；如果两个产品经理说法冲突，那就看文档怎么写的。

当文档本身进入一种类似“叠加态”的状态，同时承载着评审结论、旧规则和污染后的复写内容，每个人实际看到的又都是不同的片段，于是记忆错乱就开始了。A看到的是自己参会、发言、点过头的V1.2结论，B看到的是可以检索、可以全屏展示的V1.3文档正文。如果我是新人，我也会选择相信B，因为文档就摆在面前，而A所谓的评审结论，却只是聊天记录里的一段复述。

那天散会之后，我收到的几条私聊消息几乎都是同一句话：我是不是记错了？这让我意识到，真正的风险不是某个字段被写错，而是整个团队对“事实”的定