政务云平台项目：挣值偏差与质量成本的联合判断
某政务云平台项目工期6个月、预算800万元，采用固定总价合同，项目组12人分4个小组，采用两周一个迭代，但同时被要求按CMMI三级提交23类文档，迭代评审经常因文档返工延期。第4个月末项目经理汇报：PV=560万元，EV=420万元，AC=490万元。关键路径上的接口联调因第三方厂商延迟2周，该厂商由甲方指定分包、与承建方无合同关系，其接口文档在验收后才定稿。质量数据显示：缺陷密度3.8个/千行代码，返工工时占总工时28%，集成测试发现的缺陷中62%可追溯到需求评审阶段未被发现的歧义。测试环境只有一套，集成测试与性能测试争抢环境，性能测试已排队11天。团队已连续加班两个月，近一个月离职2人，其中1人是核心模块开发。客户方3个业务处室分别提出优先级，无统一出口；项目前期未设CCB，变更由项目经理口头同意。客户在例会上口头表示“可以先上线再补功能”，但未提交变更申请，也未确认哪些功能可延后。合同约定需求变更超过总价10%需重新审批，目前累计变更工作量估算为62万元，但尚无一份双方签字的变更单。预算中风险准备金30万元已用去21万元。系统还需通过三级等保测评，整改工作量尚未计入进度计划。监理要求两周内提交纠偏方案。
1. 计算SV、CV、SPI、CPI并解读其含义，预测完工成本与工期，并判断“增加人力赶工”是否可行。
Read the worked answer
计算
- SV = EV − PV = 420 − 560 = −140万元（进度落后）
- CV = EV − AC = 420 − 490 = −70万元（成本超支）
- SPI = 420/560 = 0.75
- CPI = 420/490 ≈ 0.857
- EAC = BAC/CPI = 800/0.857 ≈ 933万元，预计超支约133万元
- 按当前速率推算工期 ≈ 6/0.75 = 8个月
解读：SPI与CPI同时小于1，说明不是“多花钱把进度追回来了”，而是钱花了、活没出来--这与28%的返工工时、3.8个/千行的缺陷密度互相印证，属于典型的返工型偏差。若CPI<1而SPI>1才是赶工有效，本案相反。
赶工可行性：关键路径被第三方接口卡住2周，对关键路径加人无效（布鲁克斯法则），新增人力还要承担沟通与培训成本，而团队已连续加班两个月、一个月离职2人。可行路径只有三条：把非关键路径任务并行或外包；压缩范围；就第三方延迟主张工期顺延（该厂商是甲方指定分包，责任不在承建方，应发正式函件留证）。
结论：“加人赶工”不可行，应改为“范围裁剪+关键路径压缩+书面顺延”，并把EAC 933万元与8个月作为与客户谈判的基线数据，而不是继续用原承诺硬撑。
2. 用质量成本（COQ）分析返工根因，说明为什么“加强测试”不是有效对策，并给出改进措施与度量。
Read the worked answer
COQ结构对照本案
- 预防成本：需求评审、设计评审、培训、编码规范--明显投入不足，62%的集成缺陷可追溯到需求评审漏掉的歧义就是证据。
- 鉴定成本：测试、评审、静态扫描。测试环境只有一套、性能测试排队11天，说明鉴定环节本身也是瓶颈。
- 内部失败成本：返工工时28%，缺陷密度3.8/KLOC。
- 外部失败成本：政务系统带缺陷上线的修复代价与舆情代价最高，且等保整改未排期，一旦测评不过将直接阻断上线。
为什么加强测试无效：缺陷在需求阶段注入、到集成测试才被发现。修复成本沿阶段近似指数上升（需求阶段1倍、集成阶段约10倍、上线后可达100倍）。单纯加测试只是抬高鉴定成本，缺陷总量不变，总成本反而上升；何况测试环境已成瓶颈，加人只会加剧排队。
改进措施
- 需求可测试化：每条需求带验收标准，评审用检查单（完整、无歧义、可追溯），三个业务处室先统一优先级出口再进评审。
- 左移门禁：提交前静态扫描零阻断级告警、新增代码单元测试覆盖率≥60%，不达标不进入集成。
- 缺陷根因分析：按注入阶段统计缺陷并计算缺陷泄漏率（DRE），目标集成测试前发现≥85%。
- 环境治理：测试环境分时预约或申请第二套（用剩余风险准备金9万元中的一部分），消除11天排队。
- 度量目标：返工工时占比从28%降至15%以下，作为过程改进的验收指标，而不是以“测了多少用例”衡量质量。
结论：把钱从“找缺陷”移到“防缺陷”，总质量成本才会下降。
3. 客户口头同意“先上线再补功能”，项目经理应如何结构化处理范围、进度、成本与变更控制？
Read the worked answer
先定性：口头承诺不构成范围基准的变更。在固定总价合同下，未走流程的“先上线后补”会把补做工作变成无偿义务，风险全部由承建方承担；而累计变更62万元已接近合同价10%（80万元）的重新审批线，必须书面化。
结构化选项（三角约束，必须放弃一角）
- A 保范围、放进度：按EAC 933万元、8个月完成，追加预算并顺延工期，第三方延迟作为顺延依据。
- B 保进度、减范围：用MoSCoW重排，本期只交付Must，把部分统计报表、移动端次要模块移入二期，并写明二期日期与预算来源。
- C 保进度保范围、加成本：仅对关键路径可并行任务增补资源。团队已疲劳、离职2人，此选项风险最高，不宜作为主选。
推荐组合：以B为主、A兜底--先裁范围保住上线节点，把被裁功能写成带日期的二期承诺；同时就第三方延迟发正式函件保留工期与费用主张。等保整改工作量必须显式计入，否则上线后测评不通过等于没上线。
变更控制流程（立刻补建）
- 成立CCB，成员含客户三个处室的统一代表、监理、承建方项目经理；
- 变更申请必须书面，附影响分析（范围/进度/成本/质量/风险）；
- CCB决策并记录理由，更新需求基线、合同附件与进度计划；
- 同步全体干系人，口头共识一律回到流程内固化；
- 每周向监理报告变更台账与风险准备金余额（已用21万/30万，剩余9万应优先投向测试环境与等保整改）。
判断依据：项目管理不是把三方都满足，而是在约束下做出可追溯的取舍，并让取舍的代价由有权决策的人签字确认。