需求文档改了一行，通知范围就是决策

需求文档在开发手里一天改三次，在采购手里是三个月前那一版，在运营手里是上架时口头转述的那一版。三份东西不一样，出问题时没人能说清谁拿的是对的。

影响面分三档，通知范围跟着走

需求文档变更的影响面三档与通知范围

分档的依据不是改动大小。改一个尺寸数字和改一段定位描述，字数差不多，影响面差两档。

定位类改动最难，它的影响会一路传到广告组结构和主图。改了卖点而广告没跟着改，钱会继续花在旧的卖点上。

版本号三个字段

我用的版本号是三段的：日期、变更项序号、影响面档位。

2026-10-19 这一版里的第三处改动、定位类，写成 20261019-03-C。

第三段是给接收方看的。拿到 C 档，运营和广告自动进通知范围，不需要开发再判断一次该发给谁。

没通知到的变更，视为没发生

这条规则听起来不近人情，落地之后效率很高。

改了东西没发出去，等于没改。出问题时按旧版本追责，按旧版本做的那一方没有责任。

规则刚上的时候有人不服，说改了就是改了。三个月后没人再争，因为所有人都养成了改完就发版本的习惯。

旧版本留到产品下线后一年

旧版本不是垃圾，是回答「当时为什么这么定」的唯一材料。

我遇到过一次退货率突增，翻旧版本发现三个月前有一处包装参数改动只通知了采购，没进运营。参数本身没错，错在通知范围。

留一年的口子是我自定的。太短了追不到历史问题，太长了表会撑爆。

改的人和收的人要在同一张表上签字

文档发出去不算通知到，对方签回来才算。

我在文档表上加了一列签收：收到哪一版、什么时候签的、签的是谁。签收列空着的，视为未通知。

加这一列之前，开发说发过了、运营说没收到，这种争论每周都有一次。加了之后争论消失了，因为签收留痕，谁也说不圆。

签收还有个副作用：它逼着接收方打开文档看一眼。以前开发发一版，运营直接存进文件夹，上线时用的还是三个月前那一版。现在要签字，就得先翻一遍变更项。

文档改动的频率本身就是信号

我数过自己团队每月的文档变更次数。稳定期一个月三到五次，产品起量那个月二十七次。

二十七次那个月，产品上线后出了两处与页面不符的投诉。频率和事故是同步的。

变更次数突然翻上去，该问的不是哪一条错了，是这个品的规格在立项时就没定清。定得清的东西，上线前不会一天改三次。