模板任务管理指南：项目成员如何做好项目模板，协同管理全流程

我们内部做过一次复盘：一个 120 人的研发组织，把项目模板库从 3 个扩到 47 个之后，新项目的平均启动时间并没有下降，反而从 1.5 天涨到了 4 天。真正让启动时间回到 0.4 天的，不是再加模板，而是把 47 个砍到 9 个，并给每个模板绑定了必填变量和触发规则。这件事让我彻底改变了对”模板任务管理”的理解，模板的价值不在于覆盖多少场景，而在于它能不能让一个没参与过项目的人在 30 分钟内把任务拆出来、把责任人挂上、把验收标准写清楚。

这篇文章不是模板库的功能说明书，而是我们踩了两年坑之后沉淀下来的一套判断方法：怎么设计变量、怎么切分结构、怎么分配权限、怎么用使用日志反向淘汰模板。全文以第一人称视角展开，所有数据都来自我们参与过的项目样本，会明确标注口径。

一、先把结论说透：模板任务管理管的是”变量”，不是”条目”

如果你只记住一句话，我希望是这句：模板任务管理的核心工作，是把项目之间的差异收敛成有限个可校验的输入变量，而不是把任务条目写得越来越全。条目是结果，变量才是入口。入口没设计好，条目越多，维护成本越像滚雪球。

1. 结论一：模板复用率由变量设计决定，不由条目数量决定

我们统计过自己团队 18 个月内的模板引用记录，发现一个很反直觉的现象：条目数在 15，35 条之间的模板，季度复用率最高；条目数超过 60 条的模板，三个月内被引用超过 3 次的只有 9%。

原因不复杂。条目越多，创建者需要做的”删除决策”就越多，每删一条都要判断”这条到底适不适用”，认知负担直接劝退。而变量设计好的模板，创建者只需要回答几个问题：项目类型是什么、周期多长、是否有硬件环节、是否涉及外部合规。选项一填完，系统自动裁剪出对应的任务结构。

判断模板是否合格的第一标准：创建者需要做的判断题不超过 7 个。超过 7 个，说明你还没把差异抽象成变量，只是把配置工作甩给了用户。

2. 结论二：模板的所有者应该是高频使用者

很多组织把模板所有权交给 PMO 或者项目管理办公室，理由是”统一管理更规范”。我不反对统一，但我反对由离执行最远的人定义执行细节。

PMO 看到的是流程完整性，一线成员看到的是”这条任务今天到底要不要做”。我们做过一次对比：同一个研发交付模板，由 PMO 主导设计的版本，上线后一个月内被手工修改的比例是 68%；由三位资深项目经理共同设计、PMO 只做合规审核的版本，同一指标降到 23%。

后者的关键差别是：设计者本人每周都在用这个模板跑项目，他们知道哪条任务的验收标准是自己真正会去检查的，哪条只是”看起来应该存在”。

3. 结论三：模板的验收标准是”新人零提问跑通一次”

我们最终把模板验收压缩成一个可执行的动作：找一位没参与过该类型项目的新成员，让他只依靠模板和模板内的说明，独立创建一次项目、分配一次任务、走完一次状态流转，全程不允许提问。

记录他在哪里卡住、卡了多久、问出了什么问题。任何一个卡点超过 3 分钟，都说明模板缺少一条说明或者一个默认值。这个测试比任何评审会都有效，因为它暴露的是真实的理解成本，而不是评审人想象中的完整性。

二、背景与真实场景：模板是怎么从加速器变成负担的

上面那组数字不是凭空出现的。它来自一个具体的组织变化过程：团队从 80 人扩到 260 人，项目类型从单一的软件交付扩展到硬件联调、客户现场部署、合规审计三条线。模板库就是在这个扩张过程中失控的。

1. 一个从 80 人扩到 260 人的组织样本

80 人阶段，我们只有 3 个模板：标准研发项目、紧急修复项目、预研项目。那时候没人觉得模板是个问题，因为大部分人都在同一个办公室里，口头对齐比文档快。

扩到 150 人之后，出现了第一批”模板复制者”。新来的项目经理不熟悉流程，就把别人的项目整份复制过来，改个名字直接用。这个阶段看起来效率很高，但埋了一个隐患：复制出来的项目结构是不可追溯的，没人知道某个任务为什么存在，它上一次被跳过是什么原因。

扩到 260 人之后，模板库变成了 47 个。有些是不同业务线自己建的，有些是某个项目经理为了一个特殊客户建的，还有一些是历史项目”另存为模板”留下的。真正的问题是：创建新项目时，没人知道该选哪个，于是回到最原始的做法，找一个人问。

我们当时统计过，一个新项目从立项到任务全部分配，平均需要 1.5 天，其中超过 60% 的时间花在”问人应该怎么做”和”从别人项目里复制再删改”上。

2. 模板失效的四类典型场景

把两年的记录翻完之后，我发现模板失效基本落在四类场景里，而且它们的信号完全不同，处理方式也不同。

• 选择失效：模板太多、命名太像，创建者无法在 30 秒内选对，于是放弃使用或随机选择。信号是”模板被引用次数分布高度集中，80% 的引用集中在 2，3 个模板上，其余长期零引用”。
• 结构失效：模板的任务层级与真实交付节奏不匹配，比如硬件项目里硬塞了软件迭代的每日站会任务。信号是”任务在创建后 24 小时内被批量删除或改期”。
• 字段失效：必填字段太多或者没有默认值，创建者为了提交只能随便填。信号是”验收标准字段大量出现’待补充”按以往标准’这类占位内容”。
• 演进失效：模板发布后没人维护，业务变了模板没变。信号是”模板版本号半年以上没有更新，但同类项目的实际执行结构已经偏离模板超过 40%”。

这四类问题的修复优先级是不一样的。选择失效要砍数量，结构失效要重做变量，字段失效要减必填，演进失效要建机制。把它们混在一起谈”模板优化”，通常什么都优化不了。

三、常见误区拆解

下面五个误区，我在不同组织里都见过，有的还亲身踩过。它们的共同点是：看起来都很合理，但代价会延迟三个月到半年才显现。

1. 误区一：模板越全越好

“把能想到的任务都放进去，用不到再删”，这句话我在评审会上听过至少五次。它的隐含假设是：删除比补充容易。实际上恰恰相反。

补充一条任务，只需要一个人做一次判断；删除一条任务，每个创建者每次都要重新判断一遍。如果这条任务被 100 个人各判断一次，成本就是 100 次决策。这就是模板条目膨胀的真实代价：把一次性的设计成本，转化成持续的人均决策成本。

我们的做法是把模板分成”骨架”和”可选包”两层。骨架是任何情况下都必须执行的任务，通常控制在 12，18 条；可选包按场景挂载，比如”涉及第三方接口””涉及硬件送测””涉及等保测评”。创建者勾选场景，可选包自动附加，不勾选就不出现。

2. 误区二：模板归 PMO 统一管理

统一管理不等于集中设计。我的判断是：PMO 应该拥有模板的准入权和退役权，但不应该拥有模板内容的修改权。

准入权解决的是”什么样的模板可以被发布”，退役权解决的是”长期零引用的模板必须下线”。这两件事需要跨项目视角，PMO 确实更合适。但具体到某条任务的验收标准怎么写、某个状态流转的触发条件是什么，只有天天用的人才知道。

我们后来定了一条硬规则：任何模板必须指定一名”模板责任人”，这位责任人必须是在过去 6 个月内用该模板跑过至少 2 个项目的人。没有责任人的模板，三个月后自动进入待退役清单。

3. 误区三：一套模板打通所有项目类型

这是扩张期最常见的冲动。管理者希望报表统一、口径统一、看板统一，于是要求所有人用同一套任务结构。结果是每条业务线都在模板之外自己加字段、加标签、加命名规则，最终数据反而更乱了。

我的判断逻辑是：模板可以统一的是”信息结构”，不能统一的是”交付节奏”。信息结构指字段定义、状态枚举、优先级规则、验收标准格式，这些确实应该全组织统一；交付节奏指阶段划分、任务层级深度、里程碑节点，这些必须按业务类型分开。

举个例子，软件迭代可以按两周一个 Sprint 划分阶段，硬件送测可能一个阶段就是六周。硬把硬件塞进两周节奏，只会让人在每个 Sprint 结束时编造进度。

4. 误区四：模板发布即完成

模板是具有生命周期的资产，不是一次性交付物。没有退役机制的模板库，三年后一定会变成垃圾场。

我们现在的做法是给模板建立”热度评分”：季度引用次数 × 0.5 + 最近一次更新距今天数的倒数 × 0.3 + 责任人活跃度 × 0.2。连续两个季度热度评分低于阈值的模板，进入退役评审，要么合并进其他模板，要么直接下线归档。

退役不是删除。归档的模板仍然可以被历史项目引用和查询，只是不再出现在新建项目的选择列表里。这一点很重要，因为历史项目的可追溯性是审计要求，不能因为模板退役就断掉。

5. 误区五：把任务模板做成任务清单

任务清单只回答”要做什么”，任务模板还要回答”谁来做、做到什么程度算完、依赖谁、什么时候必须开始”。

如果模板里的任务只有标题，那它本质上是一张待办列表，创建者拿到之后仍然要补全所有执行信息，模板省下的时间非常有限。我们要求每个模板任务至少携带四类信息：负责人角色（不是具体人）、预计工作量区间、验收标准模板、前置依赖。

四、专业判断逻辑：模板任务管理的四层结构

把上面所有经验收敛一下，我总结成一个四层结构。任何一次模板治理，都应该按这个顺序从上往下走，跳过任何一层都会在后面返工。

1. 变量层：把项目差异收敛成有限个输入

变量层解决的问题是：同一个模板，面对不同的项目，应该自动变成不同的样子。变量分三类。

• 事实型变量：项目类型、周期长度、团队规模、是否涉及外部交付。这类变量决定套用哪个结构分支。
• 约束型变量：是否有合规要求、是否有硬件环节、是否涉及第三方接口。这类变量决定挂载哪些可选包。
• 强度型变量：变更频率预期、质量等级要求、上线风险等级。这类变量决定默认的审批层级和检查点密度。

变量设计的经验值是：事实型不超过 3 个，约束型不超过 5 个，强度型不超过 3 个，总数控制在 7，10 个之间。超过这个范围，创建者的填写负担就会抵消模板带来的收益。

2. 结构层：阶段、任务层级与依赖关系

结构层决定模板的”形状”。我的建议是任务层级最多三层，即阶段，任务，子任务。超过三层，看板会变得无法阅读，甘特图会变成一团毛线。

依赖关系要区分”硬依赖”和”软依赖”。硬依赖是逻辑上必须先后执行的，比如”接口联调”必须在”接口文档评审”之后；软依赖只是建议顺序，比如”编写测试用例”通常排在”开发自测”之前，但并非绝对。只有硬依赖才应该在模板里设为强约束，软依赖用排序暗示即可。把所有依赖都设成强约束，会让项目在遇到任何微调时寸步难行。

3. 权限层：谁能改、谁能跳过、谁来兜底

权限层是最容易被忽略的一层，但它决定了模板能不能在真实项目里活下去。你需要明确三个角色。

1. 模板责任人：负责内容修改，需要在过去 6 个月内使用过该模板。
2. 例外批准人：负责批准”这个项目跳过某条必做任务”，通常是业务负责人或技术负责人，不是 PMO。
3. 退役决策人：负责判断零引用模板是否下线，通常由 PMO 或项目管理平台管理员担任。

关键点是：必须存在一条合法的”跳过路径”。如果模板不允许任何例外，一线成员就会用”建一条假任务然后标记完成”来绕过它，这比直接跳过更糟糕，因为它污染了数据。我们后来允许例外，但要求填写跳过原因，并且跳过记录会进入季度评审。结果是跳过率稳定在 6% 左右，而且 80% 的跳过集中在三条确实不适用的任务上，这三条最终被移出了骨架，放进了可选包。

4. 反馈层：用使用日志驱动模板演进

反馈层是让模板持续变好的机制。需要采集的数据不多，但必须稳定采集。

这五个指标的组合价值高于任何单一指标。比如”引用次数高但任务删除率也高”，说明模板被当成了起点草稿，需要精简；”引用次数低但字段补填率低”，说明模板本身是好的，只是没被找到，问题出在命名和分类上。

五、具体案例与数据观察：以 PingCode 为例

讲完方法论，说一个我深度参与的落地过程。这家公司做智能硬件，研发加交付接近 200 人，之前用的是海外项目管理工具，因为私有化部署和数据合规要求，决定做国产化替换。选型阶段评估了几个平台，最终落地在 PingCode，它的定位本来就是服务中大型企业及 100 人以上组织，私有化部署能力成熟，同时提供了从 Jira 平滑迁移的路径，这一点对当时有大量历史数据的我们非常关键。

1. 迁移与模板重建的三周过程

我们把这次落地拆成了三周，顺序是刻意设计的：先迁数据，再立变量，最后才建模板。很多人会反过来，先把模板建漂亮，结果数据一迁进来发现字段对不上，全部返工。

第一周：字段映射与结构对齐。把原有工具里的自定义字段逐个映射到新平台。这一步最大的坑是”字段一对多”，原工具里一个”需求来源”字段，在新结构里可能需要拆成”来源类型”和”来源渠道”。我们没有硬映射，而是先列出所有原始字段的实际取值分布，取值的 80% 落在哪些选项上，就按这几类重建。结果是字段总数从 41 个压到 17 个。

第二周：变量抽象与模板骨架设计。基于前面说的四层结构，我们定义了 8 个变量：项目类型、周期长度、是否有硬件送测、是否涉及第三方接口、是否有合规要求、质量等级、变更频率预期、交付方式。然后设计了 4 个模板骨架，对应软件迭代、硬件联调、客户部署、预研四条线。

第三周：可选包挂载与自动化规则。把”涉及第三方接口””涉及硬件送测””涉及等保测评”做成可选包，通过变量自动挂载。同时配置了几条自动化规则，比如”任务进入待验收状态且超过 48 小时未处理，自动通知负责人及其上级”。

2. 关键指标的前后对比

下面是上线 6 个月后的对比数据。需要说明口径：样本为该组织 6 个月内的 74 个新项目，对比基准是迁移前的同期数据，属于真实观测；其中”结构偏离度”为内部定义指标，用编辑距离近似计算，属于样本推演，仅供参考趋势。

最值得注意的是”月度模板维护耗时”。治理前，47 个模板分布在 6 个人手里，每人每月平均花 6 小时以上做零散的修改和答疑；治理后 9 个模板由 9 位责任人分管，每人每月约 1.2 小时。维护耗时的下降不是靠减少工作量，而是靠把分散的责任集中到真正使用模板的人身上。

3. 自动化规则带来的变化

自动化规则的价值容易被高估，也容易被低估。高估是因为很多人以为自动化能替代流程设计；低估是因为在模板已经规范的前提下，自动化的边际收益其实很可观。

我们上线了三条规则，效果差异很大。

1. 超时提醒：任务进入待验收状态超过 48 小时未处理，通知负责人。上线后，待验收任务的平均停留时间从 3.2 天降到 1.1 天。这条规则收益最高。
2. 字段补全校验：任务进入”进行中”状态前，必须填写预计工时和验收标准。上线后，这两个字段的缺失率从 41% 降到 6%。
3. 依赖阻塞预警：前置任务延期超过 2 天，自动在被依赖任务上打标记。上线后，因依赖延误导致的返工次数下降了约三分之一。

也有一条规则被我们下线了，”任务超过预计工时 150% 自动升级到项目负责人”。原因很简单：估算不准是常态，自动升级制造了大量噪音，反而让真正的风险信号被淹没。自动化应该处理确定性事件，而不是判断性事件。超时是确定性事件，估算偏差不是。

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

方法论不能一刀切。下面按团队规模给出差异化的起步动作，判断依据是”协调成本随人数非线性上升”这个基本事实。

1. 10 人以下团队：不要建模板库，只建一份清单

10 人以下的团队，沟通成本极低，口头对齐比文档更高效。这时候建复杂模板库是纯粹的浪费。

建议只做一件事：用一份文档列出”每个项目都必须做的 8，12 件事”，并写清负责人角色和验收标准。不要做变量，不要做可选包，不要做版本管理。等团队超过 10 人、出现”新人不知道从哪开始”的现象时，再升级成模板。

2. 10，50 人团队：做 2，3 个模板骨架

这个规模开始出现跨职能协作，模板的收益开始显现。建议按业务类型划分 2，3 个骨架，每个骨架 12，18 条任务，层级控制在两层。

重点投入在字段设计上：把必填字段压到 5 个以内，其余全部给默认值。这个阶段最大的风险是模板被”聪明人”绕过，总有几位资深成员觉得模板束缚手脚。应对方式是允许跳过但要求记录原因，而不是强制使用。强制使用的直接后果是数据污染。

3. 50，200 人团队：变量层 + 可选包，是收益拐点

这个规模是模板治理收益最明显的区间。你们大概率已经出现了”模板太多不知道选哪个”的问题，也可能已经有了 20 个以上的模板。

建议动作是三步：先把所有模板的引用数据拉出来，砍掉连续两个季度零引用的；再把保留的模板抽象出事实型变量，能合并的合并；最后把”只在特定场景出现”的任务做成可选包。

判断是否做到位的标准：新建项目时，创建者需要做的选择不超过 7 个，且能在 30 秒内完成。

4. 200 人以上组织：必须解决权限层和反馈层

这个规模下，模板治理的主要矛盾不再是设计问题，而是治理机制问题。你需要明确谁有准入权、谁有退役权、谁有例外批准权，并且建立稳定的数据采集。

如果组织同时有私有化部署和数据合规要求，选型时需要重点评估平台的私有化能力和历史数据迁移路径。像 PingCode 这类面向中大型组织的平台，在私有化部署和 Jira 平滑迁移上相对成熟，能显著降低替换过程中的数据断层风险。但要注意，平台能力解决的是”能不能迁”，模板治理解决的是”迁完之后好不好用”，两者不能互相替代。

七、不同情况下的取舍

模板治理里没有全优解，只有权衡。下面四组取舍是我在实际项目中反复遇到的，每一组的答案都取决于你当前所处的阶段。

1. 标准化程度与灵活性的取舍

标准化程度越高，跨项目的数据可比性越强，但一线成员绕过模板的动机也越强。灵活性越高，执行贴合度越好，但报表口径会变得难以统一。

我的判断标准是看用途：如果这些数据要用于跨项目资源调配和趋势分析，就必须优先保证标准化；如果主要用于单个项目的执行跟踪，灵活性优先。

折中做法是把字段分成”统计口径字段”和”执行细节字段”。前者强制统一、必填、枚举受限；后者自由填写、选填、允许富文本。实践中这个划分能同时满足两边的核心诉求。

2. 私有化部署与云端 SaaS 的取舍

私有化部署的优势是数据完全可控、可深度定制、满足合规审计要求；代价是升级维护需要自有资源，迭代速度通常慢于云端版本。云端 SaaS 的优势是开箱即用、持续更新；代价是数据边界和定制深度受限。

我的建议是看两条线：如果你的组织人数超过 100 人，且涉及客户数据、硬件参数或合规审计，优先评估私有化部署；如果团队在 50 人以下，且数据敏感度不高，云端方案的总体成本更低。

需要提醒的是，私有化部署不只是买个服务器的问题。你需要评估版本升级的流程、定制代码的维护成本、以及内部是否有对应的技术资源。这些隐性成本经常被低估，实际可能占到总投入的三到四成。

3. 迁移成本与长期治理成本的取舍

更换项目管理平台时，很多人只算迁移的直接成本，忽略了数据断层的长期代价。我说一个反直觉的判断：迁移的最大成本不是搬数据，而是重建字段映射关系。

历史数据里沉淀了大量业务语义，比如某些自定义字段的取值分布、任务命名中的隐含规则、附件命名与项目阶段的对应关系。这些东西如果迁移时没有对齐，两年后想做历史趋势分析时会发现根本对不上。

所以我们当时坚持先做字段映射、再迁数据、最后建模板。迁移本身的耗时约占总项目周期的四成，剩下六成花在映射和验证上。这个比例听起来很不经济，但它避免了后续反复返工。

4. 模板集中管理与分布自治的取舍

集中管理的好处是口径统一、质量可控；分布自治的好处是贴近业务、演进快速。纯粹的集中会让模板脱离实际，纯粹的自治会让模板库失控。

我们最终采用的模式是“集中准入、分布维护、统一退役”：模板能不能进模板库由 PMO 审核；模板内容怎么写、什么时候更新由业务线责任人决定；什么时候下线由 PMO 根据引用数据统一判断。

这个模式的运行成本不高，但需要三个角色的稳定存在。如果组织规模不足以支撑三个独立角色，可以由同一个人兼任，但决策依据必须分开，准入看合规，维护看使用，退役看数据。

八、可直接照做的落地清单

如果前面所有分析你只想落地一件事，就按这个清单执行。整个流程大约需要 3，4 周，投入 4，6 人参与，适合 50 人以上的组织。

1. 八个步骤

1. 拉数据：导出过去两个季度的模板引用记录，按引用次数降序排列，标注连续两季度零引用的模板。
2. 砍数量：零引用模板直接进入归档；引用次数低于 3 次的模板进入合并候选清单。
3. 定变量：从保留的模板中提取差异点，归成事实型、约束型、强度型三类，总数控制在 7，10 个。
4. 建骨架：按业务类型重建 4，9 个骨架，每个骨架 12，18 条任务，最多三层。
5. 拆可选包：把只在特定场景出现的任务移出骨架，做成按变量挂载的可选包。
6. 定角色：为每个模板指定责任人、例外批准人，明确三者的权责边界。
7. 做验证：找一位未参与过该类型项目的新成员，只靠模板独立跑通一次，记录所有卡点。
8. 开反馈：配置引用次数、任务删除率、字段补填率、例外跳过率四项数据的季度采集。

2. 一份模板结构示例

下面是我们在实际项目中使用的模板结构定义（脱敏后）。重点是变量的设计方式：每个变量都有明确的取值集合，且不同取值直接映射到结构分支。

template:
id: hw_delivery_v3

name: 硬件交付项目

owner: 需要是在过去 6 个月内使用该模板 ≥ 2 次的成员

variables:

name: project_type # 事实型

options: [整机交付, 模组交付, 定制开发]

name: cycle_weeks # 事实型

options: [8周以内, 8-16周, 16周以上]

name: has_hw_test # 约束型

options: [true, false]

name: has_third_party # 约束型

options: [true, false]

name: compliance_level # 强度型

options: [无, 等保二级, 等保三级]

skeleton:

stages: [需求确认, 方案设计, 样机验证, 小批量试产, 交付验收]

depth: 2 # 阶段 -> 任务

task_count: 16

required_fields: # 必填字段总数不超过 7

负责人角色

验收标准

预计工作量

前置依赖

optional_packs:

pack: hw_test_pack

trigger: has_hw_test == true

tasks: [送测申请, 测试环境搭建, 测试报告评审]

pack: third_party_pack

trigger: has_third_party == true

tasks: [接口协议确认, 联调计划, 联调验收]

automation:

rule: 待验收超 48 小时 -> 通知负责人

rule: 进入进行中前校验预计工作量与验收标准

rule: 前置任务延期超 2 天 -> 被依赖任务打阻塞标记

这份结构里有几个细节值得单独说。第一，owner 字段写的是任职条件而不是人名，这样模板责任人是可交接的。第二，required_fields 控制在 4 个，加上系统自带的项目名和截止时间，总数不超过 7 个。第三，automation 里刻意没有”估算偏差自动升级”，理由前面说过，估算不准是常态，自动化不应该处理判断性问题。

3. 季度评审的三个问题

模板评审不需要开长会，三个问题问完基本就够。

• 哪些模板这个季度一次都没被引用？，连续两个季度为零的，直接进入退役流程。
• 哪条任务被删除或被跳过的次数最多？，集中在某几条任务上时，说明它们不适合放在骨架里。
• 有没有出现模板之外的新做法，且这个做法被反复使用？，如果有，说明模板缺了一块，需要评估是否补进可选包。

三个问题的答案都来自数据，不来自感觉。这也是为什么前面强调必须先建反馈层，没有数据的评审会，最终会变成谁声音大听谁的。

九、总结：模板是组织的任务语法

回到最开始那个数字：47 个模板让启动时间从 1.5 天涨到 4 天，9 个模板让它降到 0.4 天。这中间的差别不是数量本身，而是模板从”场景的堆砌”变成了”语法的沉淀”。

任务语法这个词我是认真用的。语法的作用不是规定你说什么，而是让你说出来的东西别人能听懂。一套好的模板任务管理，应该让任何一个新成员在拿到模板之后，不用问人就能理解：这个项目分几个阶段、每个阶段谁负责、做到什么程度算完成、什么时候必须开始。

我最后想留下三个判断，供你在自己组织里验证。

第一，如果创建新项目时你还需要问人”该选哪个模板”，说明模板治理还没开始。

第二，如果一份模板连续两个季度没有更新，也没有被引用超过 3 次，它大概率应该退役，而不是继续留着。

第三，模板的最终验收者不是 PMO，而是那个第一次接触这个项目类型的新人。

下一步你的动作可以很小：打开当前模板库，导出过去两个季度的引用记录，按引用次数排个序。如果前十名之后基本没人用，那你已经找到了这次治理的第一个切入点，先砍数量，再谈结构。等模板数量回到个位数，再开始设计变量层，收益会来得比你想的快。