SOW（Statement of Work，工作说明书）是以具有约束力的方式确定项目工作范围、交付成果、期限、验收标准和付款安排的文件。它通常作为甲方与乙方合同的附件，并补充需求规格书和项目章程。一份完整的 SOW 包含 14 个部分。
本指南告诉您工作说明书应包含哪些内容，它与工作范围、需求规格书和合同有何区别，以及如何把签署后的 SOW 转化为项目计划。
🔽 此外，您还可以在文中找到可复制的模板和我们为您的下一份工作说明书准备的免费检查清单。
什么是工作说明书（SOW）？
SOW（Statement of Work，工作说明书）是一份正式文件，规定乙方为甲方完成哪些工作、交付哪些成果、在什么期限内交付以及价格多少。在项目管理中，SOW 是日后一切范围讨论的依据。
SOW 记录以下内容：
PMI 的《PMBOK 指南》将采购工作说明书（procurement statement of work）描述为：对采购对象进行足够详细的描述，使潜在卖方能够判断自己是否有能力提供。因此，甲方通常在招标前编写 SOW，并将其附在建议邀请书（RFP）中。
Scope of Work 与 Statement of Work 的区别： Scope of Work（工作范围）只描述工作本身，也就是“做什么”。Statement of Work 把工作范围作为其中一个部分，并进一步规定由谁、在何时、在何地、按什么标准、以什么报酬完成工作。
为什么工作说明书如此重要？
工作说明书能在范围纠纷出现之前就将其化解：双方签字确认交付什么、何时验收、如何付款。没有它，范围会不受控制地扩大，每一次变更都会变成一次谈判。
一份认真编写的 SOW：
- 为所有参与者设定明确的期望。
- 让所有干系人对成功的样子形成统一认识。
- 防止范围蔓延，因为它准确列出交付成果和排除项。
- 降低项目风险，因为假设和甲方的配合义务都以书面形式记录。
- 明确责任，依靠里程碑、验收和签字。
这既适用于与供应商或分包商合作的外部项目，也适用于内部项目。在内部项目中，SOW 规定哪个部门在何时之前交付什么。
谁来撰写工作说明书？
工作说明书通常由提出工作需求的一方撰写：甲方的项目经理或采购部门。在服务类项目中，乙方也常根据自己的报价起草 SOW。法务和采购部门审核草案，双方达成一致后再签字。
SOW 与需求规格书、项目章程和合同有何区别？
SOW 规定双方约定了哪些工作，以及对应的期限、验收标准和价格。它的基础是规格书：甲方的需求，以及在另一份文件中乙方打算如何实现这些需求。项目章程和合同对这些文件加以补充。
在德国，DIN 69901-5 标准对这两份文件作了区分：甲方编写需求规格书（Lastenheft），乙方编写说明实现方式的实施规格书（Pflichtenheft）。
| 文件 | 编写方 | 回答的问题 | 典型内容 |
|---|---|---|---|
| 需求规格书 | 甲方 | 要达成什么？ | 需求、约束条件、目标 |
| 实施规格书 | 乙方 | 如何实现？ | 解决方案设计、技术路线 |
| Statement of Work | 甲方或双方 | 在何时、以何价格交付什么，如何验收？ | 范围、交付成果、里程碑、验收、付款 |
| 项目章程（Project Charter） | 甲方内部，例如发起人或管理层 | 项目能否启动，由谁领导？ | 目标、预算框架、项目经理、授权 |
| 合同（例如框架合同） | 双方，通常有法务参与 | 适用哪些权利和义务？ | 责任、保修、解约、保密 |
哪种合同类型和计价模式适合您的项目，请参阅我们的文章工时与材料合同和固定价格合同对比。
工作说明书应包含哪些内容？
工作说明书应包含甲方和乙方日后可能产生分歧的所有要点：范围、成果、期限、验收、付款和排除项。请先就项目的各个方面做笔记，下方的思维导图展示了 14 个部分。
-
引言： 写明各方，并用两三句话描述要完成的工作。注明 SOW 所附属的合同，例如约定价格和法律条款的框架合同。
-
项目目的： 说明项目为何启动，以及用什么衡量收益，例如节省的时间、收入或投资回报率。
-
工作范围： 描述包含哪些工作，以及使用的流程、硬件和软件。还要明确写出不包含的内容。这份排除清单能避免大多数后续索赔。
-
工作地点： 规定团队在哪里工作：甲方现场、乙方现场还是远程，以及需要哪些设备和访问权限。
-
任务： 把工作范围分解为工作包。按工作分解结构（WBS）、阶段或里程碑组织，并估算每个工作包的工作量。
-
里程碑： 确定开始日期、结束日期和中间节点。如果合同限制每周或每月可计费的工时，请在此注明上限。
-
交付成果： 为每项成果规定数量、格式和截止时间，例如“归档方案，PDF，最多 20 页，第 3 周交付”。
-
进度计划： 从分析、实施、测试到收尾，为每项交付成果分配日期。使用相对时间而非日历日期，例如“合同签署后两个月”。这样签字推迟也不会打乱整个计划。同时确定正式评审的日期。
-
标准与测试： 列出规范、法律要求（例如 GDPR）和测试。说明由谁测试、使用哪些设备和资源。
-
成功的定义： 写出可衡量的验收标准。不要写“搜索很快”，而要写“20 个测试用例中 20 个在 10 秒内返回搜索结果”。在敏捷项目中，这里写完成的定义（Definition of Done，DoD）。
-
要求： 列出前提条件和甲方的配合义务：访问权限、联系人、资质认证、差旅。
-
付款： 确定价格和付款计划：预付、按时间或按里程碑。把付款与验收挂钩，并在最终验收前保留一部分款项。
-
其他： 记录不属于其他类别的事项：安全规定、差旅费用、项目结束后的支持，以及变更请求流程。
-
收尾： 规定如何验收成果、由谁检查和签字，以及如何归档文件。
免费检查清单
下载我们的检查清单（PDF，英文）。其中列有编写 Statement of Work 时的 19 项典型任务。
SOW 示例是什么样的？
SOW 示例会在 14 个部分中填入具体的数量、日期和金额。下面的简化示例描述了一家拥有 40 个工位的工程设计公司实施文档管理系统（DMS）的项目。公司和数字均为虚构，计算是准确的。
Statement of Work：DMS 实施，框架合同附件 1
| 部分 | 示例内容 |
|---|---|
| 1 引言 | 甲方：Muster 工程设计有限公司。乙方：示例 IT 有限公司。本 SOW 为框架合同附件 1。 |
| 2 目的 | 项目文件分散在 3 个网络驱动器上。目标：按项目编号可在 10 秒内找到任何项目文件。 |
| 3 工作范围 | 包含：安装和配置、迁移 120,000 个文件、培训 40 名用户、4 周上线后支持。不包含：硬件、财务系统对接、纸质文件扫描。 |
| 4 工作地点 | 配置和迁移远程进行，培训在甲方现场进行。 |
| 5 任务 | WP1 分析与归档方案 60 小时，WP2 安装与配置 100 小时，WP3 迁移 140 小时，WP4 培训 60 小时，WP5 上线后支持 40 小时。合计 400 小时。 |
| 6 里程碑 | M1 归档方案获批（第 3 周），M2 测试系统验收（第 7 周），M3 正式上线（第 10 周），M4 最终验收（第 14 周）。 |
| 7 交付成果 | 归档方案（PDF，最多 20 页）、测试系统和生产系统、迁移日志、培训资料、运维手册。 |
| 8 进度计划 | 签字后 2 周开始，工期 14 周。 |
| 9 标准与测试 | 依据 GDPR 第 28 条签订数据处理协议。上线前抽取 500 个文件进行迁移测试。 |
| 10 验收标准 | 按迁移日志 100% 的文件完成迁移，20 个测试用例中 20 个搜索时间低于 10 秒，40 名用户中至少 38 名完成培训。 |
| 11 甲方配合 | 第 2 周前提供服务器、管理员权限，以及一名每周投入 4 小时的联系人。 |
| 12 付款 | 固定价格 43,700 欧元（不含税）：M1 支付 30%（13,110 欧元），M3 支付 40%（17,480 欧元），M4 最终验收后支付 30%（13,110 欧元）。 |
| 13 变更 | 变更请求以书面形式提出，乙方在 5 个工作日内评估，额外工作按每小时 95 欧元计费。 |
| 14 收尾 | 由双方项目经理签字的验收记录。 |
固定价格是怎么来的？乙方估算 400 小时、每小时 95 欧元，按工时与材料计算为 38,000 欧元，再加上 15% 的数量风险溢价，得到 43,700 欧元。它与按工时计费相比如何，请参阅文章工时与材料合同和固定价格合同。
可复制的 SOW 模板
把模板复制到您的文字处理软件中，替换方括号中的所有内容。不要删除任何部分；如某项不适用，请写“不适用”。这样所有人都能看到您已检查过该项。
STATEMENT OF WORK（工作说明书）
项目：[名称] 版本：[1.0] 日期：[YYYY-MM-DD]
[日期] 合同之附件 [编号]
1 引言
甲方：[公司、联系人]
乙方：[公司、联系人]
概述：[2 至 3 句话]
2 项目目的
现状：[...]
目标与指标：[例如 搜索时间低于 10 秒]
3 工作范围
包含：[...]
不包含：[...]
4 工作地点
[现场 / 远程 / 混合，所需访问权限]
5 任务与工作包
WP1 [名称]，工作量 [小时]
WP2 [名称]，工作量 [小时]
6 里程碑
M1 [名称]，[签字后第几周或第几天]
M2 [名称]，[...]
7 交付成果
[成果]，[格式、数量]，于 [里程碑] 交付
8 进度计划
开始：[签字后 x 周] 工期：[x 周]
评审：[日期]
9 标准与测试
[规范、法律要求、测试流程]
10 验收标准
[每项交付成果的可衡量标准]
11 要求与甲方配合义务
[基础设施、联系人、投入时间]
12 价格与付款
计价模式：[固定价格 / 工时与材料 / 设上限的工时与材料]
付款计划：[每个里程碑的百分比和金额]
13 其他
变更流程：[形式、期限、小时费率]
差旅费用、结束后支持：[...]
14 收尾与签字
验收人：[姓名、角色]
甲方：________________ 日期：______
乙方：________________ 日期：______工作说明书有哪些类型？
工作说明书因项目类型而异，但 14 个部分的结构保持不变。重点随行业调整：
- IT 实施： 集成步骤、测试环境、用户验收测试，以及依据 GDPR 的数据保护，如上例所示。
- 项目管理服务： 项目经理每周工时，报告、预算和风险方面的职责，以及采用的方法（瀑布、敏捷或混合）。
- 建筑项目： 建筑标准、现场检查、安全要求、材料，以及从场地准备到竣工验收的进度计划。
- 内部项目： 部门之间的流程改进或软件实施。此时由项目章程代替合同，但范围、期限和验收仍由 SOW 规定。
如何在 Merlin Project 中把 SOW 变成项目计划？
把工作包、里程碑和验收标准一一转入项目结构，签署后的 SOW 就变成了项目计划。在 Merlin Project 中按以下步骤操作：
- 转入结构： 在工作分解中把每个工作包建为群组，并创建里程碑 M1 至 M4。如果您先在思维导图中收集了各个部分，请切换到 视图 > 工作分解 > 条目；Merlin Project 会把所有节点转换为活动和群组（请参阅从思维导图到项目计划）。本文的 14 个部分可作为Merlin Project 文件（英文）下载。
- 保存 SOW： 通过 插入 > 附件 > 文件 把签署后的文件附加到里程碑“合同签署”上。附件会把文件的所有版本保留为修改记录。
- 让验收标准可核对： 把第 10 部分的标准作为 检查清单 附加到验收里程碑上。检查清单的状态显示为 计划的、进行中、过期 或 完成。
- 体现付款计划： 在财务检测器的 预算 标签页中，把约定金额填入 已核准，并分配到各个里程碑。
项目文档中的 SOW
附件视图列出项目中的所有检查清单、文件和风险。附属于列显示每个附件属于哪个活动或里程碑。这样，SOW、验收检查清单和未解决的风险都集中在一处。Merlin Project 可免费试用 30 天。
签字：最后一步
没有签字的 SOW 对任何人都没有约束力。请在工作开始前让所有关键干系人签字：
- 项目负责人或管理层
- 供应商或第三方代表
- 承担直接责任的团队负责人
签署后的 SOW 是发生纠纷时您的证据：它记录了各方对范围、进度和验收标准的同意。
来源
- DIN 69901-5:2009-01 项目管理、项目管理体系，第 5 部分：术语（Lastenheft 与 Pflichtenheft 的定义）
- Project Management Institute：《项目管理知识体系指南（PMBOK 指南）》第 6 版，第 12 章 项目采购管理
- Computerworld: How to write a statement of work
- ProjectManager.com: Statement of Work Definition & Examples
如果您对这篇博客文章有任何疑问或希望参与讨论，欢迎您在我们的论坛中发帖。
常见问题
SOW 是什么意思？
SOW 是 Statement of Work 的缩写，中文称为工作说明书。它是甲方与乙方之间规定工作范围、交付成果、期限、验收标准和付款的文件。
SOW 有法律约束力吗？
双方签字或合同将其作为附件纳入后，SOW 即具有约束力。责任、保修和解约通常由合同本身规定，例如框架合同。起草合同时请让法务部门参与。
SOW 应该写得多详细？
详细到第三方能够核实工作是否完成。不要写“合理时间”，而要写“四小时内完成并由质量保证部门测试”。每项交付成果都需要格式、数量、日期和可衡量的验收标准。
敏捷项目的 SOW 怎么写？
在敏捷 SOW 中，固定时间框架、团队规模和预算，让范围保持灵活。为每个迭代确定完成的定义（DoD），把冲刺或增量作为里程碑，并说明待办事项列表如何排序、由谁决定。
内部项目也需要工作说明书吗？
需要。即使没有外部供应商，SOW 也能明确部门之间的目标、任务、职责和期限。由发起人或管理层批准的项目章程代替合同。
收到 SOW 后应如何回应？
完整阅读 SOW 并记下不清楚的地方。就含糊或缺失的要点要求澄清，协商范围、期限或付款条件，在同意每一项之后再签字。
SOW 中应避免哪些错误？
最常见的错误：措辞含糊、缺少验收标准、没有排除项清单、没有变更请求流程，以及工作开始前签字不全。
