SOW 的十项，缺哪项就在哪项上吵架

工作说明书不是合同附件。它是五件事的书面版本：范围、依赖、验收、变更、退出。十条条款把这五件事撑起来，每一条都靠拦住一场具体的争论来证明自己该在。少一条，争论照样发生，只是发生得更晚，双方的好脾气更少，钱也更少。

范围，两条

第一条，交付什么，细到操作路径。 不写「一个报表模块」，写一个文员走的那条路：打开页面、导入这份导出、看到这个总数、改这一行。判断标准是客户能不能指着这句话说「对，就是这个」。这一条含糊，争论就变成「模块算不算做完」，而裁决权落在更生气的那一方手里。

第二条，明确不做什么。 每个产品周围都有一片相邻功能，客户默认它们都在里面。一句话就够：未列在本文件中的功能、页面、对接和报表，不属于交付义务。它把没有说出口的期待变成一张有价的变更单。缺这一条，演示就变成一项没有报价的义务。

依赖，三条

第三条，甲方要提供什么。 数据、账号、权限、流程负责人、决策人的时间，每一项后面写一个名字。没有这一条，等待是不计费的，而 FDE 会把这段延迟当成自己的成本消化掉。

第四条，哪些前置不满足就停。 不是所有缺失都该停工，所以要写明哪几项算。导不出数据、拿不到系统访问、没有人能确认一条业务规则，都算停止条件。没有这一条，每一个缺失的前置都会变成你扛着的延期，而项目在纸面上一直「还算正常」。

第五条，给评审写日期，不是给工期。 「两周」不是日期，它会变成「数据到了之后的两周」。写明每一次评审在哪天、看哪份东西。这一条也让阶段边界对一个没跑过交付的客户变得可见。

验收，两条

第六条，怎么测。 哪套测试集、谁跑、在什么环境、用什么数据。做完系统再补写的测试集，往往只剩下系统已经答得上的那些题。

第七条，什么算验收。 每一行落到通过、失败、未验证、不适用之一，带日期和证据位置，由将要操作这套系统的人签字。「不适用：原版未提供」是合法结果，沉默不是。缺这一条，验收就成了一种感觉，而感觉是每个月月底都要重谈一次的东西。

变更与风险，两条

第八条，变更按类型处理。 变更只有三类：客户新增、乙方低估、前置被证伪。第一类改价格，第二类是乙方的成本，第三类是改排期并补新的前置。把三类都塞进加班里，是毛利和信任在同一周一起消失的方式。这一条要写明每类由谁拍板、多久给答复。

第九条，风险谁承担。 模型行为、上游接口变更、客户数据质量、双方之外的事件，各自归谁。这一条不用长，但要写清出事时谁付钱、谁拍板。没有它，第一次故障会被当成追责来吵，而不是当成一个案子来处理，技术响应会排在商务争论后面。

退出，一条

第十条，培训与售后边界。 包含什么、多久、走哪个渠道、响应时间多长、什么另外计费。缺这一条，项目就永远结束不了：FDE 变成客服热线，每个小问题都重开一次关系，退出这件事从来没有被设计过。培训不是结束时的客套，它是让交接成为可能的那一条。

它保护什么	对应条款	缺了以后怎么吵
范围	第一、二条	「模块做完了」对「这显然本来就该有」
依赖	第三、四、五条	延期是真的，账单不是，也没人同意过谁负责
验收	第六、七条	算不算「能用」，按情绪和职级决定
变更	第八、九条	每个新要求都变成免费加班，然后变成怨气
退出	第十条	项目没有终点，FDE 没有退路

判断一条条款是否成立

条款成立的标志是：没参加过会议的人，能照着它办事。把第二条和第十条交给一个新来的项目经理，请他说出三件不会发生的事。说不出来，这两条就只是文字，不是承诺。

第二个判据来自定义阶段：每声称一次「做完了」，都要能指回某一条。指不回去，就不叫做完，叫一个带日期的演示。付款同理——每一笔挂在可核对的成果上，永远不挂人天，因为人天报的是你的日历，它把每一次范围讨论都变成对你有没有空的争论。

签字之前，把这两个判据在整份文件上跑一遍。把十条的标题列出来，每条旁边写一句「如果缺它，到时候会怎么说」。一句话就能写出来的，就是这周该补的。写不出来的，说明这个客户不会为它吵架——这也是有用的信息，前提是你在第一张发票之前就知道，而不是在之后。数字住在报价里，边界住在这份 SOW 里，退出住在日落条款里。三样齐的项目才能干净地结束，而干净地结束，是开始下一单唯一可靠的方式。