# 项目开始前，把“做完”和“成功”分成两句话说清楚

验收标准、成功标准、范围边界，写成一页纸并让人认下来

> 项目管理基础 · 范围与目标 · 约 7 分钟 · 10 月 02 日

## 本篇要点

1. 交付完成和项目成功是两件事：前者指约定的交付物都交出来并符合条件，在项目结束时判定；后者指整件事达到了启动它的目的，往往在结束之后才看得出来，两者必须分开写。
2. 范围说明书要包含三块：立项理由、交付物、目标。立项理由是后续所有取舍的依据——资源不够时砍哪块、牺牲什么，都对着它判。
3. 验收标准挂在单个交付物上，要写成能回答“过”或“不过”的句子，而不是“系统稳定”“培训到位”这类形容词。
4. 成功标准挂在项目整体上，PMI 建议的格式是属性＋尺子＋数值；未量化的目标比如“提升客户满意度”会带来高风险，要么换成可数的观测对象，要么写清谁在何时怎么测。
5. 产品范围（产品要有哪些功能）和项目范围（为做出它要做哪些工作）要分开：产品范围对着需求衡量，项目范围对着计划衡量。
6. 没写的东西在现实里默认被当成包含在内，所以排除项必须主动写出；假设和限制同样要显式写下，它们是最容易悄悄挪动边界的两类东西。
7. 写成一页纸后必须找出资方、使用方、验收方确认，“我以为”变成“我们都说好了”才是这份文档的作用。
8. 探索性项目不适合先写死交付物，可以固定时间和质量、让范围浮动；范围被批准变更后文档要跟着更新。

---

上一篇讲到，项目是临时的、独特的，所以带队的第一件事不是排期，而是把“做成什么样才算完成”定义清楚。但“定义清楚”这四个字本身也很模糊——你手上大概率只有一句“把客服系统换掉”“今年把三家门店开出来”。这句话离能拿来管理项目还差很远。

这篇就把这一步拆开：最后要交出哪几样东西，每样凭什么叫合格，整件事凭什么算成功，以及哪些东西明确不在这件事里。

## 一、先把“做完”和“成功”分成两个问题

拿“把客服系统从旧平台换到新平台”举例。交付那天，旧系统停用、数据搬完、新系统上线，这叫作做完了。但半年后如果客服人员还在用 Excel 记工单，你会说这个项目成功吗？多半不会。

所以要分清两层：

- **交付完成**：约定要交的东西都交出来了，每样都符合事先讲好的条件。
- **项目成功**：整件事达到了当初启动它的目的，而且这个目的能用数字或明确的观测方式检验。

两层都要写，而且要分开写。它们的判定对象不同、判定时间也不同：交付在项目结束时判定，成功常常要等结束之后才看得出来。混成一句话，就会出现“东西都交了，却没人说得清这算不算成”的局面。

还有第三样要写在一开始：**为什么做这件事**。PMI 把范围说明书归纳成三部分——立项理由、交付物、目标 [1]。立项理由看着最虚，实际最有用：后面所有取舍都靠它来判。预算不够要砍功能、时间不够要牺牲点什么时，看的就是哪部分最贴近当初的理由。

## 二、验收标准：挂在交付物上，一条条能判过或不过

每个交付物都要有明确的完工条件。PMI 举的反例是“临床试验”：它不是一个能判定的交付物，写成“按已批准的方案完成三期一期试验”才可以判定 [1]。

写验收标准的关键，是**写成能回答“过”或“不过”的句子**，而不是形容词。对比一下：

- “系统稳定” → “上线后连续 30 天内，非计划停机累计不超过 2 小时”
- “数据迁移完成” → “随机抽查 1000 条历史工单，字段与原系统一致率不低于 99.5%”
- “培训到位” → “全部 40 名客服完成 2 小时培训并通过考核”

左边那种写法的问题不在于不认真，而在于验收那天双方会各按自己的理解打分。右边这种写法，做的过程中你就知道该测什么、测给谁看。

## 三、成功标准：挂在项目整体上，要说清尺子和数值

成功标准不是验收标准的加强版，它问的是另一个问题：这件事有没有达到启动它的目的。

PMI 给的写法很好用：一条可量化的目标要包含三个部分——**属性、尺子、数值**。例如属性是成本、尺子是货币、数值是不超过 150 万 [1]。照这个格式，客服系统项目的成功标准可以写成：

- 客服平均首次响应时间从 12 分钟降到 8 分钟以内（上线后第 90 天统计）
- 上线 6 个月后，一线客服在新系统里处理的工单占比不低于 95%
- 项目总投入不超过 XX 万

PMI 在同一处提醒：像“提升客户满意度”这种没有量化的目标，会给项目带来很高的风险 [1]。这不是说软目标不能有，而是说软目标也得交代清楚怎么观测、谁来观测、什么时候观测。上面那条“占比不低于 95%”，就是把“大家愿意用”换了一种说法——我们不去测“愿意”，而是找一个能反映它的、可数的东西。

## 四、两条“范围”要分开：产品范围管需求，项目范围管工作

划边界时还要分清两条线 [1][2]：

- **产品范围**：这个产品要有哪些功能、达到什么性能。验收时对着它比。
- **项目范围**：为了做出这个产品，我们要做哪些工作。排期和资源对着它比。

产品范围的完成情况是对着需求衡量的，项目范围的完成情况是对着计划衡量的 [2]。

这解释了两种最常见的扯皮。一种是：交付物确实按需求做了，你说“我没计划做这个功能”，对方说“需求里没写不做”。另一种是：功能一个不少，工期却超了，团队说“需求就长这样”，业务说“我不管你计划怎么排”。两条范围分开写清楚，才分得清眼下争的到底是需求变了，还是计划没做到。

## 五、边界靠“显式排除”划出来

范围边界最容易漏的是**不做什么**。按 PMBOK 的定义，没写进范围的东西本来就不算在范围里 [1]；但现实正好相反：没写的东西，默认会被相关的人当成包含在内。所以不做什么必须主动写下来。

除排除项外，还有两类东西会悄悄挪动边界，也必须写：

- **假设**：你按什么前提在做。比如“旧系统的历史录音不需要迁移”“业务部门会上线前两周完成话术确认”。假设一破，范围就跟着变，所以它得写在纸上让对方看见。
- **限制**：绕不过去的条件。预算上限、必须赶在某个节点前上线、只能用现有服务器。

客服系统那个项目，一页纸的边界大概长这样：

- 不做：不改动客服话术流程；不迁移历史录音和三年以前的工单；不做移动端 App
- 假设：旧平台的导出接口在项目期内保持可用；业务侧每周能抽出一个人配合确认
- 限制：总预算不超过 XX 万；必须在大促开始前完成切换

## 六、一页纸就够，但要给人认

把上面几块拼起来，成品只有一两页，不需要正式文档的架子：

1. 为什么做（一句话）
2. 交付物清单，每项后面跟验收标准
3. 成功标准，每条写清属性、尺子、数值，以及谁在什么时候测
4. 显式排除项、假设、限制

写完还有一步不能省：**找人认下来**。出钱的人、用结果的人和验收的人，至少要知道第 2、3、4 条写的是什么。这不是流程要求，而是这份东西唯一的用处——它把“我以为”变成“我们都说好了”。对方不同意，现在改的成本最低；等到验收那天再改，就没有余地了。

## 七、这套办法什么时候不适用

上面这套写法默认你已经大致知道要交什么。如果项目本身是探索性的——比如“试试看能不能用 AI 自动分类工单”——那连交付物都得边做边发现，先写死的验收标准反而是负担。这种情况可以换个固定项：**把时间和质量固定住，让范围浮动**，先用一小块东西验证假设，再决定要不要往下做 [3]。

另外，这些内容不是写完就冻住。范围一旦被批准变更，文档要跟着更新，否则它就从工具变成了摆设。区别只在于：变更是写下来、被同意的，还是悄悄发生的。

<details>
<summary>自检：下面几条目标，问题出在哪</summary>

- “三个月内提升团队协作效率”：没有可数的观测对象。“效率”要换成一个数得出来的东西，比如“需求从提出到上线平均耗时从 20 天降到 12 天”。
- “按计划上线新系统”：这是项目范围的完成，不是成功标准。上线之后业务上有没有变好，还缺一条。
- “完成用户手册编写”：交付物写成了动作，没有完工条件。改成“用户手册完成，经客服主管按附件清单逐项确认”。
- “本项目不包含移动端”：这条是对的，显式排除项就该这么写。
</details>

## 术语表

- 验收标准：挂在单个交付物上的完工条件，必须能判“过”或“不过”。
- 成功标准：挂在项目整体上的可检验目标，常写成属性＋尺子＋数值。
- 立项理由：当初为什么要做这件事，用来判断后面的取舍。
- 产品范围与项目范围：产品要有哪些功能，与为做出它要做哪些工作，是分开的两条线。
- 显式排除项：主动写下不做什么，因为没写的东西现实中会被默认包含。
- 假设与限制：事情成立才作数的前提，以及绕不过去的条件；两者都会影响范围边界。

## 来源

1. [PMI：范围说明书的三部分、交付物完工条件与目标“属性＋尺子＋数值”写法](https://www.pmi.org/learning/library/scope-statements-3399)
2. [产品范围与项目范围的区别，以及排除项、假设、限制在范围说明书中的位置](https://www.deepfriedbrainproject.com/2009/07/product-scope-project-scope-statement-requirements)
3. [PRINCE2 Agile 速查：质量固定、范围浮动的处理方式与适用场景](https://open-exam-prep.com/study-guides/prince2-agile-foundation/cheat-sheet/)

---

原文：https://pangzhengboyin.com/articles/define-project-scope-and-success-criteria-7aff0653

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com