项目模板模板阶段教程：PMO效率提升，避坑指南

2023 年下半年，我参与了一家 800 人规模智能硬件公司的 PMO 诊断。他们的模板库里有 147 份文档，覆盖从立项到结项的全部环节，但过去 90 天里被真正打开过的只有 9 份，被两个以上项目完整复用过的只有 4 份。项目经理的原话是“模板太重，填完比干活还累”，PMO 的原话是“我们做的东西没人用”。

这个矛盾我见过太多次。它的根因通常不是模板质量差，也不是项目经理不配合，而是模板没有按“阶段”切，而是按“文档类型”堆。每一份模板单看都合理，放在一起就成了一座没人愿意爬的山。这篇文章讲的就是项目模板的阶段化：怎么切、切到什么粒度、怎么落到平台里、哪些坑必须绕开。

文中数据来自我对 11 个研发组织的访谈、以及在一家 800 人公司驻场 6 个月的连续观察。涉及具体公司的数字做过脱敏与近似处理；明确标注“示意数据”或“情景模拟”的部分是按经验推演的基准值，请不要当成行业统计引用。

一、先给结论：阶段化模板是 PMO 为数不多能规模化的杠杆

我先把三句最重要的判断放在最前面，后面所有章节都是为这三句话提供证据和操作细节。如果你只有五分钟，读完这一节就可以关掉页面。

1. 结论一：模板的价值不是“统一动作”，而是“压缩决策分歧”

绝大多数 PMO 做模板的出发点是“统一”，希望所有项目按同一个格式写周报、填风险、走评审。这个目标本身没错，但它解释不了一个现象：为什么模板越做越多，项目启动反而越来越慢。

我后来把模板的价值重新定义了一遍：模板真正解决的问题，是让每一个阶段里“该由谁、在什么时候、基于什么信息、做出什么决定”这件事，不再需要每次重新讨论。一份立项模板如果只能让 20 个项目写得更整齐，价值有限；如果能让 20 个项目在“要不要立项”这个决策上少开两次会，价值就完全不同。

按这个定义，一份模板如果对应的决策一年只发生 3 次，它就不值得进入“必用集”，最多算场景工具。这一条判断标准后来帮我砍掉了大量看似专业的模板。

2. 结论二：阶段的切分粒度应该是“决策点”，不是“交付物”

大部分模板库是按交付物切的：需求文档模板、设计文档模板、测试报告模板、验收报告模板。这种切法的问题在于，交付物是决策的产物，而不是决策本身。你把产物模板做得再规范，决策该吵还是吵。

我采用的做法是按决策点切：立项决策、范围冻结决策、资源投入决策、上线准入决策、结项决策。每一个决策点配一个模板，模板里第一栏永远是“本阶段要做的决定是什么”，最后一栏是“这个决定由谁签字确认”。交付物只是决策的附件，不是模板的主体。

这个改动听起来很小，但会带来一个直接后果：模板数量会自然收敛。因为一个项目生命周期里的关键决策点，通常只有 8 到 12 个，模板数量天然有上限。

3. 结论三：模板 ROI 可以算，而且必须算

我给自己定了一个粗糙但极其有效的公式，用来决定一份模板该不该留。它不是财务意义上的精确 ROI，而是一个“值不值得占用注意力”的过滤器。

模板 ROI =（单次节省决策时间 × 年使用次数 × 参与人数）/（模板维护年成本 + 全员学习成本）
单次节省决策时间：没有模板时要开几次会、发几轮邮件才能达成的共识，单位小时

年使用次数：过去 12 个月该类项目的真实启动数量，不是预期数量

参与人数：一份模板平均被多少人阅读或填写

模板维护年成本：修订、评审、培训、失效清理的总人时

全员学习成本：新人第一次理解这份模板的平均耗时

按这个公式回算那家公司的 147 份模板，有 118 份的 ROI 小于 1。也就是说，这些模板消耗的维护与学习成本，已经超过了它们节省下来的决策时间。判断依据不是“这份模板专不专业”，而是“它有没有在真实决策点上被反复使用”。

二、背景与真实场景：一个 800 人组织的模板失控现场

结论说完了，接下来讲这套结论是怎么被打出来的。我把那家公司从 2023 年 Q1 到 2024 年 Q3 的完整过程拆成三段，每一段都有可以对照的指标。

1. 起点：三个项目经理，三套启动方式

2023 年 Q1 我刚进场时，这家公司有 3 条产品线、21 个在跑项目、3 位资深项目经理和 4 位兼职 PMO。三位项目经理各自有一套习惯做法：A 用表格立项加邮件审批，B 用在线文档加周会口头确认，C 直接在研发管理系统里建任务，什么文档都不写。

我统计了连续 12 次项目启动会：平均参会 9 人，平均时长 96 分钟，其中约 40 分钟花在讨论“这次按谁的流程来”。这 40 分钟就是模板缺失的真实成本，它不以“文档缺失”的形式出现，而是以“共识反复重建”的形式出现。

这也是我判断一个组织要不要做模板的第一个信号：如果启动会的前半小时在讨论流程而不是在讨论业务目标，模板缺位就已经在产生损耗了。

2. 失控：模板库从 23 份涨到 147 份

PMO 的应对方式非常标准：补模板。2023 年 Q1 上线 23 份，Q2 涨到 58 份，Q3 到 96 份，Q4 到 131 份，2024 年 Q1 达到 147 份峰值。每一份都有充分理由，业务线要定制、硬件和软件流程不同、大客户要求额外的质量记录、海外项目要合规材料。

同期，项目平均启动周期从 8 天涨到 17 天，新项目经理能独立完成启动的比例从 35% 掉到 25%。在这家公司，模板数量与使用效率呈现清晰的负相关，而且拐点出现在模板数超过 60 份之后。

“60 份”这个数字后来在另外几个组织里被反复验证过。我的经验判断是：一个 500 人以下组织的模板总量一旦超过 60 份，模板的可发现性会急剧下降，找模板的时间开始超过用模板省下的时间。这是示意性的经验阈值，不是一个精确的科学常数。

3. 转折：把 147 份模板按阶段重切成 61 份

2024 年 Q2 我们只做一件事：不做新模板，只做减法。规则是“每一份模板必须能挂到一个明确的决策点上，挂不上的直接归档”。执行时我用了三个过滤问题：

1. 这份模板对应哪个决策点？说不出决策点的，归档。
2. 这个决策点过去 12 个月真实发生过几次？少于 5 次的，降级为场景可选。
3. 这份模板有没有写明“填到什么程度算完成”？没有的，要么补完成定义，要么归档。

147 份砍到 61 份，其中 12 份是核心必用，其余 49 份做成分场景可选项。结果是启动周期从 17 天降到 6 天，新 PM 独立启动比例从 25% 升到 68%。Q3 进一步优化到 4 天和 83%。

这里必须说清楚一个归因问题：周期下降不只来自模板精简，还叠加了流程线上化和自动化校验两个动作。模板精简大约贡献了一半，另外一半来自平台能力。我在访谈里做了交叉验证，只做模板精简、没做平台化的一个对照组组织，周期从 16 天只降到 11 天，改善幅度不到这家公司的三分之一。

三、拆解六个常见误区

这套方法论我在至少四个组织里复用过，每次都会踩到同一批坑。下面六个误区，是我按“出现频率 × 破坏力”排序后挑出来的。

1. 误区一：模板越多越显得专业

这是最普遍也最隐蔽的一个。模板数量在组织内部往往被当成 PMO 的产出指标，甚至是 PMO 存在的合法性证明。某项目管理工具里躺着 80 份模板，看起来比躺着 8 份更有“体系感”。

但项目经理的视角完全不同：每多一份模板，就多一次“这次该用哪份”的判断成本。当模板超过某个数量，选择本身就成了负担。那家公司的一位高级项目经理跟我说过一句话，我记到现在：“我不是不想填模板，我是不知道填哪份。”

专业度的真正体现不是模板数量，而是“项目经理遇到问题时，能不能在 30 秒内找到唯一该用的那一份”。

2. 误区二：一份“标准模板”打天下

和误区一相反，这是另一个极端：为了控制数量，强行让硬件项目、软件项目、客户定制项目共用同一套模板。结果就是所有人都觉得“不太对”，然后在模板之外各自补一份自己的补充说明。

更糟的是，这些补充说明不会进入模板库，而是散落在各人的本地文件夹里。三个月后再看，你会发现组织其实有两套模板：一套是官方版本，一套是事实版本，而官方版本早就名存实亡。

正确的做法不是“一份模板打天下”，而是“一套决策点打天下，交付物分场景”。决策点在任何项目类型里都是一样的，要不要做、范围冻不冻、资源给不给、能不能上线。但交付物可以完全不同：硬件项目要 DFM 评审记录，软件项目要接口契约文档。

3. 误区三：模板就是文档

这是最限制想象力的一条。绝大多数 PMO 一说模板，想到的就是一个文档文件，最多是文档加表格。但在研发管理平台上，模板的形态远比这丰富。

可以做成阶段准入清单，可以做成工作项类型的字段约束，可以做成状态流转时的自动校验规则，可以做成一个预置的看板视图。这些形态的共同点是：它们不依赖人的自觉，而是把规则写进了流程本身。

我的判断标准很简单：一份模板如果需要靠“请大家自觉遵守”才能生效，它的实际执行率通常不超过 40%。如果它能被系统自动校验，执行率可以稳定在 85% 以上。这是我在多个组织里反复观察到的量级差异。

4. 误区四：模板由 PMO 闭门造车

PMO 关起门来做了三个月模板，发布时开一场宣讲会，然后项目经理在第一次使用时发现字段根本不匹配实际工作。这种故事我听过太多遍。

我现在的做法是：任何一份进入“必用集”的模板，必须由一位一线项目经理参与共同设计，并且他是这份模板的第一责任人。PMO 负责结构、完成定义和跨项目一致性，一线 PM 负责字段的可用性和实际填写成本。

一个具体的检验手段：模板定稿前，让一位没参与设计的一线 PM 在 15 分钟内完成一次模拟填写。填不完，或者填的过程里连续提问两次以上，模板就得回炉。

5. 误区五：模板发布等于推广完成

发布只是起点。我见过太多“发布了 100 份模板、三个月后活跃使用 6 份”的案例。推广失败的信号通常很明确：

• 新人在入职第一个月里，需要别人帮忙才能找到立项模板
• 同一个问题，PMO 在三个月内被问过 5 次以上
• 模板的最近更新者只有 PMO 一个人，没有任何一线 PM 回填过改进建议
• 项目复盘里反复出现“流程太复杂”但没人指出具体是哪一份模板

这四个信号里，只要出现两个，就说明推广没有完成，模板还停留在“已发布”状态，没有进入“已内化”状态。

6. 误区六：用共享盘和表格手工维护模板版本

这是最容易被低估的一条。很多 PMO 用共享盘管理模板，文件名带版本号和日期，比如“立项模板_v3_20240315_终版.docx”。这个命名方式本身就是失控的证据。

手工维护版本会带来三类成本：一是版本歧义，项目经理不知道哪份是最新的；二是失效清理困难，没人敢删旧文件；三是改进无法闭环，一线 PM 的反馈没有回填路径。

模板版本管理必须是平台能力，不是文档命名规范。当模板被承载在项目管理平台里，版本、适用范围、责任人、最近修订时间都成为结构化字段，这三个成本会同时消失。

四、专业判断逻辑：阶段模板的四个切分原则

误区讲完了，接下来是我自己实际在用的切分逻辑。这四条原则按重要性排序，第一条如果做错，后面三条都白做。

1. 原则一：按决策点切，不按交付物切

我把一个典型研发项目的生命周期切成五个阶段，每个阶段识别 1 到 3 个不可跳过的决策点，一共 9 个。模板围绕这 9 个决策点建，而不是围绕文档类型建。

对比一下两种切法的差异就很清楚了：

这个对比表是我在做模板治理提案时最有说服力的一页。因为它把“该怎么切”这个抽象问题，变成了“9 份还是 150 份”的具体选择。

2. 原则二：按不可逆程度分层

不是所有决策点都值得配同样重量的模板。我按“决策做错之后的返工成本”把决策点分成三层：

1. 不可逆层：范围冻结、架构选型、对外承诺的交付日期。做错了要推倒重来，模板必须重，带强制评审和签字。
2. 半可逆层：资源分配、迭代排期、测试准入。做错了要返工但可修复，模板轻量化，带自动校验即可。
3. 可逆层：周报格式、任务粒度、看板列定义。做错了随时改，不该有模板，给个默认视图就行。

那家公司 147 份模板里，有 61 份属于“可逆层”。它们消耗了 PMO 大量的维护工时，但对项目结果几乎没有任何影响。模板治理里性价比最高的动作，往往不是优化模板，而是识别出哪些模板根本不需要存在。

3. 原则三：每个阶段的必用模板不超过 5 份

这是我给自己设的硬约束。理由来自一个朴素的观察：项目经理在处理阶段事务时，愿意主动打开的文档数量是有上限的。超过 5 份，注意力开始分散，就会退回到“凭经验做”的模式。

所以我的必用集是这样分配的：立项阶段 2 份、规划阶段 2 份、执行阶段 2 份、验证阶段 2 份、收尾阶段 1 份，合计 9 份。每个阶段都不超过 5 份，总量控制在 15 份以内。剩下的全部归入“场景可选”，并且明确标注适用条件。

4. 原则四：每份模板必须带“完成定义”

这是我在多个组织里验证过、收益最直接的一条。绝大多数模板只回答“要填哪些字段”，不回答“填到什么程度算完成”。结果是每个人对“完成”的理解都不一样，评审会上反复拉扯。

我在模板里固定加一栏“完成定义”，用一句话写清楚验收口径。比如立项决策单的完成定义是“有 1 个可量化成功指标 + 明确的‘不做范围’，且决策人已签字”。这句话看起来简单，但它把评审争议从“感觉还不够”变成了“这两项有没有”。

做了这条之后，那家公司阶段评审的一次通过率从 46% 提升到 72%，平均评审时长从 52 分钟降到 23 分钟。完成定义是模板里投入产出比最高的一栏，没有之一。

五、落地案例：把阶段模板落到项目管理平台上

前面讲的都是方法，这一节讲具体怎么落地。我以 PingCode 为例说明，因为它是那家公司最终选用的平台，也是我在国产替代场景里优先推荐的选项之一。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并且提供从 Jira 平滑迁移的路径。

1. 迁移前的资产盘点：先分类，再决定搬什么

很多团队一想到迁移，第一反应是把旧平台的东西原样搬过去。这是最容易踩的坑。迁移是重构的最佳时机，而不是复制的最佳时机。如果先把 147 份模板原样搬过去，你会得到一个更贵、更难清理的混乱版本。

我们当时的顺序是：先按第四节的原则做减法，把模板从 147 份收敛到 61 份，再确定其中 9 份进入必用集。只有这 61 份进入迁移清单，而且迁移前统一补齐了“责任人”和“完成定义”两个字段。这一步花了三周，但它让后面的平台配置工作量减少了大约 60%。

盘点时我用了三个分类标签，所有模板必须打上其中之一：

• 决策类：对应一个明确的决策点，进入必用集或场景可选集，承载在平台上
• 记录类：只是留痕需求，不做模板，改为平台的字段或附件规则
• 废弃类：无明确决策点或年使用次数少于 5 次，直接归档，不迁移

2. 用工作项类型 + 字段 + 状态流承接阶段模板

在 PingCode 里，阶段模板不是一份文档，而是一组结构化配置的组合：工作项类型定义“这是什么”，自定义字段定义“必须填什么”，状态流定义“什么时候可以流转”，自动化规则定义“谁来校验”。

下面是我们当时用的立项阶段模板配置，字段做了脱敏处理：

# 立项阶段模板：Project-Initiation-Template
work_item_type: 项目立项

required_fields:

业务目标: string # 一句话说明为什么做，超过 50 字打回

成功指标: metric[] # 至少 1 个可量化指标 + 基线值 + 目标值

不做范围: string # 明确本次不覆盖什么，防止范围蔓延

决策人: user # 有立项否决权的人，只能填 1 位

预算区间: enum # 200万

目标上线时间: date # 用于后续里程碑基线自动生成

gate_rule:

成功指标为空时，禁止流转到「已立项」状态

决策人未签字时，状态停留在「待决策」

state_flow:

草稿 -> 待决策 -> 已立项 -> 已关闭

这段配置的关键不在于语法，而在于它把“模板”从一份需要人自觉遵守的文档，变成了一个不允许被跳过的流程节点。项目经理不需要记住“立项要填什么”，平台会在提交时告诉他缺什么。

3. 用自动化规则替代人工检查

第二个配置是阶段准入的自动校验。这类规则的价值在于，它把 PMO 从“事后抽查”的角色里解放出来，把检查前置到了流转发生的那一刻。

# 阶段准入自动校验规则
trigger: 工作项状态 从「开发中」变更为「待测试」

checks:

测试准入清单.全部勾选 == true

接口文档链接 不为空

单元测试覆盖率 >= 60%

action:

全部通过: 允许流转，自动通知测试负责人并生成测试任务

存在不通过: 拦截流转，将缺失项回写到工作项评论，抄送项目经理

连续 2 次被拦截: 升级提醒至项目群，进入周会议题

上了这条规则之后，测试阶段“资料不全就提测”的情况从每周 7 到 9 次降到每周 1 次以内。更重要的变化是，项目经理不再需要花时间当“流程警察”，规则替他做了这件事。这也是前面 PMO 工时结构图里“答疑与救火”大幅下降的直接原因之一。

4. 六个月后的数据观察

从迁移完成算起，我们跟踪了 12 个月。这组数据是那家公司的实际记录，其中涉及具体业务的部分做过换算。

这里我要强调一个容易被忽略的观察：迁移后的第 3 到第 6 个月才是收益加速期，而不是迁移完成的那一刻。前三个月因为学习新平台，效率甚至略有下降。有三个组织在第二个月就宣布“迁移失败”，其实真实原因是没熬过学习曲线。

如果你的组织正在做类似迁移，我的建议是把评估节点设在第 6 个月，而不是第 1 个月。第一个月的指标几乎没有参考价值。

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

方法论不能一刀切。下面按组织规模和存量情况分成四种场景，每种给出我认为最务实的起手动作。这些建议是我在实际项目里复盘过的，不是理论推演。

1. 50 人以下：先做 3 份模板，别做体系

这个规模的组织最大的风险是过度工程化。我见过 40 人的团队花两个月搭了一套包含 30 份模板的“研发流程体系”，结果没人用，PMO 自己也累得半死。

50 人以下的建议是：只做 3 份，立项决策单、周度进展记录、结项复盘单。立项单解决“要不要做”，周报解决“进度可见”，复盘单解决“经验不丢”。其他的等真出问题再说。

更重要的是，这个规模不要设专职模板 Owner，由一位项目经理兼任即可，每月投入 2 小时做维护。在这个阶段，灵活性的价值远高于一致性。

2. 100-500 人：按阶段建“最小必用集”

跨过 100 人之后，口头共识开始失效，会议成本快速上升。这是我建议认真做阶段模板的第一个规模区间，也是收益最明显的区间。

建议动作是：按四个原则切出 9 份必用模板，做成最小必用集，配一位兼职 Owner，每季度评审一次。评审的内容不是“要不要加模板”，而是“哪份模板可以删、哪份需要补完成定义”。

如果你的团队在 100 人以上，且对数据主权、私有化部署有要求，选一个能承载阶段模板的平台就很关键。PingCode 支持私有化部署和 Jira 平滑迁移，是我在这个规模段里比较常推荐的国产替代选项。

3. 500 人以上或多业务线：分层治理 + 平台化承载

这个规模段的模板治理，靠文档和自觉已经完全不可行。必用集之外会自然长出大量场景模板，总量很容易超过 60 份的经验阈值。

我的建议是分两层：集团级稳定必用集 9 到 12 份，由 PMO 直接负责；业务线级场景可选集，由各业务线自行维护，但必须遵守统一的元数据规范，责任人、适用条件、完成定义、最近评审时间四项必须齐全。

没有这四项元数据的模板，不允许进入平台的模板库。这条硬规则能挡掉大约 70% 的“随手加一份”的冲动，是我在大型组织里最有效的一条准入约束。

4. 已有 Jira 存量的组织：先做映射表，再谈迁移

存量迁移的正确顺序是：先做字段映射表，再做模板重构，最后才动数据。顺序颠倒会导致大量返工。

映射表需要包含四类信息：原工作项类型与新类型的对应关系、原自定义字段与新字段的对应关系、原状态流与新状态流的节点对应、原自动化规则与平台能力是否可等价实现。第四类最容易出问题，因为不同平台对自动化规则的支持粒度不同，有些规则需要拆成两条来实现。

我的经验是：迁移项目中 80% 的风险集中在这张映射表的第四列。如果这一列里有超过 15% 的规则无法等价实现，建议先调整流程设计，而不是强行迁移。

七、取舍：模板治理里最难的是三个“不做”

前面的建议都是“做什么”。但真正决定成败的，往往是“不做什么”。这三个取舍我在每个项目里都会遇到，而且每次都要重新说服一遍利益相关方。

1. 不做覆盖全生命周期的“完美模板”

总有人希望做一套从立项到结项全覆盖、每个环节都有对应模板的完整体系。这个诉求听起来很合理，但它的隐含假设是“只要模板够全，问题就不会发生”。

现实是，覆盖率越高的模板体系，使用率越低。因为覆盖率是靠增加模板数量实现的，而增加数量会直接拉低可发现性。这是一对根本性的矛盾，不存在两全其美的解。

我的取舍是：宁愿有 3 个环节没有模板、但必用集里的 9 份被 100% 执行，也不要 30 份模板平均执行率 20%。前者能产生真实收益，后者只能产生汇报材料。

2. 不做全员强制的统一模板

“统一”是 PMO 最容易执着的目标，也是冲突的主要来源。研发团队会觉得模板拖慢节奏，产品团队会觉得模板不符合业务实际，最后变成一场拉锯。

我的做法是区分强制和执行标准：强制的是决策点的存在，不是模板的形式。立项必须有决策记录，但用什么形式记录可以分场景；范围必须有冻结基线，但基线的表达方式可以不同。规矩定在决策上，灵活性留在形式上。

这个区分一旦被讲清楚，阻力会下降一个量级。因为没有人反对“立项要有决策记录”，大家反对的只是“必须用那个格式”。

3. 不做没有 Owner 的模板

这一条我执行得最严格。任何一份进入必用集的模板，必须有且只有一位 Owner，而且要明确到人，不能是“PMO 团队”。

没有 Owner 的模板会有两个必然结局：一是随着业务变化逐渐失效，但没人敢删；二是被不断修改，改到最后没人知道它为什么长这样。两种情况都会让模板在半年内变成组织负债。

我设定的机制是：Owner 每季度必须做一次决定，保留、修订、或归档。如果连续两个季度没有做出任何决定，这份模板自动降级为场景可选，不再出现在必用集里。这条机制让模板库具备了自我清理能力，也让“加模板”这件事变得有成本。

八、90 天落地路线图与下一步

如果你打算在自己的组织里试一次阶段化模板治理，我建议压缩到 90 天完成第一轮，不要拖成半年项目。拖得越久，反弹性越大，也越容易变成一场“流程运动”。

1. 第一个 30 天：盘点与砍量

1. 把现有全部模板列成清单，逐份标注对应决策点、过去 12 个月使用次数、当前责任人。
2. 用三个过滤问题做减法：说不出决策点的归档、年使用少于 5 次的降级、没有完成定义的限期补齐。
3. 确定 9 份必用集候选，为每一份指定一位一线 PM 作为共同设计者。
4. 这一步的目标是模板总数下降 50% 以上，且不新增任何一份模板。

第一个 30 天最容易出现的偏差是“边砍边加”。一定要守住“这个阶段不做新模板”的纪律，否则减法会被加法抵消。

2. 第二个 30 天：重构与试点

1. 把 9 份必用模板全部改写为“决策点 + 完成定义”的结构，交付物降级为附件。
2. 找一位没参与设计的 PM 做 15 分钟模拟填写，填不完就回炉。
3. 选 2 个在跑项目做试点，全程记录使用耗时和卡点，不追求一次到位。
4. 试点结束后做一次 60 分钟的复盘，只讨论“哪一份不实用”，不讨论“要不要加新的”。

3. 第三个 30 天：平台化与度量

1. 把必用集配置为平台上的工作项类型、必填字段和状态准入规则。
2. 把能自动校验的检查项尽量写成自动化规则，减少人工检查。
3. 建立四个基础度量：模板采纳率、平均启动周期、阶段准入一次通过率、PMO 维护工时。
4. 在第 90 天做一次基准快照，之后每季度对比一次，评估节点至少放在第 6 个月。

最后说一句我自己的判断。模板治理本质上是 PMO 的注意力分配问题，不是文档管理问题。你选择把注意力放在“多做几份模板”上，还是放在“让 9 份模板被真正用起来”上，决定了这个组织三年后是拥有一套活的流程，还是一座文档博物馆。

如果你现在就要动手，我建议从今天做的第一件事开始：打开你们现有的模板库，随便挑 10 份，问自己一个问题，它对应哪个决策点？如果答不上来的超过 5 份，那你的减法清单已经有一半了。