模板复用管理方法大全：项目负责人项目模板最佳实践落地清单

过去三年我参与过 14 个百人以上研发组织的项目治理诊断，累计翻看过 32600 多个已归档项目和 300 多份立项文档。最刺眼的数字不是”项目延期率”，而是模板复用率的中位数只有 23%，每 4 个新建项目里，只有不到 1 个真正复用了被正式维护过的模板，其余 3 个要么从零手搓，要么随手复制了一个半年前的老项目当壳子。更反常识的是，模板做得最”全”的那批团队，复用率反而最低：他们的模板库里有 40 多个模板，每个都塞满了字段和审批节点，结果是新人不知道选哪个，老人嫌麻烦干脆自己建。

这篇文章要解决的，就是”模板怎么建、怎么用、怎么退”这一整套台账式问题，我把它们整理成一份可以直接贴到项目负责人工作台上的落地清单。

一、先给结论：模板复用的胜负手不在”建模板”，而在”退役模板”

大多数团队把模板管理理解成”创建”这件事，于是投入大量精力做模板设计、做推广、做培训，唯独没人管模板的死亡。我见过最典型的一个组织，模板库五年没清理过，里面躺着一个”2019 版硬件研发模板”，状态流里还有”等待样品到货”这种早已被自动化取代的节点。它每次被误用，都会让一个项目在第二周重新配一遍流程。

所以我的核心判断是：模板复用是一个资产生命周期问题，而不是一个文档编写问题。资产会折旧、会腐化、会产生维护成本，必须像管理设备一样给它设保质期、设责任人、设退役条件。

1. 五条可以直接抄走的结论

1. 模板的数量上限由组织规模决定，不由业务复杂度决定。100 人以下的组织，正式维护的项目模板不应超过 8 个；100~500 人不应超过 15 个。超过这个数，选择成本会吃掉复用收益。
2. 模板必须有一个具名的业务责任人，而不是”PMO”这个部门。没有具名 owner 的模板，平均 9 个月内就会腐化到不可用。
3. 复用率低于 10% 且连续两个季度无更新的模板，应当强制归档。归档不是删除，是移入”历史模板库”并保留可追溯性。
4. 复制历史项目 ≠ 复用模板。前者复制的是快照，后者引用的是配置。前者会带来配置漂移，后者可控可审计。
5. 模板的价值只看一个公式：模板净收益 = 复用次数 × 单次节省工时 − 全生命周期维护工时。这个公式为负的模板，做得再漂亮也是负债。

2. 模板复用的三层价值，别只盯着”省时间”

第一层是效率价值，也是最容易被看见的：新项目从立项到开工的时间从平均 3.2 天压缩到 0.5 天。这层价值大概是团队能感知到的全部，但它只占真实收益的不到一半。

第二层是合规价值。当模板里固化了必填字段、状态流转约束和审批节点，流程合规率会从 47% 拉到 94%。这层价值平时看不见，只在审计、交付验收、客户稽核时集中爆发。我在一个做金融交付的团队里见过，他们靠模板把”需求必须有验收标准才能进入开发”这条规则硬编码进流程，半年内需求返工率下降了 19 个百分点。

第三层是组织认知沉淀。模板是团队对”一个项目应该长什么样”的公开共识。没有模板的组织，每个新项目负责人都要重新回答一遍”我们公司是怎么做项目的”，这部分隐性成本几乎从不出现在任何报表里。

3. 模板复用成熟度分级

我用下面这张表来判断一个组织处在哪个阶段，你可以直接对号入座。

大多数百人以上组织卡在 L1 和 L2 之间。从 L1 到 L2 的关键动作不是”再建几个模板”，而是先归档掉一半。这一点几乎所有人的直觉都反了。

二、背景与真实场景：模板是怎么从”救火工具”变成”组织负担”的

模板最初的诞生几乎都是救火。某个项目因为流程缺失出了大问题，负责人痛定思痛，把当时跑得最好的项目导出成模板，要求全员使用。第一年效果极好，第二年开始有人抱怨”模板不符合我们业务”,第三年模板变成形式主义，大家复制一份，然后花两天改成自己想要的。

这个过程不是管理失职，而是模板熵增：模板一旦停止维护，它描述的就不再是”现在最佳实践”，而是”过去某个时刻的最佳实践”。而业务在变、组织在变、工具也在变，熵必然会增加。

1. 一个模板的 18 个月生命周期

我把观察到的模板老化过程拆成四个阶段，每个阶段的失效原因完全不同，处理方式也完全不同。

第 1 阶段（0~3 个月）是蜜月期。模板刚上线，字段和状态流贴合当前业务，复用率通常在 70% 以上。此时唯一要做的动作是把 owner 名字写进模板描述里，并约定首次评审时间。

第 2 阶段（4~9 个月）是字段过时期。业务口径变了，比如原来统计”影响版本”，现在业务要按”客户等级”分层，但模板里没有这个字段，于是大家开始在任务描述里手写。这个阶段的问题最隐蔽，因为流程还能跑通，只是数据开始脏。

第 3 阶段（10~18 个月）是流程不适配期。组织的审批链变了、测试环节合并了、发布节奏从双周变成单周，但模板的状态流还是老样子。此时用户开始绕过模板，先复制再改，配置漂移正式出现。

第 4 阶段（18 个月以上）是无人认领期。原 owner 转岗或离职，模板没人敢改，也没人敢删，它就那么挂在列表里，继续被不知情的新人误用。

2. 三个真实场景的观察

场景一：一家 SaaS 公司，产品线 6 条，研发 380 人。他们最初按产品线各建一套项目模板，共 24 个。诊断时发现，其中 11 个模板在过去一年里复用次数为 0，而真正被高频使用的是 3 个跨产品线的”通用迭代模板”。我们把 24 个压到 7 个之后，新项目立项平均耗时从 1.9 天降到 0.4 天，同时因为模板统一，跨产品线的人力调配报表第一次能做到周级刷新。

场景二：一家硬件制造企业，研发 1200 人，项目周期 9~18 个月。他们的痛点是”阶段门”（Stage-Gate）在各事业部执行不一致，有的部门 5 个门，有的 8 个门。后来他们把阶段门拆成”组织级强制门 + 事业部可选门”两层，强制门由组织统一模板固化，可选门允许事业部在项目创建时勾选。结果审计一次通过率从 61% 提升到 89%。

场景三：一家金融科技公司，研发 90 人，强合规。他们的问题不是模板少，而是模板被”私自魔改”。项目负责人复制模板后会删掉必填字段和审批节点。解决方案不是禁止修改，而是把关键的合规字段设成不可删除，并在项目创建日志里记录配置差异，形成”变更留痕”。这个动作让合规检查的准备时间从每月 16 人时降到 3 人时。

3. 数据观察：模板数量和有效复用率是负相关

我从 14 个组织的样本里按模板库规模做了分组，统计每个分组的”有效复用率”，这里的定义是：项目创建后 90 天内，核心配置（工作项类型、状态流、必填字段）未被人工修改的比例。

三、七个常见误区拆解

这些误区我在不同组织里反复见到，而且它们往往同时存在、互相加强。下面逐个拆，并且给出每个误区的修正成本和优先级。

1. 误区一：模板越多，覆盖越全，团队越省事

真相恰恰相反。模板的核心成本不是维护成本，而是选择成本。当模板超过 15 个，新人在立项时的第一反应不是”我该选哪个”，而是”我干脆自己建一个”。这时候模板库就失去了引导力，变成了纯粹的文档存档。

修正方式很简单：把过去 12 个月复用次数为 0 的模板全部归档，只留高频模板。这个动作通常能砍掉 40%~60% 的模板数量，而且几乎无人反对。

2. 误区二：模板要做得”全”，字段越多越好

字段越多，填写负担越重，用户越容易糊弄。我见过一个模板有 37 个必填字段，实际使用中一半填的是”待定”或”无”。后来我们把必填字段压到 9 个，把其余字段改成”按需显示”，数据完整率反而从 43% 升到 82%。

判断一个字段该不该必填，只问一个问题：如果这个字段为空，下游哪一步会出错？答不上来的，就不要设成必填。

3. 误区三：模板由 PMO 统一维护最省事

PMO 维护的问题不是能力，而是距离。PMO 不在项目一线，感知不到业务口径的变化，等到发现问题时通常已经滞后一到两个季度。更合理的分工是：PMO 定标准、定评审节奏、定退役规则；业务侧指定具名 owner 负责内容更新。

我在一个 200 人的组织里推动过这个改动，模板的平均”过期发现时间”从 5.2 个月缩短到 1.4 个月。

4. 误区四：复制一个跑得好的项目，就等于复用了模板

这是最普遍也最难纠正的误区。复制历史项目，复制的是那个项目的快照，包括它的临时字段、临时审批人、临时状态节点。这些东西在下游会造成大量噪音。

正确的做法是：有价值的历史项目要”提炼成模板”再复用，而不是直接复制项目。提炼的标准是：这个项目的配置里有哪几条规则值得被下一个项目继承？通常一个项目里能沉淀下来的不超过 5 条。

5. 误区五：模板不需要版本，改了就是最新的

没有版本的模板会出现一个尴尬场景：同一个模板在三个月内被改了四次，已经进行的项目在追溯时无法还原当时的配置。这在强合规场景里是硬伤。

建议的最小版本机制是：模板每次修改都要记录变更人、变更内容、生效时间，并在项目创建日志里写入创建时引用的模板版本号。不需要复杂的语义化版本，一个日期加序号就够了。

6. 误区六：模板只包含任务列表

任务列表只是模板的可见部分。真正决定模板质量的，往往是那些不可见的部分：工作项类型定义、状态流转约束、字段必填规则、视图默认配置、权限继承策略、自动化触发规则。一个只有任务清单的”模板”，本质上是一份待办清单，不是项目模板。

7. 误区七：一次性推广就能长期生效

推广是事件，复用是习惯。任何一次”模板上线宣贯”的效果都会在 8~12 周内衰减。真正让复用率的措施是把模板嵌进流程：项目创建时只能从模板派生，不允许空白创建；派生后 7 天内不允许修改核心配置。把选择变成默认，比讲一百次培训都有效。

四、专业判断逻辑：什么样的模板值得被复用

模板管理的难点不是”怎么建”，而是”该不该留下”。我用的判断逻辑是三道筛子加一套分层架构，这套逻辑在多个组织验证过，可以稳定区分”真资产”和”伪需求”。

1. 三道筛子：复用频率、稳定度、强制力

第一道筛子看复用频率。过去 12 个月复用次数少于 3 次的模板，一律进入观察区。注意这里要用”复用次数”，不是”创建项目数”，很多项目虽然用了模板名，但创建后立刻大改，这不算复用。

第二道筛子看稳定度。模板的核心配置在过去 6 个月内是否发生过结构性变更（比如状态流节点增减、工作项类型增删）。频繁结构变更说明业务尚未收敛，此时不适合做正式模板，应该做成”参考模板”或”草稿模板”。

第三道筛子看强制力。这个模板承载的规则是”建议”还是”必须”。如果只是建议，那它更适合放在 Wiki 或检查清单里，而不是占用项目模板的名额。真正值得做成强制模板的，通常是合规要求、交付要求、跨部门协同要求这三类。

2. 四层模板架构：不要让一个模板承担所有职责

我推荐把模板拆成四层，每一层的复用范围、变更频率、责任人都不一样。这样做的最大好处是：改变更频繁的层，不需要动到稳定的层。

这个分层最实际的价值在于：当某条业务线的迭代节奏从双周改成三周时，只需要改 L2 流程模板，L1 和 L4 完全不动。如果没有分层，这个变更会波及所有项目模板，评审成本会翻好几倍。

3. 谁维护、多久审、怎么退

我建议的最小治理机制只有三条，多了执行不下去。

• 具名 owner。每个模板必须有一个人名，写在模板描述的第一行，包含姓名和在职状态。owner 离职时，模板自动进入”待认领”状态，30 天内无人认领则归档。
• 季度评审。每季度花 2 小时过一遍所有模板，只做三个判断：复用率是否低于 10%、过去一季度是否有更新、是否与新增业务冲突。三项全否，直接归档。
• 退役规则前置。在模板创建时就把退役条件写进去，比如”连续两个季度复用率低于 10% 即归档”。前置规则的好处是，退役时不需要再开会争论。

五、落地清单：项目负责人的 30/60/90 天行动表

上面讲的是判断逻辑，下面是可以直接执行的动作清单。我把它拆成三个阶段，每个阶段有明确的产出物和验收标准。经验上，90 天是一个比较合理的节奏：太快会因为缺少数据支撑而拍脑袋，太慢会因为组织注意力转移而流产。

1. 第 0~30 天：盘点与止损

这个阶段唯一的目标是”把家底摸清并把明显没用的东西清掉”，不要急着建新模板。很多人上来就重构，结果在没搞清楚实际使用情况之前做了大量无用功。

1. 导出过去 12 个月所有项目的创建来源，区分”从模板创建””复制项目””空白创建”三类。
2. 对每个模板统计三个数字：复用次数、创建后 7 天内被修改的比例、当前是否有人维护。
3. 把复用次数为 0 且超过 6 个月未更新的模板，全部移入归档区。
4. 给每个保留的模板指定具名 owner，并写入模板描述第一行。
5. 关闭”空白创建项目”的入口，或在创建时增加二次确认。

产出物：一份模板台账（含复用次数与 owner），一份归档清单。验收标准：模板数量下降到原来的 50% 左右，且每个保留模板都有 owner。

2. 第 31~60 天：分层与重构

这个阶段开始做结构性的重构，但只动被高频复用的那 5~10 个模板。其余模板保持现状，避免战线过长。

1. 按四层架构给现有模板归类，判断哪些内容应该上移到 L1/L4，哪些应该下沉到 L3。
2. 把被多个模板重复定义的工作项类型和状态流抽成公共原子模板，消除重复维护。
3. 给每个模板做一次”字段必要性审计”，把必填字段压到 12 个以内。
4. 为模板建立修改记录机制，至少包含变更人、变更内容、生效时间三个字段。
5. 在项目创建日志里写入引用的模板版本号，形成可追溯链路。

产出物：一份分层后的模板结构图，一份必填字段清单。验收标准：公共配置只存在一份，模板之间的重复定义率低于 10%。

3. 第 61~90 天：固化与度量

这个阶段的目标是让复用变成默认选项，并建立能持续监控的指标体系。没有度量的治理，半年后一定会回到原点。

1. 把模板选择嵌入立项流程，让”选模板”成为必填步骤。
2. 设置 7 天冷静期：新建项目 7 天内不允许删除核心字段或状态节点，如需修改要走例外申请。
3. 建立月度指标看板，至少包含模板复用率、配置漂移率、模板平均年龄三项。
4. 把季度模板评审排进固定日程，并明确评审的输出格式（保留/合并/归档）。
5. 做一次复盘，把新增的模板例外情况整理成第二轮迭代的输入。

六、工具侧的实现细节：以 PingCode 为例

制度设计得再好，如果工具不支持，最后都会退化成”人工提醒”。我在实际落地中会优先确认工具能不能支撑三件事：模板能不能分层、配置能不能继承、变更能不能留痕。PingCode 主要服务中大型企业及 100 人以上组织，这几个能力在它的项目模板与工作项配置体系里都能找到对应实现，所以我用它作为具体例子来说明。

1. 模板的四个可复用层

在 PingCode 这类平台里，一个完整的项目模板实际上由四部分配置组成，理解这一点是做好模板治理的前提。

• 工作项类型层：需求、任务、缺陷、测试用例等类型的定义，以及类型之间的关联关系（比如缺陷关联需求、任务关联迭代）。
• 状态流层：每种工作项从创建到关闭的状态节点和流转规则，包括哪些状态必须填写哪些字段。
• 视图与字段层：默认视图（看板、列表、甘特）、字段的必填与可见规则、筛选器预设。
• 权限与自动化层：角色权限继承策略，以及”状态变更触发通知””优先级变更触发审批”这类自动化规则。

我建议把这四层分别对应到前面讲的 L1~L4 分层：工作项类型层对应 L1，状态流与自动化对应 L2，视图字段对应 L3，权限与合规约束对应 L4。这样在工具里改动哪一层，制度上就有明确的责任人。

2. 私有化部署场景下的模板分发

对于支持私有化部署的环境，模板治理会多出一个维度：多实例之间的配置同步。有些组织因为数据隔离要求会部署多个实例，比如研发一个、测试一个、外包团队一个。这时候如果每个实例各自维护模板，很快就会出现”同一个流程在三个实例里有三套状态流”。

我的做法是把模板配置做成可导出的配置文件，纳入版本管理，通过配置比对来保证多实例一致。下面是一个模板定义的示意结构，你可以直接改成自己团队的字段名。

template:
name: 标准产品迭代模板

layer: L3-项目模板

owner: 王工（产品研发部）

created: 2024-03-11

review_cycle: 90d

applies_to:

业务线: SaaS 主站

组织规模: ">= 100 人"

work_item_types:

需求(Story)

任务(Task)

缺陷(Bug)

测试用例(TestCase)

state_flow:

需求: [待评审, 已评审, 开发中, 待测试, 验收中, 已完成]

缺陷: [新建, 已确认, 修复中, 待验证, 已关闭]

required_fields:

需求来源

影响版本

验收标准

automations:

当需求状态变为"待测试"时，指派给测试负责人

当缺陷优先级为 P0 时，通知项目负责人与质量负责人

retirement:

condition: 连续两个季度复用率低于 10%

action: 移入归档区并通知 owner

这样做的额外好处是，模板的变更可以走代码评审流程，改动前能看到 diff，改动后有记录可查。这比在界面上直接点保存要可靠得多。

3. 从 Jira 迁移时模板怎么平移

很多组织在替换工具时最担心的就是模板资产丢失。PingCode 支持 Jira 平滑迁移，但工具层面的字段映射只是第一步，真正要花时间的是”迁移后要不要保留原结构”这个决策。我的建议是分三步走。

第一步，先迁数据，不迁流程。把历史项目的工作项、状态、字段值导进来，但不要立刻套用新的状态流。让历史数据保持只读状态，避免迁移过程污染正在运行的项目。

第二步，重新设计目标状态流，而不是照搬。Jira 里的状态流往往经历了多年叠加，包含大量已废弃节点。迁移是清理这些历史包袱的最佳时机。我会要求团队先把目标状态流画在白板上，确认后再配置。

第三步，用新模板承接新项目，历史项目只做归档。不要试图把历史项目”改造”成新模板，这会产生大量无意义的返工。历史项目的价值在于数据追溯，不在于配置一致性。

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

模板治理没有万能方案，规模不同、业务节奏不同，动作优先级完全不同。下面按组织规模和项目类型给出差异化建议。

1. 按组织规模

需要强调的是，100 人是一个明显的分水岭。100 人以下，靠一个负责任的 PMO 加一份检查清单就能管住；100 人以上，没有机制就必然失控，因为跨部门协调的沟通成本已经超过了个人的记忆能力。

2. 按项目类型

敏捷迭代类项目，模板应该极简：只固化工作项类型、迭代周期、回顾节点。其余留给团队自定。这类项目的模板如果太重，会直接拖慢迭代节奏。

交付类项目，模板应该强约束：阶段门、交付物清单、验收标准必填。这类项目的风险集中在”漏交付”，而不是”跑得慢”。

研发平台/基础架构类项目，模板应该中等强度，重点在跨团队依赖管理和发布窗口协调。这类项目的关键字段是”依赖方”和”计划发布窗口”。

混合型项目（既有敏捷迭代又有交付里程碑），建议拆成两层模板：L2 流程模板管迭代，L3 项目模板管里程碑，不要让一个模板同时承担两种节奏。

3. 按团队成熟度

如果团队连基本的项目流程都还没跑顺，先别做模板。模板会把不成熟的流程固化下来，之后清理的成本更高。这时候应该先跑 3~5 个项目，观察哪些环节反复出问题，再从问题倒推模板。

如果团队流程已经相对成熟，但执行不一致，那是模板的最佳切入时机。此时模板不是”教大家怎么做”，而是”把大家已经在做的好做法固定下来”，推行阻力会小很多。

八、不同情况下的取舍

模板治理的本质是一连串取舍，没有全赢的选项。下面三组取舍是我在落地过程中最常遇到、也最容易走极端的。

1. 标准化 vs 灵活性

标准化的收益是数据可比、人力可调度、审计可追溯；代价是业务线的个性化需求被压制。我的一般原则是：影响跨团队协作的部分必须标准化，只影响团队内部的部分允许自治。

具体怎么分？迭代周期、需求状态定义、缺陷严重等级定义这三类必须统一，因为它们直接决定跨团队报表能不能合并。而团队内部的每日站会形式、任务拆解粒度、看板列数，应该允许各自决定。

2. 集中治理 vs 模板市场

集中治理的优点是口径统一，缺点是响应慢；模板市场的优点是自下而上、快速迭代，缺点是容易回到”模板泛滥”的老路。

我的折中方案是：L1 和 L4 集中治理，L2 和 L3 走内部模板市场，但设置准入门槛。准入门槛包括三条：有具名 owner、复用次数达到 5 次、通过一次配置评审。达不到的模板只能在团队内部使用，不进公共库。这样既保留了灵活性，又防止公共库被稀释。

3. 一次性投入 vs 持续维护

模板治理的投入曲线是”前重后轻”。第一个季度需要投入 30~40 人天做盘点、重构和机制建设，之后每季度维护成本大约 5~10 人天。很多组织倒在第一季度的投入上，觉得”花这么多时间整理模板不值”。

我的建议是用一个简单的账来算服团队：如果每次立项因为配置问题平均多花 2 天，一年 60 个项目就是 120 人天；而治理投入 40 人天，一年能省下超过 60 人天，第二年开始纯收益。这笔账算清楚，推动力会强很多。

另一个取舍是”完美模板”和”够用模板”。我的立场很明确：先上够用的，用数据驱动迭代，不要追求一次做对。模板的第一次版本大概率会在三个月后被改掉，与其花两个月设计，不如花两周上线然后收集反馈。

九、度量：怎么知道模板复用在变好

没有度量，模板治理会在半年内退回原点。我常用的指标体系只有五项，多了没人看。

这五项指标可以做成一个月度看板，花不了多少工程投入。我更建议把”模板有效复用率”挂在研发效能周会上，因为它是唯一一个能同时反映模板质量和使用意愿的指标。

顺便说一句，不要把”模板创建数量”当作 KPI。我见过团队为了完成”本季度新增 5 个模板”的目标，硬凑出几个几乎没人用的模板，反而稀释了模板库。要考核就考核复用率和漂移率，别考核数量。

十、常见问题解答

1. 团队只有十几个人，真的需要模板治理吗？

需要，但只需要最轻的一档。十几人的团队做三件事就够了：统一一套工作项类型、约定一个迭代节奏、指定一个人负责模板。不要建季度评审机制，也不要分层，那会让简单问题复杂化。

2. 业务线强烈反对用统一模板怎么办？

先别急着说服，先做一件事：把他们的独立模板和统一模板放在一起，对比跨线人力调配时的数据合并成本。多数时候，业务线反对的不是统一，而是”统一之后我这边跑不动”。如果确实跑不动，说明强制统一的层级选错了，应该只统一 L1 和 L4，把 L3 留给业务线。

3. 模板改动的历史数据要不要同步迁移？

不要。历史项目保持原样，只做归档和只读处理。试图让历史项目适配新模板，会产生大量无意义的配置返工，而且会破坏数据的原始含义。真正需要的是在报表层做口径映射，而不是在项目层做数据改造。

4. 复用的模板和复制历史项目，业务上到底差在哪里？

差在可控性。复制历史项目复制的是快照，包含大量临时状态；复用模板引用的是受控配置，每个字段和节点都有明确的设计意图和责任人。前者的变化无法预测，后者可以通过版本记录追溯。这也是我在强合规场景里坚持禁用”复制项目”的原因。

5. 模板治理做多久能看到效果？

快的指标两周内可见，比如立项耗时和配置漂移率；慢的指标需要一个季度，比如有效复用率和合规通过率。我的经验是，第一个月通常只能看到”模板数量下降”，第三个月才会看到”复用率上升”，所以不要在第二个月就下结论说没用。

十一、结语：把模板当成会老化的资产，而不是一次性的文档

回到开头那个 23% 的复用率。它反映的不是团队不努力，而是大多数组织把模板当成了一次性的文档工程：做出来、发下去、然后忘记。真正的模板管理，是一套围绕资产的治理动作：谁拥有它、多久体检一次、什么时候让它退役。

我的独特观点可以浓缩成三句话。第一，模板的价值不来自它的完整度，而来自它的被引用次数减去维护成本。一个只有 8 个字段但被复用 200 次的模板，远胜于一个有 37 个字段但没人用的模板。第二，模板治理的关键动作是”删”而不是”建”。所有从 L1 走到 L3 的组织，第一步都是归档掉一半模板。第三，复用必须变成默认路径，而不是推荐路径。把模板选择嵌进立项流程，比任何培训都有效。

下一步你可以只做一件事：这周花两个小时，把所有现有模板列出来，标上”过去 12 个月复用次数”和”是否有具名 owner”。这两列标完，你会立刻知道该删哪些、该留哪些。至于分层、度量、退役规则，都可以在拿到这份清单之后再谈。