范围定义落地方案：研发团队开展项目范围的流程优化案例解析

我在过去八年里参与过 30 多个研发团队的流程诊断，有一个现象反复出现：项目延期复盘时，团队几乎从不把原因写成”范围没定义清楚”，而是写成”需求变更频繁””联调时间不够””测试资源不足”。这不是在回避问题，而是因为范围定义做得差这件事，在时间线上离故障点太远，远到复盘会上已经没人记得第 3 周那次”顺便加一个导出功能”的口头承诺。我见过一个 120 人的研发组织，单个版本进入范围的需求条目是 187 条，最终交付 121 条，交付率 64.7%，而返工工时里有 62% 可以追溯到范围变更。

这篇文章不讲范围管理的理论分类，只讲我实际跑过的一套落地方案，包括它在哪里失效过、我又怎么改的。

一、核心结论：范围定义的收益不在”少做需求”，而在”减少返工”

先把结论放在最前面，因为大多数人做范围优化的目标是错的。很多人以为范围管理做得好，意味着团队能砍掉更多需求、做更少的活。我实测下来的结论恰好相反：做得好之后，需求条目数量通常只下降 15%~25%，但返工工时能下降 60% 以上。收益的来源是返工的减少，而不是工作量的减少。

1. 结论一：范围定义的本质是给”变更”提前定价

范围文档写得再漂亮，如果它不能回答”现在加这个功能，要付出什么代价”，那就是一份没有生产力的文档。我在团队里推行范围优化时，从来不用”范围说明书”这个词，而是用”变更定价表”。因为一旦把范围定义和变更代价绑定，产品经理在提需求时就会自己先做一次取舍，而不是把所有想法都丢给研发评估。

这个视角的转变带来一个直接结果：需求评审会的时间从平均 2.5 小时压缩到 50 分钟。原因很简单，当每个新增需求旁边都挂着预估人天、影响版本和需要重做的测试范围时，讨论会自动从”要不要做”转向”值不值得做”。

2. 结论二：范围文档的寿命取决于它是否被工具承载

我做过一次不太体面的实验。同一个团队，同一份范围描述，一次放在共享文档里，一次放进项目管理工具的需求模块并绑定迭代和测试用例。三个月后再查：文档版本的范围描述，最后一次更新停留在第 2 周，之后所有变更都散落在聊天记录里；工具版本的范围记录，因为每次变更都要走状态流转，反而保持了 100% 的可追溯性。

结论很直白：凡是需要人主动想起来去更新的文档，三周内一定会失效。范围定义要活下来，就必须寄生在团队每天都要打开的流程节点上。这也是为什么我在选型时，会把”需求、迭代、测试用例、缺陷能否串成一条链”排在功能丰富度之前。

3. 结论三：范围优化的最小可行单元是”变更单”，不是”范围说明书”

如果你现在只能做一件事来改善范围管理，不要写范围说明书，先设计一张变更单。因为它倒逼的是流程中最痛的那个环节。变更单需要回答四个问题：改什么、为什么现在改、影响哪些已完成的工作、由谁承担代价。这四个问题一旦强制填写，团队里 40% 的临时需求会自己消失。

我带的团队里有一条不成文的规定：变更单可以由任何人发起，但必须由发起人自己填写”影响已完成的测试用例数量”这一栏。这个设计让变更总量在整个季度下降了 43%，而且没有任何人觉得被流程卡住，因为卡住他们的是自己填出来的代价，不是审批人。

二、背景和真实场景：一个 120 人研发组织的范围失控过程

抽象的方法论意义不大，我更愿意把一次完整的失败过程拆开讲。这是我 2023 年接手的一个案例，团队规模 120 人左右，做工业设备物联网平台，两条产品线并行，研发分成 6 个小组：3 个业务研发组、1 个平台组、1 个测试组、1 个 DevOps 组。

1. 团队当时的真实状态

他们不缺流程，缺的是流程与流程之间的连接。需求池在一个工具里，排期在另一个表格里，测试用例在第三处，缺陷又回到第一个工具。范围变更的口头确认占比我自己抽样统计过，一个版本内 32 次变更，有 27 次只在即时通讯里留了痕迹，没有进入任何正式记录。

更隐蔽的问题是范围膨胀的方式。他们不是一次性加一个大功能，而是每次加”顺手改一下”。一个版本累计下来，这类小改动占了新增工作量的 38%，但几乎没人把它们计入范围变更。这就像信用卡的小额免密支付，单笔无感，账单惊人。

2. 失控的时间线

我把一个典型版本（6 周迭代）的过程按周拆开看，问题节点非常清晰。第 1 周范围确认时，团队用 3 小时过完了 187 条需求，平均每条需求 58 秒。第 2 周到第 3 周，产品侧新增 19 条需求，全部口头确认。第 4 周进入联调，测试组发现 11 条需求的验收标准与研发理解不一致。第 5 周开始返工，同时又有 6 条需求插入。第 6 周压缩测试时间，交付 121 条，上线后两周内产生 34 个线上缺陷。

3. 把损失折算成可比较的单位

范围失控最难沟通的地方在于它没有独立科目。项目延期会被记为”开发效率问题”，返工会被记为”质量问题”，需求变更多了会被记为”产品节奏问题”。为了让它可讨论，我把它折算成两个统一单位：人时和交付准时率。

折算结果是：单个版本因范围问题产生的额外人时约 860 人时，相当于 5.4 个全职工程师六周的工作量；版本交付准时率 58%，即 5 个版本里有 2 个延期；上线后两周内的缺陷数量中，有 61% 可以追溯到验收标准未在范围阶段明确。这三个数字后来成了推动流程改造的核心论据。流程改造最难的从来不是方案，而是让人相信现状的代价比改变的代价更大。

三、拆解常见误区：为什么多数团队的范围定义”看起来做了，实际没用”

我在不同团队里见过至少五种对范围定义的误解，它们有一个共同特征：在流程文档里都写着”已执行”，但在实际交付中不产生任何约束力。

1. 误区一：把范围定义等同于需求文档

需求文档回答的是”要做什么”，范围定义回答的是”这一版不做什么、什么条件下可以改”。前者是描述，后者是契约。我见过团队的需求文档写到 80 页，但翻遍全文找不到一句”本次不做”的表述。

判断标准很简单：如果一份范围描述里没有明确的”排除项”，它就不是范围定义，只是需求清单。排除项的价值在于它给了研发一个可以拒绝的锚点。没有排除项，任何”顺便加一个”都无法被判定为超范围。

2. 误区二：用敏捷当不做范围定义的借口

“敏捷就是拥抱变化”是我听到最多的一句话，也是被误用最多的一句。拥抱变化不等于免费变化。敏捷宣言里那句话说得很清楚，变化要被响应，而响应是有成本的。敏捷真正要求的是短周期内把范围切小，而不是不做边界。

我通常会反问一句：如果你的团队连这一周要交付哪几条需求都说不清楚，那你的敏捷体现在哪里？实践下来，越是节奏快的团队，越需要轻量的范围锚定，因为快节奏意味着试错次数更多，没有边界的话错误会被快速放大。

3. 误区三：范围变更只走口头确认

口头确认不是没有确认，而是把确认的成本推迟到了未来。我统计过一个团队三个月的变更记录：口头确认占比 84%，其中在交付时被研发和产品各执一词的有 11 次，平均每次争议消耗 4.5 小时的对齐时间。这些时间几乎全部发生在版本末期，也就是团队最不该被打断的时候。

这里有个反直觉的观察：让变更显性化的最大阻力往往不是研发，而是产品经理。研发的痛点在交付期，产品的痛点在写变更单的那一刻。所以设计变更流程时，一定要让填写成本低到产品经理不会抗拒，我的经验是单张变更单填写时间不能超过 3 分钟。

4. 误区四：把范围管理当成项目管理办公室的职责

一旦范围管理被划归某个职能角色，它就变成了一个审计动作，而不是一个协作动作。我见过设置了专职范围管理岗的团队，结果是研发觉得那是”来检查的”，产品觉得那是”来卡我的”，两边都绕着走。

更有效的做法是把范围责任分散到具体的角色动作上：产品负责写排除项，研发负责估影响，测试负责标记受影响的用例，项目经理负责确认代价被记录。每个人只做一件小事，范围基线就自然形成了。

5. 误区五：以为工具越重，范围越可控

工具确实重要，但重不等于好。我见过一个团队把范围管理做成 11 道审批，结果是所有变更都流向”先做了再说，事后补单”的路径，流程反而更不可信了。

我的判断标准是：审批节点数量不应超过范围的颗粒度层级。如果你的范围只切到”版本”这一层，那审批就应该只有版本级的冻结和版本内的变更受理两级，多出来的都是形式主义。

四、专业判断逻辑：范围定义的四个锚点

讲完误区，需要给出一套能落地的判断逻辑。我不喜欢列十条原则，因为团队记不住。我最终收敛成四个锚点，任何范围定义只要这四个锚点都成立，就足够用了。

1. 锚点一：可验证的交付边界

边界必须能用”是/否”回答，不能用”基本满足”回答。我见过最多的模糊表述是”支持多设备接入”，这句话在验收时一定会打架，因为没有说清楚接入多少种、什么协议、性能到什么量级。

我的改写方式是把边界写成三段：能力描述 + 量化阈值 + 不在范围内的相邻能力。比如”支持 5 种主流工业协议接入，单节点并发 2000 连接，不包含协议自定义扩展”。第三段”不包含”是大多数团队最容易漏掉、也最省事的一段。

2. 锚点二：变更成本的显性化

我要求每个变更单必须填三个数字：预估新增人天、受影响已完成工作的人天、对交付日期的影响天数。前两个数字是成本，第三个数字是后果。三个数字都用原始数据填，不允许填”待评估”。

这套做法刚开始会遇到阻力，研发会说”现在估不准”。我的回应是：估不准也要给区间，因为决策需要的是量级，不是精度。实际上跑三个版本之后，团队的区间估计误差能收敛到 25% 以内，已经足够支撑取舍决策了。

3. 锚点三：干系人确认的闭环

确认不等于通知。我区分这两个动作的标准是：确认必须留下可查的、带时间戳的、明确表态的记录；通知只是单向告知。在工具里，我通常用需求状态的流转来实现这一点，比如从”待评审”到”已确认”必须由指定角色点击，系统自动记录人和时间。

这里有个容易被忽略的细节：确认必须包含下游角色。很多团队的范围确认只有产品和研发，测试完全缺席，结果验收标准的分歧全部堆到第 4 周才暴露。我坚持测试负责人在范围确认阶段必须签字，哪怕只是确认”验收标准可测”。

4. 锚点四：范围基线的版本化

基线必须能回答”第 3 周时的范围是什么样”。做不到这一点，所有的变更影响评估都是事后编故事。我的做法是每个版本建立独立基线快照，快照包含当时的需求清单、验收标准摘要和排除项，并且冻结后不可修改，只能新增版本。

基线版本化还有一个组织价值：它让复盘从互相指责变成数据对话。当你能拿出第 3 周和第 6 周的两份基线对比时，讨论的焦点自然从”谁的锅”转向”哪一类变更最值得拦”。

五、落地方案：从需求进入到范围冻结的七步流程

这套流程我在三个不同规模的团队跑过，最长的一次跑满 9 个版本。它不是最完整的，但它是唯一一套团队没有在执行三个月后偷偷废弃的。核心设计原则是：每一步都对应一个具体角色的具体动作，没有一步是”大家都应该注意”。

1. 第一步：需求统一入口与分级

所有需求必须从同一个入口进入，不允许在即时通讯里直接指派给研发。入口之后立即分级，我用的是三级：版本必做、版本可选、待评估。分级动作由产品负责人完成，研发不参与，避免过早陷入可行性讨论。

分级的关键不是准确，而是速度。我的经验值是 20 秒内完成一条需求的分级，因为分级阶段的目的是筛掉明显不合适的，不是做精细评估。这个阶段通常会过滤掉 20% 左右的需求条目。

2. 第二步：三方澄清会与验收标准前置

澄清会必须三方在场：产品、研发、测试。缺任何一方，这个会议就退化成了需求宣讲。会议的唯一产出是每条需求的验收标准，用可测的语句写清楚，写不清楚的直接退回待评估。

我在澄清会上用一个硬性规则：研发和测试如果对同一条需求的理解出现分歧，这条需求当场退回，不进范围。这个规则的杀伤力很大，第一轮会退掉 15%~20% 的需求，但会让后续的返工大幅下降。

3. 第三步：范围切分与排除项撰写

这一步是整个流程里最被低估的环节。我要求产品对每个版本都写一份排除项清单，明确列出”本次不做但相关的能力”。清单长度不设限，但必须覆盖三类：相邻功能、性能等级的取舍、非功能性需求的边界。

写排除项的心理门槛不低，因为它等于提前宣布”我知道有这些东西但我选择不做”。我给产品经理的话术是：排除项不是承诺永远不做，而是承诺这一版不做。有了这句话，填写阻力会明显下降。

4. 第四步：基线冻结与冻结范围声明

冻结不是把所有东西锁死，而是要区分冻结什么、不冻结什么。我的做法是冻结”验收标准”和”排除项”，不冻结”实现方式”和”任务拆分”。这样研发在实现上保持自由度，但交付边界不动。

冻结时点通常放在版本启动前 2 个工作日，留出缓冲处理最后的分歧。冻结动作在工具里体现为需求状态批量流转到”已确认”，并自动生成一份基线快照。

5. 第五步：变更受理与影响评估

变更单是我整个方案里最小的可执行单元。它必须包含四项内容：变更描述、发起原因、影响评估、承担方。其中影响评估由研发填写，包含新增人天、受影响已完成工作、对交付日的影响天数。

受理规则我设了两档：影响小于 3 人天的变更，由项目负责人直接受理并记录；影响大于 3 人天的变更，必须回到三方澄清会重新评估。这个阈值的设定依据是3 人天以下的变更走完整流程的边际成本高于收益，而 3 人天以上的变更往往涉及验收标准调整，必须重新对齐。

6. 第六步：执行链路的打通

这一步是工具承载的核心。需求、任务、测试用例、缺陷必须串成可追溯的链路，否则前面五步的记录在版本末期会全部失去作用。我在选型时的硬性要求是：从一条需求出发，能直接看到它拆出的任务、覆盖它的用例、以及它关联的缺陷，不需要人工拼表。

这里我以 PingCode 为例说明工具承载的具体形态。PingCode 的需求模块支持自定义工作项类型和状态流，可以把”待评审，已确认，变更中，已完成”这套状态直接固化成流程，避免团队靠自觉维护；需求与任务、测试用例、缺陷在同一条链路上关联，第 6 步要求的可追溯性不需要额外建表。它还支持私有化部署，这对有数据合规要求的团队是硬门槛。另外，如果团队原来用的是 Jira，PingCode 支持平滑迁移，字段映射和历史记录可保留，这一点对 100 人以上的组织尤其重要，因为迁移成本往往是流程改造最大的隐形成本。

7. 第七步：版本回顾与范围命中率复盘

复盘只看三个指标：范围命中率（最终交付条目 / 冻结基线条目）、变更强度（变更新增人天 / 基线预估人天）、以及返工归因分布。这三个指标可以在 30 分钟内过完，不需要长篇复盘文档。

我特别看重范围命中率这个指标。它低于 80% 说明基线定得不实，高于 105% 说明范围在冻结后仍在膨胀。健康区间的经验值是 88%~98%，这个区间意味着基线基本可信，同时保留了应对真实变化的弹性。

六、案例与数据观察：优化前后 9 个版本的对比

回到开头那个 120 人的案例。流程从第 4 个版本开始上线，前 3 个版本作为基线对照，后 6 个版本为优化后区间。我记录了 8 个可对比指标，这里把最有代表性的几个放在一起。

1. 核心指标对比

需要说明数据口径：这是该团队内部统计，不是行业基准，样本量为 9 个版本、约 11 个月的周期。我在引用时更愿意说它是”一个可复现的方向”，而不是”一个可以照抄的数字”。不同团队的基础差异很大，但返工工时的下降幅度通常是最先出现、也最稳定的那个信号。

2. 一个失败过的尝试：变更阈值设得太低

我把这段失败的细节写出来，因为它比成功经验更有参考价值。流程上线初期，我把变更受理阈值设成了 1 人天，也就是超过 1 人天的变更都要重新开澄清会。结果是前两周变更单数量激增到 58 张，团队每天有 1.5 小时花在变更会上，研发怨气很大。

第 3 周我把阈值调到 3 人天，变更单数量降到 21 张，同时返工工时没有反弹。阈值的作用不是拦截变更，而是把团队的注意力集中在代价最大的那部分变更上。这个教训让我后来在任何流程设计中都先问一句：这个节点每天会消耗团队多少分钟？

3. 第二个失败尝试：排除项写得太长

第二个坑来自排除项。有个版本产品的排除项写了 60 多条，结果研发在实现时反复纠结”这条是不是在排除项里”，反而增加了沟通成本。后来我把排除项控制在 15 条以内，并且只保留与本次交付能力直接相邻的那些。

这背后的判断是：排除项的密度和团队规模成反比。小团队靠默契就能理解边界，大团队才需要显式列举。100 人以上的组织，我建议把排除项固化成模板字段，避免每个版本重新讨论格式。

七、不同情况下的行动建议

同样是范围定义，团队规模、产品形态、合规要求不同，落点差异很大。我把常见的四类场景分开讲，每一类只给出最该先做的那件事。

1. 20 人以下的小团队：先做变更单，别做流程

这个阶段的团队人少、沟通成本低，做完整范围流程的收益很小，反而会拖慢节奏。我建议只做一件事：建立一张变更单模板，每次范围变更填一次，填完贴在版本记录里。不需要审批，不需要工具承载，只要留下痕迹。

判断是否该升级流程的信号是：变更单在一个版本内超过 10 张，并且团队开始出现”说过但记错了”的争议。到这之前，轻量记录比完整流程有效得多。

2. 20~100 人的团队：把验收标准前置，把链路打通

这个规模是最容易出现”半套流程”的区间，也就是有文档但没有约束力。我建议优先做两件事：验收标准前置到澄清会，以及需求与测试用例的关联打通。这两件事能直接消灭 60% 的返工来源。

工具上，这个规模开始需要考虑协作平台的选择。国产替代的场景下，PingCode 覆盖了需求、迭代、测试、缺陷的完整链路，支持私有化部署，也可以从 Jira 平滑迁移，对处在工具切换期的团队是比较省心的选择。但我要强调，工具只解决”记录是否可信”，不解决”团队是否愿意记录”。流程设计仍然要先跑通，再上工具固化。

3. 100 人以上的中大型组织：先统一字段，再统一流程

超过 100 人之后，最大的问题不再是习惯，而是口径。不同小组对”需求变更”的定义不同，导致跨组统计失效。我建议第一步不是推流程，而是统一三个字段的定义：变更的判定标准、影响人天的计算口径、验收标准的写法模板。

这三个字段统一之后，跨组数据才可比，管理者才能看到真实的分布。这个阶段的工具选型需要额外考虑私有化部署、细粒度权限、以及与已有研发链路的集成能力。对中大型组织来说，范围定义的难点已经从”能不能做到”变成”六个组能不能按同一套口径做到”。

4. 强合规与私有化场景：把范围基线当成受控记录

在医疗、工控、金融这类场景里，范围定义不只是管理工具，还是合规证据。这类团队的关注点会从”效率”转向”可审计”。我建议把范围基线作为受控记录管理：冻结后不可修改、变更必须留审批痕迹、基线版本与交付版本可一一对应。

这类场景对工具的硬性要求包括私有化部署、操作日志完整、权限可分角色配置。选择时不要只看功能清单，要实际验证三件事：历史记录的导出能力、权限变更是否留痕、以及离线环境下的可用性。

八、不同情况下的取舍

任何流程设计都是取舍的结果。我把这套方案里最需要权衡的四组矛盾列出来，方便你判断自己该往哪边偏。

1. 速度与确定性：越早冻结越确定，但灵活性越差

冻结越早，团队越稳定，但错过真实市场机会的风险越高。我的经验规则是：与外部客户合同绑定的版本，冻结要早且严；纯内部探索的版本，冻结可以晚且松。不要用同一套冻结策略覆盖两类版本，那会导致要么创新被卡死，要么交付不可控。

2. 文档重量与沟通成本：文档越薄，沟通越依赖默契

文档和沟通是替代关系，但不是线性关系。文档减少到某个点之后，沟通成本会非线性上升，因为隐性知识无法传递。我观察到的临界点大约是：当团队超过 30 人、或者存在跨地域协作时，范围定义必须显性化，不能靠默契。

3. 工具自建与采购：自建灵活，采购省心

自建工具的好处是能完全贴合流程，坏处是维护成本和人员流失风险。我见过一个团队自研了一套范围管理工具，两年后原作者离职，没人敢改。采购工具则相反，功能边界固定但持续维护。

取舍的核心变量是团队有没有稳定的工具维护能力。如果研发团队连 0.5 个人力都无法长期投入到工具维护，就不要自建。对中大型组织，私有化部署加成熟产品通常是更稳的选择。

4. 冻结严格度与团队信任：越严的冻结越依赖前期质量

冻结严格的前提是范围定义本身足够准确。如果前期澄清做得粗糙，严格冻结只会把矛盾推后，形成”冻结，绕过，事后补单”的循环。所以我建议的顺序是：先提升澄清质量，等验收标准可测率超过 85%，再收紧冻结。顺序反了，流程会被架空。

九、下一步：从一张变更单开始，三个月内跑完一轮

这套方案真正的难点不在设计，而在启动。我见过太多团队把范围优化的启动条件设成”等工具选好””等流程文档定稿”，结果三个月过去什么都没发生。我的建议是从最小单元开始，第一周就能产生可见结果。

1. 第 1~2 周：只做变更单

设计一张不超过 6 个字段的变更单，本周内投入使用。字段固定为：变更描述、发起原因、新增人天、受影响已完成工作、对交付日影响、发起人。不做审批，只做记录。两周后统计变更单数量，这个数字就是你团队范围失控的基线。

2. 第 3~6 周：加入验收标准前置与排除项

把澄清会改成三方在场，产出物只有验收标准；让产品为当前版本写一份不超过 15 条的排除项清单。这个阶段会出现明显的阻力，因为验收标准写不出来就意味着需求本身不成熟，这会暴露之前被隐藏的问题，属于正常现象。

3. 第 7~12 周：基线冻结、工具承载与复盘

开始做版本基线快照，把状态流转固化到协作平台里。此时如果团队规模在 20 人以上，建议评估一下现有工具能否支撑需求、任务、用例、缺陷的完整链路，以及是否支持私有化部署和从现有系统平滑迁移。区间结束前做一次复盘，只看范围命中率、变更强度、返工归因三个指标。

4. 判断这套方案是否成功的三个信号

• 范围命中率进入 88%~98% 区间，说明基线可信且有弹性。
• 版本内变更次数相比基线下降 50% 以上，说明变更单机制在起作用。
• 返工工时占开发总工时比例降到 15% 以下，这是收益最直接的体现，也是最难造假的一个数字。

最后说一句可能不太受欢迎的话。范围定义做得好的团队，往往会经历一个短暂的”效率下降期”，因为在前期投入了更多澄清时间，短期交付速度看起来变慢了。但这个阶段通常只有一个版本周期，之后返工减少带来的收益会迅速覆盖投入。如果你在第 1 个版本后就因为”感觉更慢了”而放弃，那大概率不是方案错了，而是评估周期定短了。

# 范围基线快照结构示例（YAML，用于版本冻结时生成不可变记录）
baseline:

version: "v2024.09"

frozen_at: "2024-09-02T18:00:00+08:00"

frozen_by: "pm_zhang"

scope_items:

id: REQ-10231

title: "设备接入协议扩展"

acceptance: "支持 5 种主流工业协议，单节点并发 2000 连接"

level: "version_required"

owner: "dev_group_a"

id: REQ-10245

title: "历史数据导出"

acceptance: "单次导出上限 50 万行，耗时不超过 90 秒"

level: "version_optional"

owner: "dev_group_b"

exclusions:

"协议自定义扩展能力（下一版本评估）"

"跨节点数据去重（本期不做）"

"导出文件加密（依赖平台组密钥服务）"

metrics:

estimated_effort_days: 312

estimated_test_hours: 186

change_threshold_days: 3

# 变更影响评估速算脚本（Python，用于变更单填写时的快速估算）
输入为变更单原始字段，输出为是否触发三方重评估

CHANGE_THRESHOLD_DAYS = 3          # 变更受理阈值（人天）

REWORK_MULTIPLIER = 1.6            # 涉及已完成测试用例时的返工放大系数

BASELINE_SLACK_RATIO = 0.12        # 版本缓冲余量占基线工作量比例

def assess_change(new_effort_days, affected_done_days, baseline_total_days):

rework = affected_done_days * REWORK_MULTIPLIER

total_cost = new_effort_days + rework

slack = baseline_total_days * BASELINE_SLACK_RATIO

need_review = total_cost > CHANGE_THRESHOLD_DAYS or total_cost > slack

return {

"total_cost_days": round(total_cost, 1),

"available_slack_days": round(slack, 1),

"trigger_full_review": need_review,

"suggestion": "回三方澄清会重评" if need_review else "项目负责人直接受理"

}

示例：新增 2 人天，但影响 1.5 人天已完成测试工作

print(assess_change(2.0, 1.5, 312))

=> total_cost_days: 4.4, trigger_full_review: True

这两段代码本身不重要，重要的是它们体现的两个设计意图：基线必须不可变且有明确的责任人；变更的成本必须能用一个公式算出来，而不是靠开会讨论。只要这两点成立，剩下的流程细节都可以按你团队的实际情况调整。