# 一句“顺手也加上”值多少人天：变更来了先算三笔账

新增、返工、下游三笔账，余量与窗口两道关，以及拿三个算好代价的方案让人选

> 范围与目标 · 进度与排期 · 风险管理 · 约 8 分钟 · 10 月 28 日

## 本篇要点

1. “顺手加一下”没法直接判断，要先把含糊的动词换成看得见的产出，才谈得上估工作量。
2. 变更的成本要算三笔：新增的活、碰到已验收部分的返工、测试培训文档等下游；只算第一笔会严重低估。
3. 人天缺口换成的天数是下限，排不进的评审窗口和外部依赖不因加人而变快，往往比人天缺口更能决定结论。
4. 可选的从来不是“接或不接”，而是几个算好代价的方案；取舍不会消灭代价，只会决定这笔代价由谁承担、什么时候承担。
5. 变动上线日和首期范围由唯一有 A 的人拍板，项目经理负责算清方案、给出建议、限期要决定，因为可选空间会随时间缩小。
6. “不碰里程碑、不动已验收内容、总计不超过 2 人天”的改动可以直接消化；阈值过严会逼人绕开流程。
7. 变更大到接近剩余工作量一半以上时，应当重做基线而不是打补丁。

---

第 6 周周二上午，客服部王经理在群里说：“迁移的时候顺手把邮件渠道也接进来吧，反正都在做客服系统。”下午技术负责人接了一句：“客户等级那个字段也趁这次改了吧，以后别的系统也要读。”

两句话听起来都很轻。但两条加起来是 24 个人天，而项目当时只剩 12 个人天的余量。这类请求的麻烦不在该不该答应，而在于“顺手”两个字把代价藏了起来。下面把这件事完整走一遍：先算清，再决定接不接、拿什么换。条件全部摆出来，你可以先自己算，再对照后面的解法。

## 先把案例的条件摆全

| 项 | 现在的情况 |
| --- | --- |
| 项目 | 客服系统迁移：12 万条历史工单迁到新系统，接电话和在线聊天两个渠道 |
| 上线日 | 4 月 30 日，离现在还有 4 个工作周 |
| 团队 | 3 名开发、1 名测试（半投入）、1 名实施 |
| 实际产能 | 15 人天/周（已扣掉例会、线上问题、休假） |
| 剩余工作量 | 48 人天（上周五重新估过，不是年初的计划数） |
| 余量 | $15 \times 4 - 48 = 12$ 人天 |

“实际产能 15 人天/周”是关键的一行：5 个人不等于每周有 25 人天可用，能真正投到项目活上的是扣完日常损耗剩下的那部分。用它一除就得到余量：48 ÷ 15 ≈ 3.2 周，还剩 4 周，缓冲 0.8 周，也就是 12 人天（这套算法的来历见[周报上的 85% 为什么不动了](https://pangzhengboyin.com/articles/why-percent-complete-misleads-progress-tracking-44110ae0)）。

## 第一步：把口头要求写成一条能判断的变更

“顺手加上”没法评估，因为它没说清改什么、改到什么程度、什么时候要。先落成两条记录，每条至少回答三件事：改的是什么、谁提的、他什么时候想用上。

- 变更 1：首期迁移同时接通邮件渠道，客服能在一个界面里处理电话、在线、邮件三类工单。
- 变更 2：把“客户等级”从自由填写的文本改成受控字典，供后续系统读取。

注意“接通邮件渠道”和“在一个界面里处理三类工单”是两件事，前者是接口，后者是坐席端改造，工作量差得很远。含糊的动词要换成看得见的产出，才谈得上估工作量。

## 第二步：算人天，要算三笔账

多数人只算第一笔：这块新活要多少人天。三笔全算上，数字常常差一倍以上。

**第一笔，新增的活。** 这块活原来不在 WBS 上，从零开始做。

- 邮件渠道：接口开发 10 人天 + 测试 5 人天 + 培训材料补一章 2 人天 = **17 人天**。

**第二笔，返工。** 这是最容易漏、也最贵的一笔。变更碰到已经做完、甚至已经验收过的东西，那部分要重新动一遍，动完还要重新验一遍：已经通过的测试、已经核对过的数据、已经定稿的文档，全部付第二次成本。

- 客户等级字段重构：开发本身 3 人天，但迁移脚本里这一列的处理逻辑要改，12 万条数据要重跑并抽样复核——**返工 4 人天**。合计 **7 人天**。

**第三笔，下游。** 测试、培训、文档、数据核对、上线支持，这些活挂在 WBS 的别的行下面，改一块会牵动好几行。上面的 17 人天已经把测试和培训算进去了；漏掉的话，你得到的会是一个偏小一半的数字。

三笔加起来：$17 + 7 = 24$ 人天。

## 第三步：跟余量比，把缺口换成人天再换成天数

原有剩余 48 人天，加上变更 24 人天，共 72 人天；产能是 60 人天。

$$72 - 60 = 12 \text{ 人天缺口}, \quad 12 \div 15 = 0.8 \text{ 周} \approx 4 \text{ 个工作日}$$

这就是“两个都接”的价格：上线日往后推约 4 个工作日。

但这个 4 天是下限，不是承诺。它成立的前提是多出来的活能平铺进日历，而这个项目里至少有一处不能：邮件网关要接外部服务，安全评审要多走一轮，窗口是别人排的，排到哪天不由你决定。所以人天账算出 4 天，日历上可能要 8 天，也可能根本上不去。**人天可以买，窗口买不到**——这类环节要单独拎出来看，它往往比人天缺口更能决定结论。

## 第四步：不是接或不接，是给三个算好代价的方案

最糟的反应是自己咬牙消化（“加加班吧”）；第二糟的是回一句“这个做不了”，把球原样踢回去。

| 方案 | 算下来 | 代价落在谁身上 |
| --- | --- | --- |
| 一、两个都接，日期后推 4 个工作日 | 缺口 12 人天，约 4 个工作日 | 业务方多等；安全评审窗口仍可能让它变成 8 天 |
| 二、邮件渠道这次接，字段重构放二期 | $48 + 17 = 65$，缺口 5 人天，约 2 个工作日 | 二期还得再动一次迁移脚本，这 4 人天返工以后照样要付 |
| 三、两个都接，砍原范围：历史全量归档放二期（省 8）、邮件模板美化不做（省 2）、培训改录播（省 2） | $72 - 12 = 60$，正好等于产能 | 缓冲归零，所有意外都挤到上线前一周 |

方案三看上去最漂亮：日期不动，需求全接。但它把 12 人天缓冲花得一分不剩，等于把风险从“日期”换成了“上线质量”，而这份风险会在最后一周由整个团队承担。**取舍的真实形态不是消灭代价，而是选择由谁承担、什么时候承担。**

还别忘了第四个选项：什么都不做。邮件渠道不接，客服每天要手工转大约两百封邮件——这个成本也要摆上桌。不算它，拒绝看起来就是零成本，而实际不是。

## 第五步：谁拍板

改动上线日和首期范围，已经超出项目组自己能定的范围。谁对这件事有唯一的 A，就由谁拍板（见[谁做、谁拍板、谁只要知道](https://pangzhengboyin.com/articles/raci-responsibility-table-one-accountable-2711b0e7)）。项目经理的活是把三个方案算清楚、给建议、限期要决定，而不是替业务方扛下来。

> 这两条加起来要 24 人天，现在只剩 12 人天余量。三个选法：推到 5 月初；字段重构放二期，日期推 2 天；砍历史全量归档，日期不动但上线前没有缓冲。我建议第二个，因为字段重构二期做只多付一次数据复核。需要你在周四前定——再晚，第三个方案也来不及排了。

最后半句不是催促，是信息：变更的可选空间本身会随时间缩小，越晚决定，方案越少、越贵。

决定之后留两行字：改什么、谁提的、人天影响、换了什么（日期、范围还是人力）、谁批的；再加一页变更登记表，一条一行。它唯一的作用是让“这个项目为什么晚了三周”在上线后有据可查。

## 什么样的变更不必走这一套

设一条阈值：不碰任何里程碑、不动已验收的东西、总计不超过 2 人天的改动，直接进 WBS 消化，周报里加一句说明就行。

这条阈值不是偷懒。流程太重会逼所有人绕开它——PMI 在分析范围蔓延的成因时，把“变更流程过于僵硬或繁琐”列为原因之一 [1]。而真正拖垮项目的往往也不是显眼的大改动：微软在讲变更评估时提醒过，造成损害的多半是大量小范围改动，而不是大的、显而易见的那些 [2]。阈值的意义就是：小的放过去并记录，大的必须算。

## 最容易出错的三处

- **只算新增，不算返工。** 已经验收的东西被改动，成本是新增的好几倍。案例里那 4 人天返工，藏在一个“只要改 3 人天”的要求后面。
- **拿“加加班”当第四个方案。** 加班产能不是线性的，而且它不留记录，同一个坑下个项目再踩一次。
- **接了变更却没改范围文件。** 上线那天争论“这算不算做完”，比推迟两周更伤。

## 这个算法什么时候不成立

变更大到接近剩余工作量的一半以上，就不是变更而是重新立项，该重做基线而不是硬塞进原计划。合规要求带来的改动没有“不接”这个选项，重点全部转到“砍什么来换”。另外，÷15 这一步要求团队产能相对稳定；产能本身在晃，先稳住它，否则算出来的天数只是好看的数字。

一句能记住的话：**变更从来不贵在改本身，贵在它没有对应的交换。**

## 思维导图

```mermaid
flowchart LR
  A["一句顺手的请求"] --> B["写成能判断的变更：改什么、谁提的、何时要"]
  B --> C["算三笔账：新增 + 返工 + 下游"]
  C --> D["比余量：产能 − 剩余工作量"]
  D --> E{"有缺口吗"}
  E -->|没有| F["直接接，进 WBS 并记录"]
  E -->|有| G["换算成天数是下限"]
  G --> H["单独看买不到的窗口与外部依赖"]
  H --> I["给三个算好代价的方案，含什么都不做"]
  I --> J["有唯一 A 的人拍板，限期决定"]
  J --> K["记两行：改了什么、换了什么"]
```

## 术语表

- 范围蔓延（scope creep）：范围悄悄变大，却没有相应调整时间、人力或成本；问题不在改动本身，而在改动没有对应的交换。
- 变更的三笔账：新增的活、碰到已验收部分的返工、测试培训文档等下游活；三笔加起来才是真实人天。
- 余量：剩余产能减去剩余工作量剩下的部分，用“每周实际能投入的人天 × 剩余周数”再减剩余工作量算出，是能不能接变更的分母。
- 变更阈值：事先定好的界线，越过就走评估和记录，没越过就直接消化；作用是让流程轻到没人想绕开。

## 来源

1. [PMI: Top five causes of scope creep — 范围蔓延的定义（未经授权、未调整时间成本），以及流程过于僵硬本身也是成因](https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)
2. [Microsoft Support: How to evaluate project change requests — 小范围改动累积造成的损害更大、变更分类与阈值、评估问题清单](https://support.microsoft.com/en-us/project/how-to-evaluate-project-change-requests)

---

原文：https://pangzhengboyin.com/articles/scope-change-impact-tradeoff-362fb7c0

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具：每篇 5–10 分钟，边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com