衡量范围蔓延，关键是把“未经批准的范围增加”和“已批准的范围变更”分开统计，再用范围变更率、未授权需求占比、范围基准偏差三个指标交叉判断。单看一个数字容易误判，需要先固定计量单位、统计时间窗和分母口径，再结合变更审批记录与需求来源证据解释结果。
要点总览（TL;DR）
- 衡量范围蔓延要把“未经批准的范围增加”和“已批准的范围变更”分开统计，再用范围变更率、未授权需求占比、范围基准偏差三个指标交叉判断。
- 范围变更率＝统计期内已批准变更涉及的范围量÷基准范围量，分母取基准确定时的范围量，分子只计走完审批的变更。
- 未授权需求占比＝未走变更流程的新增需求数÷同期新增需求总数，判定依据是变更审批记录与需求来源证据。
- 范围基准偏差同时给出绝对值和相对值，便于安排资源与跨周期比较；三个指标都要固定计量单位、时间窗和分母口径。
- 阈值应基于项目自身历史数据设定，先看趋势再看单点，指标用于迭代复盘改进，不宜直接作为单一考核依据。
衡量范围蔓延要回答什么问题
范围蔓延评估的目标是判断项目范围是否在基准内受控演进，而不是追求“零变更”。范围基准确定后，客户提出新需求、市场出现新机会、技术方案调整，都可能带来合理变更。真正需要识别的是那些绕过变更流程、直接进入执行范围的内容，以及虽走流程但累积量已超出项目承受能力的调整。
因此评估要回答三个问题：统计期内范围总量相对基准增加了多少；这些增加中有多少经过正式审批；增加的速度和方向是否与项目阶段匹配。三个问题分别对应范围基准偏差、未授权需求占比和范围变更率的趋势观察。
计量单位需要在评估开始前确定，并在整个观察周期内保持一致。常用单位有三种：需求条目数，适合需求粒度较均匀、以功能交付为主的项目；人天或故事点，适合需要反映工作量影响的项目；功能点，适合有功能点估算基础、需要跨项目比较的场景。单位一旦选定，分子分母都使用同一单位，中途更换会导致前后数据不可比。
观察周期同样要固定。可以按迭代、按月或按阶段设置统计窗口。周期太短，单次变更就会造成比率剧烈波动；周期太长，问题暴露滞后。建议以项目自身的交付节奏为基准，例如两周迭代按迭代统计，阶段交付型项目按月统计，并在多个周期上观察趋势。
三个核心指标的定义与统计范围
三个指标从不同角度描述范围变化，需要组合使用。范围变更率反映受控变更的规模，未授权需求占比反映失控增加的比例，范围基准偏差反映范围总量相对基准的偏离程度。下表给出建议口径，实际使用时需在项目内形成书面约定。
| 指标 | 公式 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 范围变更率 | 统计期内已批准变更涉及的范围量 ÷ 基准范围量 | 走完审批流程并被批准的变更所涉及的需求条数、人天或功能点 | 范围基准确定时的范围总量 | 百分比 |
| 未授权需求占比 | 统计期内未走变更流程的新增需求数 ÷ 同期新增需求总数 | 没有变更审批记录、但已进入需求池或执行范围的新增需求数 | 同期所有新增需求数，含已批准与未批准 | 百分比 |
| 范围基准偏差 | 当前范围量 − 基准范围量；相对偏差 = 绝对偏差 ÷ 基准范围量 | 当前已纳入范围的需求条数、人天或功能点 | 基准范围量（计算相对偏差时使用） | 绝对偏差用原单位，相对偏差用百分比 |
范围变更率的分母应取基准确定时的范围量，而不是当前范围量。用当前范围量作分母会稀释变更比例，变更越多、分母越大，比率反而被压低。分子只计已走完审批的变更，审批中的变更可以单独列为“在途变更”，不混入已批准口径。
未授权需求占比的判定依据是变更审批记录与需求来源证据。一条需求如果出现在需求池或任务列表中，但找不到对应的变更申请、审批结论或基准更新记录，就应归入未授权。判定时需要区分“尚未提交审批”和“明确被拒绝后仍被执行”两种情况，后者性质更严重，可以在备注中单独标记。
范围基准偏差同时给出绝对值和相对值。绝对偏差说明范围量增加了多少条需求或多少人天，便于安排资源；相对偏差便于跨项目、跨周期比较。两者并列展示，避免只看百分比忽略绝对规模。统计范围要明确纳入与排除项，例如缺陷修复、技术债偿还、纯文档修订是否计入范围量，应在口径说明中逐项列明。
数据从哪里取、口径怎么统一
指标可复算的前提是数据来源固定、取数规则书面化。建议从三类记录取数：范围基准文档或基线版本，提供分母和基准范围量；变更审批记录，提供已批准变更的分子数据；需求池、工单和任务列表，提供新增需求与当前范围量。三类数据的时间戳要能对应到同一统计窗口。
口径规则需要提前约定以下事项：
- 需求拆分粒度：一条需求拆成多个子任务时，按父需求计数还是按子任务计数，全项目统一。建议以可独立验收的需求条目为计数单位。
- 重复需求去重：同一需求在不同渠道重复录入时，以最早进入需求池的记录为准，合并关联记录，避免分子分母同时虚增。
- 跨期需求归属：需求提出、审批、纳入范围可能跨越多个统计周期。建议以“纳入执行范围”的时间点归属周期，审批时间单独记录用于分析审批周期。
- 变更撤销与回退：已批准后又撤销的变更，从分子中剔除，并在口径说明中注明处理方式。
- 分母为零或数据缺失：基准范围量为零时，范围变更率和相对偏差不计算，标注“不适用”；未授权需求总数为零时，占比标注“无新增”，不写为0%。
数据可比性依赖同粒度、同周期、同计量单位三个条件同时成立。跨项目比较时，还要确认各项目的“未授权”判定标准一致，否则一个项目把口头确认视为授权、另一个项目要求书面审批，占比差异反映的是口径差异而非管理水平差异。
在工具层面，范围基准、变更审批和需求来源需要在同一套记录体系中留痕，才能支撑上述取数。ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过版本对比追溯变更细节；同时支持在项目下管理需求范围、研发任务，并提供多维度项目数据统计和分析能力。实际配置中，可以把基准版本、变更审批记录和需求条目关联起来，使范围变更率与基准偏差的分子分母有据可查。具体指标项与报表口径以实际配置为准。
计算与评估步骤
按以下步骤执行，可以保证每次评估结果可复算、可比较。
- 确定评估周期和计量单位，写入项目度量说明。例如“按双周迭代统计，以需求条目数计”。
- 锁定基准范围量。取范围基准确定时的需求条目清单，记录总数作为分母，并保存基准版本快照。
- 提取统计期内的变更审批记录，筛选出已批准的变更，按需求条目去重后计数，作为范围变更率的分子。
- 提取同期新增需求清单，逐条比对变更审批记录，标记未授权需求，计算未授权需求占比。
- 统计当前已纳入范围的需求总量，减去基准范围量得到绝对偏差，再除以基准范围量得到相对偏差。
- 将三个指标按周期排列成趋势表，同时记录当期的变更审批通过率、变更平均审批时长等辅助指标。
- 设定预警阈值。阈值应基于项目自身历史数据，例如取过去若干周期的中位数或上四分位数作为参考线，超出时触发复盘，而不是套用统一达标线。
评估时先看趋势再看单点。某个周期范围变更率突然升高，可能是集中审批了一批积压变更，属于流程节奏问题；连续多个周期未授权需求占比上升，才更可能指向范围入口失守。变更审批通过率可以作为交叉验证：通过率很高且变更率也高，说明变更容易获批，需要检查审批标准是否过松；通过率低但未授权占比高，说明审批流程可能过长，团队绕开流程执行。
算例：一个迭代的范围蔓延测算
以下数字为演示情景，仅用于说明计算过程。某项目在迭代开始时确定范围基准为80条需求。本迭代内，走完审批并被批准的变更涉及12条需求；同期新增需求共20条，其中6条没有变更审批记录；迭代结束时，已纳入执行范围的需求共94条。
| 指标 | 代入计算 | 结果 |
|---|---|---|
| 范围变更率 | 12 ÷ 80 | 15% |
| 未授权需求占比 | 6 ÷ 20 | 30% |
| 范围基准绝对偏差 | 94 − 80 | 14条 |
| 范围基准相对偏差 | 14 ÷ 80 | 17.5% |
结果解读：范围总量比基准多出14条，相对偏差17.5%，其中12条来自已批准变更，说明大部分增加有审批依据；但新增需求中有30%没有走变更流程，这部分是范围蔓延的主要信号。范围变更率15%本身不能判断好坏，需要与项目历史周期比较：如果过去几个迭代稳定在8%至10%，本迭代的15%值得复盘变更来源；如果项目处于需求密集的早期阶段，15%可能在正常波动范围内。
可能的误判点有两个。一是把审批中的变更计入未授权，导致占比虚高，计算前应确认审批状态。二是当前范围量94条中可能包含基准外但属于缺陷修复的条目，如果口径未排除缺陷，绝对偏差会被高估。算例中的分母80和20都非零，实际项目中遇到分母为零应标注不适用，不强行计算。
结果怎么解读、有哪些限制
指标高不直接等于管理失控。范围变更率高，可能说明项目处于探索阶段，需求本身需要快速迭代；未授权需求占比高，也可能反映审批流程层级过多、响应太慢，团队为保交付选择先执行后补流程。解读时要回到变更性质和流程效率，区分“该批的批得慢”和“不该进的进来了”。
分母口径变化是常见的不可比来源。基准范围量在项目中途重新基线化后，前后周期的范围变更率不能直接比较；需求拆分粒度调整后，需求条目数也会跳变。发生这类变化时，应在趋势表上标注口径变更点，分段比较，或者改用同一口径重算历史数据。
指标适合用于改进讨论，不宜直接作为单一考核依据。如果把未授权需求占比与个人绩效直接挂钩，可能出现需求被拆小、延迟录入或改走其他渠道的情况，数据反而失真。更稳妥的做法是把指标用于迭代复盘，追问未授权需求的来源、审批卡点和基准维护方式，形成具体改进动作。
范围蔓延还需要与进度、成本指标联动观察。范围增加14条需求，如果进度和成本没有相应调整，后续可能出现赶工或质量下降；如果进度计划已同步更新、资源已追加，范围变化就处于受控状态。单独看范围指标，无法判断项目整体是否健康。ONES 瀑布项目管理解决方案提供多维度项目数据统计和分析能力，可将范围、进度相关数据放在同一项目视图中对照，帮助管理者在复盘时结合偏差来源判断。资料未说明具体指标项与统计口径，实际使用以配置为准。
常见问题
项目刚启动、基准范围量很小，范围变更率算出来波动很大，怎么处理？
基准范围量较小时，单条需求的增减就会让比率大幅跳动，这时比率本身的信息量有限。可以同时看绝对偏差，例如“基准20条、当前24条、增加4条”，比“变更率20%”更直观。也可以把统计窗口从单迭代拉长到月度或阶段，让分母积累到一定规模再计算比率。分母为零时标注“不适用”，不强行计算。
需求在迭代中途提出、下个迭代才审批通过，应该算在哪个周期？
建议以“纳入执行范围”的时间点归属统计周期，审批时间单独记录用于分析审批周期。这样同一需求不会在两个周期重复计数，范围变更率与基准偏差的口径也能对齐。如果项目更关注审批效率，可以另设“在途变更”一栏，把已提交未批准的变更单独列出，不混入已批准口径。
未授权需求占比高，是不是说明团队不守流程？
占比高有多种可能：审批层级过多、响应太慢，团队为保交付先执行后补流程；需求入口分散，多个渠道直接对接开发；或者“未授权”的判定标准本身过严，把口头确认的需求也计入了。复盘时应逐条追问未授权需求的来源和审批卡点，区分流程效率问题与范围入口失守，再决定是简化审批还是收紧入口。
项目中途重新基线化之后，前后的范围变更率还能直接比较吗？
不能直接比较。重新基线化会改变分母，前后周期的比率反映的是不同基准下的变化。处理方式有两种：在趋势表上标注口径变更点，分段比较；或者用同一基准重算历史数据，保持口径一致。需求拆分粒度调整、计量单位更换也会造成同样的不可比问题，发生时同样需要标注或重算。
这三个指标能不能直接用来考核项目经理？
不建议直接挂钩个人绩效。指标与考核绑定后，可能出现需求拆小、延迟录入、改走其他渠道等情况，数据反而失真。更稳妥的做法是把指标用于迭代复盘，追问未授权需求的来源、审批卡点和基准维护方式，形成具体改进动作。范围指标还需要与进度、成本联动观察，单独看范围无法判断项目整体是否健康。
