第三章 需求定义与 SOW
3.3 SOW 怎么写
承前：指标定了、用例砍了，现在要把这些共识变成一份能签字、能打款、能打官司的文件。SOW（Statement of Work，工作说明书）是 FDE 职业生涯里写得最多的"非技术文档"，也是最值得写好的——因为它决定了你在客户现场的一年是"按图施工"还是"无尽扯皮"。这一节从合同常识讲起，拆 SOW 的六个核心要素、里程碑付款设计、乙方的报价逻辑，最后给一个可以直接改用的模板骨架。
3.3.1 先补课：SOW 在合同体系里的位置
很多工程师以为 SOW 是一份"技术方案文档"，错。SOW 是具有法律约束力的商业协议——它通常作为主合同（Master Service Agreement，MSA）的附件存在：MSA 管总则（知识产权、保密、责任上限、争议解决），SOW 管具体的"这一单"（范围、价格、时间、验收）。MSA 签一次管多年，每来一个新项目签一份新 SOW。
理解这个结构对 FDE 有实战意义：你在客户现场答应的每一个"可以加"的改动，最终都要落到 SOW 变更上；而 SOW 里每一条模糊的措辞，将来都是对方律师的弹药。所以写 SOW 的第一心法是：写清楚"不做什么"和写清楚"做什么"同样重要，甚至更重要。 业界通行的 SOW 要素划分（SAP、Icertis 等企业服务厂商都有公开指引）大同小异：范围、交付物、时间表、验收标准、价格条款、变更流程——我们逐个展开。
3.3.2 六个核心要素
一、范围（Scope）。 上一节的取舍结果落在这里。写法要点：用可数的边界词（"试点 20 家门店"、"沉睡会员定义见附录 A 口径公式"），不用形容词（"显著提升"、"全面覆盖"）。范围条目最后附明确排除项（Exclusions）：比如"不含 App 端改版、不含历史数据清洗（另行报价）"。
二、交付物（Deliverables）。 每一项都要"可验收"：能点开看、能跑起来、能审阅。Agent 项目的交付物清单通常长这样：
D1 会员复购指标口径说明书（含SQL） 文档 + 注册到指标语义层
D2 沙盘数据诊断报告 文档，含问题清单与修复建议
D3 沉睡会员召回 Agent（试点范围） 可运行系统，含 trace 日志
D4 运营审核工作台 Web 应用
D5 效果回测报告 文档，含对照组数据
D6 运维手册与知识转移培训 2 场培训 + 录像三、里程碑（Milestones）。 把交付拆成 3-5 个阶段节点，每个节点绑定可检查的产物。里程碑的意义不只是进度管理，更是风险对冲——双方都有定期"验货"的机会，烂尾的概率随里程碑密度上升而下降。
四、验收标准（Acceptance Criteria）。 这是 SOW 的灵魂。合格的验收标准要满足三要素：可测（有数字）、有方法（怎么测）、有期限（多久内完成验收）。例如："试点门店群 90 天复购率相对对照组提升 ≥1.5 个百分点；验收方式为按 D1 口径由客户 BI 团队复核计算；客户须在交付后 10 个工作日内完成验收，逾期未提出书面异议视为验收通过。"最后这句"视为通过"条款是乙方自我保护的常规写法——没有它，客户可以无限期"挂着不验"，你的尾款也就无限期挂着。
五、付款条件（Payment Terms）。 下一小节展开。
六、变更流程（Change Process）。 一句话原则：范围变了，价格和时间必须跟着谈。标准写法是任何变更须走书面变更单（Change Order），由双方授权代表签字后生效，注明对价格和里程碑的影响。没有变更流程的 SOW，等于给范围蔓延开了无限绿灯。
3.3.3 里程碑付款：乙方的现金流生命线
企业服务行业通行里程碑付款（milestone billing），典型结构是：
签约生效 30% 预付款
M1 诊断+口径 20%
M2 demo 验收 20%
M3 上线验收 20%
M4 效果回测 10% 尾款（验收通过后 30 天内）三个设计要点：
- 预付款是对客户诚意和内部审批链的测试。30% 收不进来的项目，后面 70% 大概率也有麻烦。反过来，客户财务也用预付款门槛筛掉没把握的乙方。
- 不要把大比例款项压在最后一档。效果回测这种"结果型"验收天然拖得久（要等 90 天复购周期走完），把 30% 压在这里，等于把乙方的现金流押在客户执行力上。把结果型验收的占比控制在 10-20% 是行业里的稳妥做法。
- 里程碑验收要跟"过程物"绑定而不是"结果物"绑定。M2 验的是 demo 能跑、trace 完整，而不是复购率涨了——结果留给尾款去挂。
3.3.4 乙方报价的人天逻辑
FDE 团队怎么算报价？底层逻辑是人天 × 人天单价，但人天数怎么来是有讲究的。行业惯例把交付工作拆成六类：
| 工作类型 | 典型占比 | 说明 |
|---|---|---|
| 需求与对齐 | 15-25% | 工作坊、访谈、口径定义会议 |
| 数据诊断与接入 | 25-35% | 往往是最大头，也是最难预估的 |
| Agent 构建与集成 | 20-30% | 编排、工具注册、测试 |
| 评估与调优 | 10-15% | 建评估集、跑回归、修 bad case |
| 部署与安全合规 | 10-15% | 私有化、权限、审计日志 |
| 知识转移 | 5-10% | 培训、文档、陪跑 |
注意"数据诊断与接入"这一项：它占比最高且方差最大——数据干净的项目 100 人天够，数据像青禾这样的项目 300 人天打不住。所以成熟乙方报价时会加一条**"数据风险准备金"**或在 SOW 里写明"若诊断发现超出假设的数据问题，按变更流程追加"。
人天单价方面，国内外 FDE 类角色的人天费率显著高于普通外包开发——Palantir 式 FDE 模式的溢价本质上卖的是"在客户现场做判断"的能力，这个判断包括需求取舍、口径仲裁和风险预警。你要理解自己报价的底气在哪：不是代码行数，是判断的密度。
3.3.5 SOW 的经典陷阱清单
陷阱一：验收标准写"客户满意"。 主观验收等于没有验收，尾款变成客户心情函数。修法：一切验收落到可测条款。
陷阱二：范围用功能名词堆砌。 "提供智能会员运营平台能力"这种写法什么都没约束。修法：用例级写法 + 排除项清单。
陷阱三：没有客户义务条款。 甲方要按时提供数据、账号、接口、决策人时间——这些写不进 SOW，乙方延期全背锅。行业标准做法是加**"客户义务与依赖（Customer Obligations / Dependencies）"**一节，并写明"客户义务延迟导致的进度顺延不构成乙方违约"。
陷阱四：里程碑之间没有逻辑依赖声明。 比如 M2 demo 依赖数据接入完成，而数据接入依赖客户 IT 排期。不写依赖，M2 延期就全是你的锅。
陷阱五：变更流程只对乙方生效。 客户加需求要走变更单，乙方发现做不了想收缩范围也要走变更单——流程是双向的，写清楚可以保护双方。
陷阱六：知识产权含糊。 Agent 项目里客户数据、微调产物、编排代码、提示词资产各归谁，必须逐项写清。常见解法：客户数据及衍生数据归客户，乙方通用方法论与产品底座归乙方，项目定制代码按谈判结果（多数归客户或授权使用）。
3.3.6 一个可复用的 SOW 骨架
《XX 项目工作说明书 (SOW)》
1 背景与目标 ← 北极星指标 + 业务背景，3-5 段
2 范围 ← 用例级描述 + 试点边界 + 明确排除项
3 交付物清单 ← D1...Dn，逐项可验收
4 里程碑与时间表 ← M1...Mn，各绑定交付物与验收动作
5 验收标准与方法 ← 三要素：可测、有方法、有期限
6 付款条款 ← 里程碑比例表 + 发票与账期
7 双方义务与依赖 ← 客户义务清单（数据/账号/决策时效）
8 假设与前提 ← 假设破裂时的处理路径
9 变更流程 ← 书面变更单，双向适用
10 知识产权与保密 ← 逐类资产的归属
11 其他 ← 引用主合同条款
附录A 指标口径公式 ← 复购率完整口径（3.4 节）
附录B 数据接入范围 ← 系统、表、频率、责任人写完自检三问：拿给一个没参与项目的律师看，他能否说清"做什么、什么时候验收、验不过怎么办"？拿给客户 CFO 看，他能否算清每一笔款对应什么？六个月后扯皮时，每一条争议能否在文档里找到仲裁句？
3.3.7 SOW 与需求文档的分工
最后一个容易混淆的点：SOW 和"需求规格说明书"（BRD/PRD）是什么关系？能不能合成一份？
答案是分开放。SOW 管商业边界（谁、什么范围、多少钱、怎么验收），需求文档管实现细节（交互、字段、规则、接口）。 混在一起的后果是两头都写不好：SOW 里塞满字段定义，律师审不动、财务看不懂；需求变更时还得改合同，双方法务都痛苦。通行做法是 SOW 引用需求文档（"功能细节见附件二《需求规格说明书 v1.2》"），并且给附件标版本号——需求文档会随项目迭代，SOW 锚定的是范围和价格，版本化的附件让"细节在演进、边界不动"这两个诉求互不干扰。
还有一个 FDE 容易忽略的角色：客户的采购与法务部门是 SOW 的隐形干系人。大企业签 SOW 往往要走采购流程：供应商准入、付款条款对齐公司财务制度、法务审条款。这个流程可能比你想象的长（青禾走完花了三周），而且中途可能要求改条款——比如法务坚持把"视为验收通过"的期限从 10 个工作日改成 20 个。有经验的 FDE 在报价阶段就问清客户的采购周期，把它写进项目时间表的第一条依赖，而不是排了 M1 里程碑才发现合同还没签。
至此，第 3 章的武器库齐了：北极星指标定方向（3.1）、优先级表做减法（3.2）、SOW 固化共识（3.3）、口径公式堵住最大的雷（3.4）、场景选择的判断结构（3.5）。下一章进入 W4：SOW 签了，回到数据现场，开始诊断和 demo——你会发现口径公式那一节埋的所有伏笔，在数据里等着你。
3.3.8 要点总结
- SOW 是法律文件不是技术方案：主合同管总则，SOW 管这一单；写清"不做什么"比"做什么"更重要。
- 六要素缺一不可：范围（含排除项）、交付物、里程碑、验收标准（可测/有方法/有期限）、付款条件、变更流程。
- 里程碑付款保护乙方现金流：预付款测诚意，结果型验收占比控制在 10-20%，不要把大额款项押在拖得最久的档上。
- 人天报价六类工作里数据接入方差最大，用"数据风险准备金"或变更条款对冲；你的溢价来自判断密度而非代码量。
- 六大陷阱全部有解药：客观验收、排除项、客户义务条款、依赖声明、双向变更、逐类知识产权。
参考资料
- 什么是工作说明书 (SOW)？ — SAP — 企业服务厂商对 SOW 的定义与要素说明，具有法律约束力的商业协议。
- Statement of Work (SOW): Definition, Process & Free Templates — Institute of Project Management — SOW 写作流程与免费模板，范围/交付物/验收标准逐项讲法。
- How to Write a Solid Statement of Work — Icertis — 合同科技公司的 SOW 指南：明确责任边界与预期结果。
- OpenAI launches the OpenAI Deployment Company — OpenAI — OpenAI 官方对 FDE 交付模式的描述（诊断 → 少量优先工作流 → 设计构建测试部署），SOW 结构与之对应。