项目模板模板阶段全流程：管理层制度设计与一文讲清

项目模板模板阶段全流程：管理层制度设计与一文讲清

去年 11 月，我帮一家 800 人规模的软硬件混合型公司做研发流程诊断。他们内部平台上挂着 63 个项目模板，从“新产品导入”到“客户定制交付”一应俱全，命名规范、目录整齐。我随机拉了 6 个月的引用数据：63 个模板里有 41 个从未被任何项目引用过，真正被 3 个以上项目复用的只有 7 个。

更麻烦的不是数量，而是这 7 个“活着的”模板里，没有一个把阶段划分和公司现行的立项、评审、验收制度对齐。项目按模板跑完了，制度要求的评审记录还得另外补一遍，验收资料还得从邮件里翻。模板和管理制度成了两套并行的东西。

这篇文章要讲清楚的，就是这件事：项目模板的价值从来不在“任务清单有多全”，而在“阶段是否成为管理制度的执行载体”。我会按“核心结论，真实场景，常见误区，判断逻辑，落地方法，制度设计，工具承载，数据验证，行动建议，取舍”的顺序，把我这些年踩过的坑和验证过的方法一次讲完。

一、先给结论：模板不是文档，是制度的执行副本

在展开之前，我先把三个结论摆出来。如果你只读三句话，读这三句就够了。后面的所有内容，都是在解释这三句话为什么成立、以及怎么落地。

1. 项目模板的最小治理单元是“阶段”，不是“任务”

很多团队做模板时的第一反应是列任务：需求评审、写方案、开发、测试、上线。这是任务视角。管理层的视角应该是阶段视角，因为制度是按阶段挂钩的，不是按任务挂钩的。

立项制度挂在启动阶段，预算和资源制度挂在规划阶段，质量与验证制度挂在测试阶段，验收与结项制度挂在收尾阶段。如果模板里只有任务没有阶段，制度就找不到挂载点，只能靠人在流程外补记录。

任务可以被裁剪，阶段不可以。一个 8 人的小项目可以把“详细设计”拆成三个任务，但它不能取消“设计评审”这个阶段，因为取消之后，质量制度就失效了。

2. 管理层真正要管的是“门禁”，不是“任务清单”

管理层不需要知道每个任务叫什么名字，那是项目经理的事。管理层需要回答的是四个问题：这个项目现在能不能进入下一阶段？谁有权批准？批准的依据是什么？没通过会怎样？

这四个问题定义了门禁（Gate）。一个只有任务清单的模板，管理层几乎用不上；一个带门禁定义的模板，管理层每周都在用，因为它直接决定资源能不能放行、预算能不能释放、人能不能进场。

我判断一个模板是否“管理层可用”，标准非常粗暴：把模板打印出来，交给一位不做项目的副总，他能不能在 5 分钟内说清楚“现在卡在哪、谁能放行”。说不清，就说明这个模板只是执行层的工具。

3. 模板必须能被制度“引用”，否则一定会退化

我见过太多这种情况：模板文件放在共享盘里，制度文件放在 OA 里，两者互不引用。半年后制度改了模板没改，或者模板改了制度不知道。用户的应对方式是先看一眼模板，再回去查制度，发现对不上，最后凭经验干活。

判断标准很简单：制度文件里能不能找到一句“本项目阶段划分参照《XX 模板 V3.2》第 4 章”？找不到，这个模板的生命周期通常不超过 6 个月。

4. 四种模板形态，以及它们的适用边界

把市面上的项目模板拆开看，本质上是四种形态。形态不是越高越好，而是要和你的组织规模、合规压力、管理层介入深度匹配。用错形态，比不用模板更糟。

二、为什么大多数模板在三个月内失效

结论说完，讲背景。我跟踪过 9 家不同规模企业的模板库，从上线到“基本没人用”，平均只用了 3.4 个月。失效过程高度相似，基本是三个场景轮流上演。

1. 场景一：模板库像图书馆，项目像借书不还的人

典型表现是模板越建越多。业务部门提需求：“我们是定制项目，跟标准产品不一样，要单独建一个。”于是模板库从 8 个膨胀到 40 个。半年后没人说得清哪个模板对应哪类项目。

我在一家 1200 人的企业里做过统计：模板数量从 12 个增长到 47 个的过程中，实际被引用的模板数量始终在 6-9 个之间。也就是说，新增的 35 个模板并没有被使用，它们只是把选择成本推高了。

2. 场景二：模板很漂亮，但没有人对它的准确性负责

模板通常是某次流程优化的副产品：项目结束后，PMO 把项目计划整理一下，存成“标准模板”。问题在于，模板没有 Owner。

Owner 缺失会导致两个后果。一是模板和现实脱节，比如公司已经取消了某个评审会，模板里还挂着，新人照着做，白开三次会。二是出了问题没人改，大家绕着走，模板逐渐变成一个装饰品。

3. 场景三：换工具时模板全部推倒重来

这是最贵的一种失效。模板以文件形式存在（Excel、Visio、Word），与工具平台没有结构化绑定。一旦换平台，所有模板需要人工重建，阶段名、交付物、责任人字段全部重新录入。

我参与过一次平台迁移，客户在旧系统里有 26 个活跃模板、约 1400 个工作项。人工重建花了 5 个人 3 周，而迁移过程中产生的不一致，用了将近一个季度才清理干净。

4. 数据观察：模板活跃使用率的衰减曲线

我把三种约束条件下的模板活跃使用率（被至少一个进行中项目引用的模板占比）做了对比。数据来自 6 家企业的内部统计口径，样本不大，但趋势非常一致。

三、拆解七个最常见误区

下面七个误区，是我在诊断中遇到频率最高的。每一个我都标注了“表面看起来对在哪里”，因为误区之所以流行，往往是因为它在某个局部是成立的。

1. 误区一：把模板当成“任务清单的复制粘贴”

表面合理之处：任务清单确实能帮新人快速上手，减少遗漏。问题在于，任务清单没有准入和退出标准。项目做到一半发现前置条件不具备，只能返工。

2. 误区二：用“项目类型”分类，而不用“阶段模型”分类

表面合理之处：按产品线、按客户类型分类，符合业务直觉。但它会导致模板数量爆炸，因为分类维度是二维甚至三维的。正确做法是用有限几套阶段模型覆盖全部项目，用参数区分差异。

3. 误区三：阶段数量越多，显得越专业

表面合理之处：阶段多意味着管理精细。实际上，阶段超过 9 个之后，交付节奏会被会议和评审切碎。我见过一家企业把阶段拆到 14 个，结果是每个阶段平均持续 3 天，评审会排满一周，项目经理大量时间花在准备评审材料上。

4. 误区四：门禁等同于审批流

表面合理之处：审批流确实有卡点作用。但审批流管的是“谁签字”，门禁管的是“条件是否满足”。没有交付物清单的审批，本质是人情签字。

5. 误区五：把模板所有权交给 PMO 一个人

表面合理之处：集中管理便于统一。实际上，PMO 单点所有会导致两个问题：业务侧不认账（“那是 PMO 的模板，不是我们的”），以及变更响应慢。合理做法是“PMO 持有基线，业务侧持有变体”。

6. 误区六：模板只定义“做什么”，不定义“交付物长什么样”

表面合理之处：交付物标准属于质量体系，不属于项目管理。但恰恰是这条边界，造成了最大的返工来源。项目经理认为“我交了一份方案”，评审方认为“这份方案不合格”，来回两轮就是一周。

7. 误区七：上线即交付，没有生命周期管理

表面合理之处：模板是文档，定稿就完事了。实际上模板有明确的生命周期：草稿、试点、发布、冻结、废弃。没有生命周期的模板，最终都会变成无法清理的历史包袱。

我把这七类误区对应的返工成本做了一次量化。口径是“单个中型项目（6-9 个月周期）因该问题产生的额外人天”，数据来自我对 14 个项目的回溯估算。

四、专业判断逻辑：阶段优先于任务

讲完误区，讲我的判断逻辑。这部分是我认为整篇文章最“不可替代”的地方，因为它决定后面所有落地动作的方向。

1. 阶段定义的五个必填要素

一个合格的项目阶段定义，必须同时回答五个问题。缺任何一个，这个阶段在执行时都会变成“走形式”。

• 准入条件：进入这个阶段之前，哪些事必须已完成？谁来确认？
• 交付物：这个阶段必须产出什么？格式、模板、评审级别是什么？
• 评审方式：谁评审、评审形式（会议/异步/自动校验）、通过标准是什么？
• 角色与职责：谁负责、谁批准、谁知情、谁被咨询（RACI 的四个角色必须写清）
• 退出标准：满足什么条件才算结束？未满足时是阻塞还是带风险放行？

我用一个“四问法”快速检验阶段定义是否合格：交付物能不能被第三方验收？准入条件能不能被客观判断？评审结论能不能被记录？退出标准是二值的还是模糊的？四个问题有一个答不上来，这个阶段在系统里就只是一个标签。

2. 阶段、里程碑、门径、迭代，四个词不要混用

这四个词在企业里经常被混着用，导致模板结构混乱。我建议用下面这个口径固化下来，写进制度。

为什么要区分得这么细？因为不同概念对应不同的管理制度。阶段对应资源制度，里程碑对应汇报制度，门径对应质量与风险制度，迭代对应产能与排期制度。混在一起，制度就没法精确挂载。

3. 模板的三层结构：组织级基线 / 事业部变体 / 项目实例

我强烈建议模板采用三层结构，这是解决“模板爆炸”的关键设计。

• 组织级基线：全公司统一的阶段模型和门禁，通常只有 2-3 套，由 PMO 持有并版本化。
• 事业部变体：在基线基础上调整交付物清单、评审级别、角色名称，不做结构性改变。由事业部流程负责人持有。
• 项目实例：从变体生成，项目结束时归档，不允许反过来修改上层模板。

关键约束是：变体可以增加交付物，不能减少门禁。如果某个事业部确实需要减少门禁，走制度变更流程，而不是在模板层面偷偷删掉。这条规则如果不写死，三层结构会在一年内退化成 40 个互不相干的模板。

4. 阶段门径的实际通过率长什么样

我整理了 5 家企业的门径通过数据，合并成一个漏斗。这张图最有价值的地方不是通过率本身，而是让你看清损失发生在哪一环。

五、阶段全流程的七步落地法

逻辑讲完，进入操作层。我把一个完整的阶段模板落地拆成七步，每一步我都写了输入、动作、输出、责任人和验收标准。这套方法我在 4 家企业完整跑过，最快的一次用了 9 周。

1. 第一步：制度盘点与模板审计

输入是现行的全部管理制度文件和现有模板库。动作是逐一比对：制度里提到了哪些阶段、哪些评审、哪些交付物？现有模板里有没有对应元素？两边对不上的地方，就是后续工作的重点。

• 输出：制度，模板对照清单，标注缺口项。
• 责任人：PMO + 质量负责人。
• 验收标准：缺口项数量明确，且每一项都能追溯到具体制度条款。

这一步我踩过的坑是：只盘点了“有文件的制度”，忽略了大量口头制度。比如某公司的“重大变更必须老板点头”，没有任何文件，但实际阻塞了 30% 的项目。盘点时一定要访谈 3-5 位项目经理，把口头制度挖出来。

2. 第二步：抽取阶段模型

不要按部门抽，要按项目形态抽。我的做法是把过去 12 个月完成的项目按“交付物类型 + 不确定性程度”聚类，通常能收敛到 2-3 类。每类定义一套阶段模型。

阶段数量我建议控制在 5-7 个。低于 4 个，门禁没有挂载点；高于 9 个，节奏被切碎。5-7 是最容易执行的区间。

3. 第三步：定义交付物标准（这是最容易被跳过的一步）

每个阶段列出 1-3 个核心交付物，并为每个交付物写清“合格的定义”。不要写“完整的方案”，要写“包含范围、成本、进度、风险四部分，且风险部分至少列出 3 项并有应对措施”。

同时给出交付物的检查清单（Checklist），让评审人能逐项打勾。评审的可重复性，来自检查清单，而不是评审人的经验。

4. 第四步：设计门禁与放行规则

门禁有三条规则必须写清楚：通过条件、放行方式、未通过的处理。

1. 通过条件：交付物齐备 + 检查清单通过率达标 + 关键角色签字。
2. 放行方式：分无条件放行、带风险放行（需记录风险与缓解措施）、阻塞。
3. 未通过处理：明确是可以带风险进入下一阶段，还是必须原地整改，以及整改期限。

我见过最实用的设计是“带风险放行”机制。它给了业务灵活性，同时把风险显性化。前提是必须记录，并且在下一次门禁时复盘。

5. 第五步：模板固化与版本化

这一步的核心是把模板从文档形态转成结构化配置。阶段、交付物、门禁规则、角色，都应该是系统里的对象，而不是 Word 里的段落。只有这样，模板才能被引用、被统计、被迁移。

6. 第六步：试点与校准

选 2-3 个不同类型的项目试点，周期至少覆盖两个门禁。试点期间必须记录三件事：门禁卡了多久、哪些交付物反复被退回、哪些阶段被合并执行。

试点的目标不是验证模板“对不对”，而是找出模板“哪里过重”。根据我的经验，首次试点的阶段数通常可以减少 1 个，检查清单可以精简 20% 左右。

7. 第七步：治理与季度复审

发布不是终点。我建议固定季度复审：看三个数据，模板复用率、门禁一次通过率、交付物齐备率。任何一个指标连续两个季度下降，就触发模板修订。

下面这张图是我对七步法投入产出的量化估算。口径是“1000 人规模企业，覆盖约 60 个在跑项目”，回收人天按投产后 12 个月累计计算。

六、管理层制度设计：把模板写进制度，而不是写进文档

前面讲的是“怎么把模板做对”，这一节讲“怎么让模板活下去”。我的核心观点是：模板需要制度授权，才能获得执行力。没有制度背书的模板，只是建议。

1. 五类必须写进制度的条款

不是所有内容都值得写进制度。写太多，制度没人看；写太少，模板没有约束力。我建议只写五类。

• 强制性条款：哪些项目必须使用哪套阶段模型，不使用的后果是什么。
• 门禁授权条款：谁有权放行，放行决定的责任边界在哪。
• 交付物条款：关键交付物的最低标准，以及谁负责验收。
• 变更条款：模板修改的申请、评审、发布流程，以及生效时间。
• 度量条款：哪些数据必须记录，用于什么管理决策。

特别提醒：变更条款往往是最容易被忽略、也最容易致命的一条。没有变更条款，模板要么冻结成僵尸，要么被随意改动导致版本混乱。

2. 模板变更的审批链路

我推荐用“申请人，影响面评估，流程负责人，PMO 归档”的四段链路，并在系统里用结构化数据记录。下面是一个我实际用过的变更申请结构示例。

{
"change_id": "TPL-2024-031",

"template": "标准产品研发阶段模板",

"current_version": "V3.2",

"target_version": "V3.3",

"change_type": "deliverable_update",

"changed_items": [

{

"stage": "方案设计",

"element": "交付物清单",

"action": "add",

"item": "技术可行性评估报告",

"reason": "质量制度 QA-07 条款要求"

}

],

"impact_assessment": {

"affected_running_projects": 14,

"estimated_extra_effort_hours": 56,

"backward_compatible": true

},

"approvers": ["事业部流程负责人", "PMO 模板 Owner", "质量负责人"],

"effective_date": "2024-07-01",

"policy_reference": "QA-07 §3.2"

}

这个结构里最关键的两个字段是 affected_running_projects 和 policy_reference。前者决定这个变更要不要走高层评审，后者决定这个变更是否“有法可依”。没有 policy_reference 的变更，一律退回。

3. 制度条款与模板元素的映射表

这张映射表是审计时最有用的东西。它回答了“制度要求的每一项，在模板里落在哪里”。我做审计时，第一件事就是要这张表。

4. 谁拥有模板：三种治理模式的取舍

模板所有权是个组织问题，不是技术问题。我见过三种模式，各有明确的适用条件。

• PMO 集中所有：一致性最好，但响应最慢，适合强合规、变化慢的行业。
• 业务侧分散所有：响应快、贴合实际，但容易碎片化，适合业务差异极大的组织。
• PMO 持有基线 + 业务持有变体：折中方案，也是我最推荐的。前提是必须写死“变体不可删减门禁”。

下面这张雷达图是我对三家不同治理水平企业的评估结果，可以直接当作自评工具的参照。

七、工具承载：阶段模板如何在平台上变成可执行配置

制度写完，必须落到工具上。否则门禁就是一张纸，靠人记。这一节我以 PingCode 为例讲平台能力，因为它在阶段模板的结构化承载上做得比较完整，且支持私有化部署和从 Jira 平滑迁移，对中大型企业和国产替代场景比较友好。

1. 平台需要具备的六项能力

选平台时，我建议按下面六项能力逐条验证，不要只看功能列表。

1. 阶段可配置：阶段能独立定义，而不是写死在状态流转里。
2. 交付物可挂载：每个阶段能绑定必须提交的交付物类型，并能做齐备性校验。
3. 门禁可自动触发：条件不满足时自动阻塞流转，而不是弹一个提醒。
4. 角色与权限可映射：制度里的角色能对应到系统权限，签字有痕迹。
5. 模板可版本化：模板有版本号，历史项目能追溯到当时使用的版本。
6. 数据可度量：交付物齐备率、门禁一次通过率等指标能直接出报表。

这六项里，第三项和第五项是最容易被忽略、也最能区分平台能力的。很多工具能配阶段，但门禁是“软提醒”，模板也没有版本概念，一旦制度审计，就说不清某个项目当时按什么标准执行的。

2. 在 PingCode 上把阶段模板落成可执行配置

我的实践路径大致是这样：先用工作项类型和状态流承载阶段，再用工作项属性承载交付物清单，最后用自动化规则实现门禁。

• 阶段 → 独立的工作项类型或状态分组，保证阶段在报表里可以单独统计。
• 交付物 → 子工作项或附件必填项，配合检查清单实现齐备性校验。
• 门禁 → 自动化规则：当交付物未齐备或检查清单未达标时，禁止状态流转到下一阶段。
• 角色 → 项目角色与权限组映射，审批记录留痕，满足审计追溯。
• 模板 → 项目模板固化上述配置，新建项目时一键生成，并记录模板版本。

PingCode 支持私有化部署，这一点在金融、制造、政企类客户里比较关键。我参与过的一个制造企业项目，要求全部研发数据不出内网，私有化部署直接解决了合规前提，阶段模板的配置和门禁规则都在内网完成，没有额外改造。

3. 从旧工具迁移模板时的三个映射要点

迁移是模板治理最容易翻车的环节。我总结了三个必须提前处理的映射问题，尤其是从 Jira 这类工具迁移时。

• 状态到阶段的映射：旧系统的状态往往是细粒度的（如“待评审”“评审中”“评审通过”），需要合并成阶段，而不是一对一搬过去。
• 自定义字段到交付物的映射：旧系统里散落的字段（如“方案文档链接”）应统一收敛为交付物对象，否则迁移后仍然是散点。
• 工作流规则到门禁的映射：旧系统的工作流条件往往嵌在脚本里，迁移时要重新表达为可读的门禁规则，否则后续没人维护。

PingCode 提供 Jira 平滑迁移能力，我在实际项目中用到的路径是先把旧状态导出、做一次人工聚类，再映射到目标阶段模型。这一步千万别跳过人工聚类，自动化一对一映射看着省事，但会把旧系统的历史包袱完整继承过来。

4. 平台落地前后的效率对比

下面这组数据来自一个 600 人规模客户的真实统计，口径是“模板相关操作的平均耗时”。柱状是耗时（小时），折线是门禁自动拦截率。

八、12 个月数据观察：这套方法到底带来了什么变化

方法讲完，必须给数据。否则就是空谈。下面是一家 1000 人规模企业的 12 个月跟踪数据，我按季度汇总，覆盖约 60 个在跑项目。这套模板体系是在第一季度末完成上线的。

四个指标的趋势高度一致：Q2 是试点期，改善有限；Q3 是推广期，改善最陡；Q4 进入稳态，改善放缓但仍在继续。这个节奏很重要，它告诉你不要期待上线后一个月见效。

值得单独说的是“缺陷逃逸率”从 14% 降到 5%。这个改善并不是测试做得更好了，而是因为交付物齐备率提升后，方案阶段的遗漏被前置发现了。也就是说，缺陷逃逸率的下降是阶段门禁的副产品，不是质量活动的直接成果。

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

方法不能一刀切。这一节我按组织规模和约束条件给建议，你可以直接对号入座。

1. 按组织规模

• 100 人以下：不要做治理型模板。用 3-4 个阶段、一套模板覆盖全部项目，门禁只保留“方案评审”和“验收”两个。重点是让模板被用起来，而不是被设计完整。
• 100-500 人：这是门径型模板的最佳区间。建 2 套阶段模型，5-6 个阶段，门禁 3 个，配一个专职 Owner（可以是兼职但必须有明确责任人）。
• 500-2000 人：需要三层结构（基线 + 变体 + 实例），并且必须上平台承载。此时模板数量应控制在 10 个以内，变体控制在 6 个以内。
• 2000 人以上：模板治理要嵌入审计与合规体系，度量指标必须进入管理层看板。同时要警惕阶段数量膨胀，强制上限 9 个。

2. 按行业与合规压力

强合规行业（医疗器械、汽车电子、金融核心系统）适合治理型模板，交付物标准要细，检查清单要能作为审计证据。我建议这类企业在每个交付物上标注对应的法规条款号，审计时可以一键追溯。

互联网与消费类产品适合门径型模板，重点在门禁而不在文档量。这类企业最容易犯的错是把交付物标准定得过重，导致团队绕过流程。我的经验是：交付物标准控制在“一页纸能写完”的程度，执行率会明显更高。

3. 按现有工具成熟度

• 已有平台且支持阶段配置：优先做制度映射，再优化配置，不要先动工具。
• 已有平台但不支持门禁自动化：先补制度，同时评估迁移到 PingCode 这类支持私有化部署与门禁自动化的平台，尤其是需要国产替代的场景。
• 没有平台，用表格管理：先做阶段模型和交付物标准，工具可以后置，但要以结构化字段设计表格，为后续迁移留路。

十、不同情况下的取舍

所有方法论最后都会落到取舍上。这一节我把四个最难的选择摆出来，给出我的判断依据。

1. 取舍一：模板颗粒度 vs 执行灵活度

颗粒度越细，一致性越高，但灵活度越低，团队越容易绕过。我的判断依据是“变更频率”：如果某类项目的范围和交付物在项目中期经常变化，颗粒度就要放粗；如果变化很少，可以放细。

经验值是：阶段数控制在 5-7 个时，落地成功率最高。低于 4 个，门禁没抓手；高于 9 个，节奏被切碎，团队开始找变通方式。

2. 取舍二：强门禁 vs 交付速度

强门禁能拦风险，但也会拖慢交付。我的做法是引入“带风险放行”：允许在特定条件下带风险进入下一阶段，但必须记录风险、指定缓解责任人和复盘时间。关键不是能不能放行，而是放行有没有痕迹。

这个机制在实操中非常有用。它让管理层有台阶下，也让团队不至于因为一个次要交付物卡住整条线。

3. 取舍三：统一 vs 自治

统一意味着一致性，自治意味着贴合业务。我的建议是“统一阶段结构和门禁，自治交付物细节”。阶段和门禁是管理层的权力，交付物细节是业务侧的专业判断。这条边界划清楚，争议会减少一大半。

4. 取舍四：自建配置 vs 采购平台

自建的好处是完全贴合，坏处是维护成本和迁移风险。采购平台的好处是能力现成，坏处是可能需要调整流程去适配工具。我的判断标准是：如果你的模板体系在未来两年内会大改，优先采购；如果已经非常稳定，可以考虑自建。

对于中大型企业和有国产替代需求的组织，我倾向于采购支持私有化部署的平台，比如 PingCode 这类，原因是模板治理不是一次性投入，长期的版本管理、报表度量、迁移兼容性都需要持续支撑，自建很容易在第一年之后失去动力。

十一、总结与下一步

回到开头那个案例。那家 800 人企业的核心问题，不是模板不够多，而是模板和管理制度是两套东西。63 个模板、41 个从未被引用，本质上是“模板选型成本”超过了“模板带来的收益”。

我的独特判断可以浓缩成一句话：项目模板不是知识资产，而是管理制度的可执行副本；它的质量不取决于内容有多全，而取决于阶段和门禁是否被制度化、被系统化。理解了这一点，你会自然地把重心从“写模板”转向“设计阶段和门禁”。

另一个容易被忽略的判断是：模板体系的收益存在明显的时间结构。交付物齐备率最先改善，缺陷逃逸率滞后一个季度，周期偏差率再滞后一个季度。如果你在第一个月就要求所有指标变好，几乎一定会失望，然后错误地推翻体系。

下面是我建议的下一步动作，分 30 天和 90 天两个阶段。

1. 未来 30 天：先把底数摸清

1. 拉出全部现有模板的引用数据，标出过去 6 个月零引用的模板。
2. 做一次制度，模板对照，列出所有“制度要求但模板未承载”的缺口。
3. 访谈 3-5 位项目经理，把口头制度写下来，补进对照表。
4. 选出 1 套最常用的项目类型，作为第一个改造对象。

2. 未来 90 天：跑通一个闭环

1. 抽取阶段模型，阶段数控制在 5-7 个，每个阶段补齐五个必填要素。
2. 为每个阶段定义 1-3 个交付物，并写出可打勾的检查清单。
3. 设计 3 个核心门禁，明确放行方式，包括带风险放行的条件。
4. 把模板结构化落到平台上，优先验证门禁自动触发的效果。
5. 选 2-3 个项目试点，记录门禁卡点时长和交付物退回次数。
6. 试点结束后做一次校准，删掉过重的检查项，然后正式发布并写清版本号。

最后提醒一句：模板治理没有终点，只有节奏。把季度复审固定下来，比一次性做到完美重要得多。我见过太多企业，在第一年做出了非常漂亮的模板体系，然后在第二年因为没人复审而悄悄退化回原点。能让模板活过 12 个月的，从来不是设计得多精巧，而是治理节奏有多稳定。