范围管理：WBS 与范围蔓延

核心概念

范围管理(Scope Management) 回答两个问题：做什么（产品范围）和为此要做哪些工作（项目范围）。它的全部目的，是让团队与干系人对「边界」达成共识，并提供变更的控制闸。

需求收集 是起点。需求分业务需求(为什么做)、干系人需求(谁要什么)、解决方案需求(功能/非功能)。常见陷阱：把「方案」当「需求」——用户说「要个搜索框」，真实需求可能是「3 秒内从 10 万条里找到订单」。

WBS(Work Breakdown Structure，工作分解结构)：把项目范围逐层拆解到「可交付、可估算、可分配、可验收」的工作包(Work Package)。黄金法则——100% 规则：WBS 下层之和必须完整覆盖上层 100% 的内容，不重不漏。拆到工作包层级(通常 8/80 规则：一个工作包 8~80 人时)即可估算与排期。

范围基准(Scope Baseline) = 范围说明书 + WBS + WBS 词典。它是「验收的依据」——日后判断「这算不算该做的」以此为准。

变更控制(Change Control)：任何对基准的修改，必须走正式流程(提交→影响评估→CCB 审批→更新基准)，而非口头「顺手加个功能」。

范围蔓延(Scope Creep) 是项目头号杀手：未经控制、一点一点加进来的需求。每个单独看都「不大」，累积起来项目就失控。对抗蔓延的不是「拒绝变更」，而是「让每次变更都现出代价」——加功能就要么加钱、要么延期、要么砍别的。

实务直觉

第一原则：验收标准写在前面，而不是交付时讨价还价。 WBS 词典里每条工作包都要有「完成的定义(DoD)」。没有 DoD，「做完了」三个字毫无意义——甲以为做完，乙以为刚开始。

• 拆得够细才估得准。 人们对大任务的估算误差远大于小任务(分解效应)。WBS 的价值一半在「可管理」，一半在「逼出真实工作量」。
• 「顺手加一个」是最贵的四个字。 一个看似 1 天的小需求，可能牵动设计、测试、文档、回归——真实成本常是表面的 5~10 倍。变更流程的作用，就是把这个隐藏成本摆到台面上让干系人自己选。
• 镀金(Gold Plating)也是范围错配。 团队自作主张「多做一点显得专业」，既超出基准又可能引入风险。按基准交付，就是对客户最大的尊重。

跨学科应用

集合论：100% 规则即不重不漏

WBS 本质是集合的划分(Partition)：父节点 = 子节点并集，子节点两两不交。违反 100% 规则(漏拆或重复)会直接造成估算缺口或责任真空。「不重不漏」是项目范围可控的数学前提。

行为经济学：现状偏差与承诺升级

干系人提需求时信心满满，真要他为「加功能=延期」买单时又舍不得。变更控制把隐性代价显性化，对抗的是「损失厌恶」——人不愿承认已许诺的范围其实负担不起。

组织行为学：角色模糊导致推诿

WBS 把工作包映射到责任(见 0010 RACI)。范围不清=角色不清=出事互相甩锅。结构化的范围，本质是结构化的责任分配。

谈判：需求背后的利益

用户要「搜索框」是立场，要「3 秒找到订单」是利益。范围管理的功夫，在需求访谈里挖利益层，避免被表面方案绑架(呼应领导力 0001 的立场/利益区分)。

练习题

单选题

单选题

判断题

案例题

客户在验收前一周说：「顺手加个导出 Excel 吧，就一个小功能。」团队成员觉得不难，想直接做。你该怎么处理？

参考答案：走变更控制——评估真实影响(后端接口、前端、测试、文档、回归)，呈现代价，交 CCB/客户决策：要么加钱加期，要么放入下个版本，要么砍掉同等量级的其他项。绝不能「顺手做」，否则这次破例会成为范围蔓延的开端，且破坏了范围基准作为验收依据的可信度。