项目中产生争议的一个常见原因，是工作说明书（Statement of Work，SOW）含糊不清或不够完整。尽管它看似简单，但要编写一份高质量、详尽的 SOW 可能颇具挑战。然而正是这份文件，对确保项目成功至关重要。如果做得到位，它能避免误解，并为内部利益相关者和外部供应商双方厘清各自的期望。
在本指南中，您将了解如何编写一份工作说明书、它应包含哪些内容，以及如何利用它来制定一份扎实的项目计划。读完之后，您会理解为什么一份结构良好的 SOW 是专业项目管理的基石。
🔽 此外，您还可以在文中找到我们为您的下一份工作说明书准备的免费检查清单
什么是工作说明书（SOW）？
工作说明书（Statement of Work，SOW）是一份正式文件，用于定义并记录您项目的所有方面：
- 目标与预期成果
- 详细的工作范围
- 交付物（Deliverables）与里程碑
- 时间计划与截止日期（时间表）
- 定价与付款条件
- 关键的假设与限制条件
许多项目负责人也会问起 Scope of Work（工作范围）与 Statement of Work（工作说明书）之间的区别。简而言之：SOW 远比单纯的范围（Scope）更为详细。Scope of Work 通常侧重于“要做什么”。而 Statement of Work 则更进一步，还会描述由谁做、何时做、在哪里做、如何做以及按照哪些标准来做。
为什么工作说明书如此重要？
如果一份 SOW 含糊不清或不够完整，往往会导致分歧、进度问题以及项目范围的逐步扩张（范围蔓延）。这对内部项目适用，团队往往以为彼此已经心照不宣，而对与供应商或分包商合作的外部项目尤其适用。
一份精心编写的 SOW：
- 为所有参与方设定清晰的期望。
- 让所有利益相关者就何为成功达成一致认识。
- 通过精确定义交付物来防止范围蔓延。
- 降低项目风险与争议。
- 通过明确的里程碑和签字来确保责任落实。
即使您不与外部供应商合作，内部项目同样能从一份工作说明书中获益。它能在组织内部明确职责、时间计划与目标。
谁来撰写工作说明书？
通常由项目负责人或提出工作需求的人负责撰写工作说明书。在某些公司，法务或采购部门也会协助编写。关键在于，所有相关方都参与其中并在文件最终定稿前表示认可。
工作说明书应包含哪些内容？
所有对项目成功至关重要的细节都应事先明确厘清，然后以书面形式记录下来。
SOW 涵盖的领域与项目本身一样广泛。为了获得完整的概览，请先就项目最重要的方面记下笔记。
-
引言：首先说明需要完成哪些工作。然后列出各个项目参与方。这会引出一份框架合同，规定项目中所采购的产品或服务的价格，以及一份更为正式、进入细节的合同。
-
项目目的：从这个根本性的问题入手：您为什么要启动这个项目？项目的目的是什么？编写一份意向书（Letter of Intent）来完善这一部分，并给出有依据的回答，例如关于成果、目标和投资回报。
-
工作范围：记下项目中需要执行哪些工作。同时考虑需要哪些硬件和软件。您会采用哪些流程来完成工作？这其中包括成果、所需时间，乃至完成工作所需的总体步骤。
-
工作地点：您所投入的团队需要在某处工作。项目可以在某个特定地点、某个中央设施进行，也可以部分远程进行。无论是哪种情况，您都应在此详细说明，以及所使用的设备和软件。
-
任务：沿着工作范围中描述的总体步骤，将其细分为具体的任务。请做到精确，不要遗漏任何对项目成功必需的措施。如有需要，您可以将任务划分为里程碑或阶段。
-
里程碑：确定项目从开始到计划结束日期之间应当完成的时间区间。给出每周和每月的小时数，以及所有其他属于项目规划的方面。这里的准确性尤为重要。例如，如果供应商或合同存在可计费小时数的上限，就应在此处注明。
-
交付物：定义项目的成果。记下什么时候交付什么。请详细描述，例如数量、尺寸、颜色以及所有其他相关方面。
-
时间计划：成功的实施不能仅以速度或系统响应来定义。一个出色的应用，如果要花十年才能完成，又有什么用呢？因此，工作说明书必须包含额外的时间方面的内容。时间计划列出何时必须交付哪些成果，从供应商的选择、前期阶段、履约期间、评审阶段、开发、实施、测试到项目收尾等。SOW 是一系列时间节点，可据此制定出一份进度计划。
请使用允许灵活性的表述，而不是固定的日历日期。例如，SOW 应规定某项任务在合同签署后两个月内完成，这种表述既能推动项目，又能考虑到诸如合同签署延迟之类的潜在问题。
此外，SOW 还应规定特定的正式评审时间点，以便所有参与方都能确认进展是否在正轨上。
-
标准与测试：如果必须满足特定的行业标准，请在此处列出。如果计划进行产品测试，请说明谁参与其中、需要哪些设备，以及还需要哪些资源。
-
成功的定义：思考一下，委托方和（或）利益相关者认为怎样才算项目成功收尾。工作说明书中应清晰定义，对所有参与方而言什么是成功、什么是失败。例如，如果您期望供应商制定用户需求，SOW 就应规定供应商要采访特定的用户群体，并且这些需求必须获得批准，工作才算完成。
成功意味着什么，取决于具体项目。项目负责人必须确定，一次成功的实施是由速度、响应时间、易用性，还是这三者共同来定义，并在 SOW 中对其加以量化。在敏捷环境中，这里往往会补充“完成的定义”（Definition of Done，DoD）。
-
要求：列出项目执行所必需的所有其他设备或前提条件，并说明何时需要团队取得特定的认证或完成特定的工作。也要想到出行或项目中尚未涵盖的其他方面。
-
付款：预算一旦确定，您就可以列出与项目相关的付款，并说明它们如何支付，是预付、按时间支付，还是在完成后支付。例如，您可以在某个里程碑完成后付款，或按固定的时间计划付款，视哪种在财务上更合理而定。请注意，向供应商的付款是在主要交付物验收后进行的。请规定保留一部分报酬，直至供应商证明所有成果能够协同运作为止。
-
其他事项：项目中还会有一些无法归入上述类别的部分。请在此处列出，以免遗漏。例如安全方面的考虑、硬件或软件的限制、差旅费用、项目结束后的支持等等。
-
收尾：这里规定成果如何验收，以及由谁交付、检查和签字。此外，本部分还规范最终的行政事务，并确保一切都已签署、完成并归档。
免费检查清单
下载我们的检查清单，以启动您的下一份 SOW 设计。其中列有 19 项编写工作说明书时的典型任务。
工作说明书示例
-
IT 实施（软件项目）
如果您从事的是 IT 项目（例如软件部署），请定义集成步骤、测试环境、用户验收测试以及可能涉及的合规规则（例如 GDPR）。 -
项目管理 SOW
对于一份项目管理服务的 SOW，请描述项目负责人每周工作多少小时、他们具体承担哪些职责（报告、预算编制、风险管理），以及采用哪种方法（瀑布 vs. 敏捷）。 -
建筑项目
在建筑领域，SOW 可能包含建筑标准、现场检查、安全要求、所需材料，以及从场地准备到最终验收的详细时间计划。 -
内部项目
即使是内部举措，例如流程优化或引入新软件，一份 SOW 也很有价值，可让所有部门在任务、预算和截止日期上保持一致。
签字：最后一步
没有签字的 SOW 不具约束力。请确保所有重要利益相关者在工作开始前签字。这包括：
- 项目负责人或管理层
- 供应商或第三方代表
- 团队负责人（如果他们承担直接责任）
一份已签署的 SOW 是您在争议时的保障。它成为对从工作范围到时间计划的一切事项最终的“是的，我们同意”。
常见问题解答（FAQ）
SOW 应当详细到什么程度？
越具体越好。含糊的表述（“合理的时间”）会带来误解。请改为这样表述：“此任务必须在四小时内完成，并通过 QA 测试。”如果遗漏了某些内容，可能导致延误、额外成本或争议。
我该如何为敏捷项目撰写工作说明书？
内部项目有必要做工作说明书吗？
绝对有必要。即使内部项目有时处理得较为随意，一份正式的 SOW 仍能让所有参与方保持一致的方向。它能厘清目标、任务、职责与截止日期，从而减少混乱与摩擦。
我该如何回应一份工作说明书（SOW）？
- 仔细阅读，并记下不清楚之处。
- 就含糊或缺失的要点要求澄清。
- 如有必要，就范围、时间计划或付款条件协商变更。
- 只有在您对所有要点都表示同意后，才签署 SOW。
我该如何根据 SOW 制定项目计划？
在您将 SOW 定稿并签署后，请将其中的任务、里程碑和成果转化为一份详细的项目计划。这份计划应当：
许多团队使用诸如 Merlin Project 这样的项目管理软件来制定时间计划、跟踪进度并高效地管理资源。
如果您对这篇博客文章有任何疑问或希望参与讨论，欢迎您在我们的论坛中发帖。
