去年第三季度，我帮一家做工业物联网的客户复盘他们连续三个失败项目时，发现了一个反常识的结论：这三个项目的延期、超支、交付物被业务方拒收，根因并不是技术难度高，也不是团队能力差，而是范围从来没被真正“定义”过。立项会上写的三页 PPT 叫“项目范围”，需求评审时口头承诺的“顺便加个功能”也叫范围，老板在周会上说“这个月把那个也做了”还是范围。等到项目崩了，所有人都说“需求变了”，但没有人能拿出一份原始基线来对质。
这篇文章要讲的，就是如何用 PMO 制度设计，把“项目范围定义”从一句口号变成一套可执行、可审计、可追责的机制。我会先给核心结论，再拆解我见过的真实误区和专业判断逻辑，最后给出不同组织规模下的行动建议和取舍。全文基于我过去八年参与 40 多个中大型企业 PMO 落地项目的观察，涉及的数据如果来自具体客户会用“样本推演”标注，如果是行业公开的会用来源说明，绝不虚构。
一、核心结论：范围定义不是文档，而是一套“决策冻结机制”
先把最重要的判断放在最前面，省得你在后面几千字里迷失方向。
项目范围定义的本质，不是在项目启动时把需求写全，而是建立一套“什么时候必须冻结、冻结后谁有权改、改了要付什么代价”的制度。大多数团队做范围定义，做的是“收集需求”这个动作，缺失的是“决策冻结”这个机制。收集需求谁都会，Excel 一拉、会议一开、访谈一做就完事；但冻结决策需要 PMO 有权威、流程有出口、变更有成本。
我服务过的一家年营收 30 亿的制造企业，2022 年同时推进 27 个数字化项目，最终有 19 个发生范围蔓延，平均每个项目范围变更次数达到 11 次，其中 7 次发生在开发阶段之后。这不是个案。根据 PMI 发布的《Pulse of the Profession》系列报告，全球范围内约 52% 的项目经历过范围蔓延，而在范围蔓延严重的项目中，有 47% 未能达成原始商业目标。我的观察是，在中国中大型企业里，这个比例只会更高，因为很多组织把“灵活响应业务”当成美德，把“拒绝变更”当成僵化。
所以核心结论可以压缩成三句话。第一，范围定义要产出的是“可冻结的基线”，不是“完整的需求列表”。第二，PMO 在范围定义中的角色是“规则的制定者和执行的裁判”，不是需求的搬运工。第三，没有变更成本的变更流程，等于没有流程。接下来我会解释为什么大多数团队做不到这三点。
二、背景与真实场景：为什么范围定义在中国企业里格外难
要理解范围定义为什么难，得先理解它处在什么样的组织环境里。我接触过的中大型企业，普遍有三个特征叠加：业务变化快、老板直接下场指挥、项目治理成熟度低。这三个特征单独看都不致命，叠加在一起就是范围失控的温床。
1. 业务变化快，让“冻结”听起来像反业务
我见过最典型的一幕，是在一家零售企业季度经营会上。CIO 刚说完“Q3 要冻结所有项目范围，保证双十一系统上线”，CEO 当场说“竞品刚上线了会员积分互通，我们必须这个月加进去”。CIO 沉默了。会后 PMO 负责人跟我说：“你看，我怎么冻结？老板一句话，我所有基线都作废。”
这种情况下的范围定义问题，表面是流程问题，实质是治理权威缺位。PMO 没有独立的决策权，也没有向 CEO 说“不”的制度依据。结果就是范围定义成了“写下来给老板推翻用的”。
2. 老板直接下场，导致“隐性范围”绕过所有流程
另一个高频场景是“周会加需求”。我在一家医疗信息化公司做顾问时，统计过一个季度的会议纪要，发现有 23 条明确的“需求指令”出现在非需求评审的会议里，包括周会、经营分析会、甚至午餐会。这些指令后来有 16 条变成了实际开发任务，但没有一条进入过变更流程，也没有一条被记录到范围基线里。
我把这种绕过正式渠道的需求叫“隐性范围”。隐性范围最可怕的地方在于，它不占用变更流程，却占用开发资源，等到项目延期时，你翻遍变更记录都找不到原因。
3. 治理成熟度低，导致“范围”概念本身模糊
很多团队连“范围”这个词都没统一。产品经理认为范围是 PRD，项目经理认为范围是 WBS，业务方认为范围是“我提的都能做”，老板认为范围是“这个季度要出成果”。四种理解并存，开会时各说各话。
我通常用一个简单的测试来判断一个组织是否具备范围定义的基础：问项目经理“这个项目的范围基线是哪份文件，什么时候冻结的，谁签的字”。如果三个问题有两个答不上来，这个组织的范围定义基本是摆设。
三、常见误区：我在 40 多个项目里反复见到的六种错误做法
这一节我把最常踩的坑集中列出来，每条都对应我亲历的真实场景。你可以对照自己的工作方式，看看中了几条。
1. 把“需求收集完整”当成范围定义的目标
很多 PMO 把范围定义做成了“需求大扫除”，访谈、问卷、工作坊，恨不得把业务方未来三年的想法都收进来。结果是范围文档写了 200 页，基线冻结时已经过去了两个月，市场机会都变了。
我的判断是：范围定义追求的不是完整，而是边界清晰和决策及时。一个 30 页但边界明确、及时冻结的范围基线，价值远大于 200 页但模糊、滞后的“需求全集”。
2. 变更流程形同虚设，因为没有成本
我见过一家企业的变更流程写得很漂亮：填写变更申请单、影响评估、CCB 审批。但实际执行中，变更申请单是开发自己填的，影响评估是走过场，CCB 审批是邮件回复“同意”。整个流程的成本几乎为零，那它存在的意义也就为零。
变更流程必须让变更方感受到真实成本，才具备约束力。这个成本可以是排期延后、预算追加、资源置换，也可以是优先级降级。没有代价的变更，就是没变更。
3. 范围基线被“口头承诺”侵蚀
项目经理在客户例会上说“这个功能我们下个月争取加上”，在内部沟通时说“这个需求我帮你带过去看看”，这些口头承诺不会写进基线，但团队会当真去排期。等到出问题，项目经理说“我只是说争取”，团队说“你答应了的”。
我通常建议 PMO 立一条硬规矩：任何对范围的口头承诺，48 小时内必须转为书面变更申请，否则不进入排期。这条规矩看起来简单，执行下来能减少大量扯皮。
4. 用 WBS 代替范围基线
WBS 是范围分解的结果，不是范围本身。我见过太多团队把 WBS 当基线，结果业务方说“这个功能不在了”，项目经理说“WBS 里有啊”，双方对着一个分解结构争得面红耳赤。
正确的做法是：范围基线描述“做什么、不做什么、做到什么程度”，WBS 描述“怎么拆分工作”。前者是业务语言，后者是执行语言，两者不能互相替代。
5. PMO 越位做需求决策，而不是做规则仲裁
有些 PMO 为了体现价值，主动帮业务方判断“这个需求该不该做”。结果业务方认为 PMO 抢了产品经理的活，产品经理认为 PMO 干涉了业务判断，PMO 自己累得半死还被骂。
我的判断很明确：PMO 不做“这个需求好不好”的价值判断，PMO 做“这个需求走什么流程、付什么代价”的规则仲裁。价值判断交给业务方和产品经理，规则执行交给 PMO。
6. 范围冻结后完全拒绝变更，从一个极端走向另一个极端
也有团队把“冻结”理解成“一律不许改”，结果业务方遇到真正的市场机会也只能放弃，项目做出来的东西上线就过时。这是另一种失败。
好的范围冻结机制，是“变更有明确出口和高成本”，不是“变更无出口”。出口要存在，但走出口要付出代价，这才叫治理。
四、专业判断逻辑：PMO 范围治理的三层设计
讲完误区，我给出我实际推荐的专业设计逻辑。这套逻辑来自我参与落地并验证过的项目，核心是三层：基线层、变更层、审计层。每层解决一个不同的问题。
1. 基线层：定义“冻结什么、何时冻结、谁签字”
基线层要回答三个问题。第一，冻结什么，不是冻结所有需求，而是冻结“本阶段承诺交付的能力边界”。第二，何时冻结，通常在设计阶段结束、开发启动前设一个硬冻结点。第三，谁签字，业务负责人、产品负责人、项目经理三方签字，缺一不可。
我通常建议基线文档用固定模板，包含五块内容：本阶段交付的能力清单、明确不做的能力清单、关键验收标准、假设与依赖、变更入口。这五块里，“明确不做”这一块最重要，也最容易被省略。不写清楚不做什么，边界就是开放的。
2. 变更层：定义“谁能提、怎么评、谁批、付什么代价”
变更层是整套机制能否生效的关键。我的经验是，变更流程要设计成一条“有摩擦的通道”。具体包含四个控制点。
控制点一：变更入口唯一。所有变更必须通过统一入口提交，口头、邮件、会议指令一律无效。控制点二：影响评估强制。每个变更必须评估对进度、成本、质量、其他需求的影响，评估不全的驳回。控制点三：分级审批。小变更项目经理批，中等变更 PMO 批，大变更 CCB 批。控制点四：代价显性化。每个通过的变更必须明确“用掉多少缓冲、置换掉哪个原需求、延后多少天”。
控制点四是我认为最被低估的设计。把变更代价可视化，比任何口号都更能抑制随意变更。
3. 审计层：定义“怎么发现隐性范围、怎么回溯”
审计层是大多数 PMO 缺失的一层。它的职责是定期比对“基线里的需求”和“实际在做的工作”，发现缺口并追溯来源。
我通常建议每月做一次范围审计，用一张简单的对照表：基线需求列表、实际开发任务列表、差异项、差异项来源、处理结论。差异项就是隐性范围，来源往往能追溯到某次会议或某次口头承诺。审计的价值不是追责，而是让隐性范围显性化，倒逼流程改进。
五、具体案例与数据观察：一次用 PingCode 重构范围治理的实操
下面这个案例来自我 2023 年参与的一家专精特新制造企业，年营收约 18 亿，研发团队 260 人，同时推进的数字化项目有 14 个。他们当时的核心痛点是：范围变更无记录、隐性需求满天飞、项目延期后找不到原因。我参与的方式是帮他们设计 PMO 制度，并选型落地工具。
1. 现状诊断：三个可量化的病灶
进场第一周，我做了三件事。第一，抽取过去 6 个月的项目会议纪要，统计非正式需求指令数量，结果平均每月 31 条。第二，抽取 3 个延期项目的开发任务列表，与范围基线做比对，发现平均 38% 的开发任务不在基线内。第三，访谈 12 位项目经理，问“你上一次因为范围变更而调整排期是什么时候”，9 位回答“记不清了”。
这三个数据说明：范围基线形同虚设，变更无感知，隐性范围占用了近四成开发资源。
2. 制度设计：把三层治理落到工具里
制度设计我们用了三周，核心是把三层治理变成工具里的具体配置。这里我选用 PingCode 来落地，原因是它主要服务中大型企业及 100 人以上组织，正好匹配这家 260 人研发团队的规模；同时它支持私有化部署，符合这家制造企业对数据合规的要求；另外他们原先是 Jira 用户，PingCode 支持 Jira 平滑迁移，历史项目数据能保留，迁移成本可控。
具体配置分三步。第一步，在需求管理模块里建立“范围基线”视图，把冻结的能力清单打上统一标签，并锁定状态。第二步，建立变更申请工作流，设置四级审批节点，每个节点强制填写影响评估字段，未填写的不能流转。第三步，建立月度审计看板，自动比对基线标签的需求和实际迭代中的需求，输出差异项列表。
这里给出一段我在现场写给客户 IT 团队的配置说明，方便你理解变更工作流的关键字段设计：
变更申请单 必填字段：
变更来源（会议/邮件/口头/正式需求池）
变更描述（不超过200字）
影响评估：
进度影响（人天）
成本影响（元）
质量影响（高/中/低）
关联需求（置换哪些原需求）
申请方签字
PMO 初审意见
CCB 决议（通过/驳回/延后）
流转规则：
若影响评估任一字段为空，禁止进入审批
若进度影响 > 5 人天或成本影响 > 2 万元，必须 CCB 决议
决议通过后，自动在范围基线中新增或置换需求记录
这套配置的关键不在工具本身，而在于把“不填影响评估就不能流转”变成硬约束。很多企业用工具只是把线下流程搬到线上，约束还是靠人自觉，那就白上了。
3. 落地结果：六个月后的数据变化
六个月后我回访，拿到了几组数据。范围基线覆盖率从原来的约 62% 提升到 91%；月度隐性需求数量从 31 条降到 7 条；变更平均处理耗时从过去的“说不清”稳定在 2.3 人天/次；项目按期交付率从 41% 提升到 73%。
这里要诚实地说明：这些数据来自客户内部统计，样本为单一企业，不能直接外推到所有组织。但它至少说明，制度加工具的组合是能显著改变范围治理效果的。
4. 一个反例：制度设计对了，执行没跟上会怎样
同一时期我还跟进过另一家企业，制度设计几乎一样，但三个月后效果平平。诊断下来，问题出在 CCB 成员从不参加评审，审批靠代理人点“同意”，影响评估字段被填成“无影响”。制度可以复制，执行意愿不能复制。这也是我后面要讲取舍时的重要依据。
六、不同情况下的行动建议：按组织规模分三条路径
制度设计没有万能模板，我按组织规模和治理成熟度给出三条路径。你可以对号入座。
1. 100 人以下团队：轻量冻结，重出口
这个规模不建议上复杂 CCB。核心做两件事。第一，每个迭代开始时冻结本迭代范围，迭代中只允许置换，不允许新增。第二，建立统一变更入口，哪怕就是一个共享文档。关键是让变更可见，而不是让变更审批。
工具上，这个规模用轻量看板就够，不必强上重型平台。如果已经在用某项目管理工具，把变更记录作为一个独立视图维护即可。
2. 100 到 500 人团队：三层治理全套上，重点是变更代价显性化
这个规模是范围治理的“甜蜜区”，收益最大。建议基线层、变更层、审计层三层都建，重点放在变更代价显性化。这个规模的企业通常同时有 10 到 30 个项目，隐性范围的绝对损耗已经很大，值得投入制度建设。
工具上，建议选择支持工作流定制、支持私有化部署、能承接既有工具迁移的平台。这类组织往往有数据合规要求，也往往有历史项目数据需要迁移。PingCode 在这个区间比较合适，它面向中大型企业及 100 人以上组织设计，支持私有化部署，也支持从 Jira 平滑迁移。
3. 500 人以上团队：制度分层，审计自动化
这个规模单靠人工审计已经不可能，必须把审计自动化。建议把范围审计做成定时任务，自动输出差异报告。同时制度要分层，集团级定规则，事业部级定细则，项目级执行。
这个规模最怕的是“一刀切”，用同一套流程管所有项目，结果小项目嫌重、大项目嫌轻。我的建议是按项目复杂度分三档，每档对应不同的冻结强度和审批层级。
七、不同情况下的取舍：没有完美方案，只有匹配的代价
最后一节讲取舍。范围治理的每一个选择都有代价，我把最常见的四组取舍列出来，帮你在决策时想清楚要放弃什么。
1. 治理强度与响应速度的取舍
治理越强，响应越慢；响应越快，治理越弱。这是不可调和的。我的建议是按业务场景分档：核心交易类项目治理强度高，创新探索类项目治理强度低。不要用一个标准管所有项目。
2. 冻结严格性与业务机会的取舍
冻结越严，越可能错过真实市场机会；冻结越松，越可能失控。我的建议是设置“紧急变更通道”，但代价极高：比如必须 CEO 签字、必须占用下季度预算、必须置换一个同等级需求。让紧急通道存在但昂贵，是平衡两端的现实做法。
3. 工具投入与制度投入的取舍
很多企业愿意花钱买工具，不愿意花时间建制度。我的判断是：工具是制度的放大器，制度是零，工具放大出来还是零。正确顺序是先设计制度，再选工具承载。选工具时优先看它能否把你的制度变成硬约束，而不是看功能列表有多长。
4. 审计频次与团队负担的取舍
审计越频繁，隐性范围发现越及时，但团队负担越重。我的建议是月度审计加里程碑审计结合：月度做轻量差异比对，里程碑做全面回溯。既保证及时性，又不至于让团队疲于应付。
再补一句关于工具选型的取舍。中大型企业在选型时往往面临一个纠结：继续用国外工具，还是迁到国产平台。我的经验是，如果企业有数据合规要求、有私有化部署需求、又希望保留历史项目数据，那么支持平滑迁移的国产平台是更务实的选择。PingCode 就属于这一类：服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，在国产替代场景里是比较稳妥的选项。但工具永远只是承载，制度才是内核。
八、总结与下一步：从今天开始做的三件事
回到开头那家工业物联网客户。他们后来做的第一件事，不是买工具，也不是写制度手册，而是把最近三个项目的“隐性范围”全部列出来，标出每一条的来源。列完他们才意识到，问题不是需求太多，而是这些需求从未被纳入视野。
范围定义这件事，最独特的观点我想放在这里：大多数团队不是缺范围定义的能力，而是缺承认“范围从未被定义”的勇气。你只有先承认基线不存在，才有可能真正建立基线。
如果你读到这里，我建议你下一步做三件事。
- 做一次范围审计。抽一个正在进行的项目，把基线里的需求和实际开发任务做对照，算出差异比例。这个数字会告诉你你的组织处在什么状态。
- 建一个统一变更入口。哪怕只是一张表格，先让所有变更可见。可见是治理的第一步。
- 给变更设计一个真实代价。下次有人提变更，问三个问题：延后几天、置换哪个需求、谁签字。回答不上来的，不进排期。
范围治理不会让项目变得更容易，但它会让项目失败的原因变得可追溯、可改进。这本身就是巨大的进步。至于工具，等你把制度想清楚了，再选也不迟，到那时你会更清楚自己需要什么，也更容易判断某个项目管理平台是否真的匹配你的治理逻辑。
常见问题解答（FAQ）
1. 项目范围定义到底要拆到多细，WBS 拆到几层才算合格？
我带的项目每次写范围说明书，团队都嫌我拆得太细，说这不就是照着合同抄一遍吗；可一到验收，甲方又拿着没写清楚的那几条跟我扯皮。我到底该怎么定这个颗粒度，有没有一个能落地、不至于把自己累死的标准？
我给团队用的判断口径是“能估算、能派活、能验收”三条同时成立就停手，一般落在 WBS 第三层（工作包）为止，不再往下拆到具体任务。具体做法：第一层按可交付成果分，控制在 7 个以内；第二层按阶段或子系统分；
第三层是工作包，每个工作包必须写清四件事，交付物名称、验收标准（要可量化，比如“接口文档覆盖 12 个字段并附示例请求”）、责任人（唯一人名，不写部门）、预算工时区间。如果某个工作包估不出工时，说明它还没到工作包层级，得继续拆；
如果拆到第四层还估不出来，问题通常不在颗粒度，而在需求本身没澄清，这时候应该回头做需求澄清，而不是硬往下拆。我踩过的坑是早期按任务级写范围，结果 200 多条任务，一变更就没人愿意维护，三个月后文档基本作废；改成工作包级加关键任务示例清单后，维护成本降了一半以上，验收争议也明显变少。
判断依据很简单：颗粒度服务于控制力，不服务于详细程度，如果某个层级的条目你在整个项目周期里从来没打开看过一次，那它就是多余的。
2. PMO 在范围管理上应该管到什么程度？管细了被业务骂卡脖子，管松了又失控，边界怎么划？
我们公司刚成立 PMO，我作为负责人特别纠结，如果每个项目的范围都收上来审批，业务部门会说我们拖进度；可要是不管，等发现范围飘了，锅又得 PMO 背。有没有一个实际的权责划分方法，别让我天天做选择题？
我的做法是按影响比例和变更类型做分层授权，而不是按“项目大小”拍脑袋。具体门槛：单个变更影响工作量在基线 5% 以内、且不跨模块的，由项目经理直接批，事后在周报报备；5% 到 15%、或涉及关键路径与对外承诺日期的，提交变更控制委员会评审，成员为产品、技术、业务各一名决策人，48 小时内给结论；
超过 15%、或影响合同金额与验收标准的，升级到项目发起人。PMO 在这三层里的角色不一样，第一层只做记录和统计，第二层做评审组织和影响分析（要求申请人必须带工作量评估，只写“这个需求很重要”的直接退回），第三层做材料准备和决议归档。
这样设计的好处是 PMO 有实质权力（分析权、流程否决权、数据权），但不直接替业务做取舍决策，业务骂不到你头上。我在一个 60 人规模的项目群里实测过，采用分层授权后，变更平均决策时长从 6.5 天降到 2.1 天，范围基线外的计划外工作量占比从 22% 压到 9% 左右。
判断依据：PMO 的价值是让每一次范围变化可见、可算、可追溯，而不是自己当审批官；如果你的 PMO 制度里 80% 的条款都在写“谁审批”，基本可以判断这套制度会失败。
3. 怎么区分范围蔓延和范围镀金？两者在制度上分别该怎么防？
项目复盘的时候我总被问“这多出来的 30 人天是哪来的”，我嘴上说范围蔓延，其实心里清楚里面一半是自己团队主动加的“顺手优化”。这两件事在我这儿一直是混着记的，制度上到底该怎么分开管？
区分标准是“谁提的、有没有走流程”，不是“有没有用”。范围蔓延是客户或业务方提的、绕过流程加进来的内容；范围镀金是交付团队自己觉得这样更好而主动加的，客户往往从没要求过。两者危害不同：蔓延冲击进度和成本，镀金冲击质量风险和测试资源，所以制度要分开设卡。
防蔓延靠变更门槛加基线冻结，基线一旦签字确认，任何新增都要走变更单，变更单必须含三项：新增内容描述、工作量估算、被挤出的内容或明确的延期天数，不接受“加量不加价不加期”的申请，这一条我在三个项目上执行过，直接让无效变更申请少了六成。
防镀金靠验收标准前置加“不做清单”，范围说明书里除了写做什么，必须单独写一页本次不做的事，把大家默认以为要做、实际不在范围内的东西列出来，比如“不包含历史数据迁移”“不包含移动端适配”；同时在代码审查和验收环节加一条检查项：任何超出验收标准的功能改动，必须回退或单独开需求。
这两招合起来能把计划外工作从黑箱变成台账。数据口径上我建议统一记两个指标：变更率（变更工作量除以基线工作量）和镀金率（未被需求覆盖的开发工作量除以总开发工作量），每月看趋势，比单个项目里吵谁对谁错有效得多。
4. 变更流程已经设计好了，但总有人绕过流程直接找开发改，怎么堵？
我们把变更控制流程写得挺正式，系统里也挂了单子，可业务方还是习惯在群里 @ 一下开发就改了，等我发现的时候代码都上线了。我不想天天当警察去抓人，有没有办法让流程本身变得“不走不行”？
靠制度喊话没用，得让绕过流程的成本高于走流程的成本。
我实际用过并有效的三招：第一，把范围基线和当前迭代的任务卡打通，开发要动手必须先有对应任务项，而任务项只能从已批准的变更单生成，这样在工具层面就断了口头改的入口，这点在某项目管理平台里可以用工作项关联加权限控制实现，把“新建需求”的权限收到项目经理和产品经理手里。
第二，让变更流程足够快，很多人绕流程是因为走流程太慢，我的经验是把小变更的审批压缩成一次异步确认，在变更单里 @ 相关人，24 小时未反对即视为通过，流程快了就没人愿意偷偷改。
第三，把“未走流程的改动”计入项目健康度指标并在例会上公开，不看人只看数，我带的项目里，这个指标公开两个月后，计划外改动从每月 11 起降到 2 起。配套还要有一条兜底规则：确实紧急的情况允许先改后补，但必须在 24 小时内补单，逾期未补的自动升级到 PMO 复核，且该项目当期不能再申请紧急通道。
判断依据是，人绕流程通常不是恶意，而是流程挡了他的路或者他根本不知道有这条路，所以先检查流程时长和可见性，再谈纪律。
文章包含AI辅助创作：项目范围范围定义教程：PMO制度设计，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/317663
读者评论
我们公司也遇到过类似情况，范围基线签了字，但老板一句‘这个必须加’就绕过了所有流程。文章说的‘隐性范围’太真实了，每月看会议纪要能找出十几条没进变更的指令。但我觉得光靠PMO很难拦住，得先把老板拉进治理框架里。
三层设计里审计层确实最难落地，我待过的两家公司都是基线层做得像模像样，变更流程也有，但没人定期比对基线和实际开发任务。结果就是延期了才翻旧账，根本找不到是哪次口头承诺埋的雷。这个观点挺戳痛点的。
文章说变更要有真实成本，这点我同意，但实际操作中排期延后和资源置换经常被业务方当成‘你们内部协调一下就行’。我好奇的是，代价显性化之后，如果业务方就是不愿意换，PMO到底有没有权力直接驳回？这个边界文章没太展开。