去年第四季度，我参与复盘了一家年营收 12 亿元的装备制造企业的项目群。9 个在建项目里有 7 个延期，平均延期 38 天，超支中位数 24%。技术故障只解释了其中 11% 的延期原因，剩下的全部指向同一件事：项目启动时签了 43 页需求文档，上线时交付了 129 条从未被正式评审过的附加功能。项目范围（Scope）失控不是执行力问题，而是企业管理者没有建立范围决策机制的问题。这篇文章把我在 12 年项目治理中踩过的坑、用过的阈值、被推翻过的判断，按管理者视角完整拆一遍。
一、核心结论：范围管理的胜负手在企业管理者，不在项目经理
先把结论摆在最前面。我复盘过的 40 多个失控项目里，只有不到 15% 能在事后追溯到”项目经理能力不足”这个原因。其余 85%，根因都在管理层：没有人对”什么算完成”做出有约束力的裁决，也没有人愿意在范围扩大时承担说”不”的成本。
1. 结论一：范围失控的本质是决策权失控
大多数企业并不缺需求文档，缺的是对需求说”不”的那个人和那套流程。项目经理通常只有执行权，没有资源调配权和业务优先级裁定权。当业务部门负责人在周会上直接对开发说”这个功能下周必须加”，项目经理能做的只有记录和转达。
我见过最典型的场景：一家 300 人规模的软件企业，产品线负责人在季度中期连续插入 19 条需求，全部以”客户已经承诺”为由不走变更流程。项目最终交付延期 47 天，但复盘时没有任何一条被标记为”范围变更”。因为没有被记录的变更，等于不存在。
2. 结论二：范围基线必须可量化、可追溯、可回溯
“把需求写清楚”是伪命题。写清楚是主观判断，不同的人读同一份文档会得出不同结论。可量化指的是：每一条进入基线的交付项，都有唯一编号、验收标准、责任人、估算工作量、关联的验收场景。
可追溯指的是任意一条代码提交、任意一个测试用例，都能反向定位到某条基线项。可回溯指的是任何一次变更，都能还原出”谁在什么时候、基于什么理由、批准了多少工期的增加”。
3. 结论三：变更本身不是敌人，无序变更才是
我反对”零变更”这种教条。市场在变、合规要求在变、客户业务在变，一个 9 个月周期里完全不产生变更是小概率事件。真正杀死项目的是无序变更，没有影响评估、没有批准人、没有工期交换的那种。
健康的范围管理不是拒绝变更，而是让每一次变更都显性化定价：加这条需求，要多花 30 人天，那么是从本期范围里砍掉等价工作量，还是接受延期 12 个工作日？这个问题必须由业务方回答，而不是由技术团队默默加班消化。
4. 结论四：范围成本是最容易被低估的隐性成本
范围扩大的成本从来不只是”多写点代码”。我在多个项目中做过拆解，一条看似只有 2 人天的新增需求，实际连带成本往往是估算值的 3 到 5 倍。原因是它同时触发了回归测试、文档更新、培训材料修改、部署脚本调整和后续版本的兼容性约束。
上面这组数据来自我对 2021 年至 2024 年间 63 个企业级项目的结构化复盘记录，样本集中在 200 人以上组织，单个项目预算区间为 200 万至 3000 万元。它不是行业统计，是我个人样本库的观察，但分层规律在四年里非常稳定。
二、背景与真实场景：为什么中大型企业的范围问题更致命
小团队的范围失控表现为加班，中大型企业的范围失控表现为集体失忆。10 个人的团队，谁加了什么需求，午饭时聊两句就同步了。100 人以上的组织，需求从业务负责人到最终代码提交，中间要穿过 5 到 7 层，每一层都会发生信息衰减。
1. 组织规模改变了范围失控的形态
我把范围失控按团队规模分成了三种形态，它们的破坏力完全不同。第一种是”加班型失控”，50 人以下团队常见，代价是团队疲劳和人员流失。第二种是”延期型失控”，50 到 200 人团队常见，代价是错失市场窗口。第三种是”资产型失控”，200 人以上组织常见，代价是系统复杂度永久性上升。
第三种最危险，因为它不会立刻爆炸。多出来的功能会沉淀成代码债务，两年后你想重构时才发现，有 30% 的模块没有明确的业务归属，也没有人敢删。我经手过一个 6 年历史的 ERP 系统，最终梳理出 412 个功能点，其中 107 个没有任何活跃用户调用记录，但删除评估花了 5 个月。
2. 三类高频真实场景
第一类是”客户承诺型插单”。销售在客户现场答应了某个定制化功能，回来直接找研发负责人。这类需求通常带着”客户已经签了合同”的紧迫性标签，实际上合同里可能只是一句模糊的描述。
第二类是”跨部门协作摩擦”。A 部门建的系统，B 部门要用，B 部门提出 15 条改造要求，每条都合理，加起来工期翻倍，但没有任何一方愿意为总工期负责。
第三类是”外部合规变更”。这类最不可控，也最容易被当成免责理由。税率调整、数据出境新规、行业审计口径变化，这类需求确实必须做，但问题是很多团队把”必须做”直接等同于”不评估、不加价、不重排计划”。
3. 一组关于决策延迟的观察
比变更本身更贵的，是变更决策的延迟。我在 2023 年跟踪过 22 个项目的变更审批链路，发现从”需求提出”到”正式批准或驳回”的平均耗时是 9.4 个工作日。在这 9.4 天里，开发团队要么停工等待，要么先按自己的理解动手，两种选择都会产生额外成本。
三、拆解常见误区：六个把我坑过的认知陷阱
下面这六个误区，我本人至少踩过四个，其中两个造成了实际损失。把它们单独列出来，是因为这些说法在管理层会议上听起来都很有道理，很容易被当成最佳实践采纳。
1. 误区一：把 WBS 当成范围基线
WBS 是工作分解结构，它回答的是”怎么干”，不是”交付什么”。我见过团队把 300 行的任务清单当成范围基线，结果客户验收时提出”我当初说的不是这个”，双方都拿不出可以对照的交付物定义。
范围基线的正确形态是双向的：向上对应业务目标，向下对应可验证的验收条件。任务清单会变，验收条件不该轻易变，这两者必须分开管理。
2. 误区二：先干起来，文档后补
“先把需求做了，回头补变更单”是范围管理里最贵的一句话。我统计过，事后补录的变更记录中，工期估算偏差比实时记录的高出 62%，原因是补录时人已经投入了，估算会被已完成的工作反向锚定。
更麻烦的是责任归属。事后补录时，谁提出的、为什么批准，往往已经说不清了，最终变成”大家都有责任”等于”没有人有责任”。
3. 误区三：需求评审通过就等于范围确认
需求评审解决的是”需求是否合理”，范围确认解决的是”这条需求是否进入本期交付范围、由谁验收、什么时候交付”。这是两个完全不同的动作，很多企业只做了前者。
我在一家企业见过这样的流程：需求评审会有 14 个人参加，讨论了两小时，最后会议纪要里没有一句话提到工期和资源。评审通过率 100%，交付准时率 34%。
4. 误区四：用加班消化范围增量
这是最隐蔽的误区，因为短期看起来”团队很有战斗力”。但加班的容量是有上限的，我观察到的经验值是：持续加班能消化的额外工作量上限约为原计划的 15%，超过这个比例，缺陷率会非线性上升。
下面是我在某项目里记录的拐点数据，可以作为自查参照。
| 范围增幅 | 实际交付周期变化 | 千行代码缺陷密度 | 团队月度离职意向比例 |
|---|---|---|---|
| 0% – 10% | +6% | 1.9 个/千行 | 8% |
| 10% – 20% | +21% | 2.7 个/千行 | 14% |
| 20% – 35% | +52% | 4.4 个/千行 | 26% |
| 35% 以上 | +96% | 6.8 个/千行 | 41% |
这组数据来自单个项目 11 个月的连续采样，样本量有限，但拐点位置在后续三个项目里都复现了。结论是：范围增幅超过 20% 之后，交付周期的增长是超线性的，多投入的人天换不回等比例的产出。
5. 误区五：范围管理是项目经理一个人的事
如果范围管理的责任人只有一个项目经理，那它一定执行不下去。项目经理没有业务优先级裁定权，也没有资源调配权，只能做记录员。有效的范围治理必须有三方：业务方负责定义价值，技术方负责评估成本，管理层负责在两者冲突时裁决。
6. 误区六：工具能解决流程问题
我见过企业花几十万采购项目管理平台，上线三个月后使用率跌到 12%。原因不是工具不好，是流程没定。工具只能放大已有的规则，不能创造规则。先定义”什么样的变更必须走评估”，再谈用什么工具承载。
四、专业判断逻辑：把范围风险做成可计算的模型
经验判断的问题是不可复制。同一件事，我今天觉得风险高，下个月换了心情可能就觉得还行。所以我把范围管理的判断逻辑拆成了三层，每一层都有明确的量化和阈值。
1. 第一层：区分三种范围
产品范围回答”这个产品要提供哪些能力”，项目范围回答”这一期项目要交付其中的哪一部分”，交付范围回答”本次上线实际交付了什么”。三者必须在文档里分开，否则讨论会永远打架。
我见过最常见的争吵模式是：业务方拿产品范围的期待来验收项目范围的交付，技术方拿交付范围的现实来解释项目范围的延期，双方都觉得自己有理。
2. 第二层：变更影响必须五维评估
只评估工期是不够的。我在实践中固定使用五个维度：工期、成本、质量风险、资源占用、依赖影响。每个维度打 1 到 5 分，总分超过 15 分的变更必须升级到管理层裁决。
下面是我在项目里使用的一份范围基线定义片段，你可以直接改成自己团队的格式。
scope_baseline:
version: v1.3
product_scope:
id: PS-004
name: 供应商对账能力
status: 已确认
project_scope:
id: SC-0217
name: 自动对账单生成
acceptance:
支持按月/按供应商两个维度生成
单次生成耗时不超过 90 秒（10 万行数据量）
金额差异率大于 0.1% 时强制人工复核
owner: 财务共享中心-李工
estimate_pd: 26
iteration: 2024-Q2
out_of_scope:
供应商自助修改对账单
多币种自动汇兑
change_policy:
auto_approve_threshold: 5 # 影响分 manager_approve_threshold: 15 # 6-15 分，业务负责人+技术负责人会签
steering_required: true # 16 分以上，进入项目指导委员会
out_of_scope 这一段是整份文件里最重要的部分，也是最容易被省略的。明确写出”这一期不做什么”，比写清楚”做什么”更能降低后期的争议成本。
3. 第三层：四个范围健康度指标
我每月看四个数字，任一指标连续两个月恶化就启动范围审计。这四个指标是：范围基线覆盖率、变更批准率、变更影响分中位数、范围漂移率。
范围基线覆盖率 = 有基线编号的交付项 / 实际交付项总数。低于 90% 说明有大量”影子需求”在流程外流动。变更批准率 = 批准的变更数 / 提出的变更数。如果这个数字长期高于 90%，基本可以确认审批是橡皮图章。
变更影响分中位数反映变更的”重量”。如果中位数从 6 分缓慢爬到 11 分，说明大的改动越来越多，这时候即使变更数量没涨，风险也在积累。
范围漂移率 = 期末实际交付范围与基线范围的差异工作量 / 基线总工作量。这是我见过最能提前预警的指标，它能比延期提前 6 到 8 周发出信号。
4. 决策阈值与授权矩阵
阈值不是越严越好。阈值过严会导致大量变更绕过流程，反而更危险。我的经验是：让 60% 到 70% 的日常变更在项目经理层面就能闭环，剩下 30% 左右升级到管理层。
如果项目经理层面只能处理 20%，说明阈值定得太保守，流程会变成瓶颈；如果能处理 95%，说明授权太松，管理层实际上失去了对范围的掌控。这个比例我建议每季度回看一次，根据实际数据调整。
五、具体案例与数据观察：一次真实的范围治理落地
这一节讲一个我深度参与的项目，涉及一家年营收 40 亿元左右的装备制造集团，IT 与研发人员合计 210 人，同时在建项目 14 个。这个规模足够大到暴露组织级问题，也足够小到能看到治理动作的直接反馈。
1. 治理前的状态
2023 年 3 月我进场时，他们的需求主要靠邮件和即时通讯工具流转。我随机抽取了一个已上线项目，要求负责人提供”哪些需求进入了本期范围”的清单，他花了 3 天时间拼凑出一份 187 条的列表，其中 46 条无法确认是否真的交付过。
更麻烦的是变更审批。他们名义上有变更流程，但审批表单只有一个字段：变更原因。没有工作量评估、没有工期影响、没有替代方案。审批人看到”客户紧急”四个字就点了同意。当年的变更批准率是 94%。
2. 治理动作的三个阶段
第一阶段用了 6 周，只做一件事：把所有在建项目的交付项编号入库，建立基线版本，并强制标注 out_of_scope。这个阶段最难的不是技术，是让业务方接受”不在清单里的需求默认不做”。
第二阶段用了 8 周，上线变更影响五维评分表和三级授权矩阵。为了让流程能跑起来，我把工具选型同步推进，最终选择在 PingCode 上落地。选择它的直接原因有三个：支持私有化部署，满足集团对代码和需求数据不出内网的硬性要求；原生支持从 Jira 平滑迁移，他们原有的 Jira 数据可以在不停工的情况下完成搬迁；以及作为国产替代方案，在采购合规和后续服务响应上更适配这类中大型组织的节奏。
第三阶段是持续运营。每两周做一次范围健康度复盘，每月做一次基线版本发布，每季度调整一次授权阈值。
3. 十八个月后的数据对比
我把治理前后的关键指标整理如下。需要说明的是，这组数据来自单个企业的内部统计口径，不能直接外推到其他组织，但变化的方向和幅度有参考价值。
4. 一个反面观察
同一时期，我也跟进过另一家规模相近的企业，他们在治理中走了一条更激进的路：把所有变更审批权收归到 CIO 办公室。结果是变更决策平均耗时从 7 天涨到 22 天，项目组为了不等审批，开始把需求拆成”优化项”绕过流程。半年后范围漂移率不降反升，从 31% 涨到 44%。
这个对比让我确认了一件事：范围治理的目标不是收紧审批，而是让决策发生在正确的层级。把小决策压到高层，只会催生更多规避行为。
六、不同情况下的行动建议
范围治理没有统一模板。下面按组织规模和合规要求分了四类情况，每类给出最小可行动作集。建议先做第一项，跑通后再加第二项。
1. 情况一：50 人以下团队，项目周期 3 个月以内
这个规模不适合上重流程。我的建议是只做两件事：一是用一页纸定义本期交付清单和明确不做的清单，双方签字；二是设置单一的变更入口，所有变更必须走同一个表单，哪怕内容只有三行。
这个规模的授权阈值可以放得很宽，项目经理可以直接批准影响分 8 分以下的变更，超过 8 分找业务负责人确认。关键不是审批层级，而是变更必须进入记录。
2. 情况二：50 到 200 人团队，多项目并行
这个规模的核心矛盾是资源冲突。建议引入五维影响评估和三级授权矩阵，同时开始建立跨项目的资源日历。这个阶段最容易出现的错误是各项目自建一套需求编号规则，导致跨项目统计无法进行。
我的建议是统一编号规则和字段定义，工具层面可以先用轻量方式承载，不必急着上重型平台。等变更月均超过 40 条、跨项目依赖超过 15 组时，再考虑工具升级。
3. 情况三：200 人以上组织，多产品线并行
这个规模必须做组织级治理。第一件事是建立范围管理委员会，成员至少包含业务负责人、技术负责人和财务代表。第二件事是把范围健康度纳入项目月报，与进度、成本同等级呈现。
工具层面，这类组织通常需要私有化部署、细粒度权限和与现有研发链路的深度集成。以 PingCode 为例，它面向的正是中大型企业及 100 人以上的组织，支持私有化部署，支持 Jira 平滑迁移，在国产替代场景下磨合成本相对可控，这类特性对受监管行业尤其重要。
4. 情况四：受监管行业，需要完整审计链路
金融、医疗、能源等行业，范围变更的记录本身就是合规资产。这类情况下要走最严格的路径：每一次变更保留提出人、评估人、批准人、生效版本和回滚方案，并且这些记录要能导出成审计可接受的格式。
我的建议是在项目启动时就明确审计要求，而不是等审计前补材料。补材料的成本通常是实时记录的三到五倍，而且真实性容易被质疑。
七、不同情况下的取舍：没有完美方案，只有代价选择
范围管理的所有决策本质上都是取舍。我在下面列了四组最常见的取舍，每组都说明我倾向的选择和理由，但请结合你的业务节奏判断，不要照搬。
1. 取舍一：交付速度 vs 范围稳定
如果业务窗口期短、竞争激烈，我倾向于牺牲部分范围稳定性，用更短的迭代周期换取更频繁的调整机会。具体做法是把大版本拆成 3 周到 4 周的小批次，每批次结束后重新确认范围。
反过来，如果是核心交易系统改造、监管报送系统建设，我强烈建议牺牲速度保稳定，把范围基线冻结期拉长到 8 周以上。在这类项目里，一次范围失控带来的合规代价，远超延期三个月的商业损失。
2. 取舍二：流程灵活 vs 可追溯性
流程越灵活，记录越难完整；记录越完整，团队越觉得繁琐。我的选择是分场景处理：影响工期 3 天以内的变更走简化记录，只记三要素（提什么、谁提的、什么时候生效）；影响超过 3 天的一律走完整评估。
这样做的结果是大约 70% 的变更能快速闭环，30% 的重变更保留了完整证据链。这个二八比例在实践中比较稳，不会让流程变成纯负担。
3. 取舍三：自研工具 vs 采购平台
除非你有 20 人以上的专职工具团队，否则自研范围管理工具几乎一定亏。我算过一笔账：一套支持变更评估、基线版本、权限分层的系统，自研初版需要 6 到 9 个月，之后每年维护投入约为初版成本的 30%。
采购平台的成本更可预测。真正需要重点评估的是三件事：数据能否私有化部署、能否与现有研发链路打通、迁移成本是否可控。迁移成本经常被低估，我见过迁移一个 5 年期的历史项目数据花了 4 个月的案例。
4. 取舍四：短期交付指标 vs 长期范围资产
这是最难的取舍。建立范围基线、维护 out_of_scope 清单、记录五维评估，这些动作在当期的交付指标上全是”负收益”，它们占用的时间不产出功能。
但我的观察是，坚持做满 12 个月的组织，第二年的返工工时平均下降 55% 以上，而放弃的组织会在第三年左右遇到系统重构的硬墙。这是一笔明显的前期投入、后期回本的账。
八、下一步怎么做：一份可以本周启动的清单
如果你读到这里，说明你已经意识到范围管理需要系统化处理。下面这份清单我按”本周可完成”的标准设计，不需要任何采购和立项流程。
1. 本周做的三件事
- 挑一个在建项目，让负责人列出当前所有已交付和待交付的功能项，标出哪些有基线依据、哪些没有，算一次范围基线覆盖率。
- 统计过去三个月的变更记录，算一下变更批准率。如果高于 90%，直接去抽查 10 条被批准的变更，看有多少条包含工作量评估。
- 为当前项目写一份
out_of_scope清单，哪怕只写 5 条，也要让业务方确认签字。
2. 本月做的三件事
- 上线五维影响评估表，先在一个项目试点，跑满 20 条变更后回看评分分布是否合理。
- 建立三级授权矩阵，明确哪些分数段由谁批准，并公示给所有相关部门。
- 把范围漂移率纳入项目周报，作为和进度、成本并列的一级指标。
3. 本季度做的三件事
- 完成跨项目的编号规则和字段统一，为后续横向统计打基础。
- 评估工具承载能力，重点看私有化部署、迁移路径和与现有研发链路的集成深度。
- 做一次范围治理复盘，对比治理前后的返工工时和按期交付率，用数据决定下季度的投入强度。
最后说一个我在多次治理中反复验证的判断：范围管理的收益不是体现在某个项目上，而是体现在第二年的整体研发效率上。第一年你几乎看不到明显改善，甚至会因为流程增加而感到变慢。但只要能坚持到第二年，返工率和交付确定性会出现结构性变化。
如果你只能记住一句话，我希望是这句：项目范围的本质不是一份文档，而是一套让”说不”变得低成本的组织机制。文档谁都能写，机制才决定项目能不能活过第二年。
常见问题解答（FAQ）
1. 项目启动时，管理者怎么把范围边界定清楚，避免后面扯皮？
我带团队做项目时经常遇到立项时大家口头说“先做核心功能”，但到了开发阶段各部门不断加需求，最后工期和预算都失控。作为管理者，我不想一上来就陷进细节，但又怕范围没锁死，后面没人认账。到底启动阶段要锁定哪些内容才算够？
启动阶段至少锁三样：交付物清单、验收标准、不做清单。做法是把项目拆到可验收的交付物层级，每个交付物写清输出物、负责人、验收人、验收口径；同时单列“明确不做”列表，例如不覆盖哪些部门、哪些终端、哪些数据源。判断依据：如果一项需求无法对应到已确认交付物或验收标准，就不能直接进排期，必须先走变更评估。
数据口径上，启动基线里交付物数量、验收指标、排除项数量要写进项目章程或范围说明书，后续所有排期和预算都以这份基线做对照。不要只写“完成系统上线”这种模糊目标。
2. 范围变更频繁，管理者该不该全部拦？怎么判断哪些必须接？
我遇到过业务方今天加一个报表、明天改一个流程，项目经理说这是小变更不用走流程，结果三个月后范围膨胀了一倍。可如果全部拒绝，又怕影响业务价值，被说成不支持一线。管理者到底该怎么建立变更判断标准？
不能一刀切拦，也不能让口头变更直接进排期。先设变更门槛：任何影响交付物清单、验收标准、关键里程碑、预算或跨部门协作的需求，都必须书面提交变更申请，写清业务理由、不做的后果、工作量估算、对工期和成本的影响。判断接不接，看三点：是否直接支撑项目原定目标；是否能用现有预算和资源吸收；
如果必须接，是否愿意同步砍掉或延后同等工作量的原范围。数据口径建议跟踪变更率=已批准变更工作量/原基线总工作量，超过10%要升级到项目 steering 层复核，超过20%应考虑重新立项或重排优先级。小变更也要进日志，避免积少成多。
3. 怎么提前发现项目范围正在失控？有哪些预警信号和指标？
我平时不看代码也不盯每日站会，等到发现延期时，往往已经被业务方追着问了。项目经理汇报时总说“整体可控”，但我心里没底。有没有一些不需要技术背景也能看懂的早期信号，能让我判断范围是不是已经跑偏？
看四个信号：第一，需求池持续净增长，每周新增需求数大于关闭需求数，连续两周就要警惕；第二，原定里程碑完成率下降，但团队人数或加班时长上升，说明范围在吃资源；第三，会议里频繁出现“顺便再加一个”“这个很简单”的小需求，且没有记录；第四，验收标准被反复修改，尤其是已经进入开发后的修改。
做法上，让项目经理每周给你一页范围健康度：基线交付物完成数、变更申请数、已批准变更数、未批准但已占用工时数、里程碑偏差天数。判断口径：未批准需求占用工时超过团队周产能5%，就必须停下来做范围复盘，而不是继续赶工。管理者不需要懂技术，但要看趋势和对照基线。
4. 跨部门项目范围怎么划分，才能避免互相推诿和背锅？
我们公司做跨部门项目时，最头疼的是接口和边界。业务说这是IT的事，IT说流程没定清楚，最后项目延期却算在项目经理头上。我作为管理者，怎么在范围里把各部门责任切干净，又不至于让大家觉得太斤斤计较？
用“交付物+接口+责任矩阵”来切，而不是用部门名称切。先把跨部门项目拆成端到端流程，标出每个环节的输入、输出、接口人和验收人；再用 RACI 明确谁负责、谁批准、谁咨询、谁知会，尤其把“谁提供数据、谁做最终验收、谁处理异常”写到范围说明书里。
判断依据：如果某个环节的输入输出无法对应到唯一责任人，就是范围漏洞，必须在启动或变更评审时补上。数据口径上，跨部门接口数量、每个接口的交付时间、验收通过率要作为范围基线的一部分；接口逾期超过3个工作日或验收一次通过率低于80%，就要升级协调，而不是等到项目末期再算总账。
别怕前期显得细，前期细是为了后期不背锅。
文章包含AI辅助创作：项目范围Scope教程：企业管理者风险控制，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/322485
读者评论
我们公司去年上了一个项目管理平台，但变更审批还是走邮件，结果系统里查不到任何变更记录。文章说工具放大规则而非创造规则，这点我认同。但实际操作中，如果管理层不先拍板流程，工具上线就是摆设。我们那个平台现在只用来填工时。
关于事后补录变更估算偏差高出62%这个数据，我挺好奇样本量。我们团队做过类似复盘，偏差确实存在，但没这么夸张。另外，文中把范围失控85%归因于管理层，会不会忽略了组织政治因素？有些'不'不是没人敢说，是说了会被换掉。
那组范围增幅与缺陷密度的拐点数据挺有参考价值。我们项目去年范围涨了约25%，交付周期拉长了近一半，当时以为是估算不准，现在看来是超线性增长规律。不过单项目11个月采样还是偏少，希望作者能补充更多项目的复现情况。