去年冬天，我在一家做智能硬件的客户现场参加项目复盘会。实施团队交付了 11 个月，合同签的是 6 个月,人力投入从预估的 380 人天涨到 620 人天，超支 63%。复盘时把需求确认单翻出来才发现，整个项目里正式走变更流程的需求只有 7 条，但实际做进去的”顺带支持”有 34 条。这 34 条没有一条有书面确认，全部来自会议纪要里的”顺便看一下”、微信群里的”这个能不能加一下”、以及客户方业务主管在演示会上临时提的”我觉得再加个字段会更好用”。
项目最后不是死在技术上，是死在范围边界上。这篇文章我想把这套边界管理的方法论完整拆开，包括我自己踩过的坑、验证过的流程、以及在 PingCode 这类平台上怎么把它落到可执行的动作。
一、先说核心结论：范围边界管理的本质是”让变更成本可见”
很多人把范围边界管理理解成”写需求文档”或者”签确认单”，这是把手段当成了目的。我做实施交付和项目管理咨询八年多，服务过制造业、金融、医疗、政企的几十个中大型项目，最核心的一条判断是：范围边界管理不是控制变更，而是让每一次变更的成本变得可见、可比较、可决策。
为什么这么说？因为没有任何一个实施项目能做到零变更。客户在需求调研阶段不可能想清楚所有事，业务部门的真实诉求往往要在看到第一个可用版本之后才会浮现。你越是试图用一纸合同把范围锁死，后面爆发的妥协式变更就越猛烈。
所以真正有效的边界管理，追求的不是”不变”，而是”每次变之前，所有人都知道这次变要付出什么代价”。这个代价可以是工期天数、可以是人天成本、可以是砍掉另一个需求的取舍，但一定要被看见。
1. 范围边界的三个判断基准
基于我自己的项目数据，我总结出三条判断基准，后面所有方法都是围绕这三条展开的。
- 边界写的是”不做什么”，而不仅是”做什么”。只写做什么的需求文档，等于给所有人留下了无限解释空间。真正拦住扯皮的是排除项清单。
- 边界要在报价之前确定，不是在调研之中确定。很多团队签合同时只写了一个功能模块清单，等到进场调研才发现工作量是报价时的两倍。边界前置是盈利的前提。
- 每一次变更都必须携带一个价格标签。没有价格标签的变更等于免费加班，会持续到团队崩掉为止。
2. 一个反常识的数据：变更数量与项目成败不是负相关
这是我最想打破的一个认知。我统计过自己经手的 42 个中大型实施项目，把正式变更数量（走完流程、有签字或系统记录的变更）和项目毛利率、客户续约率做了交叉分析，结果是这样的：
数据摆在这里，结论很清楚：变更数量在 20 条左右的规范项目，毛利率反而稳定在 30% 上下，客户满意度也是最高的。真正拖垮项目的是那类变更 40 条以上、其中超过一半没有走流程的项目。
这背后的逻辑不复杂。规范变更意味着每一次加需求都对应了排期调整和费用协商，客户知道自己的每一次开口都有代价，因此会主动收敛；而免费变更意味着客户零成本开口，需求会像滚雪球一样膨胀，直到团队扛不住。
二、背景与真实场景：范围是怎么一点点失控的
想解决问题，先要看清失控的路径。我发现范围失控几乎从来不是一次性发生的，而是在几个特定的时间窗口里被反复撕开的。
1. 失控通常发生在三个时间点
第一个时间点是需求调研末期。调研做了三四周，客户方业务人员已经把能说的都说了，但还有一部分隐性需求他们自己也说不清。这时候团队为了尽快进入开发，会把调研文档打包签字，把这些模糊地带全部”留待后续明确”。这些后续，就是未来变更的来源。
第二个时间点是首次演示。第一版可运行的系统摆出来，客户的想象力突然被激活，从”我原来想要一个报表”变成”既然数据都在了，能不能顺手做个看板、做个预警、做个移动端审批”。这是变更爆发最集中的窗口。
第三个时间点是 UAT 验收前两周。业务部门在正式使用中发现流程跟实际不符，要求调整审批链、调整字段权限、调整报表口径。这时候距离交付节点已经很近，团队往往选择加班硬扛而不是走变更流程。
2. 一个真实的失控时间线
我把它记下来，是因为这个项目太典型了。客户是一家年营收 20 亿左右的制造企业，我们做的是生产协同平台。合同签订时功能清单 47 项，工期 5 个月。
第 1 个月调研结束，需求文档增加到 68 项，团队判断通过加班可以消化，没有走变更流程。第 2 个月首次演示，客户追加了 12 项，团队用”反正是小功能”的心态接了下来。第 3 个月,客户方换了一位分管副总，新领导对系统有完全不同的预期，提出重构审批模型，这次变动涉及 3 个核心模块。
到第 5 个月原定交付期，实际完成度 62%，团队连续加班 6 周，两位核心成员离职。最终项目延期到第 8 个月交付，毛利率从预估的 34% 跌到 6%。复盘时最扎心的一句话是团队负责人说的：”我们从来不知道这个项目做到哪算完。”
3. 为什么”客户满意度”和”范围控制”看起来总是对立
很多实施经理心里有个潜台词：管得严客户会不高兴，客户不高兴以后就没单了。这个担心是真实的，但它建立在一个错误前提上，把”范围控制”等同于”拒绝需求”。
我观察到的真实情况是：客户对实施团队最大的不满从来不是”你拒绝了我的需求”，而是”你答应了却没做到”和”你不知道什么时候能做完”。前者制造失望，后者制造失控感。一家能清晰告诉客户”这个需求可以做，需要增加 8 人天和 2 周工期，你确认一下优先级”的团队，客户的信任度会显著高于一家说”没问题我们加班给你做”的团队。
三、拆解常见误区：为什么大多数团队的方法失效
方法失效往往不是因为不够努力，而是因为方向错了。我梳理出四个最普遍、也最致命的误区。
1. 误区一：把需求文档当作范围边界
需求文档描述的是”系统应该长什么样”，范围边界描述的是”这次交付的边界在哪里”。这两个东西经常被混为一谈，但作用完全不同。
需求文档写得再详细，它本质上是一份功能的正面描述。凡是没写进去的，都可以被解释成”隐含需求”、”行业惯例”、”正常的系统都应该有”。而范围边界是反向定义的：明确列出这次不做的内容、不在范围内的模块、不支持的场景。
我给客户的合同附件里，除了功能清单，一定会有一页叫《本期明确不包含事项》，列 15 到 25 条。这一页在后期的扯皮中价值极高，因为它把”我以为”变成了”白纸黑字”。
2. 误区二：变更审批靠项目经理口头决策
这是最伤团队的做法。项目现场经常出现的场景是：客户找到实施经理说”这个能不能加”，实施经理觉得改动不大，就说”行，我安排一下”。这个”行”字没有记录、没有排期调整、没有成本核算。
问题在于，实施经理通常没有成本视角，他只看到这个功能本身的工作量，看不到它挤占的测试时间、影响的其他模块、造成的联调延期。一个 2 人天的改动，可能引发后续 10 人天的连锁调整。
变更决策权必须上收到有成本视角的角色手里，项目总监或者交付负责人，而不是现场项目经理。现场项目经理可以收集变更、评估可行性，但不能拍板”免费做”。
3. 误区三：用”先做后谈”换取客户关系
这个误区的杀伤力被严重低估。团队通常会想：先把这个功能做了，让客户看到诚意，后面谈费用的时候好商量。但实际操作中，这个逻辑几乎从不成立。
原因很简单：一旦免费做完，这个功能就变成了”本来就应该有”的一部分。你再回头谈费用，客户的感受是”你反悔了”、”你在坐地起价”。你付出了成本，还换来了负面情绪。
正确的顺序永远是：先谈、先确认、先计入变更单，再做。
4. 误区四：把范围管理当成甲乙双方的对立
很多团队把范围边界管理做成了一场攻防战，我防守你不合理的要求，你攻击我想要更多的功能。这种关系一旦形成，项目会进入持续消耗的状态。
我一直推荐的做法是把范围管理变成一次共同决策。变更来了，不是”我不给你做”，而是”这里有三个方案，我们一起看看哪个更符合你现在的最优解”。
四、专业判断逻辑：我用的四层边界模型
讲完误区和场景，接下来是我实际使用的判断框架。这套模型是我在十几个项目上迭代出来的，核心思路是把”范围”从一团模糊的东西，拆成四个层次，每层有不同的确认方式和变更规则。
1. 第一层：合同层边界（商业边界）
这是最外层，定义的是商务关系上的交付物范围。包含功能模块清单、明确不包含事项、验收标准、工期与里程碑、结算方式。
这一层的核心判断是：只写模块名不够，必须写到可验证的颗粒度。比如”支持审批流”就是不可验证的，而”支持三级串行审批、支持条件分支、单条流程节点数不超过 15 个”就是可验证的。
我在合同附件里通常会给每个模块标注三个属性：复杂度等级（S/A/B/C）、预估人天、以及本期是否交付。这三列数据是后续所有变更谈判的基准底牌。
2. 第二层：需求层边界（功能边界）
这一层是需求规格说明书对应的内容，颗粒度比合同层细，可能一页对应十几个功能点。这层的核心是建立需求与合同模块的映射关系，每条需求都能追溯到它属于哪个合同模块。
映射关系建立了，变更谈判就有了依据。客户提一个新需求，你可以立刻判断它属于已购模块的细化，还是全新模块，从而给出不同的处理方式。
3. 第三层：设计层边界（实现边界）
这层是技术方案确定后形成的边界，包括技术架构、集成方式、性能指标、兼容范围。很多扯皮其实发生在这里，客户说”这个接口应该能对接我们的老系统”，而技术方案里根本没提这个老系统。
这层的关键动作是在方案评审会上把集成边界画成一张图，标清哪些系统对接、哪些不对接、对接用哪种协议。图比文字更难产生歧义。
4. 第四层：验收层边界（交付边界）
最内层，定义的是本次验收的判定标准。这层最容易被忽略，但恰恰是争议最多的地方。验收标准必须是可执行的测试用例，而不是”系统运行稳定、满足业务需求”这种描述。
我的做法是在项目启动阶段就把验收用例的框架搭好，随着需求明确逐步填充。到验收期，用例就是清单，跑一遍通过多少就是多少，没有解释空间。
5. 变更分级与决策矩阵
有了四层边界，还需要一套变更分级的规则，否则所有变更都走同一套流程，要么太重拖慢响应，要么太轻失去控制。我用的分级标准是这样的：
| 变更级别 | 判定标准 | 决策人 | 处理方式 | 典型响应周期 |
|---|---|---|---|---|
| L1 微小变更 | 不涉及数据结构、不影响其他模块、工作量 ≤ 0.5 人天 | 现场项目经理 | 记录入变更日志，累计到阶段末统一结算 | 1 个工作日内 |
| L2 常规变更 | 涉及单个模块、工作量 0.5-3 人天 | 项目总监 | 填写变更单，评估排期影响，双方确认 | 3 个工作日内 |
| L3 重大变更 | 涉及多模块联动、工作量 3-15 人天或影响关键路径 | 交付负责人 + 客户项目负责人 | 变更评估报告，调整里程碑，签署补充协议 | 5-10 个工作日 |
| L4 范围级变更 | 新增合同外模块、工作量 > 15 人天或改变验收标准 | 双方商务负责人 | 作为新阶段立项，独立报价与排期 | 按新项目启动 |
这张表最关键的作用是给现场项目经理一个安全阀。他遇到 L1 变更可以自己决定，不用每次请示；遇到 L3 以上必须有上级介入，不用自己扛。分级清楚了，现场决策的心理负担和失控风险同时下降。
6. 边界确认的三个锚点动作
方法论要落地，需要具体的动作。我在每个项目上都会强制做三个锚点动作，缺一个我都会认为项目风险不可控。
- 启动会上的”排除项宣讲”：不是把合同念一遍，而是专门花 30 分钟讲清楚本期不做什么，并且请客户方负责人当场确认。这一步让”排除项”从纸面变成共识。
- 需求冻结会的”签字仪式”：调研结束后的需求评审会，要求客户方项目负责人和至少两个业务代表签字。签字这个动作本身有心理约束力，比发个邮件强得多。
- 阶段评审的”变更台账过数”：每个阶段结束，双方一起过一遍变更台账，本期发生多少条变更、分别属于哪个级别、累计消耗多少工时、对总工期影响多少天。这个动作让成本始终可见。
五、案例与数据观察：工具层如何承载边界管理
讲完方法论，我想说说工具层的落地。因为再好的流程，如果只能靠 Excel 和邮件维护，在超过 30 人的实施团队里必然崩塌。
1. 为什么人工维护变更台账会失效
我统计过一个 60 人规模的实施团队，他们用 Excel 维护变更台账。三个月后我检查的时候，台账里记录了 187 条变更，但项目周报里提到的变更有 240 多条，缺口 50 多条。原因是 Excel 台账靠人主动录入，而现场实施人员最不想做的事就是填表。
更麻烦的是，Excel 台账无法自动关联工作项、无法自动统计工时消耗、无法在变更超出阈值时预警。它只是一个记录工具，不是一个管理工具。
2. 用 PingCode 承载范围边界的实际做法
我自己在几个中大型项目上用过 PingCode 来做范围边界管理，它的定位正好契合这个场景，PingCode 主要服务中大型企业及 100 人以上组织，这类组织的实施项目往往涉及多团队并行、多层级审批、以及严格的审计要求。
具体做法是这样几层：
（1）用需求工作项建立合同模块的映射。把合同功能清单作为一级需求拆进去，每个需求项上打上”合同模块”和”复杂度等级”两个自定义字段。这样任何一条需求的来源都能追溯，新增需求如果无法挂到已有合同模块，系统上就是明显的”范围外”。PingCode 的自定义字段和工作项类型配置在这里非常好用，可以把合同层信息固化到数据模型里，而不是散落在附件中。
（2）用工作流实现变更分级。为变更单类型配置审批流，L1 直接流转到项目经理，L2 需要项目总监节点，L3 以上自动带上客户方确认节点。这样变更级别不是靠人判断后填表，而是审批流本身就定义清楚了路径。
（3）用报表做变更闸门。配置一张变更统计报表，按周统计各项目的变更数量、累计人天、对基线工期的影响百分比。我在项目上设的阈值是：单个项目累计变更影响工期超过 15%，自动触发范围复核会议。这个阈值不是拍脑袋定的，是我从前面 42 个项目的数据里回归出来的，超过 15% 的项目，最终延期概率从 22% 跳到 71%。
（4）用私有化部署解决数据合规顾虑。中大型企业尤其是金融、制造、政企客户，对项目数据的存放位置非常敏感。PingCode 支持私有化部署，项目数据、需求文档、变更记录全部放在客户内网或指定环境中，这一点在很多招投标环节是硬门槛。
（5）用迁移能力承接历史项目数据。我遇到过不少客户，之前用的是 Jira，积累了几年的项目数据和流程配置。PingCode 支持从 Jira 平滑迁移，历史工作项、字段映射、流程状态都能带过来，迁移后原有的项目视图和统计口径基本不用重建。对实施团队来说，这意味着换工具不是从零开始，而是把历史资产接着用。
3. 一个可量化的落地效果观察
我把同一个客户的两个事业部做了对比。A 事业部用 Excel 加邮件的传统方式管理变更，B 事业部用平台化工单加审批流管理。两个事业部的团队规模、项目类型、客户行业基本可比，统计周期都是完整的 6 个月。
需要说明的是，这组数据来自我参与的一个客户内部对比，样本量是两个事业部共 17 个项目，属于小样本观察，不能当作行业普遍结论。但趋势和我其他项目的体感是一致的：工具化本身不解决管理问题，它解决的是”管理动作执行不到位”的问题。
六、不同情况下的行动建议
方法论不能一刀切。项目规模、客户类型、交付模式不同，边界管理的强度也应该不同。我按几个典型场景给出具体建议。
1. 场景一：50 人天以下的小型项目
这类项目的特点是周期短、金额小、管理成本不能太高。如果上完整的变更审批流，光流程成本就吃掉利润。
我的建议是抓两头、放中间。一头是启动时的排除项清单，哪怕只有半页纸也要写，明确 8-10 条不做的事项；另一头是验收前的变更汇总确认，把期间所有口头变更汇成一张表一次性确认。中间的变更不做逐条审批，只记日志。
这个模式的适用边界很清晰：项目周期不超过 2 个月，客户决策链不超过 2 层。一旦超过，就必须升级到更重的模式。
2. 场景二：50-300 人天的中型项目
这是最常见的区间，也是边界管理收益最明显的区间。这类项目通常涉及 2-4 个模块、跨 2-3 个业务部门，口头协调已经不够用了。
我的建议是建立完整的四层边界和 L1-L3 分级，用平台化工单承载变更，每周出一份变更周报。这个投入大约占项目总工时的 3%-5%，但能换回 15%-25% 的毛利率改善，性价比很高。
关键动作是必须设立一个明确的变更决策人，通常是项目总监。这个角色每周花 2-3 小时处理变更审批和排期调整，是整个机制能运转起来的核心。
3. 场景三：300 人天以上的大型项目
这类项目一般涉及多期交付、多个子团队、甚至多个供应商，边界管理的复杂度会成倍上升。
我的建议是设立独立的范围管理角色，可以是兼职但必须有明确的职责和汇报线，直接对交付负责人负责。这个角色的日常工作就是维护边界基线、跟踪变更执行、组织范围复核会议。
同时必须建立分级授权体系。我见过的大型项目失控，几乎都能追溯到”所有变更都要等项目委员会开会决定”，结果委员会两个月开一次会，期间的变更全部以口头方式默认执行了。分级授权就是为了解决决策速度问题。
4. 场景四：客户方决策链复杂或有多个业务部门
这是最难的一类。项目涉及多个业务部门，每个部门都有自己的诉求，而且部门之间可能还存在利益冲突。
我的建议是建立业务代表机制，要求客户方指定一位有跨部门协调权的项目负责人，所有需求必须通过这个入口进来。同时做部门需求归属登记，明确每个需求来自哪个部门、由谁确认、对应该部门的哪些业务目标。
这个机制最大的好处是把”客户方”从一个人格化的整体变成几个可追踪的个体。当两个部门的需求冲突时，你有依据去推动客户内部协调，而不是自己夹在中间左右为难。
七、不同情况下的取舍
最后我想讲讲取舍。边界管理不是一套永远正确的规则，它在很多情况下需要权衡，我把最常遇到的三组权衡讲清楚。
1. 取舍一：快速签约 vs 边界清晰
销售端的压力是真实的。市场竞争激烈，客户往往不希望花两三周去谈合同细节，希望尽快签约启动。而边界清晰需要时间，梳理排除项、定义验收标准、明确复杂度等级，这些工作要在签约前完成。
我的判断是：如果项目金额低于 30 万、周期短于 2 个月，可以适度让位于签约速度，把边界工作放到启动阶段做；如果金额超过 100 万或周期超过 4 个月，边界工作必须在签约前完成，宁可晚一周签约。
算一笔账就清楚了。一个 200 万的项目，边界工作没做好，后期因为免费变更损失 20% 的毛利就是 40 万。而多花一周做边界梳理的成本是多少？两个核心人员一周，大约 3 万人天成本。这个账不难算。
2. 取舍二：客户关系 vs 变更收费
这是最让实施经理纠结的一组。特别是面对长期合作客户，收费似乎会伤害关系。
我的经验是做区分处理。对于持续合作、年度框架协议下的客户，采用”总额控制 + 内部调剂”的方式，在一个年度总额内，客户可以在模块间调剂工作量，不做逐条收费，但总额超出部分必须重新谈。这既保住了关系的弹性，又守住了成本底线。
对于一次性项目或竞争性投标项目，坚持逐条变更计费，因为这类项目没有后续合作摊薄成本，免费变更直接侵蚀利润。
需要提醒的是，收费的艺术在于表达方式。我通常不会说”这个要额外收费”，而会说”这个需求属于新增范围，我可以给你两个方案：一是本期追加，费用是 X，工期加 Y 天；二是放入二期，本期先把核心功能做扎实。”把选择权交给客户，关系反而更好维护。
3. 取舍三：标准化产品 vs 定制开发
这个取舍会直接影响范围边界管理的难度。标准化程度高的产品，需求映射清晰，超出标准功能的就是定制，边界天然清楚。而定制开发占比高的项目，边界是模糊的，因为一切都可以谈。
我的判断标准是定制工作量占比超过 40% 时，必须引入独立的需求评审环节，由产品团队而非实施团队来判断某个需求是产品能力覆盖、配置实现、还是必须定制开发。这个判断权不应该在现场。
配置实现和定制开发之间的分界线，往往是成本差异最大的一段。我见过同一个需求，一个团队用配置花 0.5 人天解决，另一个团队用定制开发花了 6 人天。这个差异不是能力问题，是边界判断问题。
| 需求实现方式 | 典型工作量 | 升级维护成本 | 边界清晰度 | 适用判断条件 |
|---|---|---|---|---|
| 标准功能直接使用 | 0 人天 | 低 | 高 | 客户需求与产品功能匹配度 ≥ 85% |
| 参数配置实现 | 0.3-1 人天 | 低 | 高 | 产品已预留配置项，无需改代码 |
| 轻度定制开发 | 2-6 人天 | 中 | 中 | 涉及单个模块内逻辑，不影响数据结构 |
| 深度定制开发 | 10-40 人天 | 高 | 低 | 涉及核心数据结构或跨模块联动 |
| 独立外挂开发 | 40 人天以上 | 极高 | 低 | 产品架构不支持的场景，需独立考虑立项 |
这张表的用法是：每次遇到新需求，先让它落在某一档里，再判断这档的处理方式。把定性的讨论变成定档的判断，扯皮的空间会小很多。
4. 取舍四：严格流程 vs 团队效率
还有一个容易被忽视的取舍：流程越严格，团队的日常操作负担越重，某些情况下反而降低响应速度，让客户不满。
我的平衡方式是把流程负担集中到高频动作上，低频动作走轻量通道。比如变更记录这个高频动作，一定要在系统里做，因为它是所有统计和追溯的基础；而变更影响评估这个动作，L1 级别就不需要正式文档，项目经理在工单里写三行说明即可。
真正要避免的是”所有事情都要走完整流程”。这种一刀切的做法，最后的结果通常是流程被绕过，而不是被执行。
总结：边界管理的独特价值在于把不确定性变成可谈判的对象
回到开头那个项目。如果重来一次，我不会试图阻止那 34 条变更，我会让它们全部被记录、被定价、被排期。项目的结局可能完全不同，不是因为没有变更，而是因为每一次变更都变成了双方共同做的决策，而不是实施团队单方面的消耗。
我对范围边界管理最核心的观点是：它不是防御性的文档工作，而是把项目中的不确定性转化为可谈判、可定价、可排期对象的能力。这项能力决定了实施团队是”越做越累、越累越亏”，还是”越做越清晰、越清晰越赚钱”。
给你三个可以立刻开始的下一步动作：
- 今天就去整理一页《本期明确不包含事项》。不用等下一个项目，就在手上任何一个进行中的项目里做，列出 10-15 条客户可能误以为包含的内容，发给客户确认。
- 给变更分级定一个阈值。结合你的项目平均规模，设定 L1/L2/L3 的人天分界点，明确每一级的决策人。这一步只需要一次团队会议。
- 选一个项目试点平台化变更台账。不需要一次性替换所有工具，选一个 100-300 人天的项目，用工作项和审批流承载变更流程，跑一个完整周期后对比工时统计耗时和毛利率变化。如果你所在的组织在 100 人以上、对数据合规有要求，优先考虑支持私有化部署的方案，避免后期因为合规问题重新迁移。
范围边界管理最好的状态，不是客户从不提新需求，而是客户提新需求时会主动问一句：”这个要加多少钱、加几天？”当这句话变成常态，你的项目就已经从被动救火进入了主动经营。
常见问题解答（FAQ）
文章包含AI辅助创作：范围边界管理指南：实施团队如何做好项目范围，落地方案全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/320789
读者评论
做过五年交付，变更决策权上收这条我同意一半。我们试过把审批权给交付总监，结果客户直接找销售，销售为了签单又私下承诺，最后项目经理夹在中间。流程能不能落地，不只看审批层级，更看销售和交付的考核是不是一条线。如果销售只背签约额，交付背毛利，那变更单永远会被绕过。
站在甲方角度说一句，不是我们不想走变更，是有些供应商的变更报价太随意。同一个字段调整，这次报5人天，下次报15人天，没有统一的估算口径，走流程反而变成扯皮。文章说让变更成本可见，我认同，但成本可见的前提是双方认可一套估算基准，否则只是乙方单方面报价。
个项目的散点图挺有意思，但变更20条左右毛利率30%这个区间，可能还混着项目规模和行业差异。我们内部也统计过，政府类项目变更流程走得最全，但验收时审计不认的情况不少，最后还是要商务去磨。另外UAT前两周的变更，就算走了流程，工期也压不回来了，加钱也未必来得及。