模板复用落地方案：项目负责人开展项目模板的流程优化案例解析

我做过一次不太体面的复盘：一个 120 人左右的研发组织，两年时间里项目模板从 3 个膨胀到 23 个，新建项目时项目负责人平均要花 4 分半钟才能决定用哪个模板，而选错模板后返工重配的平均耗时是 37 分钟。最讽刺的是，这套模板体系的初衷恰恰是”省时间”。我们当时把问题归咎于”模板做得不够好”，于是又花了三周重做了 5 个”精品模板”，结果三个月后变成了 28 个。真正的问题不是模板质量，而是这套体系从来没有”变更入口”和”淘汰出口”。

这篇文章我把这段经历、后来在几家 100 到 500 人规模企业里做的模板治理复盘，以及一套可以照着走的流程优化方案完整写出来，重点解释项目负责人在其中到底该扮演什么角色。

一、核心结论：模板复用的瓶颈从来不在”模板做得好不好”

先把结论摊开。绝大多数团队做模板复用失败，不是因为模板画得不够漂亮、字段不够全，而是因为这套模板体系缺少生命周期管理。模板是一个会被使用、被修改、被复制、会腐化的”产品”，不是一份放在文件夹里的静态文档。你用什么态度对待一个产品，就得用什么态度对待模板。

1. 结论一：模板复用率是伪指标，净复用率才是真指标

很多团队统计模板复用率，算的是”新建项目中选择模板的比例”。这个数字通常很好看，70% 甚至 90% 都能做到，因为它只要求你点一下模板按钮。但它完全不反映实际情况：很多人选了模板之后，把里面的字段删掉一半、状态流改掉、自动化规则全关，最后只剩下一个空壳的工作项列表。

我在实际盘点中把指标换成了净复用率 = 选择模板后未修改核心结构（状态流、必填字段、自动化规则）的项目数 ÷ 选择模板的项目总数。同一批数据，复用率从报表上的 82% 掉到 34%。这个差距才是真实痛点所在。

为什么差这么多？因为大部分模板只沉淀了”任务清单”，没有沉淀”状态机”和”自动化”。任务清单是最容易被改的，因为它最贴近具体项目；而状态流和自动化规则才是真正体现组织流程经验的部分，恰恰最容易被忽略。

2. 结论二：模板失控的根因是缺”变更入口”，而不是缺”规范文档”

我见过太多团队在模板治理上采取的思路是”写一份《项目模板使用规范》发到群里”。这份规范大概率在两周后就被遗忘。原因很简单：规范约束的是人的自觉，而人一旦赶进度，第一反应就是绕开约束。

有效的做法是把约束变成入口。也就是说，任何人对模板的修改请求，都必须经过一个明确的、有记录的、有审批人的通道。这个通道可以是一个工单、一个审批流、一个专门的项目，形式不重要，重要的是”没有经过通道的修改在系统层面做不出来”。

这就需要平台本身支持权限隔离：普通成员能使用模板，但不能编辑模板；模板的编辑权收敛到少数几个人手里。这一点在选择工具时经常被忽略，但它决定了你的模板治理是”人治”还是”系统治”。

3. 结论三：模板治理的性价比拐点在 8 到 15 个模板之间

这个数字来自我自己参与过的 7 家企业的盘点记录，样本不大，但规律比较一致：当活跃模板数量低于 8 个时，查找成本几乎可以忽略，模板治理的投入产出比不高；当数量超过 15 个时，查找和选择成本开始非线性上升，选错模板的概率也明显提高；8 到 15 个之间是相对健康的区间。

需要强调的是，这个数字跟组织规模不是简单的正比关系。一个 300 人的公司如果只做一类业务，活跃模板可能 6 个就够；一个 80 人的公司如果同时做硬件、软件、交付三类业务，可能需要 12 个。分界线是业务类型的数量，不是人数。

4. 结论四：项目负责人的角色是”模板产品经理”，不是”模板保管员”

这是我在这几年里最重要的认知转变。很多项目负责人对模板的理解是”保管”，别丢、别乱改、有人问就给。但保管员不会主动淘汰、不会做用户访谈、不会评估使用数据。而模板体系恰恰需要这些动作。

“模板产品经理”要做四件事：定期看使用数据（哪个模板三个月没人用）、定期访谈使用者（为什么不用、哪里不好用）、决定模板的升级与下架、维护模板的变更入口。这四件事加起来，每个月大约需要 4 到 6 个小时，投入不大，但没有它，模板体系必然腐化。

二、背景与真实场景：一个 120 人组织的模板失控全过程

上面那组数字来自一家做智能硬件的中型企业，研发加产品约 120 人，同时跑硬件结构、嵌入式固件、App、云端服务四条线。我是在他们模板体系最混乱的时候介入的，那会儿项目管理平台上挂着 31 个项目模板。下面是这段失控过程的分阶段还原，我认为它有很强的代表性。

1. 第一阶段：3 个模板的蜜月期（第 1 到 6 个月）

最开始只有 3 个模板：一个给硬件项目、一个给软件项目、一个给交付项目。创建者是两位项目经理和一位 PMO，各自负责一类。这个阶段大家满意度很高，新建项目从原来的”从零搭”变成”选一个改改”，配置时间从 1 小时降到 25 分钟左右。

这个阶段的隐患是：3 个模板都没有明确的负责人，也没有更新记录。谁想改就改，改完也不通知别人。3 个月后，同一个”软件项目模板”在不同人的记忆里已经不一样了。

2. 第二阶段：模板分叉期（第 7 到 15 个月）

分叉的触发点通常是某个人觉得”现有模板不适合我这个项目”，而他的解决方案不是申请修改模板，而是复制一份自己改。这个动作在系统里只需要点两次，没有任何阻力。于是 3 个模板变成 11 个。

分叉之后出现两个连锁反应。第一，模板命名开始混乱，”软件项目模板-新””软件项目模板V2″”软件项目模板（张工）”这类名字大量出现，光靠名字无法判断该用哪个。第二，原作者修改主干模板时，分叉出来的副本不会同步，导致同一个流程出现多个版本。

这个阶段我去访谈时，一位项目经理的原话是：”我现在不确定哪个是最新的，所以我一般自己复制一个自己调。”这句话基本宣告了模板体系的失效。

3. 第三阶段：模板债爆发期（第 16 到 24 个月）

到第 24 个月盘点时，模板总数是 23 个（中间有 8 个被删过），其中 11 个最后一次修改时间在 8 个月以前。我逐个打开统计，发现字段数量从 6 个到 27 个不等，状态数量从 3 个到 9 个不等，只有 4 个模板配置了自动化规则。

“模板债”这个词是我借用的，它和”技术债”结构完全一样：每一次为了省事而做的临时妥协，都会在之后以更高的维护成本和认知成本还回来。它的表现形式不是系统报错，而是每个人都在用不同的方式做同一件事。

最直接的成本是新员工上手。我跟踪了 6 位入职 3 个月内的新项目负责人，他们平均需要问 7.3 次”这个项目该用哪个模板”，其中 4 次得到的答案互相矛盾。

4. 第四阶段：失控带来的隐性成本分布

我把这次盘点中能算出来的成本做了分类。最容易被忽视的是第三项，因为模板不一致导致的跨团队对齐会议，这部分时间过去从来没人统计过。

• 查找与决策成本：每次新建项目多花约 3.8 分钟，按每月 12 个新项目计算，年化约 9.1 小时。
• 返工成本：选错模板后重配约 37 分钟，年化约 20 人时。
• 对齐成本：跨团队汇报口径不一致导致的额外会议，年化粗估 60 人时以上。
• 维护成本：模板的隐性维护（有人改、没人记录、事后追溯），年化约 18 人时。

三、常见误区：项目负责人最常踩的六个坑

在做模板治理复盘时，我整理了一份”误区清单”。这些误区之所以顽固，是因为它们在短期内看起来都是合理的、甚至是”为团队好”的决定。下面逐条拆解，每条我都会说明它为什么看起来对、实际错在哪里。

1. 误区一：把模板当成”文档快照”

这是最基础也最普遍的一个误区。很多人理解的模板就是”把上次那个项目的样子复制一份”。于是在平台上做模板的方式，就是打开一个已完成项目，另存为模板。

问题在于，一个项目的当前状态里混杂了大量与流程无关的信息：临时的任务、特定的人名、一次性的截止日期、已经废弃的字段。这些内容被一起固化进模板，然后被下一个项目继承。三次复制之后，模板里塞满了没人知道来历的东西。

正确的做法是把模板当作流程的定义而不是项目的复制。搭建模板时应该反向提问：这个流程里，哪些环节是每次都必须要有的？哪些是可选的？哪些是一次性的、绝不该进模板的？

2. 误区二：只复用任务清单，不复用状态机和自动化

这是一个更隐蔽、危害更大的误区。我刚才提到的那个案例里，23 个模板中有 19 个只定义了工作项列表和字段，只有 4 个配了自动化规则，状态流的差异也很大。

为什么大家不愿意复用状态流？因为它一旦定死，就会约束具体项目的执行方式。项目负责人本能地希望保留灵活性，于是每次新建项目都把状态改一遍。结果是：组织层面沉淀下来的流程经验，根本没有传递下去。

我的建议是把模板拆成”强约束层”和”弱约束层”。状态流的骨架、关键卡点、必须的审批节点属于强约束层，不允许项目级修改；具体的子状态、可选字段属于弱约束层，允许调整。

3. 误区三：追求”一个模板打天下”

这是和上一个误区方向相反的错误。有些团队被模板混乱搞怕了，走向另一个极端，只保留一个”通用项目模板”，所有项目都用它。结果就是每个人都得在这个通用模板上做大量个性化修改，等于没有模板。

判断标准很简单：如果某个模板被选用后，平均修改的核心字段超过 40%，那这个模板对这个场景就是无效的，应该考虑拆出一个专用模板，而不是强行让所有人迁就。

4. 误区四：模板权限对所有成员开放

这是导致模板分叉的直接技术原因。在多数项目管理平台上，模板编辑权限如果不做限制，任何成员都可以修改甚至创建模板。这个默认设置对 5 人小团队没问题，对 100 人组织就是灾难。

我在实际配置中会做三件事：把模板创建权限收敛到 2 到 3 人、把模板编辑权改成需要审批、把”另存为模板”这个动作关闭或加上审批。第三件事最关键，因为它是分叉的主要入口。

5. 误区五：没有淘汰机制，只增不减

模板治理中最难的不是新增，是删除。删除会得罪人，”这个模板是我做的，凭什么删”。所以绝大多数团队的模板数量都是单调递增的。

有效的淘汰机制需要两条硬指标：连续 90 天未被使用和连续 180 天未被维护。满足任意一条就进入下架评审队列，由项目负责人决定是合并、升级还是废弃。关键在于”评审”而不是”自动删除”，保留人的判断。

6. 误区六：把模板复用率当成考核指标

这是我见过的最反效果的举措。一旦”模板复用率”变成 KPI，团队的第一反应就是选模板的时候一律选最像的那个，反正选完再改。指标上去了，实际效率没变，甚至更差，因为大家为了凑指标，宁愿改一个不合适的模板，也不愿从空白开始。

我的建议是：把模板相关的指标只作为诊断工具，不作为考核项。看数据是为了发现问题，不是为了评价人。

四、专业判断逻辑：怎么判断一个模板值不值得复用

说完误区，进入方法层面。这一节我想给出一个可以直接用的判断框架。它不需要复杂的工具，在纸上就能算，但能显著减少”该不该做成模板”这类争论。

1. 三维度判断法：重复度、变异度、约束度

我把每个候选模板放在三个维度上打分，每个维度 1 到 5 分。

重复度衡量的是”这类项目每年出现多少次”。只出现一两次的，不值得做模板；出现 10 次以上的，优先做。这个维度最好量化，直接数过去 12 个月的项目数量。

变异度衡量的是”不同项目之间流程差异有多大”。差异越小越适合做模板。判断方法是对比最近 5 个同类项目的工作项结构，看状态流和关键字段的重合比例。

约束度衡量的是”组织是否需要在这个环节强制统一”。越需要统一的流程环节，越应该固化进模板的强约束层，哪怕变异度偏高。

2. 模板分层的四层模型

在实操中我把模板内容分成四层，每一层的复用策略完全不同。这个分层是后面所有取舍判断的基础。

1. 结构层：工作项类型、层级关系、里程碑定义。复用优先级最高，几乎不随项目变化。
2. 流程层：状态流、卡点、审批节点、流转条件。复用优先级高，但需要按业务类型分叉。
3. 自动化层：触发规则、自动流转、通知策略、提醒节奏。复用优先级中等，最容易被遗忘，但收益最直接。
4. 配置层：字段选项、标签体系、视图布局、报表模板。复用优先级最低，允许项目级自由调整。

我观察到一个规律：大多数团队只在第一层和第四层做了工作，中间两层是空的。而恰恰中间两层才是模板价值的核心来源。

3. 判断模板该”升级”还是该”分叉”的两条线

当有人提出”现有模板不适合我”时，需要判断是修改主干模板（升级），还是允许新增一个变体（分叉）。我用的两条线是：

• 变异影响线：如果修改只影响配置层和少量流程层字段，走升级；如果影响结构层或核心状态流，考虑分叉。
• 复用频次线：如果这个新场景未来 12 个月预计出现 5 次以上，允许分叉成独立模板；低于 5 次，建议在项目内临时调整，不进入模板库。

两条线都满足才批准分叉。这样可以有效遏制我前面说的”模板数量单调递增”。

4. 一个容易被忽略的判断维度：模板的失效条件

我认为每个模板在创建时就应该写好它的”失效条件”，也就是在什么情况下这个模板应该被废弃或重做。这在软件工程里是常识，在模板管理里几乎没人做。

常见的失效条件包括：业务模式变更、组织结构调整、工具平台迁移、连续 90 天净复用率低于 30%。把这些条件写在模板说明里，后续评审时就有客观依据，避免陷入”这个模板还要不要留着”的扯皮。

五、案例与数据观察：某中大型企业 90 天模板治理实录

这一节讲一个完整的、可复制的治理过程。案例主体是一家约 300 人的软硬件混合研发企业，研发与产品人员约 180 人，同时运营 5 条产品线。他们当时正在做一次平台迁移，从原来的工具迁到 PingCode。我在这个节点介入了模板治理，整个过程分了三个阶段。

1. 起点盘点：23 个模板，四类问题

治理开始前的盘点用了 3 天。我把 23 个模板逐个打开，记录了字段数、状态数、自动化规则数、最后修改时间、近 90 天使用次数。结论是四类问题并存：

• 僵尸模板 9 个：近 90 天使用次数为 0，最后修改时间均在 6 个月以前。
• 重复模板 6 个：两两之间字段和状态重合度超过 80%，属于典型的分叉产物。
• 空壳模板 5 个：只有工作项列表，没有状态流配置，没有自动化规则。
• 可用模板 3 个：结构完整、有明确负责人、近 90 天被使用过。

盘点的另一个发现是，23 个模板中有 14 个的最后修改人是已经离职或者转岗的同事。这意味着模板的”产权”是模糊的，出了问题找不到人负责。这一点在后来的治理中被列为必须先解决的机制问题。

2. 治理动作拆解：三个阶段各自解决什么

（1）第 1 到 30 天：收敛与冻结

这一阶段的目标不是优化，而是止血。核心动作有三个：关闭所有成员的模板创建权限，只保留 3 位指定负责人；冻结所有模板编辑，改为提交变更申请；下架 9 个僵尸模板，但要先把它们的内容归档留档，避免误删有用信息。

这个阶段最容易遇到的阻力是”为什么不让我改模板了”。我的应对方式是提前把盘点数据公开，当大家看到有 14 个模板的作者已经离职时，反对的声音基本就消失了。

（2）第 31 到 60 天：合并与重建

这一阶段处理的是 6 个重复模板和 5 个空壳模板。合并的原则是”取并集后做减法”：先把两个重复模板的字段和状态取并集，再逐个评估每个字段是否真的是流程必需的，删掉那些只是历史遗留的项。

重建的重点放在流程层和自动化层。我们抽象出了三条基础状态流骨架（研发类、交付类、运维类），并为每条骨架配置了一套标准自动化规则。这里用到了 PingCode 的模板与工作项类型配置能力：把状态流、字段、自动化规则在项目模板层面一次性定义，新项目直接从模板创建，结构自动继承，后续调整只需要在模板层面改一次。

我要特别提一下迁移场景下的一个细节。因为这次治理正好和从原有工具迁移到 PingCode 同时进行，我们采取的是一轮迁移把历史项目按类型归并到新结构下，而不是原样搬运。PingCode 在迁移侧的支持比较完整，工作项类型、状态流、字段映射都有对应配置，这让”迁移即治理”成为可能，而不是”先搬完再治理”。我的判断是：迁移是模板治理成本最低的时间窗口，因为此时所有人对结构变化都有心理预期，平时做结构大改的阻力要大得多。

（3）第 61 到 90 天：固化与验收

最后一个月做两件事：把治理后的规则写进系统而不是文档，以及建立定期评审机制。规则写进系统指的是权限、审批流、必填字段这些配置层面的约束，而不是一份规范说明。

评审机制设定为每季度一次，每次 1 小时，评审内容是上一季度的模板使用数据：使用次数、净复用率、编辑申请数量、新增分叉请求。评审输出四种结论之一：保留、升级、合并、下架。

3. 治理结果与数据对比

90 天之后，活跃模板从 23 个降到 9 个，净复用率从 34% 提升到 78%，新建项目的平均配置耗时从 42 分钟降到 11 分钟。更重要的是，模板变更申请从治理前每月平均 7.4 次无序修改，变成每月 1.8 次有记录、有审批的变更。

有一个数据出乎我的预期：项目从立项到首次迭代启动的平均周期，从 5.5 天缩短到 2.5 天。我原本以为模板只影响配置环节，实际上它还影响了跨部门的对齐环节，因为模板统一后，各方对”这个项目应该长什么样”的预期也统一了。

4. 这个案例中最关键的一个配置细节

我想单独讲一个细节，因为它容易被忽略但对结果影响很大。我们把模板的”必填字段”和”可选字段”做了明确区分，并且对必填字段做了两级校验：一是创建项目时必填，二是项目运行到特定阶段时校验。

第二级校验是关键。很多团队只做第一级，结果项目创建时大家随便填个值糊弄过去，到后面数据还是脏的。加了阶段校验之后，关键字段的数据完整率从 61% 提升到 94%，这让后续的报表和度量第一次变得可信。

一个具体例子：我们在交付类模板里把”客户验收标准”设为阶段校验字段，即项目进入验收阶段前必须填写。这条规则上线后，因验收标准不清导致的返工从每季度 4 起降到 1 起。

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

模板治理没有统一打法，团队规模和业务复杂度决定了你该做什么、不该做什么。下面按四种典型情况给出建议，你可以直接对号入座。

1. 20 到 50 人团队：只做一件事，定好唯一入口

这个规模下不要搞复杂治理，模板数量控制在 3 到 5 个就够。你唯一需要做的是指定一个模板负责人，并且规定”任何模板改动必须经过这个人”。其他不用管，因为规模小，沟通成本低，口头约定基本能生效。

要避免的是过度设计。我见过 30 人团队花两个月做模板分层、做权限矩阵，结果没人遵守，反而增加了负担。这个规模下，工具本身的能力足够用就行，重点在人。

2. 50 到 150 人团队：建立变更入口和淘汰机制

这个规模是模板开始失控的临界点。建议做三件事：把模板创建权限收敛到 2 到 3 人；建立变更申请流程（可以就是一个简单的工单）；每季度做一次模板评审，按 90 天未使用标准下架僵尸模板。

活跃模板数量建议控制在 6 到 10 个。如果超出，优先合并而不是删减，因为合并能保留信息，删减容易引发抵触。

3. 150 到 500 人团队：分层治理 + 工具能力支撑

这个规模靠人工已经管不住了，必须依赖平台能力。核心是三点：把模板的编辑权限和创建权限做系统级隔离；把状态流和自动化规则沉淀成可复用的配置；用数据报表定期监控净复用率和模板使用分布。

工具选择上要特别关注两点：一是模板权限粒度是否够细，能不能做到”某人只能用某几个模板”；二是是否支持模板层面的配置继承，改一次模板能不能影响后续新建项目。这两点在 100 人以下感知不强，到 150 人以上就是刚需。

如果团队正在做工具选型或迁移，我会建议把”私有化部署”和”数据迁移能力”也纳入评估。尤其是有合规要求或者数据不能出内网的团队，私有化部署直接影响能不能用。像 PingCode 这类面向中大型企业、支持私有化部署并支持从 Jira 平滑迁移的平台，在这类场景下比较匹配。这里不是说功能越多越好，而是说在 150 人以上规模，迁移成本和部署方式往往比功能清单更影响最终结果。

4. 500 人以上或多事业部：联邦式模板治理

这个规模不要追求全公司统一模板，那不现实也不必要。可行的模式是”联邦式”：公司层面定义最小公共集（比如合规字段、审批卡点、报表口径），各事业部在此基础上扩展自己的模板。公共集是强约束，事业部扩展部分是自治的。

这种模式的关键是明确边界，写清楚哪些字段是公司强制、哪些是事业部必填、哪些是项目可选。我在一家约 800 人的企业见过一个比较实用的做法：用字段名的前缀区分层级，比如强制字段统一加特定前缀，这样在做跨部门报表时可以直接按前缀筛选。

七、不同情况下的取舍

治理方案最终都要落到取舍上。下面四组取舍是我在做类似项目时反复遇到的，每一组我给出我的默认建议和例外条件。

1. 取舍一：标准化的粒度，锁到哪一层

我建议锁住结构层和流程层的骨架，放开配置层。理由是结构层和流程层骨架决定了跨团队协作的基础，一旦各自为政，后续的数据汇总和流程对接都会出问题；而配置层的差异不会影响协作，放开反而能提高使用意愿。

例外条件是强合规场景。金融、医疗、政企交付类项目，配置层的关键字段也可能需要锁定，因为那些字段直接对应审计要求。这种情况下宁可牺牲一部分灵活性。

2. 取舍二：模板数量与查找成本

这是一组非常清晰的权衡：模板越多，覆盖场景越全，但查找成本越高。我的默认建议是把活跃模板压在 10 个以内，超过的场景通过”在现有模板上做项目级调整”来覆盖，而不是新增模板。

例外条件是这个场景的重复度高。如果某个新场景每年会出现 10 次以上，那就值得为它单开一个模板，即使短期内会让模板数量增加到 12 个。判断的依据是”新增模板节省的总时间”是否大于”所有人增加的查找成本”。

3. 取舍三：集中治理与业务自治

集中治理的好处是标准统一、数据可比；坏处是响应慢、容易脱离业务实际。我的默认建议是关键流程集中、边缘流程自治。具体来说，状态流的骨架、审批卡点、合规字段由统一团队管理；具体的标签体系、视图布局、提醒节奏由业务团队自己定。

例外条件是业务线差异极大。如果公司同时做标准产品、定制交付和运维服务，这三类业务的流程逻辑差异可能大到无法共用骨架，这时应该按业务线分别设定治理边界。

4. 取舍四：迁移时机的选择

很多团队在犹豫”是先在旧工具上治理完再迁移，还是一边迁移一边治理”。我的判断是：如果迁移已经在计划中，就应该合并做，不要在旧工具上花大力气治理。原因是在旧工具上治理的成果很大一部分无法直接带走，而迁移窗口是推动结构变化阻力最小的时机。

例外条件是迁移时间不确定。如果迁移还在评估阶段、半年内不会启动，那先做一轮轻量治理是值得的，尤其是权限收敛和僵尸模板下架这两件事，成本低、效果好、成果可迁移。

5. 取舍五：模板复用深度的边界

最后一个取舍是关于”要不要把模板做得更细”。我见过有团队把模板做到了极致，连每个任务的默认工期都预设好。这种做法的好处是新手可以直接上手，坏处是模板会迅速过时，且维护成本极高。

我的默认建议是预设”结构”和”规则”，不预设”数值”。工期、工时、截止日期这类数值受团队实际能力影响很大，写死在模板里很快会失真，反而让人失去信任。

八、落地检查清单：项目负责人可以照着做的 12 件事

最后给一份可以直接执行的清单。这 12 件事按优先级排序，我建议先做前 5 件，它们投入小、见效快，能建立起治理的基本盘。

1. 前 5 件事：一周内可以完成

1. 盘点现有模板，记录每个模板的最后修改时间、作者、近 90 天使用次数。
2. 找出作者已离职或转岗的模板，标记为”无主模板”，优先处理。
3. 关闭全员模板创建权限，收敛到 2 到 3 人。
4. 下架连续 90 天未被使用的模板，但先归档留档。
5. 统一模板命名规则，把”版本号”和”负责人”写进模板名。

2. 中间 4 件事：一个月内完成

1. 抽象出 2 到 3 条基础状态流骨架，按业务类型划分。
2. 为每条骨架配置一套标准自动化规则，作为模板的默认内容。
3. 建立模板变更申请通道，可以是一个工单类型或一个审批流。
4. 定义必填字段和阶段校验字段，明确哪些在创建时校验、哪些在阶段推进时校验。

3. 后 3 件事：一个季度内建立机制

1. 建立季度模板评审，输出保留、升级、合并、下架四类结论。
2. 把净复用率、模板使用分布、变更申请数量纳入季度回顾看板。
3. 为每个模板指定负责人，并在模板说明里写明失效条件。

4. 执行中最容易卡住的三个点

第一是”下架得罪人”。 我的经验是提前把数据摆出来，用”这个模板近 90 天使用 0 次”这种客观事实开场，比讨论”这个模板好不好”有效得多。

第二是”权限收不上来”。 通常是因为团队担心响应变慢。解决办法是承诺变更申请的响应时限，比如 24 小时内给答复。让人看到收敛权限不等于拖慢进度。

第三是”治理完又反弹”。 这一定是因为只做了 90 天治理，没有建立季度评审。模板体系会持续腐化，就像代码会持续产生技术债一样，定期评审是唯一的解药。

写在最后

回到最开始那个问题：为什么模板做得挺认真，复用率就是上不去？我现在给出的答案是，模板复用本质上不是内容问题，而是治理问题。 内容做得再好，只要没有变更入口、没有淘汰出口、没有明确负责人，它就会在 12 到 24 个月里腐化成 20 多个互相矛盾的版本。

另一个我想强调的判断是：不要把模板数量当作管理目标，也不要把复用率当作考核指标。这两个数字都太容易被”做漂亮”而不产生实际价值。真正值得盯的是净复用率和新建项目的实际配置耗时，因为它们没法糊弄。

如果你现在正处在模板开始失控的阶段，我建议你今天就做一件事：打开模板列表，按最后修改时间排序，把超过 6 个月没动过的模板单独列出来。这一个动作花不了 10 分钟，但它会告诉你，你的模板体系里到底有多少是活的。

下一步则是判断自己属于哪种规模和组织形态，对照第六节的建议先做那一两件成本最低的事。模板治理不需要一次做完，它更像是一个长期维护的产品，只要机制建起来了，后面每季度花 1 小时就能维持住。