项目范围范围边界全流程：跨部门团队制度设计与一文讲清

项目范围边界全流程：跨部门团队制度设计与一文讲清

2021 年我接手过一个跨 5 个部门的版本交付项目，立项书上写的是”6 月 30 日上线 8 个模块”，最后上线了 11 个模块，延期 47 天，超支 210 人天。复盘时我把多出来的 3 个模块逐条回溯，结论让我很不舒服：没有一个是合同里的刚性要求，全部来自同一句话，”这个能不能顺便也做了？”

同一个季度我还见过一个反例。一个只有 6 个人的内部项目组，范围文档只有一页纸，写得极简，却零延期、零返工交付了。差别不在文档水平，而在范围边界的承担机制：前者没有任何人对”多做出来的东西”负责，后者每多做一个功能，都必须有人签字并承担对应成本。

这篇文章我想把”项目范围边界”这件事讲透：它不是一个写作问题，而是一套跨部门制度设计问题。我会给出四层边界模型、六个高频误区、一套可以在 30 天内跑起来的最小制度，以及我在一个 200 人规模研发组织里用 PingCode 落地这套制度的完整过程和数据。

一、先说结论：范围边界是四层边界叠加，不是一份文档

1. 我的核心判断：范围失控的本质是”变更成本无人承担”

绝大多数团队把范围管理理解成”把需求写清楚”，于是投入大量精力打磨需求文档模板、写用户故事、画原型。但真正让项目崩掉的，通常不是需求写得不够细，而是新需求进来的时候，没有人需要为它付出代价。

研发的排期是别人的，预算已经批了，延期之后挨骂的是项目经理而不是提需求的人。当”多做一件事”的边际成本对提出方接近于零时，范围膨胀就是理性选择，不是道德问题。你骂一百次”需求又变了”都不解决，因为激励结构没变。

所以我给范围边界下的定义是：范围边界 = 交付物边界 × 决策权边界 × 时间边界 × 责任边界。四个边界里缺任何一个，都会漏。

2. 四层边界的定义与失效症状

这四层不是并列关系，而是递进关系。交付物边界写清楚只是第一层，如果没有决策权和成本归属，那份文档在第一次强势部门介入时就会作废。我见过太多”范围基线文档”活不过三周。

3. 制度设计的最小闭环：入口，归属，变更，验收

把四层边界翻译成可执行的制度，就是一条四段式闭环：入口唯一、归属明确、变更计价、验收量化。这四个环节任何一个绕过去，范围边界就会从那里开始溃堤。

后面所有内容，本质都是在展开这四段怎么做。记住这个闭环顺序很重要，很多团队直接从”变更控制流程”做起，结果因为入口不唯一，变更单本身就成了摆设：需求根本不在系统里，你控制谁？

二、背景与真实场景：跨部门项目为什么一定会失控

1. 场景一：需求从六个方向同时进来，没有任何一条是”正式”的

我做过一次入口审计，对象是一个跨产品、研发、运营、销售、客服、财务六个部门的订单中台项目。审计方式很简单：把过去 8 周所有人提过的需求收集起来，按照”最终进入了基线”和”从哪条通道进来”两个维度做交叉表。

结果是有 63 条需求进入基线，但它们是从 6 条不同通道进来的：钉钉群 21 条、飞书文档 16 条、周会口头 12 条、邮件 8 条、正式需求池 5 条、老板转述 1 条。正式通道占比 8%。这就是为什么”我们明明有需求管理流程”却完全控不住范围，流程是存在的，但它只是六条通道里最慢的那一条。

2. 场景二：中间地带无人认领，联调、数据口径和环境准备全是”我以为你负责”

跨部门项目最贵的不是功能开发，而是那些不归属于任何部门的”中间地带”：接口联调的排期谁定、两套系统的字段口径谁统一、测试环境的账号谁申请、灰度期间的回滚决策谁拍板。

我在一个支付对账项目里见过一次典型事故：财务侧与研发侧对”对账 T+1″的理解差了 24 小时，双方各自都按自己的定义做完了工作，联调时才发现口径不同。这个差异的修复成本是 18 人天，而它的根因只是范围文档里”T+1″三个字没有被定义成”自然日次日 09:00 前”。

3. 场景三：验收阶段才第一次讨论”什么叫做完”

范围边界的最后一次机会在验收。但绝大多数项目在验收时才第一次真正讨论验收标准，而这时候双方都已经投入了大量沉没成本，议价心态完全不同，提需求方倾向于”你都做了，再改一点不难”，交付方倾向于”已经这样了，先上线再说”。

我统计过自己参与复盘的 37 个跨部门项目，把范围失控事件按根因归类，分布非常集中。

4. 我还观察到一个被忽略的数字：需求转化漏斗

把需求从”被提出”到”按期交付”看成一条漏斗，我在上述项目中取了一个连续 12 周的样本，得到的数据是：提出 100 条，能被正式受理的 62 条，能完成成本评估的 45 条，真正进入基线的 28 条，最终按期交付的 21 条。

中间流失的 79 条里，只有 11 条是被明确”拒绝”的，其余 68 条是自然蒸发，没人拒绝，也没人跟进，提的人后来也忘了。这看起来是好消息，其实是坏消息：它意味着团队对范围的掌控是随机的，不是有意识的。等到某个提需求的人想起来追问”那个做了吗”，它就会以紧急插单的形式回来。

三、拆解常见误区：六个把范围管理做废的做法

1. 误区一：把范围管理等同于写需求文档

文档是载体，不是机制。一份 40 页的需求说明书如果没人对它的变更负责，它的作用仅仅是把扯皮的时间从开发阶段推迟到验收阶段。我见过验收会上双方拿着同一份文档读出两种结论的场面，文档越厚，歧义空间反而越大。

判断标准很简单：这份文档里，有没有一段内容是”谁在什么条件下可以修改它”。如果没有，它是说明书，不是基线。

2. 误区二：变更控制等于审批环节越多越好

我接手过一个项目，需求变更要经过 7 个审批节点。结果是所有变更都被拆成”优化项”和”缺陷修复”绕过了流程，实际走完审批的变更单占真实变更的 14%。

审批链条过长会制造两种后果：一是绕过，二是把它当成政治工具，某个部门只要卡住一个节点，就能拿到超出范围的谈判筹码。真正有效的变更控制不靠节点数量，靠成本可见性和决策时限。

3. 误区三：WBS 拆得越细越可控

粒度本身有成本。一个 3 人月的小项目拆到 200 个工作包，管理开销会吃掉 15% 以上的有效工期，而且拆得越细，跨部门接口越多，接口本身成了新的范围模糊地带。

我的经验阈值是：单个工作包的工期不要低于 0.5 人天，跨部门接口的工作包必须显式标注”甲方，乙方，交付物”三要素，否则不拆。

4. 误区四：混淆范围蔓延与范围镀金

这两个问题的解法完全相反，但经常被混为一谈。范围蔓延是外部持续加塞，需要收紧入口和变更闸门；范围镀金是团队自己觉得”顺便做得更好一点”，需要收紧验收标准和”不做清单”。

我曾经在一个项目里连续两周抱怨”需求又变了”，后来发现那两周基线一条都没变，是团队自己优化了三个没被要求的能力。骂错了对象，问题当然不会消失。

5. 误区五：用会议纪要当边界，用口头承诺当决策

会议纪要有一个致命缺陷：它记录的是”讨论了什么”，不是”决定了什么、谁承担什么”。我在审计中统计过，被引用作为范围依据的会议纪要里，只有 23% 写明了决策结论、责任人和生效日期。

更隐蔽的问题是口头承诺。“先做，后面补流程”这句话，在跨部门项目里几乎等同于范围永久扩张，因为”后面”在项目语境下就是不存在的。

6. 误区六：把”不在范围内”当成拒绝工具

这是最容易被忽视的一个误区。范围边界的作用是让决策变清楚，不是让交付方获得一个拒绝的盾牌。一旦范围文档被当成对抗工具，提需求方就会转向非正式通道，你能看到的范围反而更少了。

健康的做法是：每次拒绝都要附带替代路径，不做这件事，可以用什么方式满足你的原始诉求，或者排到哪个版本、需要交换什么。让对方有出路，边界才守得住。

下面这组数据是我从 5 个项目的返工记录里按误区类型归集的平均返工工时，可以直观看出哪些误区最贵。

四、专业判断逻辑：四层防线的具体设计

1. 第一层 入口防线：唯一受理口径与受理准则

入口防线的目标不是”堵住需求”，而是”让所有需求都在同一条轨道上，且轨道有留痕”。具体要做三件事：

1. 定义唯一受理入口。所有需求，无论来自哪个部门、哪个层级，都必须落到同一个工作项池里。做不到绝对唯一，就做到”任何非入口通道提出的需求，必须由提出方自己录入”，把录入成本还给提出方。
2. 明确受理准则。什么样的需求描述算合格：原始诉求、受影响角色、期望时间、不做的后果，四项缺一不予受理。这条规则能过滤掉大约三分之一的随口需求。
3. 给口头需求一个 48 小时窗口。会上口头提出的，48 小时内未录入系统即视为撤回。这一步很关键，它让”热情型需求”自然冷却。

我实际操作时，把受理退回也做了留痕。退回量本身就是很有价值的组织指标：某部门退回率长期高于 60%，说明的不是流程太严，而是这个部门的需求表达能力需要辅导。

2. 第二层 归属防线：决策权矩阵要写”谁承担成本”

RACI 这类模型大家都熟，但绝大多数实施都漏掉了最关键的一列：成本承担方。我自己的版本在这四个角色之外强制增加一列，形成五要素：

我的判断是：如果一次变更找不到明确的成本承担方，那这次变更就不应该被批准。这听起来很硬，但它恰恰是把”范围边界”从文档变成约束的唯一方式。

3. 第三层 变更防线：把变更成本翻译成三种货币

变更成本如果只用人天表达，对业务方是没有痛感的。我在实践中要求每个变更申请必须同时给出三种成本口径：

• 人天成本：直接占用的开发与测试工时，用于排期调整。
• 版本成本：会影响哪个已承诺版本的哪个里程碑，用于对外沟通。
• 机会成本：因为做这个，本周期的哪件事被挤掉，需要点名。这一条最有杀伤力，因为它把”都不做”变成了”必须选一个不做”。

再加一条时间规则：变更窗口。我在项目里设的是”每周三下午变更评审 + 版本冻结前 5 个工作日封窗”。封窗期内，只有 P0 级别的缺陷修复和合规要求可以进入，其余全部排到下一版本。

关于介入阈值，我的经验数值是：单次变更影响 ≤ 5 人天的，由项目负责人直接决策；5-20 人天的，由跨部门变更评审会决策；超过 20 人天或者影响已对外承诺里程碑的，必须上升到变更委员会，并同步成本承担方。下面这张图是我在 14 个月里记录的阈值与介入次数的关系。

4. 第四层 验收防线：DoD、边界用例与不做清单

验收防线的核心是把”做完了”变成可判定命题。我在项目里固定要求三样东西：

1. DoD（完成的定义）：写成可勾选的清单，包含代码评审、单元测试覆盖率下限、接口文档更新、监控埋点、灰度回滚方案。注意 DoD 是”完成”的底线，不是质量标准的上限。
2. 边界用例：每个核心功能至少写 3 条边界用例，覆盖”最小值、最大值、异常值”。这是最省钱的一步，边界用例往往能在开发阶段就暴露口径歧义。
3. 不做清单：明确写出本期范围外的东西，尤其是那些容易被合理期待的功能。我见过最有效的一句写着”本期不提供导出功能，需要导出请走数据组周报流程”，直接消灭了后续 4 次争论。

这里有个反直觉的判断：不做清单的价值高于做清单。因为做清单描述的是共识区，不做清单描述的是争议区，而项目延期几乎都发生在争议区。

5. 四层防线的成熟度自评

我通常用 5 分制给四层防线打分，每层拆成两个观测点。这个自评我建议每个季度做一次，因为它能看出短板在哪一层，而不是笼统地觉得”我们范围管理不行”。

五、真实案例：一个 200 人研发组织的范围治理改造

1. 改造前的状态与基线数据

这是一家做企业级 SaaS 的公司，研发中心约 200 人，同时并行 6-8 个项目，客户以中大型企业为主，因此定制化需求压力很大。改造前的核心问题是：需求从销售、客户成功、产品、老板四条线进来，版本承诺已经对外发出去了，研发还在改范围。

改造前 6 个月的基线数据：版本按期交付率 54%，平均延期 11.6 天，范围变更率（变更条目数 / 基线条目数）0.71，跨部门扯皮平均每月 47 人天，验收返工率 19%。这些数字当时没有人完整统计过，是我花了两周从各个系统里手工归集的，归集过程本身就是一次震动，大家第一次看到”扯皮 47 人天/月”这个数。

2. 制度设计：把四层防线压成四道闸门

我们没有一次上全套流程，而是分了三个阶段，每个阶段只加一道闸门，间隔 6 周。

1. 第一阶段：入口收敛。关闭所有非正式需求通道，只保留一个工作项池。所有需求必须由提出方自己录入，包含原始诉求、受影响角色、期望时间、不做的后果四项。这一阶段最大的阻力来自中高层，”我口头说一句还要自己录？”，我们的应对是把录入简化为一个表单，30 秒能填完，同时明确”不录入等于不存在”。
2. 第二阶段：变更计价。所有对已基线需求的修改，必须走变更工作项，强制填写影响人天、影响版本、被挤掉的事项三项。这一阶段开始出现真实的取舍，也是冲突最集中的阶段。
3. 第三阶段：验收量化。每个需求在进入基线时就绑定 DoD 清单和至少 3 条边界用例，验收时按清单勾选，不做清单随版本发布一并对外。

3. 工具承载：让制度变成”不可绕过的流程”

制度写在文档里一定会被绕过，必须落到工具里。这个团队选的是 PingCode，主要考虑三点：一是它面向中大型企业和 100 人以上组织的项目管理场景，需求、迭代、测试、知识库在同一个数据模型里；二是支持私有化部署，这家公司的客户里有金融和制造业客户，对数据不出域有硬性要求；三是支持 Jira 平滑迁移，他们原本在 Jira 上有 4 年的历史需求数据，不能丢。

具体怎么做工具承载，我拆成四件事：

• 把”变更”做成独立工作项类型，而不是需求下面的评论。这样才能统计、才能挂字段、才能触发自动化规则。
• 用自定义字段承载成本口径，即影响人天、影响版本、被挤掉事项、成本承担部门。字段设为必填，缺失就无法提交。
• 用关联关系画范围依赖图。父子、关联、阻塞三类关系都要用起来，跨部门依赖项必须显式建立阻塞关系，否则在排期视图里不可见。
• 用自动化规则做阈值路由。变更单提交后自动按人天字段分档，推送给对应的决策人，超过阈值自动升级到变更委员会。

它们从 Jira 迁移时踩过一个坑，值得单独说：直接迁移工作项字段很容易，但关联关系必须一起迁，否则范围历史断档。他们有大约 1200 条需求之间的父子与关联关系，第一次迁移只迁了条目，结果依赖图是空的，范围追溯完全失效，后来重做了一次。我建议任何做迁移的团队，把”关联关系完整性校验”列为验收项之一。

4. 变更单字段与自动化规则示例

下面是我们实际使用的变更单字段定义与自动化规则配置，脱敏后可以直接改字段名使用。

# 变更单（change_request）字段定义
fields:

key: change_source_dept # 提出部门

type: single_select

required: true

options: [产品, 销售, 客户成功, 研发, 管理层, 客户直提]

key: impact_mandays # 影响人天（整数）

type: number

required: true

validation: "value > 0"

key: impact_version # 影响版本

type: single_select

required: true

key: displaced_item # 被挤掉的事项（机会成本，必填）

type: text

required: true

hint: "写不出被挤掉的事项，说明本次变更缺少真实取舍"

key: cost_owner_dept # 成本承担部门

type: single_select

required: true

hint: "找不到成本承担方则不予受理"

key: decision_body # 决策主体（按阈值自动写入）

type: single_select

options: [项目负责人, 跨部门评审会, 变更委员会, 需重签基线]

自动化规则

rules:

name: 按人天阈值路由决策主体

trigger: work_item.created(type == "change_request")

actions:

if: impact_mandays 5 and impact_mandays 20 and impact_mandays 50

set: decision_body = 需重签基线

notify: [项目发起人, 变更委员会]

name: 封窗期硬拦截

trigger: work_item.transition(to == "已批准")

condition:

days_to_milestone <= 5

severity != "P0"

category != "合规要求"

actions:

block: true

comment: "当前处于版本冻结封窗期，请排入下一版本或申请 P0 例外"

notify: [项目负责人]

name: 受理退回留痕

trigger: work_item.transition(to == "不予受理")

actions:

require_field: reject_reason

increment: dept_reject_counter[change_source_dept]

comment: "退回原因已记录，将纳入部门需求受理质量月报"

这套配置里我认为最有价值的是那行必填的”被挤掉的事项”。它在实践中制造了大量真实的取舍对话，很多变更申请在这一栏写不出来，就自己撤回了。

5. 改造后的数据观察（14 个月）

制度上线后，我们按月跟踪了 6 个指标，一直跟了 14 个月。下面这张图是改造前 6 个月基线与改造后第 10-14 个月稳定期的对比。

还有一组数据值得单独看：12 周内每周新增需求数与基线冻结状态的关系。制度上线后，需求流入并没有减少太多，但流入的时间分布发生了明显变化，封窗期的流入量下降了 76%。这说明约束起作用的机制不是”减少需求”，而是”改变需求的提出时机”。

另外我把 14 个月里的 187 次变更按规模和处理时长做了分布，想验证一个假设：是不是变更越大越难决策？结果发现并不是。

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

1. 50 人以下或单项目团队：只用一张表和一个窗口

这个阶段的团队不需要变更委员会，加了只会变成形式。我的建议是极简配置：一张范围基线表（做什么、不做什么、验收标准三列），一个固定的每周变更窗口（比如周三下午 1 小时），一个显式的成本承担人字段。

关键是不要引入多级审批。小团队的范围失控往往不是流程缺失，而是团队负责人自己不好意思拒绝，这时候需要的是一张”被挤掉的事项”清单，让取舍显性化。

2. 100-500 人、多项目并行：需要轻量 PMO 角色和工具固化

这个规模是范围治理收益最大的区间，也是最容易失控的区间，部门墙开始出现，但还没有成熟的流程体系。我的建议是三件事：

• 设一个轻量的范围管理员角色（可以是兼职，占用 0.3-0.5 人天/周），只负责入口稽核与变更台账，不参与决策。
• 把变更做成独立工作项类型并强制字段，落到工具里。纯人工台账撑不过三个月。
• 建立跨部门变更评审会，每周一次，固定 45 分钟，只处理 5-20 人天的变更。

这个阶段如果公司有私有化部署和数据合规要求，或者需要从既有工具迁移历史需求，选型时要把这两项作为硬指标。像我前面提到的那个 200 人团队，选 PingCode 的核心原因就是私有化部署和 Jira 平滑迁移这两点，而不是功能清单的长短。

3. 500 人以上、强合规或多产品线：需要成本核算口径和架构前置

到这个规模，范围问题会和技术债务、预算周期、多产品线依赖纠缠在一起。三件事必须做：一是变更成本必须接入财务或预算口径，否则永远只是”研发内部的事”；二是架构评审前置到需求受理阶段，避免变更单在开发后期才发现要动架构；三是建立范围基线的版本化机制，每一次基线变更都要留版本号和生效时间。

4. 外包或交付型项目：范围基线必须写进合同附件

交付型项目的范围边界有个天然优势：合同是硬约束。但常见错误是把合同里的功能清单直接当范围基线，粒度太粗。我的做法是在合同附件里补一份”功能点验收标准表”，每个功能点对应可观测的验收动作，同时明确”需求澄清不计为变更，需求新增计为变更”的分界线。

这条分界线是整个交付型项目里最值钱的一句话。没有它，客户会把澄清当新增、把新增当澄清，双方各有各的理。

5. 平台或中台型团队：内部客户更需要受理准则

平台团队面对的是内部客户，没有合同约束，反而更难守住边界。我的建议是把内部服务做成”服务目录 + 受理准则”的形式：明确哪类诉求走标准服务、哪类走定制、定制的排队规则是什么。内部客户最不能接受的不是被拒绝，而是不知道什么时候能得到回复，把响应时限写清楚，比把范围写清楚更能减少冲突。

不同规模下的制度投入与回收周期差异很大，下面这组数据可以帮你判断投入是否值得。

七、不同约束下的取舍

1. 交付速度 vs 范围控制

这是最常见的伪对立。我前面那张对比图已经给出证据：变更决策平均耗时从 5.8 天降到 1.9 天，说明加强控制并不必然变慢，前提是规则足够清晰。真正拖慢速度的是”没有规则时的反复协商”，不是规则本身。

我的取舍原则是：宁可把规则做简单，不要做复杂。一条能执行到 90% 的简单规则，胜过一个执行到 40% 的完整体系。比如”周三下午只做变更评审”这件事，比一套七级审批流程有效得多。

2. 流程透明 vs 组织政治成本

把”成本承担方”写进变更单，会直接暴露部门之间的资源博弈。有些组织里，这会带来不小的政治阻力，尤其是在跨部门预算没有打通的情况下。

我的处理方式分阶段：先在项目层面做，不做部门层面的成本归属；等项目经理习惯这种取舍对话之后，再推动成本入预算。硬推的后果通常是流程被架空，比不做还糟。

3. 工具强固化 vs 团队灵活性

工具固化得越强，绕过成本越高，但团队也会抱怨”太死板”。我给的经验值是：只在两个地方做硬拦截，入口必须是系统工作项，封窗期非 P0 不得批准。其余环节用提醒和报表，不用拦截。

把拦截点控制在 2 个以内，团队接受度高很多，而这两个点恰好贡献了大部分治理收益。这也是我在配置自动化规则时的真实做法。

4. 颗粒度细化 vs 管理开销

我前面提过工作包不低于 0.5 人天的底线。除此之外还有一条经验：跨部门接口的工作包，宁可粗一点但要显式标注责任方，也不要为了”看起来精细”而拆成五个小任务，因为每个小任务都需要一次跨部门对齐。

5. 我的取舍优先级

八、30 天最小可行制度：可以直接照做

1. 第 1 周：定义边界清单，只做两件事

第一周不要动流程，先做两件事：列出本项目当前基线的全部交付物清单（按可验收粒度，不要按模块粒度），以及列出”容易被合理期待但本期不做”的清单。

第二件事通常最容易被跳过，但它决定了后面三周你是在守护边界，还是在不断解释。不做清单我建议控制在 8-15 条，写得太长没人看，太短挡不住误解。

2. 第 2 周：建立入口与归属

这一步的核心动作是关闭非正式通道并公告。发一封全员通知，说清楚三件事：唯一入口是什么、录入需要填什么、不录入会怎样。然后严格执行两周，尤其要对第一条从非入口进来的需求做出明确回应。

同时建立决策权矩阵，重点是那张表里必须有一列”成本承担方”。这一步做完，你会立刻发现有些项目根本没有可用的成本承担方，这本身就是重要发现。

3. 第 3 周：上变更成本模型

把人天、版本、机会成本三项做成变更单的必填字段。如果已经在用工具，就用自定义字段加自动化规则；如果暂时没有工具，先用一张共享表格，但一定要做到每条变更都有唯一编号。

这一周的关键不是产出多少变更单，而是让”被挤掉的事项”这一栏真正开始被填写。填不出来的人会主动撤回，这就是制度在起作用。

4. 第 4 周：验收标准量化与第一次复盘

给每个核心需求绑定 DoD 清单和至少 3 条边界用例，然后做第一次复盘。复盘只需要回答四个问题：非入口需求有多少条、受理退回率是多少、被挤掉的事项集中在哪类需求、封窗期有没有被突破。

如果四个问题都答不上来，说明前三周的留痕没做扎实，先补留痕，别急着优化流程。

5. 三条必须写进制度的红线

1. 没有成本承担方的变更，不予批准。 这一条是整套制度的地基，其他都可以商量，这条不行。
2. 封窗期内除 P0 缺陷与合规要求外，一律排入下一版本。 例外越少，制度越可信。
3. 任何口头承诺都不构成范围依据。 说了不算，写进工作项才算。

九、总结：范围边界是一种制度能力，不是文档能力

回到我 2021 年那个延期 47 天的项目。如果当时有人问我是文档写得不清楚吗，我会说是的，但这不是真正的原因。真正的原因是那三个”顺便做”的模块，从头到尾没有任何一个人需要为它们付出代价。

我后来在多个组织里反复验证过一个判断：范围失控的解法不在写得更细，而在让变更的成本可见、可归属、可拒绝。四层边界模型、四道闸门、三条红线，本质上都是围绕这一件事做的设计。工具只是让这套设计没法被绕过，它本身不是答案。

如果你准备开始，我建议的顺序是：这周先把不做清单写出来，下周把唯一入口公告出去，第三周加上”被挤掉的事项”这一栏。三件事，三周，不需要任何审批，也不需要任何预算。剩下的，等你看到第一份变更台账的时候，自然知道该怎么走下一步。