项目阶段如何做好阶段负责人？项目成员实操方法与操作步骤

我带过一个 11 人的 MES 上线项目，六个阶段、六位阶段负责人。复盘时发现一个很扎心的数字：真正推动阶段结果的只有 2 个人，另外 4 位在阶段里的全部动作，是把上游的原话转述给下游，再把下游的问题带回给项目经理。项目整体延期 23 天，其中 17 天延期恰好发生在这 4 位负责人的阶段里，而他们每个人在阶段结束时的自评都是“我已经尽力了”。

这不是态度问题，是角色定义问题。阶段负责人不是“汇报接口人”，而是这个阶段里的临时 CEO，他在有限的阶段窗口内，对目标、资源、取舍、交付负全责。绝大多数团队把“阶段负责人”写进了项目计划表，却没有给他对应的授权、工具和判断标准，于是这个角色名存实亡。

下面我会按“结论，场景，误区，判断逻辑，操作步骤，案例数据，行动建议，取舍”的顺序，把这件事拆到可以直接照做的程度。文中引用的数据一部分来自我在制造、金融、SaaS 三类项目中的复盘记录，一部分来自与使用 PingCode 的中大型团队交流时拿到的样本，涉及推演的地方我会明确标注。

一、先给结论：判断一个阶段负责人合不合格，只看三个硬标准

我判断阶段负责人是否合格，从来不看他的职级、工龄或者汇报能力，只看三件事。这三件事任何一件不成立，这个阶段的失败就已经在第一天埋好了。

1. 他能不能“冻结”阶段内的三样东西

阶段负责人必须在阶段启动后的 48 小时内冻结三样东西：阶段范围、验收标准、关键路径。冻结不等于永不改变，而是任何改变都必须经过他同意并留下记录。

我见过太多“假冻结”。比如某银行的信贷中台项目，需求澄清阶段的负责人在启动会上说“需求清单暂时定这样”，结果两周内业务方陆续加了 37 条需求，没有一条走过变更评审。阶段结束时交付物被退回，理由是“和业务期望不一致”。不能冻结范围的阶段负责人，本质上只是一个记录员。

2. 他能不能“调动”跨职能资源

阶段负责人的权力边界通常小于项目经理，但他在阶段内必须能直接向至少三类人提出工作要求：上游交付方、本阶段执行成员、下游接收方。

如果每一次资源调动都要经过项目经理转达，这个阶段负责人的实际管理半径就是零。我在一个 200 人的装备制造企业看到过极端情况：测试阶段负责人需要借调一名自动化测试工程师，走流程走了 6 天，等工程师到位时，阶段只剩 4 天。这不是流程问题，是授权设计问题。

3. 他能不能“自主”做阶段内的取舍

阶段内一定会出现冲突：进度和质量的冲突、范围和资源的冲突、局部最优和整体交付的冲突。阶段负责人必须被明确授权在这些冲突中拍板，并且他的拍板不能被随意推翻。

判断方法很直接：问他一个问题，“如果阶段快结束时，你发现还有两个中优先级功能没做完，你有权决定砍掉、延期还是加人吗？”如果他的回答是“我要先问一下领导”，那么这个阶段实际上没有负责人。

4. 一句话公式

把上面三条压缩成一句可以贴在阶段看板上的话：阶段负责人 = 阶段范围内的最高决策者 + 阶段结果的第一责任人 + 阶段风险的第一升级人。

这三者缺一不可。只有决策权没有责任，会变成独断；只有责任没有决策权，会变成背锅；只有升级权没有决策权，会变成甩责。

二、真实场景：阶段负责人为什么总是变成“挂名角色”

要解决问题，得先看清它在真实项目里长什么样。下面三个片段，几乎覆盖了我见过的大部分失败模式。

1. 场景一：阶段启动会开成了任务宣读会

某零售企业的会员系统重构项目，需求阶段启动会开了 25 分钟。项目经理念了一遍阶段目标，把任务清单发到群里，说“有问题的会后找我”。会上没有人问验收标准，没有人确认上游交付时间，没有人讨论关键路径。

三周后阶段结束，交付物被下游打回。下游设计负责人说：“我以为他们只要把需求列出来就行，没想到还要业务目标映射。”这就是启动会没有对齐出口标准的典型后果。

2. 场景二：阶段负责人是“资历最老的执行者”

很多团队选阶段负责人，标准是“谁在这个领域最资深”。这个标准在技术攻坚阶段有效，但在跨职能阶段往往失效。

我在一个车规级软件项目里见过：开发阶段的负责人是团队里代码能力最强的人，但他不擅长也不愿意做协调。阶段里他个人产出了 42% 的核心代码，同时该阶段跨部门接口对齐只完成了 60%，最终集成测试阶段多花了 11 天补接口。最会干活的人，往往不是最该被提拔为阶段负责人的人。

3. 场景三：阶段交接靠口头和群消息

阶段之间的交接是缺陷成本放大的关键节点。我跟踪过一个 5 阶段项目的交接缺陷流向：上游阶段遗留 10 个未澄清问题，设计阶段没有被识别出来，到开发阶段暴露 18 个，到测试阶段暴露 34 个，上线后触发 8 个线上事故。

这 8 个事故的修复成本，按人时折算，相当于在上游把它们澄清清楚所需成本的 60 倍以上。这就是为什么我一直强调：阶段负责人的核心产出不是“我完成了什么”，而是“我交接出去的东西能不能被 100% 接收”。

三、拆解常见误区：七个把阶段负责人做废的坑

下面七个误区，我在不同项目里反复见到。它们的共同点是：看起来都是“规范动作”，实际上都在削弱阶段负责人的作用。

1. 误区一：把阶段负责人当成汇报接口人

典型表现是要求阶段负责人“每周五提交阶段周报”。周报本身没问题，但如果这是他在阶段里唯一被考核的动作，他就会把精力放在写周报而不是解决问题上。

判断方法：翻一翻这个阶段的会议记录，如果他在会上说的话 80% 是“我了解到的情况是……”，而不是“我决定……”或者“我要求……”，那他就是接口人，不是负责人。

2. 误区二：认为阶段负责人必须懂全部技术细节

这是最常见的能力错配。阶段负责人的核心能力是判断与取舍，不是自己动手。他需要知道“这件事做不完的后果是什么”，而不需要知道“这段代码怎么写”。

我习惯用一个比例来判断：阶段负责人的时间投入中，自己动手执行不应超过 40%，阶段越大这个比例应越低。如果一个大阶段（80 人天以上）的负责人还在承担 60% 以上的编码任务，这个阶段一定会在中后期失速。

3. 误区三：用周报代替阶段管理

周报是结果记录，不是管理动作。真正的阶段管理动作包括：每日风险扫描、关键路径偏差检查、资源到位率确认、出口条件达成度评估。

我在一个 SaaS 公司做过对照：同一类阶段，一组只做周报，另一组做每日 10 分钟站会加阶段看板。到第 6 周时，只做周报的那组进度偏差率达到 35%，做站会的那组稳定在 1%-2% 之间。

4. 误区四：把阶段交接当作“发一封邮件”

邮件发出不等于交接完成。交接的完成标准只有一个：下游阶段负责人能够用自己的话复述他要接收的东西，并且书面确认。

我在项目里推行过一个硬规则：交接必须包含一次 30 分钟的面对面（或视频）走查，下游抽检 20% 的交付物，抽检通过才算接收。这个规则上线后，我们统计的交接缺陷遗留率从 21% 降到 6%。

5. 误区五：阶段负责人只有责任没有授权

责任和权力必须同时授予。如果一个阶段负责人被要求“保证阶段按期完成”，但没有权限锁定团队成员、没有权限拒绝不合理变更、没有权限调动测试环境，这个承诺就是空话。

更糟的是，团队会从中学习到一个隐含规则：承诺不重要，反正做不到也不用负责。这比延期本身对组织的伤害更大。

6. 误区六：阶段负责人越级直接指挥

有些阶段负责人因为没有正式授权，就绕过职能经理直接给执行成员派活。短期看起来效率高，长期会破坏组织秩序，导致职能经理开始“藏资源”。

正确的做法是在阶段启动时，由项目经理和职能经理共同签署一份《阶段资源确认单》，明确哪些人在本阶段归阶段负责人调度，调度规则是什么。授权写在纸面上，比靠人际关系推进要稳得多。

7. 误区七：阶段结束后不做结构性复盘

很多团队的复盘停留在“这次延期是因为需求变更太多”这种描述层面。这种复盘没有行动项，也不会改变下一次的结果。

有效的复盘必须回答三个问题：哪一条出口条件没有提前写清楚？哪一个风险升级时延迟了超过 24 小时？下一次阶段启动时应该增加哪一条检查项？每个问题的答案都必须落到具体的模板修改上。

四、专业判断逻辑：四权四责模型与阶段健康度评估

我给阶段负责人设计的判断框架叫“四权四责”。它的价值在于把模糊的角色描述变成可检查的清单。

1. 四权：阶段负责人必须被授予的四种权力

（1）范围解释权，当需求描述出现歧义时，由他裁定以哪个解释为准，并记录裁定理由。

（2）任务分派权，在本阶段资源确认单范围内，他可以直接向执行成员派出任务并调整优先级。

（3）阶段质量判定权，他有权判定某交付物是否达到出口标准，未达标的可以拒绝签字放行。

（4）风险升级权，他有权绕过常规汇报层级，直接把风险升级给项目经理或项目发起人，并要求在约定时限内得到答复。

这四项权利中，最容易被忽略的是第三项。很多团队给了阶段负责人分派任务的权力，却没给他“拒绝放行”的权力，结果他只能把明显不达标的东西交出去，然后在下一个阶段被追责。

2. 四责：阶段负责人必须承担的四种责任

（1）交付责任，对本阶段出口物清单的完整性、正确性负责。

（2）进度责任，对关键路径的偏差负责，偏差超过阈值必须主动升级。

（3）门禁责任，对出口评审的执行质量负责，不能出现“评审会开了但没人真的检查”的情况。

（4）交接责任，对下游能否顺利接收负责，直到下游书面确认为止。

请注意，这四项责任里没有“团队成员绩效评价”。阶段负责人不是职能经理，他不应该承担绩效打分职责，否则他会因为顾忌人情而不敢说真话。

3. 阶段健康度：五个可以每周检查的指标

阶段负责人不能凭感觉判断阶段是否健康。我一般用五个指标做周度扫描，任何一项低于阈值就触发专项处理。

4. 什么时候该换阶段负责人

换人是最后手段，但有三种情况必须换。第一种是阶段负责人连续两周主动隐瞒真实进度，这不是能力问题而是诚信问题。第二种是阶段负责人与关键上游负责人之间存在不可调和的冲突，且已经影响交付。第三种是阶段目标发生实质性变化，原负责人的能力结构不再匹配。

除此之外的情况，我更倾向于补授权、补资源、补工具，而不是换人。频繁换阶段负责人会造成交接损耗，一次交接平均损失 3-5 个有效人天。

5. 一个反直觉的判断：前段加时间，总周期反而更短

很多项目经理担心“给阶段负责人更多门禁检查会拖慢进度”。我跟踪的样本显示恰好相反。在需求澄清和方案设计两个前置阶段增加门禁检查，短期会让这两个阶段各多花 1-2 天，但能让开发、测试、验收三个后置阶段合计压缩 6-9 天。

五、实操方法与操作步骤：从接任到交接的完整流程

这一节是全文最实用的部分。我把它拆成七个动作，按时间顺序排列，你可以直接照着做。

1. 接任前 24 小时：读完三份文件，问清五个问题

阶段负责人在正式接手前，必须读完三份文件：项目章程（了解阶段在整体中的位置）、上游交接单（了解你拿到的是什么）、阶段出口标准（了解你要交出什么）。

同时必须问清五个问题，缺一个就不要签字接手：

1. 这个阶段如果不合格，直接后果是什么？谁来判定？
2. 我能在本阶段直接调度的人有哪几个？名字、投入比例、来自哪个职能？
3. 上游交付物的验收责任在谁？如果我发现问题，多久能拿到修正版本？
4. 我有权拒绝放行的标准是什么？拒绝之后谁来仲裁？
5. 阶段结束时，我的交付物由谁接收？接收标准有没有书面版本？

2. 第 1 天：开一场 60 分钟的阶段启动会

启动会的目标不是宣读任务，而是对齐出口。我用的固定议程是：出口标准逐条确认（15 分钟）、关键路径与依赖识别（15 分钟）、风险预登记（15 分钟）、角色与授权确认（10 分钟）、行动项与责任人（5 分钟）。

会议必须产出四样东西：一份被逐条确认过的出口清单、一张带依赖关系的关键路径图、一份初始风险登记册、一份阶段资源确认单。

3. 第 2-3 天：把阶段任务拆到 2 天粒度

拆解的粒度决定管理的精度。我要求阶段负责人把所有任务拆到不超过 2 天的粒度，关键路径上的任务不超过 1 天。超过这个粒度的任务，意味着你无法在周中发现问题。

拆解完成后，把阶段出口标准写成机器可读的检查清单。下面是我常用的 YAML 模板，可以直接放进项目管理平台的自定义字段里。

stage: 需求澄清阶段
owner: 张伟

start_date: 2025-03-03

duration_days: 15

exit_gate:

id: G1

desc: 需求条目 100% 进入需求池并关联业务目标

evidence: 需求池截图 + 目标映射表

id: G2

desc: 每条需求有唯一且可测试的验收标准

evidence: 需求规格说明书 v1.0

id: G3

desc: 需求评审一次通过率 >= 90%

evidence: 评审记录表

id: G4

desc: 与业务方签署阶段确认单

evidence: 扫描件归档路径

artifacts:

需求规格说明书 v1.0

需求追溯矩阵

阶段风险登记册

handover:

receiver: 设计阶段负责人

sampling_ratio: 20%

accept_criteria: 抽检需求可 100% 追溯到业务目标

confirm_by: 书面确认 + 平台状态流转

4. 第 1 周：建立信息线、风险线、质量线

阶段负责人要同时运营三条线。信息线保证你知道真实情况，风险线保证问题能被及时处理，质量线保证出口标准不会在最后一天才知道没达到。

（1）信息线：每天 10 分钟站会，只问三个问题，昨天完成了什么、今天计划什么、有什么阻塞。不要让站会变成进度汇报会。

（2）风险线：风险登记册必须有明确的触发条件和升级时限。下面是我常用的字段结构。

{
"risk_id": "R-014",

"stage": "开发实施阶段",

"description": "第三方支付接口联调环境 4 月 10 日才可用",

"probability": "高",

"impact": "阶段延期 5-8 天",

"owner": "阶段负责人",

"response": "先做本地 Mock 联调，正式联调顺延，压缩测试缓冲",

"trigger": "4 月 8 日仍未拿到环境账号",

"escalate_to": "项目经理 + 采购负责人",

"escalate_deadline": "2025-04-08T18:00",

"status": "open"

}

（3）质量线：每周做一次出口条件达成度盘点，不是等到阶段最后一天才检查。盘点结果直接写进阶段看板，让所有人可见。

5. 阶段中期：做一次 90 分钟的专项健康度检查

阶段过半时，召开一次专项检查会。议题只有四个：出口条件达成度与剩余工作量的匹配情况、关键路径是否发生变化、未关闭风险的处置进度、资源到位率是否需要升级。

这次会议的核心产出是一个决定：继续按原计划推进，还是启动范围裁剪或时间重估。我建议在这个会上就做出裁剪决定，而不是拖到阶段最后一周。拖到最后一周，你唯一的选择就是牺牲质量。

6. 阶段末期：出口评审与交接包

出口评审不是走过场。我要求评审必须逐条核对出口条件，每一条都要有证据，没有证据视为未达成。评审结论只有三种：通过、有条件通过（附整改清单和时限）、不通过。

交接包的内容我固定为六项：交付物清单及存放路径、出口条件达成证据、未关闭问题清单及处置计划、风险移交说明、下游使用注意事项、书面确认单。任何一项缺失，交接不算完成。

7. 阶段结束后 3 天内：做一次 45 分钟的结构性复盘

复盘只讨论三件事：哪条出口条件应该在启动时就写清楚？哪个风险升级延迟超过 24 小时，原因是什么？下一次同类阶段启动时应新增哪条检查项？每个答案都要落到模板的修改上，而不是停留在感想层面。

8. 阶段负责人的动作节奏表

六、案例与数据观察：一个 180 人组织的阶段负责人改造

下面这个案例来自我深度参与的一家 180 人规模的智能硬件企业。他们做的是软硬件一体的交付项目，单个项目通常分 6-8 个阶段，跨研发、测试、供应链、交付四个职能。

1. 改造前的状态

改造前，他们的阶段负责人由各部门主管兼任，共 6 人。阶段出口条件写在项目计划里，但没有人逐条核对。阶段交接以邮件为主，平均每次交接产生 9 个需要澄清的问题。

我们统计了改造前 8 个项目的阶段数据：阶段按期完成率 58%，缺陷逃逸率（遗漏到上线后的问题数 ÷ 总缺陷数）12%，阶段平均周期 42 天，跨职能资源到位率 82%。

2. 改造的三个动作

（1）把阶段负责人从“部门主管兼任”改为“离交付最近的人担任”，并配套下发《阶段资源确认单》，明确可调度人员名单。

（2）把出口条件从文档搬到项目管理平台，做成阶段门禁，未达成时无法流转到下一阶段。这一步他们用的是 PingCode。

（3）建立阶段看板与周度健康度扫描，五个指标对所有干系人可见。

选择 PingCode 的原因很实际：他们属于中大型企业，研发与供应链团队合计 180 人，需要跨职能的阶段流转和细粒度的权限控制；同时因为涉及硬件参数与客户交付数据，必须支持私有化部署。另外他们原本用 Jira 管理研发流程，历史数据量很大，PingCode 支持 Jira 平滑迁移这一点直接降低了切换成本，也符合他们国产替代的选型方向。

3. 改造后的数据

改造覆盖 9 个项目、51 个阶段。运行 6 个月后，数据变化如下：阶段按期完成率从 58% 提升到 84%，缺陷逃逸率从 12% 降到 4.5%，阶段平均周期从 42 天缩短到 36 天，跨职能资源到位率从 82% 提升到 94%，每次阶段交接的平均澄清问题数从 9 个降到 2.6 个。

4. 这个案例里最容易被忽略的一个细节

改造过程中最有效的动作，不是上了平台，而是把《阶段资源确认单》变成了必须签字的流程节点。在改造前，阶段负责人说自己“调不动人”；改造后，因为名单是职能部门负责人签字确认的，调度效率立刻提升。

工具解决的是可见性和可追溯性，授权解决的是意愿问题。这两件事必须同时做，只做一件都无效。这可能是我在这个案例里得到的最重要的一条经验。

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

现实项目很少具备理想条件。下面按常见的六种情况给出具体建议。

1. 情况一：一个人同时兼两个以上阶段负责人

这种情况在小团队很常见。建议按“阶段规模加权”的方式分配你的精力：把 80% 的时间投入到规模最大或风险最高的那个阶段，其余阶段采用“轻管理”模式，只保留每日站会和风险登记册，出口评审放在关键节点而非每周。

同时必须做一件事：为每个兼任阶段指定一个“副手”，明确在你不在场时可以代为做哪些决策。没有副手的兼任，本质是把风险集中在你一个人身上。

2. 情况二：矩阵组织，阶段负责人没有行政权

矩阵组织里的阶段负责人，最容易陷入“求人办事”的状态。破解方法是把非正式权力制度化：争取一份由项目经理和职能经理共同签署的资源确认单，把口头承诺变成书面约定。同时把每次资源不到位的记录留存下来，在阶段复盘时用数据说话，而不是用情绪说话。

3. 情况三：多供应商或外包参与交付

多供应商场景下，阶段负责人的核心工作从“管理任务”变成“管理接口”。建议在每个阶段启动时明确三张表：接口清单（谁给谁什么）、责任边界表（哪些问题由谁负责）、争议升级路径（出现分歧时的裁决顺序）。

尤其要注意验收标准的写法。对外部供应商，验收标准必须可测量、可复现，避免出现“满足业务需要”这类无法判定的表述。

4. 情况四：阶段负责人中途换人

中途换人是不得已的选择，但可以降低损耗。交接时要求原负责人完成三件事：整理一份“未关闭问题及真实背景”说明、陪同新负责人参加一轮完整站会、在关键干系人面前做一次正式交接说明。

我统计过，完整走这三步的中途交接，平均需要 3 个有效人天完成过渡；如果只做文档交接，过渡期会拉长到 8-10 天，而且新负责人通常会重复踩一遍旧坑。

5. 情况五：强合规行业（医疗器械、车规、金融）

这类行业的阶段负责人多了一项责任：合规证据的完整性。建议在出口条件里直接加入合规检查项，例如设计历史的可追溯性、需求变更的审批链完整性、测试记录的签署完整性。

不要把合规检查留到审计前临时补。合规证据的补齐成本通常是过程记录的 5-10 倍，而且补出来的证据说服力更弱。

6. 情况六：项目已经延期，临时换阶段负责人

这时不要急着换人。先做一次 48 小时的诊断：延期是范围蔓延、资源不足、依赖阻塞还是技术风险导致。如果原因是前三者，换人解决不了问题，应该做范围裁剪和资源补充。只有确认是决策能力或执行力缺陷时，才考虑换人。

八、不同情况下的取舍

阶段管理本质上是取舍的艺术。下面六组取舍，我在项目里几乎每次都要面对。

1. 取舍一：阶段门禁的严格程度

门禁太松，问题流向下游，成本放大；门禁太严，阶段负责人会把大量时间花在形式上，交付速度下降。我的建议是分层设置：核心出口条件（如验收标准、接口定义、合规证据）必须硬性通过；辅助条件（如文档格式、命名规范）允许有条件通过并在下一阶段补齐。

2. 取舍二：阶段负责人是否专职

专职意味着人力成本上升，不专职意味着阶段管理投入不足。我的经验分界线在 80 人天：小于 80 人天的阶段不必专职，大于 200 人天的阶段必须专职，中间区间用半专职（管理 55% 左右）。强行让一个大阶段的负责人边写代码边管阶段，几乎必然在中期失速。

3. 取舍三：自研工具与商用项目管理平台

自研的好处是贴合自身流程，坏处是维护成本和扩展速度。商用平台的好处是开箱即用、迭代快，坏处是需要适配。我的判断是先看流程是否稳定。如果你的阶段模型已经稳定运行一年以上，自研才有意义；如果流程还在调整，用商用平台更快。

4. 取舍四：私有化部署与 SaaS

对于涉及客户数据、硬件参数、金融信息的项目，私有化部署往往是硬约束，不是偏好问题。中大型组织在选型时，应该把私有化部署能力和历史数据迁移能力放在与功能同等的位置评估。像 PingCode 这类主要服务中大型企业及 100 人以上组织的平台，在私有化部署和 Jira 平滑迁移上的支持，对于从既有工具切换过来的团队来说，能显著降低迁移期的阶段管理真空风险，也是很多团队把它作为国产替代方案的原因之一。

5. 取舍五：文档完整度与交付速度

文档不是越多越好，而是越“刚好够用”越好。我的判断标准是：如果下游阶段负责人能凭这份文档独立开展工作，不需要回头问任何问题，这份文档就够用了。超过这个标准的部分，收益递减。

但有一条底线不能破：验收标准、接口定义、未关闭问题清单这三类文档，任何情况下都不能省。它们省下来的成本，一定会在下游以数倍的形式还回来。

6. 取舍六：阶段负责人与项目经理的权限重叠

权限重叠会导致两件事：决策变慢、责任模糊。建议用一张边界表把两者区分清楚。

九、结语：把阶段负责人做成组织能力，而不是个人英雄主义

回到开头那个 MES 项目。那 4 位“挂名”阶段负责人后来我们做了调整：给他们补了资源确认单、出口条件和风险升级权，没有换人。下一个项目里，同一批人负责的阶段按期完成率从 63% 提升到了 88%。

这让我确认了一件事：阶段负责人做不好，绝大多数时候不是人的问题，是设计的问题。组织没有给他边界、授权和工具，却期待他凭责任感把阶段扛下来，这是不现实的。

我在这篇里想要传递的最独特的判断是：阶段负责人的价值不在于他做了多少事，而在于他把多少不确定性提前消除了。一个优秀的阶段负责人，80% 的贡献发生在阶段启动的头三天和出口交接的最后两天，中间那段，反而是他最“闲”的时候，因为该埋的雷都已经埋好了。

如果你现在正好在负责某个阶段，我建议你接下来七天只做三件事：

1. 今天：把出口条件写成可逐条检查的清单，每条都要有证据形式。
2. 本周内：开一场 60 分钟的启动会，逐条对齐出口条件，产出一份资源确认单并拿到签字。
3. 本周内：建立风险登记册和每日 10 分钟站会，把信息刷新率提上来。

这三件事做完，你负责的阶段就已经超过了大多数项目的平均水平。剩下的，是把它变成习惯，再变成组织里所有人都默认遵循的标准动作。