Scope管理指南：项目经理如何做好项目范围，最佳实践全流程

我在过去六年里参与过 40 多个项目的范围评审，其中至少有一半的项目，在启动会上所有人对范围的认知是一致的，但到了第 30 天左右，需求池里的条目数量会变成最初的两倍。更麻烦的是，没有人觉得自己在”加需求”，销售觉得那叫”客户合理诉求”，老板觉得那叫”战略微调”，开发觉得那叫”顺手优化一下”。三股力量各自合理，合在一起就把一个 90 人天的项目推成了 130 人天。

这就是范围管理（Scope Management）真正难的地方。它不是把需求文档写得多厚，也不是把变更流程做得多严，而是要解决一个组织行为问题：当”加一点”这件事对提出者几乎零成本、对承接者成本极高时，你靠什么让这笔账被看见、被定价、被决策。

下面这套东西，是我在甲方信息化团队、乙方交付团队、以及后来做研发效能咨询时反复迭代出来的。它不完美，但至少在我手里把三个曾经延期超过 40% 的项目拉回了可交付区间。我会把结论、误区、判断逻辑、真实数据、以及不同规模团队该怎么做，全部摊开讲。

一、先给结论：范围管理的胜负手在”变更受理的第一天”

如果你时间有限，只记住下面三句话就够了。这三句话听起来都不新鲜，但它们和我见过的绝大多数团队的实际做法是相反的。

1. 范围失控的成本是后置的，所以注定被系统性低估

一个 3 人天的变更，在提出的时候看起来”就是加个字段”。但它真正吃掉的不只是 3 人天的开发，还有联调时间、回归测试时间、文档更新时间、以及最关键的一一它挤掉的那个原本排在迭代里的需求所引发的一系列连锁重排。

我做过一次抽样统计：在一个 25 人的研发中心里，被记录为”3 人天以内”的小变更，实际引发的总工时消耗中位数是 3.8 倍。也就是说，变更是有”暗物质”的，而你只看到了可见的那一部分。成本后置 + 暗物质，导致几乎所有人在提变更时都会天然低估代价。

2. 抓手不是”拒绝变更”，而是”让变更可见、让代价可定价”

我见过太多项目经理把范围管理做成了”守门员”角色，阻拦、辩论、消耗人情。这种模式最多撑三个月，之后要么你被绕过去，要么你自己累垮。

真正可持续的做法是反过来：不预设拒绝，而是强制每一次变更都附带影响分析（人天、关键路径、被挤掉的需求），然后把决策权交给有权限的人。你从”说不行的人”变成”算账的人”，对抗感立刻下降一个数量级。

3. 流程不落到系统里，90 天内必然退化

这一点我要说得更重一些。我见过至少五支团队，花两周时间精心设计了变更控制流程，做了一版漂亮的 Excel 模板，开了三次宣贯会。三个月后我去回访，Excel 还在，但最后更新时间停在 41 天前。

原因很简单：Excel 不在任何人的日常动线上。开发每天打开的是需求管理工具、代码仓库、流水线，而不是某个共享盘里的表格。范围管理的载体必须和团队每天工作的地方是同一个。这不是工具崇拜，这是行为设计的基本常识。

基于这三点，我总结出一个四道闸门框架，后面第四节会详细拆解。

二、范围为什么会失控：三个真实场景的复盘

抽象地讲”范围蔓延”没有意义。我更愿意把失控过程拆成具体的场景，因为每个场景的解法完全不同。下面三个是我见过频率最高、也最容易反复发生的。

1. 场景 A：销售在验收前两周”补一句”

这个场景的典型剧本是这样：项目进入 UAT（用户验收测试）阶段，还差两周验收。客户方的业务对接人在一次饭局上跟销售提了一句”你们这个报表能不能按片区再拆一层”。销售当场答应”没问题，小事”。

三天后，这句话以”客户提出的紧急需求”的形式，出现在项目群里。

它的杀伤力在于时机：验收前两周是团队最脆弱的时间窗口。此时测试资源已经排满，任何插入的需求都会直接挤占回归测试时间，而回归测试缩水的代价通常不会当场暴露，而是在上线后两周以生产事故的形式暴露。

我复盘过的一个项目正是这样：验收前插入了一个”按片区拆分层级”的报表需求，开发用了 2 人天，测试被压缩了 1.5 天。上线后第 9 天，对账模块出现金额偏差，追查工时 34 人时。2 人天的变更，最终账单是 6.3 人天。

2. 场景 B：老板在周会上的一句”顺便”

这类变更的可怕之处在于它没有书面载体，只有一句口头指令，但它自带最高优先级。

我印象最深的一次：某制造企业的项目周会上，分管副总听完进度汇报后说了一句”对了，这批设备的巡检记录，顺便也接到系统里吧”。会场上没有人提出异议，项目经理在会后把它记成了”待评估”。

两周后，这句话已经变成了 12 个功能点和 3 张新表。而且因为”是领导提的”，没有任何人愿意站出来说”这个应该走变更流程”。

我的处理方式是：越是高优先级的变更，越要用最低摩擦的方式让它被记录。不是让领导去填表，而是让项目经理在会后 10 分钟内，用一句话把变更录入系统，并自动触发影响分析任务。记录动作的成本必须接近于零，否则记录行为一定不发生。

3. 场景 C：技术团队自己的”顺手优化”

这是最被忽视的一类范围蔓延，因为它看起来”很正面”。

开发在做订单模块时，顺手把订单状态机的实现方式重构了一遍；测试在测登录时，顺手把密码强度校验也加严了；运维在部署时，顺手把日志采集方案升级了。每一件事单看都是改进，但它们共同消耗的是同一个迭代的容量。

我在一个项目里做过精确统计：某个两周迭代，团队承诺了 42 个故事点，实际交付了 39 个。看起来只差 3 个点，但通过对代码提交和任务日志的追溯发现，其中 约 11 个故事点的工时被”内部优化”消耗掉了，也就是说，如果没有这些计划外工作，这个迭代本可以超额完成。

内部蔓延的解法不是禁止优化，而是把它显性化：给每个迭代预留固定比例的技术改进容量（我通常建议 15%，20%），并且要求超出这个比例的内部改动必须走轻量变更流程。你没给它时间，它就会自己偷时间。

三、四个最常见的范围管理误区

下面这四个误区，我几乎在每个出问题的项目里都能至少看到两个。它们不是能力问题，而是认知问题。

1. 误区一：把”需求文档写完”当成范围已定义

需求文档写完只代表”写的人认为自己写清楚了”，不代表”读的人理解一致”，更不代表”这是本迭代要做的全部”。

真正的范围基线至少包含三样东西：本次要交付的功能清单、明确不做的功能清单（Out of Scope）、以及验收通过的判定标准。其中”不做什么”这一项，90% 的团队从来没写过，而它恰恰是价值最高的一项，它是你和所有变更提出者对话时的锚点。

2. 误区二：用”所有人都同意”替代”有人签字”

评审会上大家点头，不等于达成共识。我在一次复盘里做过实验：让 8 位参会者在会后独立写下”本项目 V1.0 不包括哪些功能”，结果 8 份答案里只有 3 份彼此一致。

所以我坚持一件事：范围基线必须有具名确认人，而且确认行为必须留下可追溯记录。不需要纸质签字，但需要一条带时间戳的确认记录。这不是为了追责，而是为了让”遗忘”有代价。

3. 误区三：只控客户变更，不管内部蔓延

大多数团队的变更流程是”对外严格、对内放任”。外部来的需求要走评审，内部的技术重构、测试补强、UI 微调则可以自便。

但项目容量是个总量，不区分来源。我在效能咨询中常用的一个指标是净增范围（Net Scope Growth）：本迭代所有新增工作量减去所有移除工作量。健康的迭代这个值应该接近 0，如果连续三个迭代为正，几乎一定会在某个时点集中爆雷。

4. 误区四：把变更流程做成了”阻碍流程”

这是走向另一个极端的失败模式。我曾经接手过一个项目，变更申请需要填 23 个字段，走 5 级审批，平均处理周期 11 天。结果是什么？所有人都在私下口头确认，然后开发直接做，做完再补一条”需求已实现”的记录。流程变成了纯粹的表演。

好的变更流程应该满足一个标准：小变更的处理成本必须低于绕过流程的成本。如果做不到这一点，流程一定会被绕开，而且被绕开后你连数据都拿不到。

四、我的专业判断逻辑：把范围当成一个”可观测系统”

上面讲了问题和误区，接下来是我实际在用的判断逻辑。我把它设计成四道闸门，每一道解决一个特定问题，顺序不能乱。

1. 第一层：入口过滤，变更必须带影响分析才能进队列

这道闸门解决的是”变更无成本提出”的问题。规则很简单：任何变更请求，如果没有填写影响分析，就不进入评估队列，系统直接退回给提出者。

关键在于，影响分析不能由提出者单方面填写，而应该由承接方（通常是技术负责人）在收到请求后的 24 小时内完成。字段不需要多，我推荐的最小集是六项：关键路径净增天数、总人天消耗、受影响模块、回归测试时长、风险等级、以及必须被挤出的等量工作。

最后这一项是整个流程里最重要的设计。强制填写”为了做这件事，我们打算不做哪件事”，会把变更从”加法思维”拉回”减法思维”。我见过很多次，提出者在这一栏卡住了，因为他们从来没想过要付出代价。

# 变更请求单（Change Request）最小字段集
cr_id: CR-2024-0731

title: "订单导出增加按仓库维度拆分"

requester: "华东区销售-李工"

source: "客户直联" # 客户直联 / 销售承诺 / 内部优化 / 合规要求 / 战略调整

target_baseline: "V1.3 订单模块"

impact:

critical_path_days: 6 # 对关键路径的净增天数

cost_person_days: 24 # 含开发、联调、测试、文档

affected_modules: ["订单", "库存", "对账"]

regression_hours: 16

risk: "中" # 低 / 中 / 高

trade_off:

drop_items: ["批量导入模板自定义", "对账差异高亮"]

reason: "同迭代容量固定，进一项必须出一项"

decision:

level: "CCB-B" # 按人天阈值自动路由到对应层级

verdict: "有条件批准"

signed_by: ["产品负责人", "项目经理"]

2. 第二层：优先级排序，用可量化分值取代”我觉得重要”

影响分析做完之后，下一步是排序。这一步最容易变成”谁嗓门大谁优先”，所以我坚持用加权打分。

我常用的模型是四个维度加权：业务价值（权重 40%）、紧迫度（30%）、实现成本倒数（20%）、风险敞口（10%）。每个维度 1，5 分，最后得分低于 3.0 的变更默认进入待办池，不占用当前迭代容量。

这里有个经验数据：引入加权打分后，被批准变更的数量平均下降约 35%，但客户满意度基本没有变化。原因是被拒掉的变更里，绝大多数是”听起来不错但不紧急”的事项。这个结果我在三个团队里重复验证过。

3. 第三层：决策授权，按阈值分级，避免所有事情都上会

分级阈值是流程能否活下去的关键。我推荐的默认设置如下：

• A 级（≤ 3 人天）：项目经理可直接批准，只需在系统中留痕，无需开会。目标是让 70% 以上的变更在 1 天内完成决策。
• B 级（4，15 人天）：由产品负责人 + 项目经理 + 技术负责人三方会签，48 小时内给出结论。
• C 级（16，40 人天）：提交变更控制委员会（CCB），需要评估是否调整里程碑或合同范围。
• D 级（> 40 人天）：视为项目级范围变更，必须重新走立项评审，并同步更新预算与合同。

阈值的具体数字可以调，但有一条原则不能破：低层级审批必须能覆盖绝大多数量级的变更，否则高层会被淹没。

4. 第四层：回写基线，变更不落基线等于没发生

这是最容易被跳过、也是导致前功尽弃的一步。一个变更被批准之后，必须同步做三件事：更新需求基线、更新验收标准、更新对应的测试用例。

我见过太多项目，变更批了、做了、上线了，但基线文档还是三个月前的版本。到了验收阶段，双方拿着不同版本的基线对照，争执不可避免。

所以我把”回写基线”设为变更单的关闭条件之一。没有回写基线的变更单，在系统里不允许关闭。这一条硬约束把基线文档从”一次性产物”变成了”活文档”。

-- 范围健康度月度自查：变更密度与净增范围
SELECT

iteration,

COUNT(*)                                             AS total_cr,

SUM(CASE WHEN verdict LIKE '%批准%' THEN 1 ELSE 0 END) AS approved_cr,

SUM(impact_person_days)                              AS gross_added_days,

SUM(removed_person_days)                             AS removed_days,

SUM(impact_person_days) - SUM(removed_person_days)   AS net_scope_growth_days

FROM change_requests

WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)

GROUP BY iteration

ORDER BY iteration;

这条查询我建议每个月跑一次。如果 net_scope_growth_days 连续三个迭代为正，说明团队已经在持续超载，交付日期要么调整，要么必须做范围削减。这个信号比”大家最近很累”要可靠得多。

五、案例与数据观察：100 人以上团队怎么把范围管住

前面讲的都是逻辑框架，这一节我讲一个具体的、有数据的过程。这个案例的主体是一家做智能装备的制造企业，研发中心 130 人左右，同时在跑 4 条产品线。

1. 背景：一个典型的”工具用了、流程没落”的组织

我介入时，他们已经在用一款海外研发管理工具，需求、缺陷、迭代都在上面。问题在于：变更管理完全在工具之外发生。

需求变更的路径是：客户或销售在群里说 → 产品经理在微信上和技术负责人确认 → 技术负责人口头排期 → 开发直接改 → 事后补一张工单。整个过程唯一的书面记录，是那张补录的工单，而它不包含任何影响分析。

结果就是前面第二节讲过的所有问题同时出现。我拿到他们的数据是：过去 6 个月，里程碑按期达成率 51%，需求返工率 29%，并且出现了两次上线后 P1 级故障，追溯原因都是”变更导致的回归遗漏”。

2. 关键动作：把”口头变更”变成”可追溯对象”

我做的第一件事不是写流程文档，而是把变更对象建模。具体来说，是在系统里新增一个独立的工作项类型，变更请求，并强制它与前后的需求条目、迭代、测试用例建立关联关系。

这一步之所以关键，是因为它改变了整个组织的信息流：变更从”一段对话”变成了”一个对象”，对象有字段、有状态、有负责人、有历史记录。

他们最终选择落地在 PingCode 上。选型时考虑的因素有三个：一是团队规模已经到了 130 人、4 条产品线并行，需要能承载多项目组合管理的平台；二是涉及装备制造的工艺数据，必须支持私有化部署，数据不能出厂区；三是他们原有的工具里沉淀了三年的需求与缺陷数据，迁移成本必须可控。

PingCode 在这三点上比较匹配，它主要服务中大型企业及 100 人以上组织，支持私有化部署，并且提供了从 Jira 平滑迁移的路径，历史工作项的字段映射、状态流转、关联关系都能带过来，不需要团队手动重建数据。对于正在做国产化替代、又不想把历史数据丢掉的组织来说，这是一个务实的选项。

我特别想强调迁移这件事。很多团队流程设计得很好，最后死在数据搬家上，历史需求丢了、附件断了、关联关系乱了，团队对新系统立刻失去信任，然后退回老工具。迁移的平滑程度，直接决定了新流程能不能活过第一个月。

3. 三个月后的数据对比

落地三个月后，我做了前后对比。需要说明的是，这些数据来自该企业研发中心的自有度量看板，属于单一组织样本，不能直接外推到所有团队，但趋势足够清晰。

其中我认为最有价值的数字是”变更平均处理周期从 7.2 天降到 2.4 天”。很多人以为加强管控会让流程变慢，实际结果相反，当字段标准化、阈值分级、路由自动化之后，绝大多数变更反而处理得更快。慢的是那些本来就不该快的大变更。

而”净增范围从 +18.5 人天/迭代降到 +2.3 人天/迭代”这个数字，说明团队第一次真正实现了”进来一项、出去一项”的容量守恒。这比单纯的”需求做完了”要有意义得多。

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

我给建议时从来不提供”最佳实践清单”，因为不同规模、不同交付模式的团队，能承受的治理成本完全不同。下面按五种典型场景分别给。

1. 20 人以下小团队：只做两件事

小团队最大的资产是沟通效率，最大的敌人是流程负担。所以不要设计审批层级，只做两件事。

• 第一件：一个显式的”不做清单”。在每个迭代开始时，用十分钟列出本次明确不做的事，写在需求池的说明里。不写进文档，就写在团队每天都能看到的地方。
• 第二件：一条”进一出一”规则。任何人想加需求，必须同时指出要从当前迭代移除哪一项。这条规则不需要任何工具支持，但效果极好。

我见过一个 12 人的团队只靠这两条规则，把迭代承诺达成率从 60% 提到了 82%。规则少但被真正执行，胜过多而全的流程。

2. 50，150 人中型团队：必须建系统，但不要建委员会

这个规模是范围管理最尴尬的区间，靠口头沟通已经覆盖不住了，但建重流程又会拖慢节奏。

我的建议是：把变更对象落到系统里，但审批层级压到两级。人天阈值设两个档位（比如 3 人天以下 PM 批、以上三方会签），不设 CCB，不做集体评审。所有的治理能力体现在自动化上，状态流转、通知、度量看板，而不是开会。

同时开始建立度量。这个阶段最该盯的三个指标是：变更留痕率、净增范围、迭代承诺达成率。前两个是过程指标，第三个是结果指标。

3. 200 人以上多项目并行：先解决组合层面的范围冲突

到这个规模，单个项目的范围管理已经不够了。真正致命的冲突发生在组合层面，四个项目同时争抢同一批架构师，每个项目的范围看起来都合理，合在一起就不可能完成。

这时必须做两件事。一是建立统一的需求入口和统一的工作项模型，让跨项目的资源冲突可以被看到；二是建立季度级的组合评审机制，在季度开始前做一次范围总量与产能的对齐。

这个规模的组织通常也需要考虑平台的承载能力。像 PingCode 这类定位中大型企业的平台，支持多项目组合视图与私有化部署，在这类场景下比较合用，尤其是当组织同时有数据合规要求的时候。但要提醒一句：工具能呈现冲突，不能替你解决冲突。资源分配的决策仍然要由人来拍。

4. 甲方乙方合同型项目：把范围写进合同附件

合同型项目的核心手段就一个：范围基线必须成为合同的一部分，而不是项目内部文档。

我建议在合同附件里放三样东西：功能清单（带编号）、明确的除外条款、以及变更的计价与工期调整规则。第三条尤其重要，它把变更从”要不要给客户做”的人情博弈，变成了”按约定计算”的商业行为。

实践中最有效的一句话是：“本合同范围内功能清单共 128 项，清单外需求按变更流程另行计费。”这行字能挡掉一大半后期的扯皮。

5. 强监管与私有化交付场景：可追溯性优先于效率

在医疗、装备制造、金融这类强监管场景，范围管理的首要目标不是快，而是可追溯。监管部门要问的往往是”这个功能是什么时候、基于谁的批准、从哪个版本变成现在这样的”。

这类场景下，我建议至少做到三点：变更记录不可物理删除（只能作废）、每一次基线更新都有版本快照、所有决策都有具名记录。效率可以适度让位于可追溯性，因为一旦审计出问题，返工成本是数量级的。

七、不同情况下的取舍

范围管理没有”全都要”的选项。你在任何一个决策点上，本质都是在两组价值之间做交换。下面四组取舍是我被问得最多的。

1. 速度 vs 可控性

这个取舍的核心问题是：你愿意为”少返工”付出多少”流程时长”。

我的经验判断是，在项目前 1/3 阶段，应该明显偏向可控性；在后 1/3 阶段，应该明显偏向速度。前期把范围冻结清楚，代价是一次两周的评审；后期如果还在反复重新定义范围，代价是整个项目。

有意思的是，很多团队的做法正好相反，前期急着开工，评审草草了事；后期发现理解不一致，开始一轮又一轮的确认会议。这是把可控性成本放在了最贵的时间点上。

2. 客户满意度 vs 交付确定性

这是最难的一组取舍，因为它涉及短期关系和长期信誉。

我的立场比较明确：用”透明”替代”迁就”。当客户提出一个会破坏里程碑的变更时，不要直接说”不行”，也不要直接说”可以”。而是给出三个选项：按原计划交付但这项排到下期、本期交付但砍掉另两项、或者延期两周保留全部内容。

把选择权交出去，客户满意度通常不会下降，反而会上升，因为他第一次看到真实的成本结构。我做过一个小范围统计，采用这种”三选项回应”方式后，客户对变更被拒的接受度从 46% 提升到了 78%（样本量为 5 个项目中的 58 次变更交涉记录，属于经验观察，非严格对照实验）。

3. 治理成本 vs 返工成本

这组取舍可以用一个粗略的比例来判断：如果团队当前的返工率超过 15%，那么任何增加治理投入的决定，几乎肯定是划算的。

反过来，如果返工率已经低于 8%，继续加码治理的边际收益会快速衰减，此时更应该把精力放在提升单点效率上。我见过一些已经很健康的团队，还在不断增加审批环节，结果只是降低了响应速度。

4. 工具投入 vs 流程自律

这个问题我被问过很多次：到底要不要买工具、要不要换平台。

我的判断标准是看团队规模和变更频率。20 人以下、每周变更不超过 5 条，工具的价值有限，靠规则和习惯就能撑住。但一旦超过 50 人、或者每周变更超过 15 条，靠人脑和群聊维护范围状态就会开始出错，此时工具投入的回报非常明确。

另外还有一个容易被忽略的因素：数据连续性。如果你已经在一个平台上积累了两年以上的需求与缺陷数据，那么迁移的隐性成本可能高于新工具带来的收益。这也是为什么很多中大型组织在考虑国产化替代时，会把”能否平滑迁移历史数据”放在选型清单的第一位，而不是最后一位。

八、把范围管住的最小可行路径：30 天落地清单

如果你是第一次系统地做范围管理，不要试图一次性把所有机制建起来。下面这 30 天的路径，是我在多个团队里验证过、启动阻力最小的版本。

1. 第 1 周：把现状摸清楚，别急着改

这一周只做一件事：回溯过去 3 个月的所有变更，手工整理一份台账。字段不需要复杂，只要能回答四个问题，谁提的、什么时候提的、当时做了什么影响评估、最后怎么处理的。

这一步的价值在于：当你把数据摆在会议室桌上时，争论会自动减少。我多次见过这样的场景，当管理者看到”过去 3 个月共 87 条变更、其中 63 条没有做任何影响评估”时，推动流程的阻力立刻小了一个量级。

2. 第 2，3 周：建立变更对象并设两道闸门

这两周做三件事，按顺序来。

1. 定义变更工作项类型。字段按第四节的最小集设计，不超过 15 个字段，其中必填不超过 8 个。
2. 设置分级阈值与路由规则。先设两级（比如 3 人天），跑通之后再细分。
3. 跑一次试点。选一个 2，3 周的迭代做试点，只在一个团队内执行，收集反馈后再推广。

这里要特别注意一点：试点期间不要考核。如果团队觉得填变更单会影响绩效，他们就会用最省事的方式填，数据立刻失真。试点的目标是让流程跑顺，不是评估谁。

3. 第 4 周：建立度量看板并公开

最后一周把度量做出来，并且公开可见。不公开的度量等于没有度量。

我建议第一天只上三个指标：变更留痕率、净增范围、迭代承诺达成率。图表不需要漂亮，但数据必须每天更新。当团队开始在下班前瞄一眼”今天的净增范围是不是正的”，这个机制才算真正活了。

如果组织规模在 100 人以上，这一步通常会推动一次工具层面的调整。此时的选型判断可以聚焦在三点上：能否承载多项目并行的组合视图、能否支持私有化部署以满足数据合规、以及能否平滑迁移已有的历史数据。前两点决定平台能否用得久，第三点决定迁移能否落得下去。

结语：范围管理的真正产出，是一个组织对”承诺”的敬畏

回到最开始那个观察：为什么启动会上所有人对范围的认知一致，到了第 30 天就变成了两倍？因为范围从来不是一个静态的清单，而是一个持续发生的协商过程。你没法一次性定义完，只能让这个过程有记录、有代价、有决策。

我这些年最反直觉的一个体会是：范围管理做得好的团队，看起来反而”不太严格”。他们不会在变更评审上吵得面红耳赤，也不会把每一条需求都卡得很死。区别在于，他们在每一次变更被受理的第一天，就把账单算清楚了，然后让有权限的人来做决定。整个过程是安静的、数据化的、没有情绪对抗的。

而范围管理做得差的团队，表面上很”灵活”，什么都能加，但代价会在第 60 天集中爆发，以加班、返工、上线故障的形式。

你花的每一分治理成本，买的不是流程，是团队对”承诺”这两个字的信任。当工程师相信迭代计划不会被随意推翻时，他们才会认真地做估算；当客户相信交付日期是算出来的而不是拍出来的时，他们才会配合你做优先级排序。

如果你的团队现在正处在”什么都能加、什么都延期”的状态，我建议你不要从流程文档开始，而是从今天开始做一件最小的事：把本周收到的所有变更请求列出来，逐条补上”为了做这个，我们打算不做哪个”。

这一列填完，你会立刻知道团队的真实负载状况，也会立刻知道，哪些变更是真的重要、哪些只是被随口说出来。剩下的事情，就只是把这套动作固化到系统里，让它每天自动发生。