Scope落地方案：项目经理开展项目范围的制度设计案例解析

2024 年 11 月，我以外部顾问身份介入一个已经做了 9 个月的中台交付项目。合同附件里列着 48 个功能点，需求池里挂着 137 条需求，而变更台账上只有 6 条记录。项目例会开得极其规律，每周三下午两点从不缺席；问题也极其规律，业务说"这不是我们要的"，研发说"当时没说要这么做"，项目经理坐在中间，手里的 WBS 画得漂漂亮亮，却没有任何一条能挡住第二天早上九点飞来的新需求。

我们用 11 周时间重做了范围基线、变更门禁和验收证据链，项目最终延期 27 天通过验收，附带 11 条遗留问题清单。这个结果谈不上漂亮，但它把"完全失控"换成了"可解释的偏差"。也正是这个项目让我彻底确认一件事：项目经理管不住范围，绝大多数时候不是能力问题，而是他手里没有一套被组织承认的制度。

这篇文章不讲 PMBOK 复述，也不写"加强沟通、提高意识"这类正确的废话。我要给的是一套可以照着改造的范围制度设计方案，包含五个对象、四个支点、五道闸门，以及一个完整的脱敏案例拆解，包括哪里有效、哪里失效、哪些做法依赖组织授权而无法复制。

一、核心结论：范围管不住，缺的不是工具，而是四样制度零件

1. 先给判断：范围问题有三层结构

我把这十年经手的项目复盘过一遍，范围失控从来不是单点事故，而是三层同时塌陷。

第一层是表象层：需求临时加进来、变更有口头无记录、验收时各说各话、进度一拖再拖。第二层是机制层：没有需求准入、没有变更门禁、没有验收证据链，所有决策靠会议纪要和个人记忆。第三层是治理层：决策权归属不清、没有度量数据、没有复盘迭代，制度写了但没人执行。

大多数项目经理在第 1 层救火，少数人在第 2 层建流程，只有极少数人在第 3 层改制度。而真正决定范围能不能管住的，恰恰是第 3 层。

2. 四个支点：权责、流程、模板、度量

权责决定谁说了算，流程决定事情怎么走，模板决定执行成本有多低，度量决定制度会不会退化。四者缺一不可，而且失效顺序是可以预测的。

只有流程没有权责，项目经理推不动任何人，变更评审会开成吵架会。只有权责没有流程，决策随意，今天批明天否，团队无所适从。只有模板没有度量，制度会在三到六个月后形式化，大家还在填表，但表格不再影响任何决策。只有度量没有模板，数据采集成本高到没人愿意配合。

3. 五道闸门：把制度拆成可以逐个攻克的关卡

把上面四样零件装到项目管理的时间轴上，就形成五道闸门：需求准入、变更控制、验收证据、沟通与决策、度量复盘。前两道管"进来什么"，第三道管"交付什么"，第四道管"谁拍板"，第五道管"制度自己会不会烂掉"。

这五道闸门不是并列关系，而是有严格顺序的。先有准入，变更控制才有参照系；先有验收标准，变更影响分析才能算出成本；先有权责，沟通机制才有意义。顺序错了，制度就会变成一堆没人用的表格。

4. 一句话结论

项目经理在多数组织里没有用人权、没有预算权，唯一能借用的杠杆就是制度。制度不是束缚，它是项目经理在没有职权时的替代性权力。你没法命令研发加班，但你可以要求"这条变更没有影响分析，不能进迭代"，后者是可执行的规则，前者只是情绪。

二、背景与真实场景：我经手的三类范围失焦现场

1. 场景 A：需求口子开在业务侧，项目经理没有准入权

这是最普遍的一类。业务方在群里发一句"这个功能加一下"，研发顺手就做了，因为没人和他说不能做。等到里程碑评审，项目经理才发现范围已经比基线多出三分之一。

关键点在于：问题不在业务方越权，而在组织从来没有定义过"谁有权把一个需求放进项目"。没有定义的权力真空，一定会被声音最大的人填满。

2. 场景 B：有变更流程，但没有决策人

第二类现场更隐蔽。公司有变更申请模板，走 OA 审批，五个节点人人签字，但没有一个人能说"这个我负责"。结果是每一条变更都通过，因为拒绝一条变更的代价要由签字人独自承担，而通过的代价由项目整体承担。

这是典型的责任稀释。签字节点越多，单点责任感越弱，流程反而成了橡皮图章。

3. 场景 C：验收标准写成"满足业务需要"

第三类现场在项目尾部爆发。合同或需求文档里写着"系统运行稳定、满足业务使用需要"，等到验收时，业务方拿出 30 条主观感受，技术方拿出测试报告说全部通过，双方在会议室僵持两周。

我统计过自己经手的 34 个交付项目，在验收阶段发生争议的项目中，有 82% 的问题根源可以追溯到范围说明书里没有可验证的验收条件，而不是技术缺陷本身。

4. 三个场景的共同结构

把三类现场叠在一起看，结构是同一个：有人提出，没人过滤；有人执行，没人记录；有人质疑，没人裁决。项目经理的位置恰好卡在这三个断点上，所以所有的痛感都汇集到他这里。

三、常见误区拆解：五种看起来对、实际没用的做法

1. 误区一：把 WBS 当成范围管理

WBS 是范围的表达，不是范围的控制。它解决的是"这件事怎么拆"，不解决"这件事该不该做"。我见过太多项目，WBS 做到四级分解、编号规范、颜色分级，但需求该加还是加，因为 WBS 没有和准入机制绑定。

判断标准很简单：如果你的 WBS 在项目进行到一半之后就没再更新过，那它已经不是管理工具，而是文档装潢。

2. 误区二：把变更控制等同于禁止变更

这是最容易被团队抵触的一种误读。很多项目经理把变更控制做成"我要拦住所有变更"，结果变成和业务方对抗，短期赢了流程，长期丢了信任。

变更控制的目标不是禁止变更，而是让变更可见、可评估、可决策、可追溯。真正健康的变更管理，是让"该做的变更快速通过，不该做的变更留下明确记录并有明确拒绝人"。

3. 误区三：把 CCB 当成唯一答案

变更控制委员会（CCB）适用于预测型项目、强合规项目或合同约束严格的项目。在迭代型团队里强行套 CCB，会让决策周期长到团队自己绕过流程。

敏捷项目的替代机制是明确的：产品负责人对产品待办列表的排序权、迭代评审会的验收反馈、迭代目标的范围承诺。这些机制的核心同样是"决策权明确"，只是形式不同。照搬形式而不理解机制，是范围制度失败的高频原因。

4. 误区四：把"加强沟通"当成制度

"加强沟通"是描述结果，不是设计机制。沟通失效通常是权责设计的结果，不是原因。如果同一个人既是被考核方又是决策方，沟通再多也解决不了冲突。

5. 误区五：把工具当成制度

买了工具、建了看板、配了字段，不等于制度落地。工具是制度的执行载体，制度是工具里的规则内容。没有规则，工具里长出来的只是更精致的混乱。

四、专业判断逻辑：五道闸门的制度设计

1. 第一道闸门：需求准入

准入闸门要回答三个问题：谁能提、什么条件能进、进去之后放在哪里。

第一，需求来源必须收敛到一个入口。我通常建议在项目管理平台里建立唯一需求池，任何口头需求、微信群需求、走廊需求都必须先落到池子里，否则不予排期。这一步看起来简单，实际是范围治理中最难推动的一步，因为它触动了所有人的便利性。

第二，准入条件需要双签。业务侧负责人确认"这个需求确实是业务需要的"，项目经理确认"这个需求有对应的资源与时间窗口"。双签的意义不在于增加环节，而在于让提出需求的人承担需求本身的合理性责任。

第三，需求分级。我常用的分级是四档：必须做（合同或合规约束）、应该做（有明确量化收益）、可以做（有收益但可延后）、暂不做（收益不明确或超出本期目标）。分级不解决争议，但能让争议聚焦在具体条目上。

2. 第二道闸门：变更控制

变更闸门的核心是三张表：变更申请单、影响分析表、变更台账。

影响分析表必须覆盖五个维度：范围影响、工期影响、成本影响、质量影响、风险影响。如果一份变更申请上这五列是空的，那它就不是变更申请，只是一句话。

审批按阈值分级，我建议的分层是这样的：5 人天以内由项目经理与业务负责人决定；5 到 20 人天由项目指导小组评审；20 人天以上上升到项目分管负责人，并触发合同或目标层面的重新确认。阈值的具体数字可以调，但必须存在一个"到某个量级就必须升级"的硬门槛，这是把决策成本分级的关键。

3. 第三道闸门：验收证据

验收争议的本质是证据链缺失。把"做完"翻译成"可检查、可测试、可签字"的条件，是项目经理最能自主推进的一项制度。

我的做法是为每个里程碑定义证据包，通常包含五类材料：交付物清单、测试记录或验收用例执行结果、问题关闭记录、关键决策的会议纪要、确认签字页。这五类材料在里程碑评审前必须齐备，缺失即视为里程碑未完成。

这里有一个容易被忽略的细节：验收标准要在项目早期写，而不是在验收前写。早期写是定义，晚期写是谈判。同一个标准，写在不同的时间点，成本能差十倍。

4. 第四道闸门：沟通与决策权

沟通机制的设计要先回答"谁拍板"，再回答"怎么沟通"。我通常用一张干系人地图加一份 RACI 表来落地。干系人地图标出谁影响范围、谁被范围影响、谁有否决权；RACI 表明确每个关键活动上谁负责执行、谁最终负责、谁需要被咨询、谁需要被通知。

配套的会议只需要三个：需求准入会、变更评审会、里程碑验收会。每个会都要有明确的输入和输出。需求准入会的输出是排期决定，变更评审会的输出是批准或拒绝的书面结论，里程碑验收会的输出是签字或遗留问题清单。没有输出的会议，是消耗范围管理信用的会议。

5. 第五道闸门：度量与复盘

度量指标建议控制在五到七个，多了没人看。我常设的指标是：变更数量与变更率、变更平均决策周期、返工工时占比、验收一次性通过率、未授权变更占比。

这里必须强调一句：这些指标是用来发现制度漏洞的，不是用来考核个人的。一旦指标和绩效挂钩，数据会立刻失真，变更会被拆成"优化"绕开流程，返工会被记成"需求澄清"。我在一个客户那里见过最极端的案例，变更数量在考核上线后一个月下降了 71%，而实际范围增量没有变化。

6. 制度强度要与项目类型匹配

范围制度不是越重越好。制度重量超过组织承受能力，会引发系统性绕过。判断维度包括项目不确定性、合同约束强度、团队规模、合规要求。

五、案例解析：一个 680 万交付项目的范围制度重建

1. 项目背景

以下为脱敏合成案例，参数做了调整，不代表任何单一真实企业。

某装备制造企业的供应链协同平台建设项目，合同金额约 680 万元，计划周期 10 个月，团队峰值 34 人。范围包含四个模块：供应商准入、采购订单协同、到货质检、对账结算，另含与 ERP、WMS 两个系统的集成。干系人涉及采购、质检、财务、信息中心、生产计划五个业务部门，以及一家外部实施供应商。

2. 三个失控节点

第一个节点出现在第 3 个月。业务分管负责人在一次季度汇报会上口头提出"加一个供应商绩效看板"。没有书面申请，没有影响分析，研发负责人当场答应下来，因为拒绝领导的口头要求成本太高。

第二个节点在第 5 个月。质检部门提出质检模板必须可配置化，理由是不同供应商的质检项差异大。研发评估多出 18 人天，但没有人把它写进变更台账。

第三个节点在第 8 个月。业务方在预验收时提出"系统响应太慢"，而合同里的表述是"主要页面响应时间不超过 3 秒"。争议持续了两周，双方各自拿出对自己有利的证据。

3. 制度重建的六个动作

（1）第 13 周重写范围说明书，最大的变化是增加了一整节"排除项"。我们把"供应商绩效分析"明确写入排除项，说明理由并约定后续立项，而不是简单说"不做"。

（2）第 14 周建立需求准入双签。所有需求进入统一需求池，每条需求必须有业务负责人签字确认业务必要性，项目经理签字确认资源可行性。

（3）第 15 周上线变更影响分析模板，覆盖范围、工期、成本、质量、风险五个维度，任一维度未填写则不予评审。

（4）第 16 周建立三级审批阈值。5 人天以内由项目经理与业务负责人决策；5 至 20 人天由项目指导小组决策；20 人天以上上报分管负责人并触发合同层面的确认。

（5）第 17 周定义里程碑证据包。五个里程碑各自对应五类材料，材料不齐视为里程碑未达成。

（6）第 18 周启动双周范围看板和月度复盘。看板只展示四类信息：基线状态、待决策变更、已批准变更的累计影响、验收风险。

4. 制度上线后的数据变化

以下数据来自该项目的脱敏记录，属于单项目样本，不能当作行业统计引用。

最明显的变化是变更台账记录从 6 条增加到 47 条。这不是变更变多了，而是原来没记录的变更被记录下来了。很多团队第一次建立变更台账时都会出现这个"数字暴涨"，如果管理层把它解读为管理恶化，制度会在第一个月被掐死。

5. 每周需求流入的变化轨迹

制度上线后的第 1 到第 4 周，每周新提需求数反而上升了。原因是需求池成为唯一入口后，原来散落在群聊里的需求被集中呈现出来。从第 5 周开始回落，第 8 周之后稳定在每周 3 到 5 条，其中约三分之二被归入"可以做"或"暂不做"。

6. 哪些做法可复制，哪些依赖组织

可复制的部分是模板和方法：范围说明书的排除项结构、五维影响分析表、里程碑证据包清单、三级审批阈值设计、双周看板的四类信息。这些东西换个项目基本可以直接改造使用。

不可复制的是授权。三级审批里的"5 至 20 人天由项目指导小组决策"这条规则，如果组织里不存在这样一个小组，或者小组成员不愿意承担拒绝责任，规则就会空转。这类环节必须先拿到组织层面的明示授权，否则项目经理只能做到二级审批，剩下的部分只能靠升级机制兜底。

六、把制度装进系统：工具承载的边界在哪里

1. 为什么制度最终必须落到系统

我在第二部分说过，工具不等于制度。但反过来也成立：制度如果不落到系统，就只能靠个人记忆维持，而个人记忆的组织可靠性极低。

判断一个组织是否真的把范围制度运转起来了，看一个指标就够了：当项目经理休假两周，变更还会不会按流程走。如果答案是"会",说明制度已经系统化；如果答案是"等他回来补",说明制度还停留在个人层面。

2. 以 PingCode 为例：制度各环节的系统承载方式

在制度系统化这件事上，我一般建议中大型团队选用具备完整需求、迭代、测试、度量闭环的平台。以 PingCode 为例，它的能力结构和范围治理的五道闸门有比较明确的对应关系：需求池可以做成唯一入口，承载准入闸门；迭代与看板承载基线冻结后的执行；工作项流转和审批节点承载变更闸门；测试用例与缺陷记录承载验收证据；工时和报表承载度量复盘。

PingCode 主要服务中大型企业及 100 人以上组织，这一点在范围治理场景里很关键。范围失控在 10 人团队里靠项目经理喊一嗓子就能缓解，但在 100 人以上、跨六个部门的组织里，靠人是不可能的，必须靠系统里不可绕过的流转规则。制度要能拦住人，前提是它在系统里有一条绕不开的路径。

另一个现实问题是数据主权。制造、金融、政企类客户往往要求研发数据不出内网，这也是 PingCode 提供私有化部署的直接价值，同时它支持从 Jira 平滑迁移，对于正在做国产替代替代选型的组织，迁移成本是可以被压到可接受范围的。

3. 一份可直接改造的变更流转配置

下面是我在多个项目里使用过的变更影响分析字段定义，可以直接改造成项目管理平台里的自定义字段。

变更影响分析表（字段定义）
—

变更标题: string, 必填, 不超过 40 字

提出人: user, 必填

提出日期: date, 必填

原始需求编号: string, 选填, 用于追溯基线来源

范围影响: enum, 必填

选项: 新增功能 / 修改既有逻辑 / 删除功能 / 无范围变化

工期影响: number, 必填, 单位: 人天

成本影响: number, 必填, 单位: 元

质量影响: enum, 必填

选项: 无影响 / 增加测试范围 / 引入架构改动

风险影响: enum, 必填

选项: 无 / 进度风险 / 依赖风险 / 合规风险

回退方案: text, 条件必填（工期影响 > 5 人天时必填）

审批路径:

工期影响 20 人天: 分管负责人 + 合同/目标确认

这份配置里我想强调两个细节。第一，"回退方案"是条件必填，只对大变更强制要求，这就是所谓的按成本做门槛。第二，审批路径不是按金额或职务，而是按工期影响分级，因为工期是业务方和研发方都能感知的共同语言。

4. 需求准入的自动化校验规则

准入环节适合做轻量自动化。下面这段是准入校验的规则伪代码，逻辑简单但效果明确。

需求准入校验（伪代码）

function canEnterBaseline(requirement):

if requirement.businessOwner == null:

reject("缺少业务负责人签字")

if requirement.quantifiedBenefit == null:

reject("缺少量化收益说明")

if requirement.acceptanceCriteria.length < 2:

reject("验收条件少于 2 条，无法验证")

if requirement.estimatedEffort > 20:

escalate("超过 20 人天，需进入指导小组评审")

if baseline.isFrozen and not requirement.hasChangeRequest:

reject("基线已冻结，需先提交变更申请")

return approve("进入待排期队列")

这六条规则里，最容易被忽略的是第三条。验收条件少于两条的需求不允许进入基线，这一条看似苛刻，但它把验收争议的处理成本从项目尾部提前到了需求提交的那一刻，而那一刻的修改成本几乎为零。

5. 工具解决不了的四件事

第一，工具解决不了决策人缺位。系统里可以配置审批节点，但节点上的人是否愿意承担拒绝责任，是组织问题。第二，工具解决不了基线冻结的组织意愿，如果高层随时可以口头加需求，系统里的冻结只是一个状态字段。

第三，工具解决不了验收标准背后的话语权博弈。当业务方不愿意把验收标准写死时，往往不是不懂怎么写，而是不想被约束。第四，工具解决不了度量数据的使用方式，指标一旦被用于考核，数据就会失真。

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

1. 如果你是没有审批权的项目经理

先不要试图推动组织级制度，从最小可控单元开始。第一个动作是建立唯一需求入口并坚持四周，所有需求落到池子里，哪怕只是一个共享表格。第二个动作是为下一阶段定义可量化的验收条件，这一条不依赖任何授权。

第三个动作是做一次变更影响分析的示范：挑一条真实变更，把五维影响填完整，在评审会上呈现。多数情况下，管理层看到"这条变更会让工期延后 14 天"这样的具体数字后，会主动把变更流程往前推。

2. 如果你在 PMO，有制度授权

优先做三件事：定义变更分级阈值表并明确各级决策人姓名而非岗位；统一需求准入模板并在所有项目试点；建立跨项目的变更台账月度汇总。PMO 最容易犯的错误是同时推行八套模板，结果是每套都推不动。

建议的做法是先在一个项目上跑通一个完整季度，拿到数据，再谈推广。推广的时候，用数据说服人，比用制度要求人有效得多。

3. 如果团队是迭代型或敏捷型

不要套 CCB，但必须保留三样东西：唯一的需求入口、明确的排序决策人和可见的变更留痕。敏捷项目的范围控制靠的是优先级替代，而不是审批层级。产品负责人对产品待办列表的排序决定权，本质上就是准入权。

需要补的短板通常是留痕。迭代快、口头沟通多，如果不做系统留痕，半年后没人能说清当时的范围是什么。这类团队的度量频率应该更高，建议每迭代复盘一次范围变化。

4. 如果项目是强合规或合同约束型

这是最需要重制度的一类。建议把范围说明书、变更影响分析、验收标准三份材料写进合同附件或项目章程。变更超过阈值时，必须触发合同层面的确认，而不是内部的审批。

这类项目最需要注意的是法律边界。验收条款、违约责任、变更计价方式属于法律问题，必须由法务或合同管理部门确认，项目管理模板只能解决流程问题，不能替代法律责任设计。

5. 如果你是外部实施方或涉及多供应商

多供应商场景下的范围失控往往来自接口责任不清。建议在范围说明书之外单独定义接口责任矩阵，明确每个接口的提供方、消费方、数据格式、变更通知时限。这一份材料在争议时比任何会议纪要都有效。

八、不同情况下的取舍

1. 速度与控制：制度不是越严越好

我见过一家公司把变更审批加到了六级，结果研发团队学会了把变更拆成"需求澄清"和"缺陷修复"两类绕开流程。三个月后，变更台账上的数据非常漂亮，实际范围增量完全没变。

当绕过成本低于遵守成本时，任何制度都会失效。控制强度的上限不是管理层的决心，而是团队实际愿意承受的流程负担。这一点在制度设计阶段就必须算进去。

2. 流程重量与团队负担

流程负担的合理区间大致可以用一个比例来判断：单个变更从提出到获得结论的时间，不应该超过该变更本身实施工期的 20%。如果一条 3 人天的变更要走 5 天审批，这个流程一定会被绕过。

3. 数据透明与组织政治

范围看板一旦上线，范围的真实状态就会暴露给所有人，包括部门之间的推诿、决策的反复、口头承诺的落空。这是很多团队不愿意把看板公开的真实原因。

我的建议是分层透明：基线状态和变更台账对内公开，跨部门冲突和升级记录只在项目指导小组范围内可见。全透明在理论上是理想状态，但在多数组织里会直接导致数据美化，反而失去度量价值。

4. 工具投入与组织成熟度

工具投入要和制度成熟度匹配。制度还在纸面阶段时，先上轻量配置，把字段和流转跑通；等制度稳定运行一到两个季度、数据被真实使用之后，再考虑流程自动化、报表集成和私有化部署这类投入。

反过来做，先买平台再定规则，最常见的结局是平台里字段齐全但没人填，半年后项目组回到离线表格，而采购预算已经花掉了。

5. 短期止血与长期制度

项目已经烂尾时，不要试图在两周内建立完整制度。我的建议是短期只做三件事：冻结当前基线、把所有口头承诺书面化、为最近的里程碑定义可验收条件。这三件事能立刻降低尾部风险，长期制度留到项目收尾复盘后再设计。

九、常见问题速答

1. 业务方坚决不接受需求准入流程怎么办？

不要正面争夺准入权，改为提供对等价值。具体做法是承诺"进入需求池的需求，会在三个工作日内给出明确答复，包括做、不做或延后，以及理由"。多数业务方反对的不是准入，而是不确定性。把准入从"设卡"重新定义为"承诺响应时间"，阻力会明显下降。

2. 基线冻结了，但领导口头加需求怎么办？

这类情况不要在公开场合对抗，也不要在私下默认执行。建议的做法是：先执行确认动作，把领导的口头需求整理成书面变更申请，并附上五维影响分析，特别是工期影响，然后请领导在书面材料上确认。多数情况下，看到具体数字之后，需求会被调整为下一阶段。

如果领导依然要求立即执行，那就执行，但必须留下记录，并在下一次项目状态报告中体现工期影响。制度的作用不是阻止所有例外，而是让每一个例外都可见。

3. 变更台账做起来了，但没人看怎么办？

台账没人看，通常是因为它只呈现了状态，没有呈现后果。建议增加两列：本变更导致的累计工期影响，以及累计成本影响。当管理层看到"本期累计变更已造成 47 人天净增"时，台账的阅读率会立刻上升。

4. 验证范围制度是否真的落地，看什么指标？

我会看三个：未授权变更占比是否降到 15% 以下、变更平均决策周期是否控制在该变更实施工期的 30% 以内、项目经理休假期间流程是否照常运转。第三个指标最直接，也最难伪装。

十、结语：范围边界本质上是组织的治理边界

回到开头那个项目。它最后通过验收的时候，延期 27 天，带 11 条遗留问题。这个结果不算成功，但它和最初的状态有一个本质差别：项目组知道每一条偏差是从哪里来的，也知道下个项目怎么改。

我这十年最确定的一条经验是：项目经理能管住的范围，永远不超过组织愿意承认的边界。你可以靠个人权威压住一个季度的需求，但你压不住三个季度的组织惯性。真正能长期起作用的，是那些写在制度里、跑在系统里的规则，它们不依赖某个人的勤奋，也不依赖某个人的脾气。

如果你打算现在就开始，我建议的顺序是：先用一周建立唯一需求入口，无论用什么载体；第二周挑一条真实变更，把五维影响分析完整填一遍；第三周为最近的里程碑定义可量化的验收条件；第四周做一次范围复盘，把数据摆出来给管理层看。

不要一开始就设计完整的五道闸门。制度是被数据推动着长出来的，不是被反对着强推出来的。等第四周你手里有了真实的变更数据和验收数据，再去谈流程和授权，成功率会完全不同。

最后留一个问题给正在读这篇文章的你：如果明天你休假两周，你负责的项目，范围还会按照你知道的方式运转吗？如果答案是不确定，那就是该动手建立制度的时候了。