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

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

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

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

所以要分清两层：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

划边界时还要分清两条线 12：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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