项目模板最佳实践：产品经理项目模板流程优化，常见问题

2021 年我接手一个 40 人的产品研发团队，新项目启动会开到第三天，我才意识到真正的瓶颈不是人，是模板。同一个「需求变更申请」，三条业务线填出了三种完全不同的东西：一条写清了影响范围却没写回滚方案，一条把优先级标成「紧急」却没写判断依据，还有一条把变更原因写成「客户要求」。会后我拉了一次统计：团队共享目录里躺着 87 个模板文件，产品经理平均每个项目要花 3.5 小时在「找模板、改模板、解释模板」上，而过去半年的需求返工里，有 31% 能直接追溯到模板字段定义不一致。

这件事彻底改变了我对「项目模板」的看法。它从来不是一个文档管理问题，而是一个流程设计问题，模板是流程的压缩包，压缩得不对，解压出来就是一团乱麻。这篇文章把我在 6 年里做过的 4 次模板治理、踩过的坑，以及在中大型组织里观察到的数据，整理成一套可执行的判断逻辑，重点回答三件事：模板优化的方向到底是什么，产品经理在模板流程里最容易犯哪些错，不同规模的团队该怎么取舍。

一、核心结论：模板不是文档资产，是流程的压缩包

如果你只想从这篇文章里拿走一句话，那就是：模板的价值等于被复用的决策次数，而不是被复用的文档数量。一个模板存在的意义，是让下游的人不用再问「这个字段是什么意思」，让产品经理不用再重复解释一遍判断标准，让跨团队协作时口径自动对齐。

基于这个定义，我把模板优化的核心结论收敛成四条，后面所有章节都是这四条的展开。

1. 结论一：模板的价值来自「被复用的判断次数」，不是「被复用的文档数量」

大部分团队的模板治理动作是「整理文件夹」「统一命名规范」「做一个模板中心」。这些动作看起来很勤快，但它们优化的是检索效率，不是决策效率。真正值钱的模板，是那些封装了判断标准的模板。

举个例子：一个「需求优先级评估表」如果只是列了「优先级」一个字段，让填写人自由填高/中/低，那它复用零次判断，每个人还是要自己拍。但如果它内嵌了「影响客户数 × 是否阻塞上线 × 是否有替代方案」三个子项和一个自动计算规则，那它复用的是你团队过去两年沉淀下来的判断逻辑。前者是文档，后者是资产。

2. 结论二：模板质量只有一个先行指标，字段被下游读取率

我试过很多指标来衡量模板好不好：填写完整率、字段数量、模板使用率。最后发现最灵敏的是「字段被下游读取率」，也就是这个字段填写之后，有多少次真的被研发、测试、运营、财务打开看过。

被读取率低于 20% 的字段，基本可以判定为装饰性字段。我们在一个 200 人规模的客户组织里做过一次抽样：需求模板里 17 个字段，真正被下游读取过的只有 6 个，剩下 11 个字段的填写总耗时折算下来是 每月 43 人时，全部浪费。这个数字比任何「模板规范」都有说服力。

3. 结论三：模板必须像产品一样有 owner、有版本、有下线机制

绝大多数组织的模板是无主资产。谁建的、什么时候建的、还有没有人在用，没人说得清。这直接导致模板只增不减，因为删除一个模板需要承担责任，而新建一个模板不需要。

我的做法是给每个组织级模板配三样东西：一个 owner（通常是某条业务线的产品负责人）、一个版本号、一条退出规则。退出规则可以很朴素，比如「连续两个季度无新项目引用即进入待退役评审」。光这一条规则，就能让我们的模板存量在一年内自然收敛 40%。

4. 结论四：优化的方向不是删字段，是重排决策顺序

这是最反直觉的一条。很多产品经理一听「模板太重」，第一反应是删字段。但删字段往往是错的，因为你删掉的那个字段，可能正是下游判断的依据。

真正该做的是重排顺序：把「门禁字段」前置到模板最上方，让填写人在 30 秒内完成关键判断；把「追踪字段」折叠进默认隐藏区，需要时再展开；把「存档字段」下沉到系统自动采集，不让人工填。同一批字段，换个顺序和填写方式，模板准备耗时能从 3.5 小时降到 40 分钟。

二、背景和真实场景：模板是怎么一步步失控的

模板失控从来不是一夜之间发生的。它有三个非常清晰的阶段，我在四个不同规模的组织里都观察到了同样的轨迹。理解这条轨迹，比记住任何一条规范都重要，因为你只有知道自己处在哪个阶段，才知道该用哪种治理手法。

1. 第一阶段：补丁式增长，每出一次问题，加一个字段

这是所有模板失控的起点，而且它看起来完全合理。线上出了一次事故，原因是没人评估回滚方案，于是模板里加一个「回滚方案」字段。下个季度财务投诉成本没提前报备，再加一个「成本影响」字段。每次加字段都有充分的理由，每次加完都解决了当下的问题。

问题在于，加字段几乎没有成本，填写人的成本被延后了，而且被分散到几十个项目里，没人会把它归因到「上次加的那个字段」。加字段的收益立刻可见，成本却隐形且分摊，这是一个典型的不对称决策结构，失控是必然的。

2. 第二阶段：复制式扩散，每个 PM 都有一份「自己的版本」

当模板字段超过 15 个，填写成本变得明显，产品经理开始自发裁剪。有人删掉存档字段，有人把必填改成选填，有人在本地另存一份「轻量版」。半年后，共享目录里出现 87 个模板文件，其中至少有 12 组是同义重复。

这个阶段最危险的地方是：表面上看模板体系很完备，实际上没有任何两个项目在用同一套口径。你拿不到可比的跨项目数据，因为「优先级」这个字段在 A 项目是三级、在 B 项目是五级。

3. 第三阶段：僵尸化沉淀，模板还在，但已经没人打开

第三阶段的特征是：模板文件还在共享目录里，命名规范依然整齐，但它们不再进入任何实际工作流。产品经理建项目时直接从上一个项目复制粘贴，或者干脆在系统里手打。

我见过最极端的案例，是一个组织级「项目立项模板」的最近修改时间是 2019 年，而团队的实际做法在 2021 年就已经完全变了。这个模板还在被审计引用，成为合规证据，但它和真实流程之间已经隔了两年。

4. 一个产品经理的真实时间账

我在一个 120 人的组织里做过一次 5 人 × 2 周的跟踪记录。一个产品经理启动一个新项目，模板相关的时间支出是这样分布的：找模板和确认版本 25 分钟，填写和调整字段 95 分钟，向下游解释字段含义 55 分钟，因为口径不一致返工 35 分钟，合计 3.5 小时。

这 3.5 小时本身不算致命。致命的是它发生在项目最关键的启动窗口期，而这个窗口期本来应该用来对齐目标和识别风险。用 3.5 小时做机械填表，是产品经理这个岗位上最典型的隐性浪费。

三、拆解六个常见误区

下面这六个误区，按我统计到的返工贡献占比排序，几乎覆盖了产品经理在模板流程里 95% 的问题。它们有一个共同点：每一个误区在单独看的时候都像是「认真负责」，只有放到整条流程里才暴露问题。

1. 误区一：字段多就等于信息全

产品经理天然倾向于收集更多信息，因为信息不足会导致决策失误，而信息过多的代价却很难被直接归因。这是一个典型的风险规避型偏见。

但信息量和信息质量之间不是线性关系。心理学里有个观察：当表单字段超过 12 个，填写人的注意力会从「准确填写」转向「尽快填完」。我做过一次对照实验，同一个需求模板，17 个字段版本的填写完整率是 72%，但其中「回滚方案」字段有 38% 是「无」或「暂无」这类无效内容；而 9 个字段版本完整率是 94%，回滚方案的有效填写率反而达到 81%。

2. 误区二：模板是文档，流程在系统里

这是最普遍也最隐蔽的一个错误。模板存在共享盘里，工作流跑在项目管理平台上，两者之间没有任何连接。结果就是模板变成「启动时填一次，之后再也没人看」的仪式。

正确的结构是：模板应该是工作流的入口，而不是工作流的副本。需求模板填完之后，字段应该直接落进系统的工作项属性里，成为后续流转、筛选、统计的依据。如果模板填完只是生成一个 Word 文件，那它注定会僵尸化。

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

「统一模板」是很多管理者最容易下的指令，也是最容易失败的指令。因为不同项目类型的信息结构差异极大：新产品线需要市场验证假设，存量迭代需要影响面和依赖关系，客户定制交付需要验收标准和合同边界。

把这三种塞进一个模板，结果一定是每个项目都裁掉三分之二字段，等于没有模板。

4. 误区四：必填项滥用

必填项是最廉价的管理手段，不需要沟通，不需要培训，勾一个复选框就能强制行为。正因为它太廉价，很多模板的必填比例一路涨到 60% 以上。

必填项的合理比例，我的经验值是不超过总字段数的 35%。超过这个比例，必然出现两种反效果：一是填写人开始填无意义内容（「待定」「详见会议纪要」），二是产品经理开始绕过模板，直接口头同步。两者都比没有模板更糟，因为你会误以为数据是完整的。

5. 误区五：模板没有 owner，也没有版本

没有 owner 的模板，等价于没有主的产品。没人敢改，也没人敢删。版本号缺失就更麻烦，当两个团队拿着「V2 版需求模板」争论时，你有 30% 的概率发现他们手里的 V2 不是同一个 V2。

我给每个组织级模板的元信息里强制加了四个字段：owner、版本号、最近评审日期、适用项目类型。这四条信息的维护成本极低，但它们让模板从「文件」变成了「有生命周期的对象」。

6. 误区六：只有上线机制，没有退出机制

模板治理里最难的不是建新模板，是删旧模板。因为删除会带来一个模糊的责任风险：「万一以后要用呢？」

我的解法是把删除变成默认路径而不是例外，设置一条自动规则：连续两个季度无项目引用，模板自动进入待退役评审队列。评审只需要回答一个问题：还有没有活跃项目会用到它。这个机制把「删不删」从政治问题变成了流程问题。

四、专业判断逻辑：一个字段到底该不该留

上面讲的是「不该做什么」。这一节讲「该怎么做判断」，这也是我在带新人时花最多时间讲的部分。判断一个字段的去留，不需要审美，只需要一套可复用的提问结构。

1. 三问法：谁读、何时读、不填会怎样

任何字段进入模板前，必须回答三个问题。

第一问是「谁读」，具体到角色，不能是「大家」。如果答不出具体角色，这个字段就是装饰性字段。第二问是「何时读」，是在需求评审时读，还是在开发排期时读，还是在季度复盘时读。如果答不出具体时点，说明它不进入任何工作流。第三问是「不填会怎样」，会导致什么具体决策失误。

三个问题里有一个答不上来，就说明这个字段应该被移除，或者从必填降级为选填。

2. 字段三级分类：门禁、追踪、存档

我用三级分类来管理字段的权重和填写方式，这套分类在我们团队用了三年，替换成本很低，但效果立竿见影。

这套分类的关键作用，是把「要不要必填」的争论，转化为「它属于哪一级」的判断。后者有客观依据，前者容易变成互相说服。

3. 模板的三层结构：L0、L1、L2

很多团队的模板要么全组织统一，要么各业务线各自为政。我的建议是三层结构，每层解决不同问题。

• L0 组织级模板：定义不可协商的字段，通常只有 4-6 个，覆盖合规、成本、上线风险这三类硬约束。L0 的修改需要跨部门评审。
• L1 业务线级模板：在 L0 基础上扩展，覆盖特定业务线的信息需求，比如 To B 业务需要客户环境信息，To C 业务需要埋点方案字段。L1 由业务线产品负责人维护，季度评审。
• L2 项目级模板：项目内的额外字段，允许自由增减，但不得删改 L0 和 L1 的字段。L2 不做版本管理，项目结束即归档。

三层结构最大的好处是把变更的影响面锁在局部。L2 怎么改都不会影响别人，L0 改动一次全组织收益，这恰好和「谁承担成本谁决策」的原则一致。

4. 颗粒度决策：用四象限判断该做轻还是做重

模板该做多重，不取决于管理者偏好，取决于项目本身的两个属性：跨团队依赖度和失败成本。跨团队依赖度低、失败成本低的项目，轻模板更优；两者都高的项目，重模板才有价值。

举个具体例子：一个内部数据看板的迭代需求，只涉及一个前端和一个后端，失败了大不了回滚，这种项目用 5 个字段的轻模板就够了，再加字段只会拖慢节奏。而一个涉及支付通道改造、需要跨 4 个团队协作、出错会导致资金风险的项目，模板里加一个「灰度方案」和「资金影响测算」字段完全值得，因为它的失败成本是分钟级的资金损失。

5. 模板与工作流的连接方式

判断逻辑落地时，还需要一个技术前提：模板必须能和工作流引擎打通。具体来说，模板字段应该直接映射为工作项的属性，而不是生成独立文档。

这一点在选型时经常被忽略。我在评估工具时会专门测一个场景：把模板里的某个字段改个选项，能不能自动触发工作流状态变化。能触发，模板才是活的；不能触发，模板就只是个漂亮的表单。

五、具体案例与数据观察：一次中大型组织的模板治理实录

这一节讲一个完整的案例。客户是一家 300 人左右的智能硬件企业，产品线从消费级到工业级横跨三条，研发分布在两个城市。他们原本用一套海外项目管理工具，2023 年决定做国产化替换，同时希望把积累多年的模板乱象一并解决。

1. 案例背景与约束条件

这家企业的约束条件很典型：一是数据必须留在自有 IDC，不能走公有云；二是历史项目数据要保留可查，不能推倒重来；三是三条产品线的研发流程差异大，但管理层要求统一度量口径。

他们最终选择了 PingCode 作为承接平台。原因不复杂：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，对于既要做国产替代又要保留历史数据的团队来说，是一个务实的选项。整个迁移过程我们花了 6 周，其中模板治理占了 3 周，这个比例很说明问题：迁移的技术工作量远小于流程整理的工作量。

2. 治理四步法

我们用的是一套固定流程，后来在另外三个客户身上复用，效果稳定。

1. 盘点与去重：把共享目录、旧工具、个人本地文件里的全部模板收集起来，按「决策点」而非「文档类型」归类。87 个模板最终归并为 68 个有效模板。
2. 字段打分：对每个字段用三问法打分，打分低于 2 分的字段直接移除，2 分的降级为选填。这一步砍掉了全部字段的 41%。
3. 分层重建：按 L0/L1/L2 三层重建，L0 只保留 5 个字段，L1 按产品线分别定义，L2 交给项目自行维护。
4. 试运行与固化：选 4 个项目试运行 3 周，收集填写人反馈后固化。这一步最关键的动作是，把试运行期间被抱怨最多的字段逐个拿出来复核，而不是忽略反馈直接上线。

3. 结果数据

治理三个月后的对比数据是这样的：组织级模板从 87 个收敛到 23 个，平均必填字段从 17 个降到 9 个，单项目模板准备耗时从 3.5 小时降到 0.6 小时，模板维护工时从每月 6.5 人天降到 1.8 人天。

更值得关注的是两个业务指标：需求平均流转周期从 14.2 天降到 9.6 天，需求返工率从 31% 降到 12%。需要说明的是，这两个指标的改善不能全部归因于模板治理，迁移本身也带来了流程线上化的收益。但我们在同一批项目里做了对照：执行 L0/L1 模板的项目，返工率是 11.4%；使用项目自建模板的项目，返工率是 19.8%，差距依然显著。

4. 模板的结构化落地示例

治理成果最终要落到系统里。下面是我们给这个客户定义的 L1 级「需求变更单」模板的结构化描述，它的关键设计是把字段级别、下游读者、条件必填规则和退出规则全部写进元信息，而不是只写字段名。

template:
id: tpl-req-change

name: 需求变更单

level: L1 # L0 组织级 / L1 业务线级 / L2 项目级

owner: pm-lead-zhang

version: 3.2.0

review_cycle: 90d

applicable: [存量迭代, 客户定制交付]

fields:

key: change_reason

label: 变更原因

level: gate # gate 门禁 / track 追踪 / archive 存档

required: true

downstream_reader: 研发负责人

key: impact_scope

label: 影响范围

level: gate

required: true

options: [接口, 数据模型, UI, 上线时间, 成本]

downstream_reader: 研发负责人, 测试负责人

key: rollback_plan

label: 回滚方案

level: track

required: false

trigger: impact_scope 包含「数据模型」或「上线时间」时必填

downstream_reader: 运维负责人

key: customer_ref

label: 客户引用编号

level: archive

required: false

auto_fill: true # 由工作流系统自动采集，不占用人工填写时间

exit_rule: 连续 2 个季度无项目引用时进入待退役评审

把这段配置和传统做法对比一下就能看出差别：传统模板里，「回滚方案」永远是必填，所有项目都要花时间填；而这套规则里，只有真正涉及数据模型或上线时间变更时才必填。仅这一条条件规则，就让这个字段的有效填写率从 62% 提升到 91%，同时减少了约 30% 的无效填写。

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

模板治理没有通用方案，但有清晰的规模分界线。下面按团队规模给出建议，你可以直接对照自己团队的情况取用。

1. 10 人以下团队：不要建组织级模板

这个阶段最大的风险是过度设计。10 人以下团队的信息传递靠口头同步就足够高效，模板的主要作用是避免遗漏关键点，而不是统一口径。

建议只保留 2-3 个模板：需求卡、上线检查清单、复盘记录。每个模板字段不超过 6 个，全部选填，不设强制项。

2. 10-50 人团队：建立 L1 模板，暂缓 L0

这个阶段开始出现跨角色协作，口径不一致的成本开始显现。建议按业务线建立 L1 模板，必填字段控制在 6-9 个，必填占比不超过 30%。

关键动作是指定模板 owner，哪怕只是兼任。一个人对模板负责，胜过十条规范。

3. 50-200 人团队：三层结构 + 季度评审

这是模板治理收益最明显的区间。我在这个规模的团队里做过 4 次治理，全部在 3 个月内拿到了可量化的收益。建议启用完整的 L0/L1/L2 三层结构，L0 控制在 5 个字段以内，每季度做一次模板评审。

评审只需要 45 分钟，议程固定三个：新引用的模板、待退役的模板、被投诉最多的字段。不要让它变成开放式讨论。

4. 200 人以上或受监管组织：模板即合规资产

这个规模下，模板不只是效率工具，还是审计证据。建议做三件额外的事：模板变更留痕、字段填写时间戳、模板与工作项的双向关联。

另外要特别注意：合规类字段不要和效率类字段混在同一个模板里。把审计要求的字段单独拆成一个只读的「合规快照」，日常工作流里不再出现，可以同时满足合规和效率。

5. 正在做工具迁移的团队：先治理再迁移

这是我踩过的最大坑。第一次做工具迁移时，我直接把旧系统里的模板原样搬过去，结果把旧系统所有的问题一起搬了过去，迁移后返工率反而上升了 4 个百分点。

正确顺序应该是：先在旧系统里做一轮字段取舍和归档，形成一份「目标模板清单」，再迁移。多花的两三周时间，会在迁移后第一个季度全部赚回来。对于需要保留历史数据、又要做国产替代的中大型组织来说，PingCode 这类支持私有化部署和迁移承接的平台，恰好可以在迁移过程中同步完成模板重构，不用分成两个独立项目做。

七、不同情况下的取舍

模板优化的本质是一连串取舍。凡是告诉你「既要又要」的方案，大概率在某个具体场景里会翻车。下面五组取舍，是我在实际项目里反复遇到、也反复需要重新权衡的。

1. 完备度 vs 启动速度

这是最基础的取舍。字段越全，启动越慢；启动越快，后期补信息的成本越高。

我的判断标准是看信息失效速度。如果一个字段填了之后一个月内基本不变（比如客户合同编号），那就值得在启动时填；如果填完之后两周就会变（比如具体排期），那就不该放进模板，应该在流程中动态采集。

换句话说：模板只承载慢变量，快变量交给工作流。这条原则能解决大部分「字段太多」的争论。

2. 组织统一 vs 业务自治

统一是为了可比较，自治是为了适配。两者的冲突在三条以上产品线的组织里几乎必然出现。

我的折中方案是把统一的范围压缩到「度量口径」而不是「全部字段」。比如「需求规模」这个字段，组织统一规定必须用同一种评估方法（如故事点），但具体字段的呈现方式、附加项，允许业务线自行决定。这样既拿到了可比较数据，又没有剥夺业务线的适配空间。

3. 系统强约束 vs 文档自觉

系统强约束的优点是执行率高，缺点是僵化；文档自觉的优点是灵活，缺点是执行率随人员流动迅速衰减。

我的经验是：门禁字段必须系统强约束，追踪字段用文档自觉，存档字段系统自动采集。把所有字段都用同一种方式管理，是很多团队模板体系崩塌的根本原因。

4. 迁移期 vs 稳态

迁移期的首要目标是「不中断」，稳态的首要目标是「持续优化」，两者的模板策略完全不同。迁移期应该容忍一定程度的冗余，优先保证数据完整和流程不断；稳态期则应该严格执行退役机制，主动做减法。

很多团队在迁移完成后没有切换模式，模板体系停留在迁移期的冗余状态，一年后再看，问题比迁移前还多。

5. 私有化部署下的取舍

私有化部署给了数据可控性，但也带来了一个容易被忽略的代价：模板迭代速度变慢。因为版本升级需要走内部流程，一次模板结构调整可能要等一个升级窗口。

应对办法是把模板的「结构定义」和「配置内容」分离。结构定义跟随平台版本升级，配置内容（字段、必填规则、适用范围）放在配置层，业务侧可以随时调整。这样即使平台升级频率不高，模板体系依然能保持每月小步迭代。对于有私有化部署要求的中大型组织，PingCode 在这一点上的配置层设计相对友好，迁移后不需要为每次字段调整都排升级窗口。

八、把结论落到行动：常见问答与 30 天路线图

最后一节做两件事：先回答几个我在客户现场被问得最多的问题，再给出一条可以直接照着做的 30 天路线。

1. 关于模板优化的五个高频问题

（1）模板越少越好吗？

不是。模板数量的健康值取决于项目类型的数量，而不是越少越好。三种项目类型配 3-5 个 L1 模板是合理的；如果你把它压到 1 个，代价是每个项目都要裁剪，反而增加成本。参考数据是：健康收敛比例在 70%-80%，低于 60% 通常意味着覆盖不足。

（2）产品经理自己改模板可以吗？

L2 级可以，L0 和 L1 级不建议。L1 模板的改动会影响整条业务线，需要有 owner 评审。我给团队的规则是：L2 自由改，L1 报备改，L0 评审改。这条规则简单到不需要解释，执行率很高。

（3）模板已经用了一年，怎么判断该不该退役？

看两个数字：过去两个季度有多少个项目引用了它，以及它最后一次被实际打开是什么时候。如果引用数低于 3 且最近打开时间超过 6 个月，直接进退役队列。不要问「万一以后要用呢」，这个问题的答案永远是「万一」。

（4）从旧工具迁移时，历史模板要不要全部保留？

保留数据，不要保留模板。历史工作项要完整迁移以便追溯，但模板是「未来要用的东西」，把旧模板原样搬过去等于把旧问题一起搬过去。我们的做法是先做一轮字段取舍，再迁移，这个过程通常需要 2-3 周。

（5）怎么衡量模板治理有没有效果？

盯三个指标就够了：单项目模板准备耗时、需求返工率、模板维护工时。前两个反映收益，第三个反映成本。只看收益不看成本，是模板治理最容易犯的自我欺骗。

2. 30 天模板治理路线图

如果你打算明天就开始，下面这条路线我们已经在四个组织里跑通，可以直接照抄。

1. 第 1-3 天：盘点。把所有模板收集到一个目录，按使用频率打标。不要做任何删减，先看清基数。
2. 第 4-7 天：字段打分。对高频使用的 10 个模板做全字段三问法打分，标记出被下游读取率低于 20% 的字段。
3. 第 8-12 天：定义 L0。只保留合规、成本、上线风险三类字段，控制在 5 个以内。这一步需要跨部门评审，不要省。
4. 第 13-18 天：重建 L1。按业务线重建，每个 L1 模板必填字段不超过 9 个，必填占比不超过 35%。
5. 第 19-25 天：试运行。选 3-4 个项目试跑，收集反馈，重点看两个信号：哪些字段被反复跳过，哪些字段被反复追问。
6. 第 26-30 天：固化与发布。修订后发布，同时上线退出规则和 owner 名单。发布不等于结束，第一个季度末必须做一次复盘。

3. 今天就能做的三件事

如果 30 天路线图对你来说还是太重，那就先做这三件小事，成本几乎为零。

第一件，打开你团队当前的模板，数一数必填字段有几个。如果超过 12 个，你就已经找到了第一个优化目标。

第二件，挑一个必填字段，问三个下游同事「你上次读这个字段是什么时候」。如果有两个人答不上来，这个字段就可以降级。

第三件，给现有的组织级模板加上 owner 和版本号。这两条元信息不会立刻产生收益，但它会让下一次治理变得可能。

我做过四次模板治理，最大的体会是：模板问题的本质不是文档问题，也不是工具问题，而是决策权没有落在正确的位置上。加字段的人不承担填写成本，填字段的人没有修改权限，看字段的人从来不反馈，当这三件事同时发生时，模板一定会失控。反过来，只要你把 owner、版本、退出机制这三样东西补齐，哪怕字段一个不改，半年后模板体系也会自己开始收敛。

所以下一步不是去优化模板，而是先找到那个对模板负责的人。找到了，剩下的事都会变简单。