项目模板如何做好模板流程？研发团队数据分析与操作步骤

去年下半年，我参与了一个 130 人研发组织的效能复盘，问题非常具体：他们把需求、缺陷、发布三类工作项都做成了模板，上线第一个月模板使用率 92%，第六个月掉到 31%，团队开始抱怨”用模板还不如自己新建一个”。我们花了三周把模板流程重新拆了一遍，把 47 个模板压缩到 13 个，字段填充率从 58% 提到 89%，需求从创建到进入开发的平均等待时间从 2.8 天降到 0.9 天。这篇文章就是那次复盘的完整拆解，不是讲模板怎么建，而是讲模板怎么变成一条能跑起来的流程，以及研发团队该用哪些数据判断它到底有没有跑起来。

一、先给结论：模板流程不是”格式规范”，而是一条可执行的决策链

先把结论放在最前面：绝大多数团队的模板做不好，不是因为模板设计得不够漂亮，而是因为模板里只有”结构”，没有”决策”。一个真正能跑起来的模板流程，必须同时回答四个问题：什么时候用、用了之后强制填什么、填错了能不能流转、用了之后效果怎么衡量。只回答第一个问题的模板，本质上就是一张 Excel 化的表单。

1. 模板流程的四层结构

我在复盘时习惯把模板流程拆成四层，这四层是我自己总结的口径，不是某个工具的官方定义，但它在三个不同规模的团队里都验证过。

• 结构层：模板包含哪些字段、哪些子任务、哪些默认值。这是大多数人理解的”模板”。
• 触发层：什么条件下自动套用模板。是手动选，还是按工作项类型自动带出，还是按项目类型自动继承。
• 门禁层：哪些字段不填就不能进入下一状态，哪些状态下必须补充特定信息，哪些流转需要审批或校验。
• 度量层：模板的使用率、字段填充率、模板衍生工作的返工率、模板版本的变更频率，这些数字有没有人被看到。

四层里最容易缺的是门禁层和度量层。结构层做起来最快，也最有”我做了事”的成就感；触发层通常平台自带，配一下就完事；门禁层要写规则，容易和团队吵架；度量层最麻烦，因为要定义指标、埋点、做看板，而且数据一出来往往不好看。

四层缺一层，模板就会退化成一张表格；缺两层，模板会变成团队的负担。这句话听起来像口号，但它有非常具体的表现形式：缺门禁层，模板字段会被”随便填一个”糊过去；缺度量层，没人知道模板哪一条规则是多余。

2. 一条我常用的判断标准：模板的”腐烂速度”

我更愿意用一个动态指标来判断模板做得好不好，我把它叫做模板腐烂速度，即模板上线后，使用率从峰值衰减到一半所花的时间。

这个指标比”模板数量”有用得多。模板数量多不代表治理得好，往往代表治理失控。而腐烂速度是可以比较的：同样规模、同样业务形态的团队，A 团队模板使用率六个月后还有 74%，B 团队三个月就掉到 40%，那 B 团队的问题一定不是模板做得不够多。

我们在复盘时拉了三条曲线，对应三种治理强度：完全不做治理、只加字段校验、四层齐全。三条线在第三个月之后开始明显分叉，第六个月差距拉到了两倍以上。这个分叉点非常关键，它说明模板的问题不是在创建时暴露的，而是在第二次、第三次复用之后才暴露的。

3. 为什么我反对”模板即规范”

很多团队做模板的出发点是”统一规范”，这个出发点本身没错，但推导出来的动作往往是错的。

规范思维会导向”把我知道的字段全加上去”，而流程思维会导向”只保留影响下一个决策的字段”。这两者的结果差异巨大：前者做出 23 个字段的需求模板，后者做出 7 个字段的需求模板。而在实际使用中，字段数从 8 个增加到 23 个，字段填充率从 96% 掉到 54%，这组数据我在后面会详细展开。

我的判断是：模板应该服务于”下一个角色的决策”，而不是服务于”上一个角色的表达”。产品经理写需求的时候想写得很全，但开发真正需要的是”这个需求要不要拆”、”影响哪些模块”、”验收标准是什么”。模板应该只保留后者，前面的部分放进描述区自由书写就行。

二、真实场景：模板从 92% 用到 31%，只用了六个月

我把那个 130 人团队的完整过程拆出来讲，因为它的每一步都很有代表性。

1. 那个差点被删掉的需求模板

这个团队做的是 SaaS 产品，研发分四个小组，两个前端两个后端，共用一个需求池。2023 年初他们在某项目管理平台里建了一个”标准需求模板”，包含 23 个字段：需求来源、业务价值、目标用户、竞品参考、优先级、预估工时、影响模块、验收标准、埋点要求、法务风险、安全风险、国际化要求，等等。

前三个月效果不错，因为模板是一个资深产品经理牵头设计的，大家在用的时候还能感受到”想得比以前全”。第四个月开始出问题：新人入职后按模板填，填了两周就发现很多字段根本不知道填什么，索性空着；老员工开始绕过模板，直接复制历史需求改一改。

到第六个月，模板使用率 31%，而这 31% 里还有相当一部分是”套了模板但字段大面积留空”。团队当时的第一反应是”要不要把这个模板删掉”。

2. 我们统计出来的三个数字

在决定删不删之前，我们先做了三件事：埋点、抽样、访谈。这一步是整个复盘里投入产出比最高的。

1. 埋点：在平台上统计模板套用次数、字段填充率、模板衍生的需求从创建到进入开发的平均等待时间。
2. 抽样：随机抽了 120 条需求，人工标注哪些字段是”真正被下游使用”的，哪些是”填了但没人看”的。
3. 访谈：找了 6 个人聊，分别是 2 个产品、2 个开发、1 个测试、1 个项目经理，每人 30 分钟。

三个数字最后浮出来：23 个字段里只有 6 个字段被下游真实引用过；模板使用率和需求平均等待时间呈负相关，模板使用率越低，等待时间越长；团队不是在”反对模板”，而是在”反对不知道填什么”。

第三条最关键。我们原本以为是习惯问题，访谈之后发现是信息缺失问题：模板要求填”安全风险”，但团队从未定义过什么叫安全风险，也没给过示例。这种情况下空着是理性的，不是懒惰。

3. 研发团队特有的三个约束

研发团队的模板流程和销售、市场团队有本质差异，如果不理解这三点，模板一定会设计错。

第一，研发的工作项是”变形的”，不是”标准化的”。一个需求在评审后可能被拆成三个子任务，也可能和另一个需求合并，还可能被降级成技术债。模板如果假设”一个需求对应一个固定生命周期”，就会在第一次变形时失效。

第二，研发对”填写成本”极度敏感。开发同学的时间是按小时算的，让他多填 8 个字段，他心里的成本是”我又少了半小时”。所以研发模板的字段必须证明自己”能省更多时间”，否则一定会被绕过。

第三，研发的模板使用者和管理者是分离的。设计模板的人通常是项目经理或质量负责人，使用模板的人是一线开发和产品。这种分离导致模板很容易变成”管理者想要的报表”而不是”执行者想要的工具”。

三、四个常见误区，几乎每个团队都踩过

1. 误区一：字段越多越规范

这是我见过最普遍、也最致命的误区。”规范”是个褒义词，所以很少有人质疑”多填几个字段有什么不好”。但字段数量对填充率的影响是非线性的，不是缓慢下降，而是断崖式下跌。

我们在三个团队里做了同样的统计口径：把需求模板的字段数分别设成 8、12、17、23，观察两周内的字段填充率。结果 8 个字段时填充率 96%，12 个字段时 88%，17 个字段时 71%，23 个字段时 54%。

关键拐点在 15 个字段附近。超过这个数量，填充率下降的速度明显快于字段数量的增长速度，意味着你多要的信息，大部分是拿不到的，而且连原本会填的字段也开始被放弃。

2. 误区二：模板只管创建，不管流转

很多团队把模板理解成”新建工作项时的默认值集合”，于是模板只覆盖了生命周期的第一分钟。但真正影响交付质量的节点在流转：需求从待评审到已评审、从已评审到开发中、从开发中到待测试。

我们在复盘时发现，23 个字段里有 9 个字段是在创建时填的，但其中只有 2 个在流转时被系统校验过。剩下的 7 个填不填都没人管，自然就没人填。

正确的做法是把关键字段绑定到状态流转上。比如”影响模块”这个字段，在需求进入”开发中”状态时必须填写，因为不填开发就没法拆任务；”验收标准”在进入”待测试”状态时必须填写，因为不填测试没法写用例。

模板的效力不来自字段本身，而来自字段与状态流转的绑定关系。没有绑定，模板就是建议；有了绑定，模板才是流程。

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

很多团队只有一个”需求模板”，但实际业务里至少有三种完全不同的需求：面向用户的功能需求、面向系统内部的技术需求、面向合规的安全需求。这三种需求的字段诉求差异很大，硬塞进一个模板，结果就是每个人都在填自己不需要的字段。

我们在治理时把需求拆成了三类模板，每类只保留 6-9 个字段，总字段数从 23 降到 19，但每类模板的字段填充率都超过了 85%。这是一个典型的”总字段数没怎么降，但体验大幅改善”的案例。

4. 误区四：模板改了就改了，没有版本和度量

模板是需要迭代的，但很多团队的模板变更没有任何记录。一个字段被删掉，没人知道是为什么删的；一个校验规则被加上，没人知道是谁加的。

这种状态下，模板会陷入两种极端：要么长期不动，逐渐脱离业务；要么频繁改动，团队刚适应又变了。没有版本记录的模板，等于没有模板的所有权。

我们后来统计了模板失效的原因分布，结果很有意思：无门禁占比最高，达到 34%，其次是字段冗余 28%，剩下的是无版本管理、无度量、其他。这说明团队感知到的”模板不好用”，其实大部分是”模板不管用”。

四、专业判断逻辑：什么该做成模板，什么不该

1. 三维评估：复用频次 × 决策复杂度 × 出错代价

不是所有工作项都值得做成模板。我通常用三个维度快速判断，每个维度打 1-5 分。

• 复用频次：这类工作项每周产生多少次。低于每周 3 次的，模板化的收益很有限。
• 决策复杂度：新建这个工作项时，需要做多少个”不能拍脑袋”的判断。判断越多，模板越有价值。
• 出错代价：漏填某个关键信息会造成多大的返工或事故。代价越高，越需要门禁。

这三个维度不是简单相加，而是有优先级的。出错代价决定”要不要加门禁”，决策复杂度决定”要不要做模板”，复用频次决定”这个模板值不值得投入维护成本”。

这张表我在四个团队里都用过，反馈最一致的一点是：大家原本以为”重要的事情就该做模板”，实际上低复用频次的重要事情应该做检查清单或独立流程，而不是模板。模板的价值建立在”重复”上，一次性的事情不需要模板。

2. 三类模板要分开治理

这是我在多个平台之间迁移时最重要的一个认知：项目模板、工作项模板、流程模板（工作流模板）是三件完全不同的事，混在一起治理必出问题。

把这三类分开之后，最直接的好处是变更频率和变更权限可以分别设定。项目模板一季度动一次，工作项模板每月动一次，两类变更走不同的评审流程，就不会出现”因为改了一个字段导致所有项目结构变动”的事故。

3. 我用的评分表和阈值

把三个维度做成可操作的评分，我一般这样落地：每一项 1-5 分，加权后总分 12 分以上做模板 + 门禁，8-12 分做模板但不做强制门禁，8 分以下做检查清单或不做。

权重的设定是：出错代价 0.4，决策复杂度 0.35，复用频次 0.25。之所以把复用频次权重压到最低，是因为模板的维护成本虽然和频次相关，但模板的价值主要体现在防止犯错，而不是节省时间。

4. 模板不是越多越好：一个反直觉的阈值

我跟踪过的团队里，模板数量和使用体验之间有一个明显的关系：当团队的工作项模板超过 15 个时，模板选择本身的成本开始超过模板带来的收益。

原因很简单：新建工作项时，如果弹出 20 个模板让用户选，用户需要先读完 20 个名字才能做决定，这个决策耗时在 10-30 秒之间，而套用模板省下的填写时间可能只有 1 分钟。当选择成本占到节省时间的 30% 以上，用户就会开始”随便选一个”或者”绕过去”。

那个 130 人团队最后把 47 个模板压缩到 13 个，其中一个重要原则就是：同一个工作项类型下，模板数量不超过 4 个。

五、具体案例与数据观察：一次从外部工具迁移后的模板治理复盘

1. 背景：从 Jira 迁移出来的 87 个模板

2024 年我参与了一个 300 人规模的研发组织的工具迁移，他们从 Jira 迁到 PingCode。PingCode 支持私有化部署，也支持 Jira 平滑迁移，所以迁移动作本身比想象中顺利，问题全部出在迁移之后。

迁移完成后，工作项模板数量是 87 个。这个数字不是迁移工具生成的，而是过去五年里各个团队陆续建的，迁移时”原样带过来”。87 个模板里有 41 个在过去 90 天内使用次数为 0。

这个现象我在多个迁移项目里都见过：迁移最大的风险不是数据丢失，而是把历史的治理债一起搬过来。迁移是一个天然的治理窗口，一旦错过，这些债就会在新平台上继续发酵。

2. 治理动作与操作细节

我们的治理用了三周，动作不多，但顺序很重要。

1. 第一周：只做统计，不做决策。拉出 87 个模板的 90 天使用次数、平均字段数、字段填充率。这一步不做任何判断，避免先入为主。
2. 第二周：做”字段引用率”抽样。每个模板抽 20 条工作项，人工标注哪些字段被下游角色真实引用过。这一步最耗人力，但结论最有说服力。
3. 第三周：合并与退役。把 87 个模板按”业务对象 + 使用团队”两个维度做矩阵，重叠的合并，零使用的退役，最终保留 19 个。

这里有一个操作细节值得单独说：退役模板不要直接删除，要先设为”不可新建但历史可用”。直接删除会导致历史工作项丢失字段定义，报表和历史数据会失真。我们在 PingCode 里保留了退役模板的历史可用状态，三个月后才真正归档。

另一个细节是模板命名规范。原来 87 个模板的名字里有”标准需求模板””需求模板 V2″”需求模板（新）””产品需求-通用”这类高度相似的命名。我们统一成”业务对象-场景-版本”的格式，比如”需求-功能类-v3″，选择成本立刻下降。

3. 数据结果（示意数据，样本推演）

下面这组数据来自三个团队的迁移复盘口径统一后的推演，用于说明量级差异，不作为行业基准。

治理完成后 90 天的观察期里，模板数量从 87 降到 19，平均字段数从 21 降到 11，字段填充率从 61% 提升到 89%，需求从创建到进入开发的平均等待时间从 11.4 小时降到 7.8 小时，需求评审一次通过率从 51% 提升到 72%。

我还把等待时间的下降做了贡献分解，因为”总共降了 3.6 小时”这个数字本身没有指导意义，团队需要知道哪一步贡献最大，才知道下一步该继续做什么。

4. 我踩过的两个坑

第一个坑：过早地把模板和考核挂钩。我们在治理初期很兴奋，把”模板填充率”放进了团队的月度指标。结果是填充率上去了，但字段内容质量下降，出现了大量”占位符式填写”，比如”影响模块”填”暂无”。后来我们把指标从”填充率”改成”填充率 + 下游引用率”，才纠正过来。

第二个坑：把模板审批流程做得太重。我们一开始规定所有模板变更都要走变更评审会，结果一个月只改了 2 个模板，团队嫌麻烦就不提变更需求了，改为私下建新模板。后来改成”字段变更走轻量审批，流程变更走正式审批”，才恢复正常节奏。

六、操作步骤：把模板做成流程的 7 步

下面这七步是我在不同团队反复用过的顺序，顺序很重要，跳过前面的步骤直接做后面的，几乎一定会返工。

1. 第一步：模板资产盘点与使用率埋点

先统计三件事：当前有多少个模板、每个模板过去 90 天的使用次数、每个模板的平均字段数。

这一步的目标不是优化，而是建立基线。没有基线的治理，最后无法证明有没有效果。使用次数为 0 的模板单独标记出来，后面优先处理。

2. 第二步：定义最小必需字段集

对每个工作项类型，回答一个问题：下游角色在做决策时，最少需要哪些信息？

具体操作方式是做”引用率抽样”：每个模板抽 20 条工作项，找 2-3 个下游角色（开发、测试、项目经理），让他们标出哪些字段在最近一个月真实影响过自己的动作。只有被引用过的字段才是必需字段。

这一步的判断标准是“没有这个字段，下游会不会停下来问”。如果不会停下来问，这个字段就不是必需字段。

3. 第三步：把决策规则翻译成校验规则

这一步是把模板从”建议”变成”流程”的关键。原则是：每一个必需字段，都要绑定一个明确的触发条件。

绑定方式通常有三种：创建时必填、进入某状态时必填、满足某条件时必填。三种方式的填写成本递增，所以要按字段的重要性分配。下面是一段模板校验规则的示例配置，用 YAML 表达，实际平台里通常是可视化配置，但理解结构有助于判断配置是否合理。

template:
key: REQ-FEATURE

name: 需求-功能类-v3

fields:

key: acceptance_criteria

label: 验收标准

required_when: status in [待测试, 已测试]

min_length: 30

key: impact_modules

label: 影响模块

required_when: status == 开发中

type: multi_select

max_items: 5

key: rollback_plan

label: 回滚方案

required_when: tags contains 线上变更

min_length: 50

transition_guard:

from: 待评审

to: 已评审

require: acceptance_criteria

on_fail: block

from: 开发中

to: 待测试

require: impact_modules

on_fail: warn

这段配置里有两个细节值得注意。第一个是 on_fail 分了 block 和 warn 两种：影响模块缺失只是警告，验收标准缺失直接阻断。这个分级是按”出错代价”来的，不是按”管理者重视程度”来的。第二个是 required_when 用了状态和标签双条件，而不是一刀切必填，目的是让不涉及线上变更的需求不用填回滚方案。

4. 第四步：设计触发时机与套用路径

模板什么时候被套用，比模板长什么样更影响使用率。我推荐三种触发路径按顺序启用：

• 默认触发：新建某类工作项时自动带上默认模板，用户无需选择。适用于只有一个模板的场景。
• 条件触发：根据项目类型、工作项类型、创建入口自动匹配模板。适用于多模板场景，能大幅降低选择成本。
• 手动切换：允许用户主动更换模板，但更换后要做字段映射，避免数据丢失。

优先做默认触发和条件触发，手动切换只作为兜底。因为手动切换本质上是把选择成本转嫁给用户，而选择成本正是模板使用率下降的主要原因之一。

5. 第五步：建立版本与变更日志

模板一定要有版本号，且版本号的规则要简单：主版本表示字段增删或流程变更，次版本表示标签、默认值、文案调整。

变更日志至少记录四项：改了什么、为什么改、谁改的、什么时候生效。这四项看起来像形式主义，但在真实复盘里极其有用。我们在排查一次”某团队需求流转异常”时，就是靠变更日志发现两天前刚改过一条流转校验规则。

另外要考虑存量工作项在模板变更后的表现。我的做法是：存量工作项不追溯校验，只对新创建的工作项生效。否则一次规则调整会让几百条在途工作项同时卡住，团队会立刻反弹。

6. 第六步：模板效果度量看板

度量看板不需要复杂，我通常只放五个指标：模板使用率、字段填充率、下游引用率、模板相关返工率、状态停留时长中位数。

其中下游引用率是我最看重的一个。它的口径是：模板字段被下游角色在评论、任务拆分、测试用例中真实引用的比例。这个指标能直接识别出”填了但没人看”的僵尸字段。

最后一个指标模板相关返工率，口径是：因模板字段缺失或错误导致的返工工单数除以总工单数。这个指标能把模板的质量问题量化到工单层面，说服力最强。

7. 第七步：灰度、退役与 Owner 制

模板上线不要全量推，先在一个小组灰度两周。灰度期间重点看两个信号：字段填充率是否低于 80%，以及是否出现大量”绕过模板”的行为。

退役机制同样重要。我建议设定一个自动退役规则：连续 90 天使用次数低于 3 次的模板，自动进入待退役清单，由 Owner 决定合并、改造还是归档。没有退役机制的模板库，只会在三年后变成垃圾场。

Owner 制是最后一块拼图。每类模板必须有一个人负责，这个人的职责不是审批变更，而是每季度回顾一次度量数据。没有 Owner 的模板，会在半年内自然腐烂。

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

1. 20 人以下团队

小团队不要追求模板体系的完备性，追求的是”少而准”。我的建议是只做一个需求模板和一个缺陷模板，字段控制在 8 个以内，只在创建时必填，不做流转校验。

原因是小团队的沟通成本低，很多信息靠口头同步就够了，加流转校验反而增加摩擦。这个阶段模板的作用是”防止新人漏关键信息”，不是”建立流程管控”。

2. 50-150 人团队

这个规模是模板收益最高的区间，也是问题最多的区间。跨组协作开始变多，口头同步失效，但流程管控还没建立起权威。

建议动作是三步：先按业务对象拆分模板（需求拆成 2-3 类），再给每类模板加 2-3 条流转校验，最后建一个只有 5 个指标的看板。这个规模的团队，模板使用率低于 70% 就说明有问题，不要用”大家还在适应”来解释。

3. 200 人以上或多产品线

这个规模必须把三类模板分开治理，且必须有独立的流程 Owner。跨产品线的模板不要强求统一，允许各产品线在核心字段（如验收标准、影响范围）上统一，其余字段各自定义。

我在这个规模上见过最常见的问题是”模板审批链太长”，一个字段变更要走三个会议。解决方案是把模板变更按影响面分级：只影响本产品线的变更由产品线 Owner 决定，影响跨产品线的变更才上升。

4. 正在做国产替代或私有化部署的团队

如果你正在从外部工具迁移到支持私有化部署的国产平台，比如 PingCode 这类面向中大型企业的项目管理平台，我的建议是把”模板治理”直接写进迁移项目计划里，而不是等迁移完成后单独做。

具体做法是：迁移前先统计源平台模板的使用次数，零使用的模板不迁移；迁移中只迁字段定义和流转规则，不迁通知规则和历史自动化；迁移后立刻做一次字段引用率抽样，用数据决定哪些字段该保留。

这个顺序的好处是迁移本身就是一次低成本的重构机会。团队对”变了”的容忍度在迁移期间最高，过了这个窗口再动模板，阻力会大得多。

八、不同情况下的取舍

1. 规范性与填写成本的取舍

这是一个永远无法两全的取舍。我的判断标准是：如果某个字段的缺失会导致下游停下来提问，那就必须加；如果只是让报表更好看，那就砍掉。

换句话说，规范性的边界应该由”协作中断成本”决定，而不是由”管理者的信息需求”决定。这条线一旦划错，模板就会从工具变成负担。

2. 统一性与团队自治的取舍

统一性带来的好处是跨团队对比和报表汇总，代价是团队觉得”不符合我们的实际情况”。我的取舍建议是核心字段统一，扩展字段自治。

具体来说，验收标准、影响范围、优先级这三类字段必须全组织统一，因为它们是跨团队协作的公共语言。而像”技术方案文档链接”这种字段，各团队可以自己决定要不要加。

3. 私有化部署与 SaaS 的取舍

如果团队涉及数据合规要求、需要和内网系统深度集成，私有化部署几乎是必然选择。PingCode 支持私有化部署，这类平台在模板治理上的优势是可以把模板校验规则和内部系统（比如代码仓库、CI 流水线）打通，做到”字段不填则流水线不触发”。

代价是升级和维护成本更高，模板规则的迭代速度会比 SaaS 慢。所以在私有化环境下，模板设计要更保守，宁可少加规则，也不要在上线后频繁变更，因为每次变更都可能涉及一次部署。

4. 自研模板引擎与用平台原生能力的取舍

有些技术团队会觉得”平台的模板功能不够灵活，我们自己写一个”。我的经验是：除非模板规则需要和内部系统做非常复杂的联动，否则不要自研。

自研模板引擎的隐性成本极高，包括维护成本、权限体系、审计日志、和平台其他功能的兼容。真正需要自研的场景其实很窄，通常是”模板字段要驱动内网的权限申请流程”这类强集成需求。

九、下一步怎么做

1. 本周可以做的三件事

1. 统计现有模板的 90 天使用次数。零使用的单独列出来，先不要删，但心里要有数。
2. 找 3 个下游角色做一次引用率抽样。每个人标出最近一个月真实影响过自己动作的字段，这一步大概花 2 小时。
3. 把所有模板的字段数数一遍。超过 15 个字段的模板，先标记为待精简对象。

2. 一个月内可以验证的两个指标

第一个是字段填充率。如果你做完了精简和条件必填，一个月内应该能看到填充率提升 15 个百分点以上。如果没有提升，说明精简得不够或者门禁没生效。

第二个是需求创建到进入开发的平均等待时间。这个指标比填充率更贴近业务价值。如果填充率提升了但等待时间没变，说明模板改善的不是瓶颈环节。

3. 什么情况下应该放弃模板路线

最后说一个反直觉的建议：如果某类工作项的复用频次低于每月 3 次，或者每次新建时都需要大量定制化判断，那就不要做模板，做检查清单。

模板的本质是”把重复的决策固化下来”，一旦重复性不成立，模板就会变成形式主义。我在复盘里见过最健康的一个做法，是那个 130 人团队最后保留了 13 个模板和 5 份检查清单，他们明确区分了”需要固化结构的”和”只需要提醒不要漏的”。

回到最开始那个问题：项目模板如何做好模板流程？我的答案是，先别急着设计模板，先去数一数模板被用了多少次、字段被填了多少、下游真正引用了哪些。数据会告诉你答案，而且往往和你原本的判断不一样，那个 130 人团队一开始想删掉需求模板，最后发现模板本身没错，错的是 23 个字段里有 17 个从来没人看。