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

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

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

先把案例的条件摆全

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

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

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

• 变更 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 天，也可能根本上不去。人天可以买，窗口买不到——这类环节要单独拎出来看，它往往比人天缺口更能决定结论。

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

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

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

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

第五步：谁拍板

改动上线日和首期范围，已经超出项目组自己能定的范围。谁对这件事有唯一的 A，就由谁拍板（见谁做、谁拍板、谁只要知道）。项目经理的活是把三个方案算清楚、给建议、限期要决定，而不是替业务方扛下来。

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

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

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

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

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

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

最容易出错的三处

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

这个算法什么时候不成立

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

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