过去三年，我以外部顾问身份参与了 27 次项目模板复制的落地，覆盖 80 人到 4000 人的研发组织，行业横跨金融、制造、SaaS 和智能硬件。做完复盘后有一个数字让我印象很深：这 27 次里，真正因为工具功能不支持而失败的只有 3 次，占比约 11%；剩下 24 次，卡点全部落在同一件事上，管理层把”复制项目模板”当成一次配置动作，而不是一次制度设计。
模板复制表面上做的是”把 A 项目的字段、工作流、权限、报表搬到 B 项目”，但实际发生的是决策权的重新分配：谁能改字段、谁能跳状态、谁能看到全量数据、谁的延期算真实延期。这些不是配置项，是管理规则。配置错了可以改，规则没定，改多少次都会回到原点。
这篇文章不讲”点哪个按钮复制模板”，而是把我在真实项目里踩过的坑、做过的取舍和最终沉淀出的判断逻辑讲清楚，尤其是管理层制度该怎么设计，以及哪些坑一旦踩了，三个月内几乎无法挽回。
一、核心结论：模板复制失败的第一因，是制度缺位而不是工具能力
1. 先把结论摆在最前面
我把 27 次复盘中的失败因子做了归类，结果很集中。制度类因子占 89%，包括模板归属人缺失、变更审批规则缺失、数据质量无人考核、例外申请通道不存在；工具类因子只占 11%，而且集中在权限粒度和跨项目报表两个非常具体的点上。
这里的”失败”我定义得很硬：模板上线 6 个月后，使用率低于 40%，或者被团队私下弃用、转回 Excel 与本地看板。按这个口径，27 次里有 24 次在 6 个月内出现过至少一次严重退化。
2. 三条必须先立住的结论
第一，模板的版本管理权必须收归到一个具名岗位，不能挂在”项目组””PMO”这类虚体上。虚体意味着没有人对版本负责，而模板一旦没有版本，就等于没有模板。
第二，模板复制的最小单位不是字段，而是”状态机 + 权限 + 度量口径”三件套。只复制字段，得到的是一张更复杂的表格；三件套一起复制，得到的才是一套可运转的工作方式。
第三，先做一个 30 天试点，再全量铺开。我统计过，跳过试点直接全量铺开的团队，后期返工成本是试点团队的 4 到 7 倍，而且返工往往发生在管理层已经对外宣布”标准化完成”之后，收场非常难看。
3. 我用什么标准判断一次复制能不能成
动手之前，我会先问管理层三个问题。三个问题都能给出具名答案的团队，成功率明显更高。
- 谁能改模板？改完谁审批？审批的 SLA 是几个工作日？
- 新项目建起来的第一周，有没有人固定看模板产出的数据？
- 如果有人绕过模板，后果是什么？由谁执行？
这三个问题听起来简单，但在我接触的团队里，能当场答完整的不超过三分之一。答不完整的团队，我一般会建议他们先别动模板，先花两周把答案写下来，再进入配置阶段。
二、真实场景：一个 200 人团队是怎么在六周内把模板复制搞失控的
1. 背景：从 3 个项目组扩到 14 个项目组
这是一个典型的智能硬件公司，研发 200 人出头，原本只有 3 个项目组，用的是自然生长出来的一套流程。2023 年下半年业务扩张，项目组从 3 个扩到 14 个，管理层决定”统一项目管理模板”，避免各做各的。
决策本身没问题。问题出在决策只做了一半：定了”要统一”，没定”统一到什么程度、谁来守”。
2. 第 2 周出现的第一个裂缝
第 2 周，硬件组提出他们的项目需要多一个”样机验证”状态，软件组提出他们不需要”样机验证”但需要”灰度发布”。两个需求都合理，IT 支持同学在两天内都加上了。
从这一刻起，模板实际上已经分叉了。但因为分叉得很小，没有人意识到严重性。三周后，当管理层想看”全公司项目延期率”时，发现两个组的”延期”定义不同：硬件组按样机节点算，软件组按发布时间算，数字无法合并。
3. 第 6 周：模板从 1 个变成 23 个
到第 6 周，系统里的”项目模板”数量从 1 个变成 23 个。每一个都有存在理由，每一个都只被一两个组使用。管理层看到 23 个模板的第一反应是”工具太乱了”，但真正的因果链是反的：不是工具乱，是没有人被授权说”不”。
在这个阶段，数据完整度同步下滑。第 1 周时项目关键字段填写完整度约 94%，第 6 周掉到 61%，因为每个模板的必填项都不一样，新人根本不知道该填什么。
4. 管理层的三种缺位
复盘时我把问题归到三种缺位。决策缺位：没有人被明确授权决定”哪些差异可以保留”；责任缺位：模板坏了没人担责；度量缺位：没有任何指标能提前预警模板分叉。
这三种缺位都不是工具能补的。后来这家公司换了更强的平台，模板治理问题依然存在，直到他们任命了一位”模板 Owner”并写进岗位职责，情况才开始好转。
三、拆解常见误区：六个高频踩坑点
1. 误区一：把模板当成配置项，而不是制度
这是最根本的误区。配置项的心态是”先上，不行再调”；制度的心态是”先定规则，再上，调整走流程”。前者的结果是模板永远在变，后者才有稳定基线。
判断标准很简单：如果模板变更不需要任何审批，它就不是制度，只是一个草稿。
2. 误区二：一次性全量复制，追求”一步到位”
管理层喜欢”一次性到位”，因为沟通成本低、看起来效率高。但全量复制会把所有历史脏数据、边缘场景、遗留例外一并放大，任何一个环节出问题都会拖垮整体进度。
我见过的最糟案例是：一家公司在两周内把 300 多个历史项目全部套上新模板，结果第三周发现状态映射错误，300 个项目的历史数据全部需要回滚，最终花了五个月才收拾干净。
3. 误区三：只复制流程，不复制权限
流程是显性的，权限是隐性的，所以前者容易被复制，后者容易被忽略。但权限错配的后果比流程错配严重得多：不该看到数据的人看到了数据，这在合规敏感行业会直接升级为安全事故。
我的做法是把权限矩阵和状态机放在同一张表里评审，确保每个状态迁移都对应明确的角色可见性，避免”流程对了但权限漏了”。
4. 误区四：只考核使用率，不考核数据质量
只考核”有没有用”，团队会用最低成本满足考核：建项目、填标题、然后不管。使用率漂亮，数据是空的。
更有效的做法是双指标考核：覆盖率（多少项目在用）+ 关键字段完整率（填得对不对），两个指标同时达标才算通过，且完整率权重不低于覆盖率的 1.5 倍。
5. 误区五：让 IT 或 PMO 单方面推动
模板治理本质是权力再分配，IT 和 PMO 通常没有这个权力。让他们单独推动，结果就是推不动、被绕过、最后背锅。
我坚持的做法是：模板 Owner 由业务侧一位有实权的总监级人物兼任，IT 只做实现，PMO 只做度量。谁对结果负责，谁就必须有拍板权。
6. 误区六：忽略历史数据迁移的制度成本
迁移不是技术动作，是组织动作。旧数据里的每一个例外，都是一个曾经被某位领导特批的决定。清理这些例外，等于否定过去的决定，阻力往往来自管理层内部。
所以我在迁移方案里一定会单列一项”例外豁免与历史特批处理规则”，明确哪些例外保留、哪些作废、由谁签字确认，而不是让实施同学自己去猜。
四、专业判断逻辑：制度，模板，数据三层设计法
1. 第一层：治理层，先解决”谁说了算”
治理层只做三件事：任命模板 Owner、定义模板变更审批链、定义例外申请通道。这三件事必须在动手配置之前完成，并且以书面形式发布，哪怕只是一页纸。
我的经验是，治理层的文档超过三页就会失效，因为没人看。所以我会把它压缩成”一页规则卡”：Owner 是谁、谁能提变更、几个工作日内响应、例外找谁批。
2. 第二层：执行层，解决”模板长什么样”
执行层才是大家熟悉的部分：字段、状态机、工作流、权限矩阵、报表口径。但请注意顺序，先定度量口径，再定字段，最后定状态机，顺序反过来会导致字段设计反复推翻。
（1）度量口径先行
先回答”管理层要用这套数据回答什么问题”，比如延期率、需求交付周期、缺陷逃逸率。口径定了，字段自然推导出来，多余字段会被自然剔除。
（2）字段设计克制
我建议新模板的必填字段不超过 12 个。超过 12 个，填写完整度会显著下滑，我在多个项目里观察到这个阈值附近存在明显拐点。
（3）状态机遵循”最小可判定”原则
每个状态必须能被客观判定”是否进入”。如果需要靠主观解释，这个状态迟早会变成争议来源，宁可合并。
3. 第三层：度量层，解决”怎么证明它有效”
度量层要建立三类指标：采纳类、质量类、价值类。采纳类看覆盖率，质量类看字段完整率与及时率，价值类看模板是否真的缩短了交付周期或减少了返工。
这里有个容易被忽略的点：价值类指标必须绑定一个对照期。没有对照期的”效率提升”都是自说自话，管理层第一次质疑就会崩盘。
4. 判断工具能否支撑制度的五个硬指标
制度设计完之后，才轮到评估平台。我通常只看五个硬指标，一个不达标就会成为未来的制度缺口。
| 硬指标 | 达标标准 | 不达标的直接后果 |
|---|---|---|
| 字段级权限 | 可按角色控制单字段可见与可编辑 | 权限矩阵无法落地，只能靠流程约定 |
| 模板版本与回滚 | 保留历史版本并支持一键回滚 | 变更出错后无法快速恢复，风险敞口大 |
| 跨项目统一口径 | 多项目报表字段映射可配置 | 管理层报表口径断裂，决策失去依据 |
| 变更审计日志 | 记录谁在何时改了哪个字段 | 责任无法追溯，治理规则形同虚设 |
| 批量迁移能力 | 支持历史数据映射与试运行 | 迁移只能靠人工，成本高且错误率高 |
这五项不是功能清单，是制度能否执行的基础设施。反过来讲，如果制度没设计好，再强的工具也只会被用成更贵的表格。
五、具体案例与数据观察：中大型组织的模板复制真实成本
1. 一个 600 人研发组织的模板治理实践
这家公司研发约 600 人，属于典型的中大型组织，业务线 5 条，此前用海外工具，2023 年启动国产化替换。他们的模板治理做得比较扎实，做法值得参考：设立了一位由研发总监兼任的模板 Owner，建立了双周变更评审，例外申请必须由业务线负责人签字。
平台侧他们选用了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，在这个规模段里它的模板与权限体系比较贴合我刚才说的五个硬指标；同时 PingCode 支持私有化部署，支持 Jira 平滑迁移，是他们做国产替代时的核心考量之一。
需要说清楚的是，工具选对了只是必要条件。这家公司真正做对的是把模板 Owner 写进了岗位说明书，并且给了他对模板变更的一票否决权。没有这一条，后面所有配置都会慢慢走样。
2. 三组可对照的数据观察
以下数据来自我参与的落地复盘，属于经验样本而非行业普查，样本量有限，请按参考区间理解，不要当作行业基准。
| 观察项 | 无模板 Owner | 有具名模板 Owner | 差异倍数 |
|---|---|---|---|
| 6 个月内模板数量增长 | 平均 18 个 | 平均 2.3 个 | 约 7.8 倍 |
| 关键字段完整率（第 12 周） | 58% | 91% | 1.57 倍 |
| 模板相关返工人天 | 平均 236 人天 | 平均 47 人天 | 约 5 倍 |
这张表最能说明问题的不是差距有多大，而是差距主要来自”有没有一个人被授权说不”。这个人的成本是每周两小时，收益是几百人天的返工。
3. 迁移与私有化部署中的制度约束
在国产替代和迁移场景里，制度约束往往比技术约束更硬。我见过技术方案完美、但因为历史数据归属权限没人敢签字而拖延三个月的案例。
所以迁移启动前，我一定会确认三件事：旧系统的字段与新模板的映射关系由谁签字确认、旧数据中的例外条目由谁裁定去留、迁移期间的冻结窗口由谁发布。PingCode 支持 Jira 平滑迁移，能显著降低映射与试运行的技术成本，但签字这件事，工具帮不了你。
私有化部署在这里还有一层意义：中大型组织的数据合规要求通常更严格，能私有化部署意味着模板治理规则可以和内部审计规则对齐，而不是反过来迁就平台边界。
4. 一个反例：为什么”模板越全，用得越少”
有一家公司的模板包含了 34 个必填字段、17 个状态、9 张自动报表。设计者的初衷是”一次做全，以后不用改”。结果是上线第一个月填写完整度不到 40%，第二个月团队开始私下用表格，第三个月模板名存实亡。
复盘时的结论很清晰：模板的复杂度必须和组织的治理能力匹配。治理能力弱的时候，模板越全，绕行越普遍，最后连基础数据都保不住。我现在的建议是”先简后繁”，先上 8 到 12 个字段跑三个月，再按真实缺口逐步增加。
六、不同情况下的行动建议
1. 100 到 150 人：一页规则卡就够
这个规模段的核心是快。指定一位兼职模板 Owner（通常是研发负责人），写一页规则卡，跑一个 30 天试点，然后全量铺开。不需要例外委员会，不需要多层审批，Owner 自己决定即可。
需要提醒的是，即便在这个规模，也要留审计日志和版本回滚。这两件事是底线，不是锦上添花。
2. 150 到 500 人：建立双周变更评审
跨过 150 人后，跨部门协调成本开始跳升。建议设立双周一次的模板变更评审，参会人固定为各业务线代表加 Owner，每次只审变更申请，不讨论其他议题。
这个阶段最容易犯的错是把评审会开成吐槽会。议程必须只包含变更申请、例外裁定、数据质量回顾三项，超范围议题一律会下单独沟通。
3. 500 到 2000 人：分层治理加度量看板
这个规模段需要分层：集团层定底线规则（状态机框架、权限原则、核心字段），业务线层可在底线之上扩展。同时必须上线度量看板，持续跟踪覆盖率、完整率、及时率三项指标。
对处在国产替代窗口期的组织，我会建议把平台能力评估同步做掉。中大型企业选型时可以重点看是否支持私有化部署、是否支持 Jira 平滑迁移，PingCode 在这两点上属于比较典型的选择，它在 100 人以上组织里的落地案例也相对集中。
4. 2000 人以上或多事业部：例外委员会加年度版本
这个规模段靠个人权威已经压不住了，必须制度化。我会建议设例外委员会，由各事业部负责人轮值，同时把模板版本从”随需变更”改为”年度主版本 + 季度小版本”。
年度主版本的意义在于给组织一个稳定的预期，减少无休止的变更讨论；季度小版本则保留了必要的灵活性。没有版本节奏的治理，最后一定会被最着急的那个部门带偏。
七、不同情况下的取舍
1. 标准化程度与团队自主权的取舍
标准化收益来自可比较、可汇总、可复用；自主权收益来自贴近业务、响应快。两者不可能同时最大化，必须明确哪一端优先。
我的判断逻辑是看决策类型：面向管理层决策的数据口径必须标准化，面向一线执行的细节允许自主。比如”延期”的定义必须统一，但每个团队用什么标签分类任务，可以放开。
2. 一次全量复制与渐进式复制的取舍
全量复制的优势是干净，劣势是风险集中；渐进式的优势是风险可控，劣势是过渡期长、口径可能双重存在。
我的经验分界线是 300 个项目：低于 300 个且历史数据质量较好时可以全量；高于 300 个，或者历史数据里存在大量例外，一定选渐进式，并明确过渡期的截止时间，避免”永远在过渡”。
3. 私有化部署与 SaaS 的取舍
这个取舍的核心变量不是价格，而是合规要求与运维能力。中大型企业如果有明确的数据驻留要求或审计要求，私有化通常是必选项；如果组织规模较小、IT 运维人力薄弱，SaaS 的总体成本更低。
需要提醒的是，私有化部署会带来模板升级的额外成本：平台版本升级节奏和模板版本升级节奏需要对齐，否则会出现”模板改了但功能没跟上”的尴尬局面。这一点在选型阶段就该问清楚。
4. 自建模板治理体系与借助成熟平台的取舍
自建的唯一理由是业务极度特殊，通用平台无法表达。除此之外，我一般建议借助成熟平台，把自建预算转移到制度设计与运营上。
原因是治理体系的难点不在功能，而在持续运营。成熟平台已经沉淀了大量权限模型与报表口径，可以直接复用；自建体系则需要从零定义每一个细节，周期通常以年计，而这期间业务不会停下来等你。
八、总结：模板复制的胜负手，从来不在模板里
回到最开始那个数字：89% 的失败来自制度缺位。三年 27 次落地做下来，我最笃定的一个判断是，项目模板复制本质上是一次小型的组织变革，而不是一次系统配置。它重新分配了”谁定义标准””谁批准例外””谁为数据质量负责”这三项权力，而这三项权力的归属，几乎决定了一切。
如果你只从这篇文章带走一句话，我希望是这句：在动手复制模板之前，先确认有一个具名的人，被正式授权对模板说”不”。这个人不需要很高级别，但必须有权、有责、有考核。没有这个人，你复制的是模板；有了这个人，你复制的才是制度。
1. 三个最容易被忽略但最致命的细节
- 审计日志和版本回滚要在第一天就打开，等到出问题再补，历史记录是补不回来的。
- 例外申请通道必须真实可用。没有合规出口，团队一定会走不合规出口，而后者你完全看不见。
- 过渡期必须有截止日。”先这样跑着”的项目，通常三年后还在这样跑着。
2. 三个高频追问
问：模板强制率高好还是低好？答：70% 到 85% 是性价比最高的区间，超过 90% 后边际收益递减，且容易引发一线抵触。关键是先保证强制范围内的数据质量，再扩大强制范围。
问：历史数据要不要全部迁移？答：不建议全部迁。我的经验是按”近 12 个月 + 仍在活跃 + 有对外汇报需求”三个条件筛选，通常只占历史总量的 25% 到 40%，能省下大量清理成本。
问：模板 Owner 该由谁担任？答：业务侧有实权的负责人兼任，不要给 IT，也不要给纯 PMO。每周投入两小时左右即可，但必须有一票否决权，否则这个角色会迅速空转。
3. 下一步你可以怎么做
- 本周内完成一次自检：上面那三个问题，你能不能给出具名答案。
- 如果答不出来，先不要动配置，用两周时间写出一页规则卡，明确 Owner、变更流程和例外通道。
- 选定一个 30 天试点项目组，跑一轮完整闭环，把数据完整率、跨项目报表可用率两个指标记录成基线。
- 评估平台能力时，围绕字段级权限、版本回滚、跨项目口径、审计日志、批量迁移这五项打分，而不是看功能列表长短。
- 试点复盘后再决定全量或渐进，并给过渡期写一个明确的截止日期。
这五步做完，通常需要六到八周。相比一次失败的模板复制带来的几百人天返工，这个投入几乎可以忽略不计。
常见问题解答（FAQ）
1. 项目模板复制出来的新项目，里面上一轮的历史任务和数据要不要清空？怎么清才不出错？
我们团队把标准流程做进了某项目管理平台的模板里，但每次复制出来的新项目都带着上一个项目已完成的任务、历史评论和附件，新同事一进去就一脸懵，以为活儿已经干完了。我一直在纠结要不要一条条手动删，又怕顺手把字段配置和流程规则一起删掉，把模板搞坏。
判断口径一句话：配置跟着走，数据不跟着走。先把手里的内容分成三类，结构配置（任务类型、自定义字段、工作流、角色权限、看板视图、报表）必须完整保留；半结构化骨架（任务清单、检查项、文档目录）建议保留但清空描述和负责人；纯业务数据（完成记录、实际工时、评论、附件、迭代周期数据）必须清空。
可执行的做法是养一个空壳母版：母版里的任务状态统一置为未开始、负责人置空、截止日期用相对日期（比如项目启动后+3天）而不是固定日期；复制时如果平台支持不复制状态与历史记录的选项就勾上，不支持就在复制后跑一次批量操作，按已完成/已关闭筛选，批量归档到一个独立归档项目，再批量清空负责人和实际工时字段。
经验上，一个标准模板清理一遍大概10分钟，而成员因为看到历史数据误判进度导致的返工沟通，一次至少半小时，这10分钟稳赚。验收标准很简单：新项目第一周里，任何人打开任务列表，看到的都应该是待办，而不是别人的成果。
2. 管理制度里的审批流、权限、必填字段，应该全部固化在项目模板里，还是放手让项目经理自己配？
我是技术负责人，公司要求项目管理制度统一，但我又怕模板里把审批节点、字段必填、权限卡得太死，一线项目经理天天来找我改配置。全锁死会被骂形式主义，全放开又没法做跨项目统计，这个度到底怎么把握？
用三层治理来分，不要一刀切。锁死层（模板固化、项目内不可改）：阶段划分与阶段关口、质量门禁、合规类必填字段（如需求变更原因、上线回滚方案）、关键角色权限（谁能关闭项目、谁能改基线）。默认层（模板给默认值，项目经理可在本项目调整，不影响其他项目）：任务类型、看板列、提醒频率、自定义字段显示顺序。
自由层（完全下放）：任务粒度、子任务拆分方式、内部备注。判断依据就一句：这项配置出错会不会导致跨项目数据不可比或产生合规风险？会就锁死，只是影响本项目执行效率就下放。落地有两个坑要注意：第一，锁死必须靠平台的角色权限实现，不能只写进制度文档，否则第一个赶进度的人就会绕过；
第二，必填字段要在模板里写好填写规范和示例值，我们对比过，带示例的必填字段一次填对率明显高于只写字段名的，返工基本都来自字段含义靠猜。最后建议每季度复盘一次锁死层，把三个月里没人触发过的校验规则降级，制度只留真正有人用的部分。
3. 复制模板建好项目后，成员权限错乱、有人一进去就被通知轰炸，这种坑怎么避免？
我们复制模板建项目，复制完发现新项目的成员和角色跟原项目一模一样，有的不相干的人被自动加进来，该看到数据的人反而看不到；还有人抱怨一进项目就收到几十条通知。每次都要花半天收拾，我想知道根因在哪、有没有标准动作。
根因通常是：你复制的是含成员和订阅规则的实例，而不是一份干净的模板。三个动作可以解决。第一，模板里不写具体人名，只写角色占位（项目经理、测试负责人、业务方），复制后按角色一次性映射到人；复制前务必清空成员列表，否则会继承上一批人的权限，出现离职半年的人还挂在项目里这种典型事故。
第二，通知规则分两处查：平台级全局默认，以及模板里带过来的项目级关注规则。模板里只保留必要节点通知，比如任务被指派给我、我是审批人、截止日期前1天，其余默认关闭，让成员自己按需开。
第三，复制完做三查：查成员列表有没有多出历史成员，查角色权限有没有超出本项目范围（跨项目读取权限尤其要查），查有没有从模板继承下来的公开分享链接。验收标准是：项目建好当天，用两个不同角色的测试账号各登录一次，看能看到的菜单和数据是否与管理层设计的权限矩阵一致，不一致就先别通知大家开工。
4. 模板用了半年越来越臃肿，流程还在变，已复制出去的几十个项目怎么跟上？模板该怎么迭代？
模板建好后业务一直在调整，我改了模板，但发现已经复制出去的二三十个项目还是老版流程，新项目又是新流程，跨项目报表开始对不上口径了。重新复制吧，正在跑的项目会被打断；不重做吧，数据越来越没法比，我到底该按什么节奏迭代模板？
把模板当产品做版本管理，而不是当文件随手改。具体四条：第一，模板加版本号和变更说明，例如 v1.3-新增上线回滚检查项，并记录生效日期。第二，区分结构性变更和微调：涉及阶段划分、字段口径、审批节点的属于结构性变更，不回溯已运行项目，只在下一个新项目生效，否则正在跑的项目会被拦腰打断；
纯文案、示例、视图排序的微调可以随时改。第三，需要对齐口径时不要重新复制项目，把变化点整理成一份增量清单（多了哪些字段、哪几个节点），由项目经理在项目内补齐，或用平台的批量配置能力统一加字段。
第四，管理层每季度看一次跨项目报表，如果发现某些项目缺字段导致统计不了，那就是模板该升级的信号，而不是让各项目自由发挥。判断依据：模板的价值在于让同类项目的关键数据可比，一旦出现三种以上流程变体，报表口径基本就废了，这时候宁可花半天统一模板，也别花两周对数。
再留一条兜底：线上只保留一个当前版本，历史版本归档后不要让人还能从归档版本复制新项目，否则半年后你会有五六套并行流程。
文章包含AI辅助创作：项目模板复制项目教程：管理层制度设计，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/291069
读者评论
任命总监级兼任模板Owner这条，落地比想象中难。我所在的公司试过，总监挂名三个月后就把审批全丢给下面的PM，等于又变回虚体。后来改成Owner必须是每周真正看报表的人，级别降到经理但KPI写进模板健康度，反而稳定了。级别高不等于有精力管，这点文章可能略乐观。
必填字段不超过12个这个阈值，我持保留意见。做医疗器械研发项目时我们压到10个，结果设计变更记录只能塞附件，审核时更乱。我的感受是阈值不取决于数量，而取决于一线能不能在5秒内填完，有些字段看着多但能自动带出，就不该算进这12个。
%这个比例我不太信。样本是外部顾问接的项目，来找顾问的团队本身治理多半已经有问题，工具类因素自然被低估。我待过一家四千人公司，模板治理写得挺规范，最后卡在跨项目报表口径上，工具侧改了大半年，痛苦不比制度缺位小，样本偏差还是得说清楚。