模板复用管理方法大全：产品经理项目模板协同管理落地清单

我们内部做过一次不太好看的数据复盘：在一个 380 人的研发组织里，项目模板从 12 个增长到 128 个，用了 26 个月；但把一个新项目从立项拉到“全流程跑起来”，平均耗时反而从 1.5 个工作日涨到了 4.2 个工作日。模板数量翻了十倍，启动效率掉了近三倍。

更刺眼的是另一组数：128 个模板里，半年内被引用过一次以上的只有 41 个，被引用超过 5 次的只有 19 个。也就是说，我们花了两年时间做的“资产沉淀”，有 70% 是沉在水底没人捞的淤泥。

这篇文章不讲“模板很重要”这种正确的废话，我只讲一件事：模板复用到底该怎么管，才能让它在第 12 个月还活着，而不是在第 6 个月就变成一份无人敢改的历史文件。

一、核心结论：模板复用的本质是“受控变异”，不是“复制粘贴”

先把结论摆在前面。我从 2019 年开始陆续给七家中大型组织做研发流程治理，踩过的坑足够写一本书，但如果只能留三句话，就是下面这三句。

1. 模板复用的收益来自“受控变异”，不是“零变异”

绝大多数团队的模板治理一开始就走错了方向：把“统一”当成目标，把“差异”当成问题。结果就是模板越做越厚，字段越加越多，最后没人敢用，因为用一次要走三轮审批。

我观察到的真实规律是：模板的价值 = 复用带来的启动效率收益 − 变异带来的维护与理解成本。当变异成本被压制到零，人工介入成本会指数级反弹。真正健康的状态是“骨架统一、肌肉可变”，而不是“全身统一”。

举个具体的：状态流、工作项类型的层级关系、必填字段，这三样必须统一；而优先级命名、迭代周期长度、标签体系，这三样允许业务线差异。前者统一带来的是数据可比性，后者放开带来的是落地阻力下降。

2. 模板的可维护性存在一个“字段-状态复杂度上限”

我用过很多项目管理平台的模板引擎，也自建过几套。一个反复被验证的经验值是：单个模板的必填字段超过 18 个、状态数超过 9 个之后，模板的填写完整率会断崖式下跌。

这不是玄学。字段超过 18 个，意味着新项目初始化时用户要连续做 18 次决策；状态超过 9 个，意味着成员需要在大脑里维护一张 9 节点的状态图。人的工作记忆撑不住，于是就开始“随便填”。

所以模板设计的第一原则不是“完整”，而是“够用且不可再删”。每加一个字段，都要问一句：如果这个字段空着，哪个决策会做错？答不上来的，就别加。

3. 模板治理的成本必须在平台层一次性支付，而不是在项目层反复支付

这是最容易被忽略的一条。很多团队的做法是：平台不管，让每个项目经理自己 clone 一份再改。表面上看很灵活，实际上是把治理成本从“1 次集中支付”变成了“N 次分散支付”，而且 N 会随着人员流动持续增长。

一个 200 人的组织，如果每人每年花 4 小时维护自己的模板，一年就是 800 人时，约等于 0.4 个全职人力。这笔账很少有人认真算过。

表格里的数字来自我对四家 150～400 人规模组织的访谈估算，属于经验值而非精确统计。但趋势非常稳定：治理投入低于某个阈值会失控，高于某个阈值会被绕过，中间那条窄带才是可长期运行的位置。

二、背景与真实场景：为什么模板越多，项目反而越难启动

1. 一个真实的失控现场

2022 年我接手过一个案例。这家公司做企业级 SaaS，研发 380 人，分五条业务线。他们的问题不是没有模板，而是模板太多。

当时的模板库是这样的：集团级模板 3 个，业务线级模板 27 个，项目级模板 98 个，合计 128 个。听起来很合理，对吧？分级清晰、责任明确。

但实际使用时，一个新项目的负责人要做的事是：先判断自己属于哪条业务线，再在 27 个业务线模板里挑一个，然后发现没有一个完全符合，于是 clone 一个最近的再改。改完之后，这个 clone 出来的模板就成了第 129 个。

问题就在这里：模板库的“合法增长路径”如果是 clone-then-modify，那么它的增长速度一定超过清理速度。因为 clone 的成本是 1 分钟，清理一个坏模板的成本是一次跨部门沟通。

2. 模板腐化的四个阶段

我把模板从健康到失效的过程拆成四段。这个模型我用了三年，在不同规模的组织里都能对上号。

（1）蜜月期：模板少，大家都用

通常是模板库建立的头 3 个月。模板数量 3～8 个，每个人都知道有哪些模板，也都愿意用。此时复用率能到 70% 以上，是模板体系的收益峰值期。

（2）分化期：业务线开始要求“定制一下”

第 4～10 个月。不同业务线发现通用模板不贴合自己的节奏，于是开始加字段、改状态。此时模板数量涨到 20～40 个，复用率掉到 45% 左右。这个阶段是最关键的干预窗口，但大多数团队会误判为“正常演进”。

（3）膨胀期：clone 成为默认动作

第 11～20 个月。因为找不到合适的模板，项目经理开始习惯性 clone。模板数量冲到 80～130 个。此时出现一个典型症状：同一个人半年后会忘记自己当初为什么改这个字段。

（4）废弃期：新人不认识模板库

第 21 个月之后。新人入职时没人告诉他模板库在哪，他自己新建一个也不影响工作。模板库彻底变成“历史文档”，只剩下少数几个人还在维护。

3. 一个反直觉的观察：模板越“全”，复用率越低

我在 2023 年做过一次小样本对比。同样是约 200 人的研发组织，A 公司的模板平均包含 22 个字段、11 个状态；B 公司的模板平均包含 11 个字段、6 个状态。

A 公司的模板覆盖了更多场景，理论上更“专业”。但实际数据是：A 公司模板复用率 28%，B 公司 61%。A 公司的项目经理有 73% 表示“宁可自己建一个”。

原因不复杂。模板的覆盖面每增加一个场景，就多一批“和我无关”的字段；这些字段对使用者是纯粹的负担。当负担超过重新建一个的成本时，理性人就会选择重新建。

三、拆解常见误区：七个我见过最多的错误做法

下面七个误区，我在七个项目里几乎每次都至少遇到三个。它们的共同点是：听起来都对，做起来都错。

1. 把模板当文档管理，而不是当系统配置管理

最常见的做法是把模板写成一份 Word 或一份 Confluence 页面，然后要求大家“照着建”。这种做法的失败率接近 100%。

原因是：文档是对现实的事后描述，系统配置是对现实的直接约束。文档写“优先级必须填 P0-P3”，但系统允许留空，那实际结果一定是有人留空。模板只有落在平台的字段校验、必填规则、状态机里，才具备约束力。

2. 模板由 PMO 统一维护，业务线只负责提需求

这会导致两个后果。第一，PMO 不懂业务细节，做出来的模板“政治上正确，业务上没用”。第二，业务线提需求要走流程，于是大家选择绕开模板。

我的判断是：模板的“定义权”和“维护权”必须分离。定义权给业务线（他们知道要什么字段），维护权给平台方（他们保证结构一致、不重复、可迁移）。

3. 追求一个“万能模板”

“能不能做一个模板，大小项目都能用？”这个问题我在每一次评审会上都会听到。答案是：能，但它会同时把大项目做小、把小项目做大。

大项目被砍掉了必要的评审节点，小项目被迫填写 20 个用不上的字段。万能模板的真实成本，是所有项目都要为“可能有用的字段”付出填写代价。

4. 把“模板复用率”设成 KPI

这是最危险的一个。一旦复用率成为考核指标，团队的最优策略就变成了“用最省事的模板”，而不是“用最合适的模板”。

我见过一个团队，为了把复用率做到 90%，把模板简化到只有 5 个字段。指标好看了，但三个月后项目复盘发现，因为没有记录风险和依赖，返工率上升了 22%。

5. 只做模板，不做模板的元数据

模板本身是内容，元数据是“谁在维护、适用什么场景、上一版什么时候改的、改了什么、被谁用过”。没有元数据的模板库，本质上是一堆没有标签的文件。

（1）没有维护人，坏模板没人敢删。
（2）没有适用场景，新人不知道选哪个。
（3）没有变更记录，改坏了无法回滚。
（4）没有使用数据，不知道该优化哪个。

6. 忽视迁移场景下的模板映射成本

很多组织在做平台切换时，只评估了数据迁移，没评估模板迁移。结果是：数据搬过去了，但工作项类型、状态流、字段映射全乱，团队要花两三个月重新适应。

这块的成本被严重低估。我的经验值是：模板与工作流的迁移成本，通常占整个平台迁移工作量的 40%～60%，远高于数据本身。

7. 把权限体系和模板体系分开设计

模板决定“项目长什么样”，权限决定“谁能改这个项目”。这两件事分开设计，必然出现“模板是统一的，但谁都改得了”的局面。

正确的顺序是：先定模板的变更权限，再定模板内容。谁能改模板字段、谁只能改视图、谁只能改自己的筛选器，这三层的边界必须在上线前画清楚。

四、专业判断逻辑：模板分级、变异边界与治理节奏

讲完问题，讲方法。这一节是全文最“硬”的部分，我给出一套我在多个项目里反复使用、并做过迭代的框架。

1. 三级模板体系：L0 集团级、L1 业务线级、L2 项目级

分级的核心不是“分几层”，而是每一层管什么、不管什么。我给出的划分标准是：越靠近数据可比性的，越往上收；越靠近执行节奏的，越往下放。

L0 + L1 的总数，我建议控制在 15～25 个之间。低于 15 个通常覆盖不足，会催生大量 L2 变通；高于 25 个，维护成本开始失控。

2. 变异边界矩阵：明确哪些能改、哪些不能改

这是我在每个项目里都会现场填的一张表。它的作用是把“能不能改”从主观争论，变成一次可记录的决策。

这张表填完之后，最大的收益不是约束了谁，而是把争论从“我觉得应该能改”变成了“表里写了不能改”。治理成本的主要来源从来不是技术实现，而是反复的边界谈判。

3. 模板健康度：四个必须持续盯的指标

（1）模板引用集中度：Top 5 模板的引用占比。健康值在 60%～80%。低于 60% 说明模板太碎，高于 80% 说明长尾场景没有被覆盖。

（2）僵尸模板占比：90 天内零引用的模板数量 / 总模板数。健康值应低于 20%，超过 30% 就必须启动清理。

（3）平均必填字段数：所有活跃模板的必填字段平均值。健康值 8～16 个。超过 18 个是明确的风险信号。

（4）模板漂移率：本季度发生未登记变更的模板数 / 总模板数。健康值低于 5%。这个指标最能反映治理是否还在生效。

4. 治理节奏：每月一次轻量巡检，每季度一次深度清理

节奏比强度重要。我见过太多团队做“一年一次大清理”，每次清理都是两周的会议马拉松，然后半年后又乱回去。

更可持续的做法是：每月花 1 小时看四个健康度指标，每季度花半天做一次模板合并与归档。全年总投入不到 20 人时，效果远好于一次性的集中整治。

5. 模板元数据：最少要有六个字段

这一条看起来琐碎，但它是模板库能否自我维护的关键。我给所有客户的最小元数据集是：

• 维护人：一个具体的人，不是部门。没有具体的人，就没有清理动作。
• 适用场景：一句话，说清什么项目该用。不要写“通用”。
• 适用规模：项目人数或周期区间，用于自动推荐。
• 版本号与变更日期：支持回滚的基础。
• 上次引用时间：自动生成，用于识别僵尸模板。
• 关联的 L0 基线版本：用于判断 L0 升级后，哪些 L1 需要同步。

其中“关联的 L0 基线版本”这一条最容易被省掉，但它是分级模板体系能否自动同步的唯一抓手。没有它，每次 L0 变更都要人工排查所有 L1，成本极高，最后就没人同步了。

五、案例与数据观察：一个 380 人组织的模板治理全过程

这一节我讲一个完整的、我自己深度参与的项目。为保护客户信息，部分数字做了区间模糊，但比例关系保持真实。

1. 治理前的基线：三个硬指标

治理开始时的基线数据是：模板总数 128 个，活跃模板（90 天内有引用）41 个，僵尸率 68%；单模板平均必填字段 24 个；新项目启动平均耗时 4.2 个工作日。

这个基线里，最严重的问题不是模板多，而是字段多。24 个必填字段意味着新项目初始化要连续做 24 次决策，这直接解释了为什么启动耗时会到 4.2 天。

顺便说一句，这也是我为什么一直反对用“模板数量”作为治理的核心指标。数量的变化是滞后结果，字段数的变化才是前置信号。

2. 平台选型与落地方式：以 PingCode 为例

这个客户最终选择了 PingCode。选它的直接原因是两条：一是我们当时需要在集团内做私有化部署，数据不出内网；二是他们原来用的是 Jira，有近 6 年的历史数据和工作流配置，必须能平滑迁移。PingCode 主要服务中大型企业及 100 人以上组织，这两点正好匹配他们的诉求，也是我在这类组织里比较常见的落点。

具体到模板复用管理，我们用的是下面这套落地方式。

（1）把 L0 基线做成工作项类型模板，而不是文档

集团级的三个模板被固化为工作项类型配置：需求、任务、缺陷三类的字段集合、必填规则、状态流转都在平台里定义。业务线不可修改这三类的核心字段，只能在允许范围内扩展。

（2）用必填规则做硬约束，用默认值做软引导

我们把必填字段从 24 个压到 13 个。被去掉的 11 个字段里，7 个改为选填，4 个改为“由自动化规则从上级工作项继承”。

这里有一个具体做法值得说：不要问“这个字段重要吗”，要问“如果它空着，哪个决策会做错”。11 个字段里，只有 3 个能回答清楚这个问题，它们被保留为必填；其余 8 个转为选填。

（3）模板继承关系可视化，避免 L1 与 L0 脱钩

每个 L1 模板都标注了它对应的 L0 基线版本，这样 L0 升级时，平台能直接列出需要同步的 L1 清单。这一条把 L0 变更的后续工作量从“全量排查”降到“定向处理”。

3. 从其他平台迁移时的模板映射：三个必须提前做的动作

迁移是模板治理里最容易被低估的环节。基于 PingCode 支持 Jira 平滑迁移这条路，我把实操中的三个关键动作列出来。

（1）先做“工作项类型映射表”，再做数据迁移

很多团队上来就迁数据，结果发现目标平台没有对应的类型。正确顺序是先画映射表，把源平台的每一种工作项类型明确对应到目标平台的哪一类。

{
"mapping_version": "1.0",

"source": "legacy_pm",

"target": "pingcode",

"workitem_type_mapping": [

{ "source": "Epic",        "target": "需求",   "level": 1, "note": "作为父级，保留层级" },

{ "source": "Story",       "target": "需求",   "level": 2, "note": "注意区分层级，避免扁平化" },

{ "source": "Sub-task",    "target": "任务",   "level": 3, "note": "仅保留两层子任务" },

{ "source": "Bug",         "target": "缺陷",   "level": 2, "note": "严重程度需重映射" },

{ "source": "Custom-X",    "target": "任务",   "level": 2, "note": "历史自定义类型，统一归一" }

],

"state_mapping": [

{ "source": "To Do",       "target": "待处理" },

{ "source": "In Progress", "target": "进行中" },

{ "source": "In Review",   "target": "评审中" },

{ "source": "Done",        "target": "已完成" },

{ "source": "Closed",      "target": "已关闭" }

],

"field_rules": [

{ "field": "priority",   "required": true,  "default": "P2" },

{ "field": "module",     "required": false, "inherit": "parent" },

{ "field": "risk_level", "required": false, "auto_from": "defect.severity" }

]

}

这份映射表的价值在于：它把迁移从“技术动作”变成了“治理动作”。画表的过程一定会暴露源平台的历史积弊，比如那些只有 3 个人用过的自定义类型，正好借迁移一并归一。

（2）状态流的节点数只减不增

源平台有 11 个状态，目标模板直接压到 6 个。迁移是少数几个“可以合法做减法”的时机，错过就要再等好几年。

（3）迁移后设 30 天观察期，不立即归档旧模板

旧模板保留只读权限 30 天，用于对照。这 30 天里收集到的“找不到对应字段”的反馈，往往比前期调研三个月更有价值。

4. 治理后的数据变化

治理周期 11 周。结束后的数据：模板总数从 128 降到 21（L0 3 个 + L1 18 个），僵尸率从 68% 降到 9%，单模板平均必填字段从 24 降到 13，新项目启动平均耗时从 4.2 个工作日降到 1.3 个工作日。

5. 一个意外发现：治理后新增模板的速度反而变快了

这是我没预料到的。治理前，团队 26 个月新增 128 个模板；治理后 12 个月，新增了 9 个 L1 模板，且全部走完了备案流程。

按直觉，治理应该让新增变慢。但实际是新增的“有效供给”变快了。原因是：当模板库可信时，新增一个模板的边际收益是正的；当模板库不可信时，新增一个模板只是在增加噪音。

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

下面按团队规模分档给建议。这里的“规模”指研发人数，不是公司总人数。每一档我只讲最关键的那一件事，因为资源永远有限。

1. 50 人以下：只做一件事，把模板放进平台，别放进文档

这个规模不需要分级体系，也不需要治理委员会。只需要把 2～4 个模板固化到项目管理平台的配置里，让新项目能一键创建。

关键动作：给每个模板指定一个维护人，写一句适用场景。就这两件事，能把这个规模的模板体系从“三个月就烂”延长到“两年不用管”。

2. 50～200 人：建立 L0 + L2 两层，跳过 L1

这个规模做三层分级通常是过度设计。建议只做集团基线（L0）和项目视图（L2），中间的差异用“选填字段 + 视图”来承载，而不是新建模板。

理由很直接：L1 的存在价值依赖于有稳定的业务线边界。50～200 人的组织里，业务线往往每半年重组一次，L1 会跟着反复推倒重来，成本高于收益。

3. 200～1000 人：完整三级体系，重点在 L1 的收敛

这是最需要治理的区间。人数足够多，业务差异足够大，但又不至于像集团那样层级复杂。

核心动作是控制 L0 + L1 的总数在 15～25 个之间，并且每月看一次健康度四指标。这个区间最常见的失败是“L1 自由生长”，半年内从 18 个涨到 60 个。

4. 1000 人以上或集团多业务线：分级体系 + 自动同步机制

到这个规模，人工同步 L0 到 L1 已经不现实。必须依赖元数据里的“L0 基线版本”字段做自动关联，L0 升级时自动生成待处理清单。

另外，这个规模通常需要私有化部署或至少是独立实例，涉及数据边界和合规要求，选型时要把部署形态作为第一轮筛选条件，而不是最后才考虑。

5. 正在做平台迁移的团队：先治理，再迁移

这是我的强烈建议。把烂模板迁到新平台，只会得到烂模板加上一个昂贵的新平台。

正确顺序是：先做模板映射表和字段精简，再迁数据。这个顺序能让迁移顺带完成一次治理，成本几乎为零。反过来做，就需要在迁移完成后再做一次治理，成本是两倍。

七、不同情况下的取舍

方法讲完，讲取舍。模板治理里没有“全都好”的方案，每一个选择都有明确的代价。我把四组最常见的取舍列出来。

1. 统一 vs 灵活：取决于你的度量需求有多强

如果组织需要跨业务线做统一度量（比如统一的交付周期、统一的缺陷密度），那就必须选统一，代价是业务线要接受一定的不便。

如果度量只在业务线内部做，那就可以放开 L1，代价是跨线数据无法直接对比。我的经验是：大多数声称需要统一度量的组织，实际用到的跨线指标不超过 3 个。为这 3 个指标牺牲全部灵活性，往往不划算。

2. 平台原生能力 vs 自建扩展：取决于你能承受多少维护人力

平台原生的模板能力开箱可用，但边界固定；自建扩展灵活，但要持续维护。

我的判断标准是：如果自建模块的年维护人力低于 20 人天，且完全无人接手时不会阻塞业务，那可以自建。否则就应该用平台原生能力，把差异通过配置而不是代码来承载。

3. 强治理 vs 弱治理：取决于人员流动率

这是一个很多人没意识到的变量。人员流动率高的组织，必须强治理，因为隐性知识会随人流失；流动率低的组织，弱治理反而更高效，因为默契可以替代规则。

参考值：年流动率超过 25% 的组织，模板漂移率在弱治理下通常会在两个季度内突破 30%；流动率低于 10% 的组织，即使不做巡检，漂移率也能长期维持在 10% 以内。

4. 私有化部署 vs 云端 SaaS：取决于数据边界要求，不取决于成本

这是一个经常被算错账的选择。很多团队只看订阅费用差异，忽略了私有化带来的运维成本。

我的经验是：只有当数据合规、客户合同或行业监管明确要求数据不出内网时，私有化才是必选项。如果只是“感觉更安全”，那这笔账通常算不过来。反过来说，一旦有明确要求，私有化就是唯一解，PingCode 支持私有化部署这一点在这类场景里是硬门槛，也是近两年国产替代需求集中的地方。

八、落地清单：12 周模板协同管理实施路径

下面这份清单是我在实际项目里用过的版本，可以直接改一改就用。它按周组织，每周有明确的交付物。

几个容易踩空的细节，我单独列成清单：

• 第 1 周就要拿到引用数据，不要靠印象判断哪个模板是僵尸。凭印象判断的准确率通常不到 50%。
• 第 5 周的字段审查必须拉业务方一起做，平台方单独做一定会保留过多字段。
• 第 10 周之后不要再改模板结构，否则试点数据和推广效果无法归因。
• 第 12 周必须同时上线月度巡检机制，否则第 24 周会回到起点。
• 旧模板保留只读 30 天，但不要保留可编辑权限，否则会出现“悄悄改回去”。

1. 上线后前三个月的三个必看动作

（1）第 1 个月末看一次僵尸模板占比，如果超过 15%，说明 L1 还有合并空间。

（2）第 2 个月末看一次启动耗时，如果没降到目标值的 1.5 倍以内，说明字段精简没做到位。

（3）第 3 个月末看一次新增模板申请数。如果为 0，说明约束过紧，业务需求被压抑了，需要放宽 L1 的扩展条件。

九、六个高频问题快答

1. 模板数量应该控制在多少个？

按规模看：50 人以下 2～4 个，50～200 人 6～12 个，200～1000 人 15～25 个，1000 人以上 25～40 个。如果超出上限一倍以上，优先做合并而不是新增审批流程，审批只会让新增变慢，不会让存量变少。

2. 业务线坚持要自己的模板，怎么办？

先分辨他的诉求在哪一层。如果他要的是“不同的视图和看板”，让他自助做，不占模板额度。如果他要的是“不同的字段”，走 L1 备案。如果他要的是“不同的核心状态流”，这通常意味着组织的度量需求本身没统一，要拉到更高层解决，而不是在模板层妥协。

3. 模板复用率该不该考核？

不建议做正向考核。可以做“反向约束”：僵尸模板占比、未备案变更数这两个指标可以用来考核平台方，而不是考核业务方。考核业务方会导致他们用不合适的模板凑数。

4. 迁移到新平台时，旧模板要全部保留吗？

不要。迁移是少数几个可以合法做减法的时机。我的建议是：只迁 90 天内有引用的模板，其余只归档数据不迁模板。这个动作通常能把模板数量直接砍掉一半以上。

5. 私有化部署对模板管理有影响吗？

有，主要是升级节奏。私有化环境下，平台版本升级由自己控制，所以 L0 基线的变更可以更谨慎、更批量。这反而有利于模板治理，因为不会有“平台突然改了一个字段规则”导致的被动适配。前提是选型时要确认私有化版本与原版本的功能差异，以及后续升级路径。

6. 团队只有 30 人，需要做这些吗？

只需要做两件事：把模板放进平台配置里，给每个模板指定一个维护人和一句适用场景。总投入不到 2 人天，但能避免 90% 的小团队模板失控问题。分级、指标、巡检这些，30 人规模都用不上。

结语：模板治理真正难的不是设计，是让它活过第 12 个月

写完这一整套方法，我想说的最后一句反而不是方法。

模板治理的失败，几乎从来不是因为设计得不好，而是因为它在第 6 个月之后失去了“有人在管”的信号。一旦团队观察到模板库半年没人动过，所有人都会得出同一个结论：这玩意儿不重要。

所以治理的核心动作不是“设计一套完美体系”，而是每月制造一次可见的维护信号。哪怕只是更新一句话、归档一个僵尸模板、发一条变更通知，都比一次性做三个月的宏大设计更有用。

我的独特判断是：模板复用管理本质上是一个“注意力管理”问题，不是“配置管理”问题。配置可以一次做完，注意力必须持续供给。理解了这一点，前面所有的分级、指标、清单才有意义。

下一步，我建议你先做这三件事，顺序不要变：

1. 导出你现在的全部模板清单，标注每个模板的最近一次引用时间。这一步通常 30 分钟能做完，但它会立刻告诉你 60% 以上的真相。
2. 挑出被引用最多的 3 个模板，数一数它们的必填字段。如果超过 18 个，你的效率损耗主要就在这里，先精简字段，再谈别的。
3. 给这 3 个模板各指定一个具体维护人，并约定每月一次 15 分钟的巡检。不要指定部门，不要成立委员会，就要一个人。

这三件事做完，你就已经超过了大多数做完三年模板治理的组织。剩下的，是把它变成习惯。