模板阶段最佳实践：产品经理项目模板效率提升，常见问题

我做过一次不太体面的统计：把手上 27 个产品团队的项目模板库摊开，按“从创建项目到第一个任务进入开发”的时间口径算，模板最多的那个团队反而是最慢的，41 个模板，平均每次选模板犹豫 47 秒，选完之后还有 6 个字段不知道该填什么。而另一个只有 4 个模板的团队，同一口径是 8 分 30 秒。模板数量和模板效率之间不是线性关系，它更像一条先降后升的 U 型曲线，拐点大约出现在 8 到 12 个模板之间。

这篇文章讲的是“模板阶段”的最佳实践。所谓模板阶段，指的是一个组织从“没有模板、靠口头约定”走到“模板稳定、可版本化、可退役”的整个过程。它不是一次性动作，而是一段有明确阶段特征、有明显腐化风险、也有可量化收益的演进期。下面我把踩过的坑、量过的数据、以及在不同规模组织里验证过的判断逻辑，完整拆开讲一遍。

一、核心结论：模板阶段的效率不在“多”，而在“默认值密度”

先把结论放在前面。模板阶段真正决定效率的，不是模板的数量，也不是模板里写了多少内容，而是模板携带的“有效默认值密度”。所谓有效默认值，是指产品经理在创建项目时不需要再做判断、直接接受也不会出错的那部分配置。

我见过太多团队把模板做成了“项目说明书”，模板里塞满了几十页的 WBS、风险清单、干系人列表。结果是：新建项目时没人敢直接用，因为套上去之后要删掉三分之二的内容，删的时间比从零建还长。这不是模板，这是文档。

1. 结论一：模板的收益来自“减少决策次数”，不是“减少录入字段”

我在 2022 年对一个 12 人的产品中台小组做过一次计时观察，记录产品经理新建一个中等复杂度项目（周期 6 周、涉及 3 个研发小组）时的耗时构成。结果是：纯手工录入字段的时间平均 3 分 10 秒，而“想清楚工作项怎么拆、状态流怎么走、谁在哪个环节评审”的决策时间平均 14 分 40 秒，比例大致是 1:4.6。

这个比例说明了一件事：如果模板只帮你省下打字时间，你最多拿到 18% 的收益。真正有价值的是把那些“每次都要重新想一遍”的决策前置固化下来。所以我在设计模板时，优先固化的顺序是：状态流 → 工作项类型拆分 → 必填字段 → 视图与筛选器 → 自动化规则 → 权限预设 → 报告口径。字段是最后一项，也是收益最小的一项。

2. 结论二：没有退役机制的模板库，18 个月内必然腐化

模板库的腐化速度比大多数人想象得快。我追踪过 6 个团队从“有第一个模板”到“模板失控”的周期，中位数是 14 个月。在这 14 个月里，模板数量的月均净增速是 3.2%，但模板的月均退役率只有 0.4%。也就是说，增长是退役的 8 倍。

这个失衡的根源不在产品经理懒，而在组织机制：新增一个模板是某个人的个人收益（他省事了），退役一个模板是集体收益但没人有动力去做（用的人可能已经离职了）。所以模板治理必须有人“背指标”，否则一定会走到 40 个模板那个团队的老路上。

3. 结论三：模板阶段只需要盯四个指标

我在推模板治理时，只推四个指标，多了团队不看。这四个指标分别是：模板复用率（用模板创建的项目占全部新建项目的比例）、模板漂移率（新建后 7 天内被大幅修改状态流或字段的项目占比）、TTV（Time to Value，项目创建到第一个任务进入开发的时间）、字段填充率（必填字段中填写了有效值的比例）。

这四个指标的共同点是：都能从项目管理平台里自动跑出来，不需要人肉统计。任何需要人工填表才能得到的度量，在模板阶段都活不过两个季度。

4. 结论四：中大型组织的瓶颈是治理，不是设计

100 人以内的组织，模板阶段的主要矛盾是“设计得对不对”。100 人以上、尤其是 300 人以上、多业务线并行的组织，主要矛盾会迅速转移到“治理得动不动”。

设计能力是可以靠一两个高手解决的，治理能力必须靠机制。这也是为什么很多团队在 50 人时模板用得挺好，到 200 人就彻底崩掉，不是模板变差了，是没人能决定哪个模板该被合并、哪个该被删掉。

二、背景与真实场景：一个 130 人产品组织的模板阶段演进

我把模板阶段的演进拆成五个时期。这不是理论模型，是我在一个 130 人产品组织中实际经历的路径，后续在四个不同规模团队里做了验证，阶段特征基本一致，只是每个时期停留的时间长短不同。

1. 时期零：无模板，靠口头约定（0 到 3 个月）

这个时期的典型特征是：每个人创建项目的方式都不一样。有人用列表，有人用看板；有人把需求拆到 3 层，有人只建一行“大需求”。表面上看团队很灵活，实际上每次跨组协作都要重新对齐一次“你这边这个状态是什么意思”。

这个时期最大的隐性成本是对齐成本。我记录过一次跨三个小组的联调评审，光是确认“什么叫已完成”就花了 12 分钟。这不是个别现象，而是无模板状态的常态。

2. 时期一：第一个模板出现，然后失控（3 到 14 个月）

第一个模板通常来自某个流程意识强的产品经理。它很好用，于是被复制。复制的过程没有任何规范，A 组复制的版本改了两个状态名，B 组复制的版本加了三个自定义字段，C 组直接拿 A 的版本又改了一轮。

到第 12 个月，模板数量从 1 涨到了 17。这时候出现了一个我之前没预料到的现象：产品经理开始不信任模板了。他们宁可手动建项目，因为“用模板还得先搞清楚这个模板是谁的版本、有没有过时”。信任一旦崩塌，模板复用率会断崖式下跌。

3. 时期二：模板收敛，建立命名与归属规范（14 到 20 个月）

这个时期的核心动作是“砍”。我们把 17 个模板合并成 6 个，规则是：如果两个模板的状态流差异不超过一个状态节点，就合并；如果差异在两个以上，才保留独立模板。

同时建立了命名规范，格式是“业务域-项目类型-复杂度”，例如“增长-活动运营-轻量”。命名规范的价值被严重低估：它把“选哪个模板”从一个开放性问题变成了一个填空题。这一步做完，模板选择耗时从 31 秒降到了 11 秒。

4. 时期三：模板与自动化、权限、报告绑定（20 到 28 个月）

这是收益最大的一个时期。在前面的时期，模板只是一个“初始结构”；到这个时期，模板变成了一个“初始状态包”：它同时预设了自动化规则（例如需求状态变成“待评审”时自动通知评审人）、权限模型（例如外部协作方默认只读）、以及报告口径（例如燃尽图按子任务统计还是按故事点统计）。

这个时期的收益不是线性的。我在一个 6 个产品小组的范围内做了前后对比，TTV 从 16 分 50 秒降到 9 分 40 秒，但更关键的是模板漂移率从 34% 降到了 9%。漂移率下降意味着模板真正被“接受”了，而不是被当做一个起点草稿。

5. 时期四：版本化与退役机制（28 个月以后）

最后一个时期是让模板本身变成一个可管理对象：有版本号、有变更记录、有生效范围、有明确的退役流程。这个时期最重要的规则是：模板变更只对新项目生效，不回溯存量项目。这条规则救了我们很多次，后面在误区部分会详细讲。

三、拆解常见误区：六个让模板阶段功亏一篑的坑

下面六个误区，是我在 27 个团队里反复见到的。它们有一个共同特征：在短期内看起来都是“更专业”“更规范”的做法，长期却把模板库推向腐化。

1. 误区一：把模板做成“项目计划书”

最常见的误操作，是把一份完整的项目计划直接塞进模板：几十个预置任务、风险登记表、干系人矩阵、验收清单。做的人觉得自己很用心，用的人却在第一步就卡住了。

判断标准很简单：如果一个模板套用之后，产品经理需要删除超过 30% 的内容，那它就不该是模板，应该是检查清单（Checklist）。清单是“你随时可以对照”，模板是“你必须从这里开始”，两者的使用心智完全不同。

我的处理办法是把这类内容拆成两类：结构性内容（工作项类型、状态流）留在模板里，文档性内容（风险清单、验收标准）做成项目内的一个“检查项视图”，不占用模板的初始结构。

2. 误区二：用模板去解决流程治理问题

“我们流程不统一，所以做一个统一模板吧。”这句话我听过太多次。问题是，流程不统一是治理问题，模板只是容器。容器统一了，里面的东西照样可以不一样。

具体表现是：状态名统一了，但“进入开发”的准入条件各不相同；字段统一了，但同一个字段在不同组含义不同。这种情况下，模板反而制造了虚假的一致性，让问题更难被发现。

正确的顺序是：先定义“什么算进入开发”（准入条件），再把这个条件固化到模板的状态流转规则里。模板是流程的执行载体，不是流程的替代品。

3. 误区三：必填字段越多越“规范”

必填字段是模板设计里最容易被滥用的旋钮。每加一个必填字段，短期数据完整度确实会上升，但超过某个阈值之后，会出现两个反效果：一是产品经理开始填假数据（填“无”“待定”“/”），二是创建项目的心理成本上升，导致有人干脆绕过模板。

我在一个 4 组并行的团队里做过一次梯度测试，把必填字段从 3 个逐步加到 15 个，观察字段填充率和数据可信度（抽样人工核对，判断是否为有效值）。结果在 8 个字段附近出现明显拐点。

4. 误区四：一个模板打天下，或者一人一个模板

这两个极端经常同时出现在同一个组织里：主线业务被强制套用一个“大而全”的模板，边缘业务则各自建自己的模板，最后累计出几十个。前者导致主线团队的模板漂移率极高（因为不适用，只能改），后者导致模板库失去导航能力。

正确的做法是按“使用频次 × 项目差异度”分档，而不是按部门分档。同一部门里的两类项目，差异可能比跨部门还大；不同部门里的同类项目，反而可能共用一套结构。这一点在下一节会展开。

5. 误区五：模板改了，存量项目跟着变

这是最容易被忽略、但破坏力最大的一个误区。很多项目管理平台支持“修改模板后同步到已有项目”，产品经理看到这个功能会觉得很方便，一改就同步。

后果是：历史项目的状态流被改了，导致原来的燃尽图、周期统计、缺陷归因全部失真。我遇到过一次典型事故：一个团队把“已验收”状态拆成“待验收/已验收”两个状态，并同步到了全部存量项目，结果过去 8 个月的交付周期统计数据全部需要重算。

我的硬性规则是：模板变更只对新项目生效，存量项目一律不动。如果确实需要批量调整，走单独的数据迁移流程，并且事先备份统计口径。

6. 误区六：只算创建省下的时间，不算长期维护成本

很多团队做模板效益评估时，只算“每次创建省了 15 分钟，一年 200 个项目就是 50 小时”。但模板的维护成本被完全忽略了：模板设计、评审、合并、版本管理、培训、答疑，这些都是真实的人天消耗。

我实际测算过：一个稳定运行的模板库（6 到 10 个模板、覆盖 200 人规模），年度维护成本大约在 30 到 45 人天之间。如果只覆盖 30 人规模，这个成本会变成负收益。这也是为什么我在第六节会按组织规模给出完全不同的建议。

四、专业判断逻辑：三轴定位法与模板的最小可用结构

讲完误区，讲我实际使用的判断逻辑。这套逻辑我在五个不同规模的团队里用过，核心是三轴定位加七组件结构。

1. 三轴定位：使用频次 × 项目差异度 × 流程变更频率

判断一个场景该不该做模板，我看三个轴。第一轴是使用频次：这类项目一年做多少次。第二轴是项目差异度：同类项目之间，工作项拆分和状态流的差异有多大。第三轴是流程变更频率：这类项目的流程多久需要调整一次。

判断规则是：

• 高频 + 低差异 + 低变更 → 强模板。尽量把结构、字段、自动化、权限、报告全部预设好，目标是“零决策创建”。
• 高频 + 高差异 + 低变更 → 骨架模板。只预设状态流和权限，工作项拆分留给团队自己填，强行统一反而制造摩擦。
• 高频 + 高变更 → 模板 + 变更留白。预设状态流但预留 1 到 2 个“自定义状态位”，允许团队在模板内做有限调整，避免他们另起模板。
• 低频 + 高差异 → 不做模板，做检查清单。低频意味着维护成本摊不薄，高差异意味着模板命中率低，两者叠加就是负收益。
• 低频 + 低差异 → 不做模板，做复制源。直接复制一个历史项目，比维护一个专门模板更划算。

这里有一个容易被忽略的点：“流程变更频率”这个轴往往比前两个轴更能决定模板成败。一个高频低差异但流程每季度都要调的场景，如果做成强模板，产品经理每季度都要重新适应一次，反而比没有模板更痛苦。

2. 模板的最小可用结构：七个组件

我把一个“能打”的模板拆成七个组件。少于七个也能用，但收益会打折；多于七个通常是过度设计。

1. 工作项类型集合。不是越多越好，通常是“需求 + 任务 + 缺陷”三层，加上必要的子任务层。超过五层的工作项结构几乎没有人会认真维护。
2. 状态流与流转规则。核心是定义清楚每个状态的准入条件和退出条件，而不只是状态名。
3. 必填字段集。建议控制在 5 到 8 个，且每个字段都必须有明确的下游消费方，如果没有任何报表或筛选器会用到这个字段，就不该必填。
4. 默认视图与筛选器。这是最被低估的组件。一个预设好的“我的待评审”视图，能让新成员第一天上手就知道该看什么。
5. 自动化规则。至少三条：状态变更通知、逾期提醒、字段变更触发。自动化是让模板“活起来”的关键。
6. 权限预设。默认给最小权限，尤其是外部协作方和跨部门只读角色。
7. 报告口径。燃尽图按什么统计、周期从哪个状态算起、缺陷率的分母是什么。这三件事必须在模板里定死，否则跨项目数据无法比较。

下面是一个模板定义的实际结构示例。这个 YAML 是我用于内部模板评审的简化版本，重点是它显式声明了“不回溯存量”和“变更留白”两个约束。

template:
id: growth-activity-standard

version: 2.3.0

scope: new_projects_only # 硬性约束：不回溯存量项目

naming: "增长-活动运营-标准"

work_item_types:

epic

story

task

bug

workflow:

states: [待评估, 已排期, 进行中, 待验收, 已完成]

enter_criteria:

进行中: "负责人已指派且预估工时已填写"

待验收: "提测记录已关联"

custom_slots: 1 # 允许团队自建 1 个状态位

required_fields:

业务方

上线时间

影响用户量

关联需求ID

automations:

on_state_change: 待验收 -> notify: [业务方, 测试负责人]

on_overdue: 3d -> notify: [项目负责人]

on_field_change: 上线时间 -> sync: 里程碑视图

permissions:

default_role: read_only

external_collaborator: read_only

reports:

burn_down_unit: story_point

cycle_start_state: 已排期

defect_rate_denominator: delivered_story

这份结构里有三个细节值得单独说。第一，scope: new_projects_only 是硬性的，它把“模板变更不回溯”从口头约定变成了配置约束。第二，custom_slots 给了团队一个有限的调整空间，实测下来能把模板漂移率降低约 40%。第三，reports 部分定义了报告口径，这是跨项目数据可比的前提。

3. 模板健康度的五个维度

评估一个模板库是否健康，我看五个维度：覆盖度（能覆盖多少比例的实际项目）、复用率、漂移率、维护成本、以及可发现性（新成员能否在 10 秒内找到该用的模板）。这五个维度里，可发现性最容易被忽略，但它对 TTV 的影响最大。

五、具体案例与数据观察：一次模板库重建的真实过程

下面这个案例来自一家 400 人规模的硬件+软件混合研发企业，研发与产品团队合计约 180 人。他们在国产化替代的背景下，把原来跑在国外项目管理工具上的项目结构迁移到了 PingCode。我参与了这个过程，负责模板部分的重建。

1. 迁移前的模板资产盘点

迁移前，他们在原平台上有 23 个项目模板，散落在 6 个业务线里，命名规则完全不统一。我们花了两天做盘点，盘点的方法很笨但很有效：把过去 12 个月所有创建的项目拉出来，标记每个项目实际使用的模板，然后统计每个模板的真实使用次数。

盘点结果是：23 个模板里，有 9 个在过去 12 个月的使用次数为 0，有 5 个使用次数在 1 到 3 次之间。真正承担 90% 项目量的只有 5 个模板。这个分布和前面帕累托图展示的规律几乎一致。

2. 字段清理与映射

第二个动作是字段清理。原平台上有 47 个自定义字段，其中 31 个是必填。我们做了一次“字段消费方核查”：对每个字段，问三个问题，谁会看这个字段？在哪个报表或筛选器里用到？如果字段缺失，哪个决策会受影响？

三个问题都答不上来的字段，直接不进迁移清单。最终保留 14 个自定义字段，其中 6 个设为必填。字段总数从 47 降到 14，降幅 70%。

3. 用模板 + 自动化 + 权限组合重建

重建阶段，我们只做了 6 个模板，覆盖原来 23 个模板的全部场景。做法是：先用三轴定位法把 23 个场景归类，发现其中 17 个可以归入 4 类结构，剩下 6 个场景因为差异度过高，改成了“检查清单 + 历史项目复制”的方式，不做模板。

选择 PingCode 的一个关键原因是它支持私有化部署，字段和权限模型可以完全自定义，这对硬件企业的保密要求很重要。另一个原因是它提供了从国外项目管理系统平滑迁移的能力，工作项类型、状态、字段的映射关系可以在配置层完成，不需要重建数据模型。

迁移过程中我总结了三条经验：一是先迁结构，后迁数据，结构没定好就迁数据，后期返工成本极高；二是字段映射宁可留空，不要硬凑，把两个语义不同的旧字段映射到同一个新字段，会造成长期的统计污染；三是迁移后要有一段双轨期，我建议至少 4 周，让团队在新旧两边并行跑一个完整迭代周期。

4. 结果数据与观察

迁移和重建完成后，我们跟踪了 4 个月的数据。TTV 从迁移前的平均 19 分 40 秒降到 8 分 20 秒；模板漂移率从 37% 降到 11%；字段填充率从 76% 提升到 94%，同时有效值占比从 58% 提升到 89%。

最有意思的观察来自三个业务线的对比。迁移前，三个业务线的模板漂移率分别是 41%、35%、29%，看起来差异不大。重建后，同一批模板下，三者的漂移率变成了 14%、9%、7%。差异没有消失，但整体水位下降了一半以上。这说明模板治理的收益是普惠的，但它无法消除业务本身的差异。

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

下面按组织规模给出具体建议。这些建议来自实际观察，不是通用模板套话，每个规模档的建议重点完全不同。

1. 20 人以内：不要建模板库，建一个模板就够

这个规模下，模板的维护成本会超过收益。建议只做一件事：选一个最典型的项目，把它的结构整理干净，作为“标准复制源”。任何人要建新项目，直接复制这个源项目，然后改名。

不要做命名规范、不要做模板分类、不要做模板评审流程。这些东西在这个规模下是纯开销。唯一值得做的是把状态流定死，因为状态流是最容易造成沟通成本的元素。

2. 20 到 100 人：3 到 5 个模板，建立命名规范

这个规模开始需要一点结构了。建议控制在 3 到 5 个模板，命名格式统一。同时指定一个人（通常是产品运营或 PMO 角色）作为模板负责人，职责只有两件事：每季度检查一次模板使用率，把使用率低于每月 1 次的模板退役。

这个阶段最容易犯的错是过早引入复杂的治理流程。我见过 40 人的团队搞模板评审委员会，结果是三个月没通过一个新模板，团队直接绕过流程自建，反而更乱。

3. 100 到 500 人：6 到 10 个模板，建立版本与退役机制

这是最需要系统化治理的规模区间。核心动作有三件：第一，模板必须版本化，每次变更留记录；第二，模板变更只对新项目生效；第三，设立明确的退役线（例如连续 6 个月月均使用低于 1 次）。

这个规模也是自动化收益开始显现的阶段。我建议至少把三条自动化做成模板标配：状态变更通知、逾期提醒、以及关键字段变更同步到里程碑视图。这三条能显著降低项目的沟通成本。

如果你所在的组织是中大型企业、有私有化部署或数据合规要求，那么在选择承载平台时，要重点考察三件事：是否支持私有化部署、字段与权限模型能否深度自定义、以及能否从现有工具平滑迁移。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，这几点在国产化替代场景下是比较实际的考量维度。

4. 500 人以上：按业务域分治，模板库分层

500 人以上、多业务线并行的组织，不要再维护一个统一模板库。正确做法是分两层：基础层由平台团队维护，负责工作项类型、状态命名规范、报告口径这些跨业务线必须一致的元结构；业务层由各业务线维护，在基础层之上定义自己的模板，数量控制在每个业务线 3 到 5 个。

这个分层的关键在于：基础层的变更必须走正式评审，因为它影响所有业务线；业务层的变更可以自行决定，只要不违反基础层的元结构。这样既保证了数据可比性，又保留了业务灵活性。

5. 正在做工具迁移的团队：先定结构，再迁数据

如果你正在经历工具迁移（无论是国产化替代还是平台升级），模板阶段会变成整个迁移中最关键的环节。我的建议顺序是：先盘点旧模板的真实使用数据 → 清理字段 → 用三轴定位法归类场景 → 重建模板 → 双轨验证 → 迁数据。

顺序不能颠倒。我见过太多团队先迁数据再整理模板，最后不得不在已有几千个项目的环境里做结构调整，成本是前置整理的 5 到 8 倍。

七、不同情况下的取舍：五个必须做选择的地方

模板阶段没有“全都要”的选项。下面五个取舍是我在实际推进中最常遇到的，每个都必须在某个方向上明确站队。

1. 取舍一：标准化强度 vs 团队自治

标准化越强，跨项目数据越可比，但团队的适配摩擦越大。我的经验分界线是：状态流和报告口径必须标准化，工作项拆分和字段使用可以自治。前者影响的是全组织的数据资产，后者影响的是单个团队的日常体验，代价不对等。

如果你发现某个团队反复绕过模板，先别急着加制度，去看看是不是工作项拆分被强制统一了。这类问题通常是设计问题，不是执行力问题。

2. 取舍二：模板数量 vs 选择成本

模板数量少，选择成本低，但命中率下降；模板数量多，命中率高，但选择成本和维护成本上升。前面那张 U 型曲线图已经给出了参考拐点：在 100 到 500 人规模下，6 到 10 个模板是比较稳的区间。

但有一个例外：如果存在一个每年只做 2 次、流程完全特殊的项目类型（例如合规审计），那它值得占一个模板位。因为它一年只被选择 2 次，选择成本摊薄到几乎为零，而如果没有它，产品经理每次都要从零建结构，痛苦度极高。决策依据不是模板总数，而是“每个模板的年度使用频次 × 从零建立的成本”。

3. 取舍三：私有化部署 vs 云端 SaaS

这个取舍直接影响模板的迭代速度。私有化部署的安全性和自定义能力更强，但模板变更的发布周期通常更长（需要走内部变更流程）。云端 SaaS 的迭代更快，但在字段和权限上的自定义边界可能受限。

我的判断标准是：如果你们有明确的数据合规要求、或者研发流程需要深度自定义字段与状态机，优先考虑支持私有化部署的平台；如果团队分布分散、更看重快速迭代和低运维成本，云端更合适。这个取舍没有普适答案，但它会决定你后面三年的模板治理节奏。

4. 取舍四：模板精细度 vs 迁移成本

模板做得越精细，迁移时的映射工作量越大。我见过一个团队做了 18 个高度定制的模板，迁移时每个模板都要单独设计映射规则，光映射就花了 3 周。另一个团队只有 6 个粗粒度模板，迁移只用了 4 天。

建议是：把模板的精细度控制在“能覆盖 80% 场景”的水平，剩下的 20% 用模板内的自定义空间解决。这部分收益不体现在日常效率上，但在你换工具的那一天会体现得非常明显。

5. 取舍五：强制必填 vs 数据完整度

强制必填能在短期内提升数据完整度，但会降低创建意愿、触发造假行为。前面那张梯度测试图给出的参考是：必填字段控制在 5 到 8 个是效率最优区间。

如果某个字段确实很重要但填起来麻烦，我的做法是把它从“创建时必填”改成“状态流转前必填”。例如“上线时间”在创建项目时不必填，但项目要从“待排期”进入“已排期”时必须填。这样既保证了关键节点的数据完整，又不增加创建时的心理负担。

八、把模板阶段做成一个可运营的系统

写到这里，我想把整篇文章的独特观点收成一句话：模板阶段的本质不是“做模板”，而是“设计一套让默认值持续有效的机制”。模板只是这套机制的可见部分，真正决定成败的是版本管理、退役流程、度量指标和责任人这四件看不见的事。

我见过太多团队把模板当成一个交付物：设计完成、评审通过、上线，然后就没有然后了。半年后回来一看，模板库已经膨胀到没人愿意打开。这不是执行力问题，是缺少运营视角。模板库和任何一个产品一样，需要持续的迭代、清理和度量，否则一定会腐化。

另一个我想强调的判断是：模板的价值上限，取决于它对“决策”的替代程度，而不是对“录入”的替代程度。这也是为什么我始终把状态流、报告口径、权限预设放在优先级最高的位置，它们替代的是最贵的决策；而字段，替代的只是最便宜的打字。

如果你的团队现在正好处在模板阶段的某个时期，我建议的下一步是具体的三个动作：

1. 做一次模板使用率盘点。把过去 12 个月的项目拉出来，统计每个模板的真实使用次数。这个动作半天就能完成，但它会立刻告诉你哪些模板该退役。
2. 核查必填字段的消费方。对每个必填字段问三个问题：谁看、在哪个报表用、缺失会影响什么决策。三个都答不上来的，取消必填。
3. 设定一条退役线并公布。例如“连续 6 个月月均使用低于 1 次的模板自动进入退役评估”。这条规则的价值不在于它执行了多少次，而在于它让所有人都知道模板库是有边界的。

这三件事做完，你大概率会发现模板数量下降了三分之一，但产品经理创建项目的时间反而缩短了。这不是矛盾，这正是模板阶段最反直觉、也最值得记住的一条规律：效率来自于约束的清晰度，而不是选项的丰富度。