模板权限怎么做？项目经理制度设计：项目模板从0到1

我见过最贵的一次模板事故，发生在一家做智能硬件的公司。一位入职两周的新人，把全公司共用的”量产导入模板”里的 14 个里程碑删掉了 6 个，然后点了保存。三个月后产线才发现，试产评审和物料齐套评审两个节点从来没有被触发过，一批价值两百多万的物料压在仓库里等一个不存在的会议。

追责的时候没人说得清这是谁的错。模板没有锁，权限是”项目成员可编辑”，而创建这个模板的项目经理半年前就调岗了。工具里明明有权限设置，但没有一个人想过”模板也要权限”这件事。

这件事之后我花了两年时间，在十几家组织里从 0 到 1 搭模板体系，也复盘过二十多次模板失控事故。我越来越确信：模板权限不是 IT 配置问题，而是项目经理制度设计里最容易被漏掉的一块地基。地基没打，后面所有的模板复用、流程标准化、度量体系都会塌。

一、先说结论：模板权限是三层结构，不是三个开关

如果只让我用一句话回答”模板权限怎么做”，我会说：把模板当成一个有生命周期的产品来管，而不是当成一份文档来管。文档只需要读写权限，产品需要可见性、使用方式、治理权三层控制。

大多数人在工具里找到的模板权限，其实只有两个维度，谁能看见、谁能编辑。然后就卡住了，因为这两个开关既解释不了”为什么模板会被改坏”，也解释不了”为什么模板没人用”。

真正跑得起来的模板权限体系，是三层独立叠加的结构。这三层之间不做继承，不搞”能编辑就一定能看见”这种默认联动，必须分开设计。

这三层里，最容易被忽略、也最值钱的是中间那层”使用方式权限”。我复盘过的模板事故里，将近四成不是因为有人不该看，而是因为有人用错了方式用。

打个比方：可见性权限是”谁能进图书馆”，治理权是”谁能改这本书”，使用方式权限是”读者能借走、能复印、还是只能在馆内翻阅”。少了第三层，图书馆很快就会变成一本被涂花的手抄本。

下面这张图是我复盘 23 次模板失控事故后的归因分布，可以看到问题到底出在哪一层。

二、为什么模板权限会成为项目经理制度设计的第一个卡点

模板权限之所以难，不是因为它技术复杂，而是因为它同时踩在三件事的交汇点上：工具能力、组织制度、人的惰性。

工具能给你的是权限位，组织能给你的是责任人，而人的惰性会持续推动所有人选择”最省事的那个用法”。模板权限设计的本质，就是让省事的路径恰好也是正确的路径。

1. 三个真实的崩坏现场

现场 A：覆盖式事故。前面提到的硬件公司就是这一类。原因是模板只有一份”主副本”，任何有编辑权的人都能就地改。半年后没人知道这份模板最初长什么样。

现场 B：模板垃圾场。一家做 SaaS 的公司，两年积累了 400 多个模板，其中 287 个创建后从未被使用过。新人打开模板列表的第一反应是关掉它，然后自己新建项目。模板体系的复用率反而比没有模板的时候更低。

现场 C：模板孤儿。一家制造业企业的核心”新产品导入模板”，所有者是一位高级项目经理。他离职后，模板还在被 60 多个项目引用，但没人有权改它，也没人敢改。三个月后，其中 8 个节点因为工艺变更已经失效，项目组只好私下建了自己的副本，公司同时存在 5 个”官方模板”的变体。

这三个现场看起来是三个问题，其实是同一件事：模板被当成了静态文档，而它实际是一个需要所有者、需要版本、需要权限梯度的活体资产。

2. 组织的三段式轨迹

我跟踪过的组织，模板体系基本都会经历三个阶段，每个阶段该做的事完全不同。用治理期的方案管混沌期，会把创新掐死；用混沌期的方案管治理期，会把组织拖垮。

绝大多数组织的翻车，都发生在扩张期。因为扩张期的痛感最强，模板开始冲突、开始被滥用，但治理成本还没显性化为一个人的工作量，于是所有人都在等别人来解决。

3. 我观察到的三条数据规律

规律一：模板数量的增长速度大约是团队人数增长速度的 1.5 到 2 倍。一个团队从 40 人涨到 80 人，模板数量往往从 12 个涨到 35 个左右。如果不做收敛，模板列表的可用性会在 50 个左右的时候断崖式下降。

规律二：模板冲突投诉的高峰出现在 60 到 120 人区间。这个区间里跨部门协作已经足够多，但专职的流程管理岗往往还没配。我见过的组织里，这个区间平均每月产生 6 到 9 次”两个模板打架”的投诉。

规律三：模板治理的最佳投入时点，比大多数人以为的早 3 到 6 个月。等到大家实在受不了了再治理，成本大概是最佳时点的 2.5 倍，因为那时候要处理的是历史数据迁移和习惯重塑。

三、五个最常见误区

下面这五个误区，我几乎在每一家刚起步做模板治理的组织里都能见到至少三个。它们不是理解错误，而是”看起来最合理”的选择。

1. 误区一：把模板权限等同于菜单权限

最普遍的一个。很多人认为给模板列表配一个”谁能进这个页面”就够了，编辑权默认给所有人。

这种配置在 20 人团队里完全没问题。但一旦超过 80 人，模板的实际损坏速度会超过它的修复速度。你以为你在做权限管理，其实你只是做了一次目录整理。

2. 误区二：一开始就追求全局统一模板

另一个极端。新上任的 PMO 负责人往往有很强的冲动，想一步到位把全公司的项目模板统一成一套。

结果通常是：研发说这套模板不适合迭代型项目，市场说它缺了投放节点，实施团队干脆绕开系统自己用 Excel。半年后，官方模板的采用率不到 30%。

统一模板的前提是流程已经收敛，而不是流程正在分化。这个顺序搞反了，模板就成了改革的替罪羊。

3. 误区三：模板所有者默认为项目经理

这个误区的伤害是延迟爆发的。项目经理做模板所有者，在项目进行中看起来很自然，他最懂业务，改起来也最方便。

问题在于项目经理的岗位流动率高，而模板的生命周期长。我统计过的一个样本里，模板所有者的平均在岗时间是 14 个月，而模板的平均被引用周期是 26 个月。所有者任期短于模板寿命，是”模板孤儿”现象的直接原因。

更合理的做法是把所有权交给一个岗位或一个虚拟组织（比如 PMO 下的流程小组），而不是交给某个人。

4. 误区四：用审批流管模板变更

这是过度治理的典型。有些组织为了严谨，把模板变更做成三级审批，改一个字段描述要走三个人。

我见过一个极端案例：一个模板加一个”风险等级”下拉选项，从提出到上线花了 19 天，业务方直接放弃了这个需求，转而在线下维护自己的版本表。

审批流适合管”发布”，不适合管”修改”。正确的结构是：编辑不审批，发布才审批，而且审批只审版本号与影响范围，不审具体内容。

5. 误区五：只管”能不能用”，不管”改不改得动”

这个误区最隐蔽。很多团队做到了可见性和编辑权分离，但忽略了另一件事：用户在套用模板之后，能不能改结构。

如果不能改，”灵活”和”规范”就会打架，用户会选择不用模板；如果能无限制改，模板就退化成一个起点而没有约束力。

这里的关键是区分结构层和实例层：结构层（阶段、里程碑、必填字段、审批节点）由模板锁定，实例层（任务名称、负责人、日期、备注）允许完全自由编辑。这条线划在哪里，直接决定模板体系的实际价值。

四、专业判断逻辑：先分类，再定权

讲完误区，说我的方法论。整套逻辑只有四步，顺序不能换：先分类，再定权限位，再把版本机制绑进去，最后用指标复盘。

1. 第一步：按”使用频次 × 变异度”给模板分四类

不是所有模板都值得同等治理。我用的分类维度是两个：这个模板被使用的频次有多高，以及它在不同项目之间的合理变异程度有多大。

这两个维度交叉出四个象限，每个象限的权限策略完全不同。

这个分类最大的价值不是分类本身，而是它帮你砍掉了一批不该被管的东西。第四象限的模板如果硬要管，只会拉高整体治理成本，却没有人真正受益。

2. 第二步：设计五种权限位

分类完成后，我用五种权限位覆盖绝大多数场景。不要设计更多，权限位一多，配置和维护成本会指数级上升。

1. 可见：能在模板列表中看到这个模板，但看不到内部结构。
2. 可参考：能看到完整结构和字段，但不能用它创建项目。
3. 可套用：能一键用它创建项目，创建出来的项目与原模板保持弱关联。
4. 可派生：能复制出一份属于自己的副本并自由修改，原模板不受影响，副本会记录来源。
5. 可治理：能修改模板本体、发布新版本、归档旧版本。

这五级的关键设计在于“可派生”和”可套用”是分开的。这一条分割线解决了我见过的最多一类冲突：业务方需要灵活性，PMO 需要一致性。

派生制让业务方拿到了灵活性，同时因为派生版本会记录来源，PMO 可以定期看到”哪些模板被派生得最多”，从而判断是该放宽还是该修正原模板。这是一个自带反馈信号的机制。

# 模板权限配置示意（伪代码，用于说明结构，不代表任何具体工具的原生格式）
template: 硬件量产导入模板

classification: 高频 · 低变异

visibility:

scope: [研发中心, 供应链中心, 质量中心]

exclude: [实习岗, 外包岗]

usage:

default: apply_only # 默认可套用，不可派生

derive_allowed: [项目经理, PMO]

direct_edit_instance: true # 实例层字段可自由修改

direct_edit_structure: false # 结构层字段锁定

governance:

editor: [PMO-流程管理员]

approver: [研发VP, 质量总监]

versioning: auto_semver

freeze_on_publish: true

rollback_window: 90d

review_cycle: quarterly

这段配置里最值钱的两行是 direct_edit_instance 和 direct_edit_structure。把实例和结构的编辑权分开，是整个模板权限体系里杠杆率最高的一个设计。

3. 第三步：把版本和冻结机制绑进权限里

权限如果不和版本绑定，就会出现一个很尴尬的情况：用户有权编辑，但不知道自己的编辑会不会影响正在跑的项目。

我的做法是三条规则：

• 发布即冻结：模板一旦被标记为”已发布”，结构层字段不可就地修改，任何调整都必须生成新版本。
• 版本不追溯：新版本只对之后创建的项目生效，已有项目不会自动升级。这条规则保护的是正在跑的项目。
• 支持显式升级：允许在项目内主动选择”升级到最新模板”，但必须记录操作人和影响范围。

这三条规则合起来，把”模板变更”从一个危险动作变成了一个可审计动作。绝大多数模板事故，本质上都是因为变更不可审计。

4. 第四步：用三个指标复盘模板体系的健康度

权限配完不是结束。我建议每季度看三个数，它们能提前暴露问题。

复用率不是越高越好。如果它长期高于 85%，通常意味着你的模板体系过于刚性，正在强迫不相干的项目套用同一套流程，这种”虚假繁荣”会在半年后以项目灵活度下降的形式反噬。

五、案例：一家 300 人研发组织 90 天的模板治理

下面这个案例是我全程参与的一次落地，组织规模从 260 人增长到 310 人，横跨研发、测试、运维和两个业务线。我把它完整拆开，因为里面的失败和修正比成功更有参考价值。

1. 起点：模板比项目还多

接手时的情况：系统里有 187 个模板，其中 121 个在最近 90 天内没有任何引用记录。最活跃的一位项目经理个人名下建了 23 个模板，其中有 8 个名字只差一个字。

更麻烦的是权限状态：所有模板的编辑权对全员开放，没有任何模板有明确所有者，也没有版本概念。曾经发生过一次事故，一个已上线项目的验收清单被人在模板里删了两项，导致后续 14 个项目全部漏掉了这两项检查。

2. 第一版方案为什么两周就崩了

我们第一版方案很”标准”：把所有 187 个模板冻结，成立模板评审小组，新模板必须走评审，改动必须走审批。

两周后方案崩了。原因是评审小组一共 4 个人，全是兼职，积压了 31 个模板申请。业务线开始抱怨”改个字段要等一周”，有人重新开始用共享文档维护自己的模板表，系统里的模板反而没人动了。

复盘下来，第一版方案犯了前面提到的两个误区：一是追求全局统一，二是用审批流管修改。两个误区叠加，直接把方案的落地阻力放大到了不可承受的程度。

3. 第二版方案：冻结 + 派生 + 发布权收口

第二版我们只做了三件事，但顺序很讲究。

1. 先做减法。187 个模板里，把 90 天无引用且无明确所有者的 108 个批量归档，只保留 79 个进入治理范围。这一步没有征求太多意见，因为征求了就走不动。
2. 再切权限。79 个模板全部改为”只读套用 + 白名单派生”。结构层字段全部锁定，实例层完全放开。派生不再需要审批，但派生副本必须自动回填来源标记。
3. 最后收发布权。模板本体的编辑权只保留给 6 个人（每个业务域 1 到 2 个），发布新版本需要 1 位业务负责人确认，审批只审影响范围和版本号。

这套方案的关键变化是：业务方要的灵活性通过派生拿到了，PMO 要的一致性通过锁定本体拿到了，两边不再争夺同一个开关。

技术上，这次落地是在 PingCode 上完成的。选它的直接原因是模板的派生关系可以追溯，而且结构层和实例层的字段权限是分开配置的，正好对上我们需要的那个切分点。

4. 90 天后的四个数据

治理前和治理后第 90 天，我们采集了四个指标。数据来自系统后台的模板引用记录和项目创建日志，属于内部可复核口径。

值得注意的是第三项。新建项目准备耗时下降的主要原因不是模板变快了，而是用户不再需要花时间比较”该用哪个模板”。模板数量从 187 降到 79，选择成本下降的幅度超过了所有人的预期。

5. 私有化部署与迁移过程中的权限坑

这个案例还有一段值得单独说的经历：因为涉及研发数据的合规要求，这家公司最终选择的是私有化部署，并且是从原有的项目管理平台做数据迁移过来的。

私有化部署对模板权限有两个额外要求，是公有云环境下不太会遇到的。

第一是权限模型要和内部组织架构系统对齐。人员调岗后，模板的可见范围必须跟着变。如果权限是手工维护的，人事一变，模板权限就会错位。我们用组织架构同步解决了这个问题，但上线初期还是出现过两次”离职人员的模板可见性没回收”的情况。

第二是历史数据的权限映射。从旧平台迁移时，最容易出错的就是模板的归属和可见范围。旧平台如果只有”公开/私有”两档，迁移到多档权限体系里就需要设计映射规则，我们当时定的是：公开模板全部转为”可套用”，私有模板转为”仅所有者可派生”，并保留 30 天双轨期让用户自行调整。

这类迁移在工作量上往往被低估。我的经验值是：数据迁移的工作量里，模板和权限相关的部分大约占 25% 到 35%，而且是唯一不能靠脚本一次性跑完的部分。它需要人工确认归属，尤其是那些所有者已经离职的历史模板。

选择具备私有化部署能力和成熟迁移路径的平台，会显著降低这部分成本。PingCode 在这方面的优势是支持的部署形态比较完整，同时对从 Jira 这类主流平台迁移有相对成熟的映射方案，对有存量数据和合规要求的组织来说，这也是很多中大型团队在做国产替代时优先评估它的原因。

六、行动建议：按组织规模分四档

下面这张表是我给不同规模组织的起步配置建议。它的作用不是让你照抄，而是让你知道自己现在该做什么、以及暂时不该做什么。

1. 30 人以下：别做权限，做收敛

这个阶段做复杂权限基本是负收益。团队小、沟通成本低，出问题了当面说一句就能改。

唯一要做的是控制模板数量。每个团队保留 5 到 8 个模板，超过就合并或归档。这个动作花的时间极少，但能避免两年后背上一个 400 模板的烂摊子。

2. 30 到 100 人：引入所有者和派生制

这个阶段该做的两件事：给每个模板指定一个所有者（可以是岗位），以及把默认使用方式从”直接套用”改成”复制派生”。

只改这一个默认值，通常就能把模板被改坏的概率降低一半以上。因为派生制把”修改”这个动作从破坏性的变成了非破坏性的。

3. 100 到 500 人：分层治理 + 发布权收口

这个阶段是模板治理的主战场。核心动作是分层：集团层保留少量强管控模板（立项、结项、合规），业务域层保留各自的专业模板。

发布权必须从个人收口到角色。这里特别提醒：所有者要绑岗位而不是绑人。绑人的话，人员一变动，模板权限就会跟着出问题。

4. 500 人以上：治理机制化，不靠人盯

这个规模下靠人工维护模板权限是不现实的。必须做到三件事：权限和组织架构系统自动同步、模板健康度指标自动产出、孤儿模板自动预警。

同时建议设立一个轻量的模板复审节奏，季度复审即可。复审的产出不是”改模板”，而是”决定哪些模板该退役”。在这个规模下，退役机制比审批机制重要得多。

七、取舍：三组你必须提前认下的代价

模板权限没有”全都好”的方案。每一组选择都在放弃另一样东西，提前认下这些代价，比事后才发现要好得多。

1. 灵活性 vs 一致性

你选择的一致性越高，业务方绕开系统的概率越大。这是一个几乎无法消除的张力，只能通过机制设计来平衡。

派生制是目前我看到的最有效的平衡手段，但它也有代价：派生副本多了之后，你实际上会面临”有多少个变体在跑”的问题。我的做法是给派生副本设置数量预警，一旦某个模板的派生超过 8 个，就触发一次原模板的复审。

2. 治理成本 vs 模板质量

模板质量和治理成本不是线性关系。从 0 分做到 70 分，成本很低；从 70 分做到 90 分，成本会陡增。

我的判断是：大多数组织应该在 70 分停住，把剩下的精力放到模板的实际使用上。追求 90 分的模板治理，通常只在一件事上成立，这个组织的模板承载合规或审计要求。

3. 集中管控 vs 业务自主

这条取舍在执行层面最敏感。集中管控让标准统一，但也让模板对业务变化的响应变慢。

我的建议是按模板分类来决定，而不是一刀切：高频低变异的模板集中管控，高频高变异的模板下放业务域。这样做的结果是，PMO 管的东西变少了，但每一件都管得更实。

八、从 0 到 1 的 30 天落地清单

最后给一份可以直接照着做的 30 天清单。这是我用过三次的版本，节奏是经过验证的，每一周都有明确产出，不会出现”干了两周看不到东西”的情况。

1. 第 1 周：盘点与减法

1. 导出全部模板清单，标注三个字段：最近 90 天引用次数、是否有明确所有者、是否被正在运行的项目引用。
2. 把”无引用 + 无所有者 + 无在用项目”的模板批量归档。这一步不要征求意见，征求意见会让它永远做不完。
3. 剩下的模板按”使用频次 × 变异度”做四象限分类，画出第一版分布图。

2. 第 2 周：定权限位与责任人

1. 确定五种权限位在本组织内的具体命名，尽量和工具现有的权限档位对齐，不要强行自造概念。
2. 为每个保留的模板指定所有者，所有者绑定岗位而非个人。
3. 把默认使用方式统一切换为”派生”，只对白名单角色开放”直接套用”。

3. 第 3 周：结构层与实例层切分

1. 逐个检查高频模板，把字段分成结构层和实例层两批。
2. 结构层字段设为锁定，实例层字段放开编辑权限。
3. 对已发布模板启用”发布即冻结”，并告知用户变更需要走新版本。

4. 第 4 周：发布、度量与第一次复盘

1. 发布新的模板使用说明，重点解释”为什么不能就地改了”，而不是只讲”不能改”。
2. 建立复用率、派生集中度、孤儿模板占比三个指标，接入周报或看板。
3. 做第一次复盘，只看一个问题：哪一类模板的派生量明显异常，说明原模板需要调整。

九、写在最后：模板权限的本质是责任分配

回到最初的问题：模板权限怎么做。我做了这么多轮之后，最想说的一句话是，模板权限表面上是技术配置，实际上是一次责任分配的公开声明。

谁能看，谁在用，谁负责。这三个问题回答清楚了，工具里怎么配只是执行细节。反过来，如果这三个问题没回答清楚，工具配得再精细，也会在半年内退化成一堆无人维护的僵尸模板。

我还要强调一点我自己的观察：模板治理失败的绝大多数原因，不是管得太松，而是管得太早、太严、太全面。在我复盘过的失败案例里，因为”管太松”出问题的占三成，因为”管太严导致业务绕开系统”的占了将近五成。

所以如果你现在正准备做这件事，我的下一步建议是这样：

• 如果你在 50 人以下，这周只做一件事，把模板数量砍到 10 个以内，其他什么都不用做。
• 如果你在 50 到 150 人之间，先给每个模板找一个所有者，然后把默认使用方式改成”派生”，两周后再看数据。
• 如果你在 150 人以上，先算一下你的模板复用率和孤儿模板占比，这两个数会告诉你现在该做减法还是该做治理。
• 如果你正在做平台选型或迁移，务必把”结构层与实例层的字段权限是否可分”作为一条硬性评估项。这一条做不到，后面所有的模板治理方案都会走形。

模板体系不会因为你设计得完美而成功，只会因为你把责任分对了而活下来。