项目模板怎么做？实施团队效率提升：项目模板从0到1

去年冬天，一位做工业软件交付的朋友找我喝茶。他给我看了一组数字：团队 43 人，过去 12 个月交付了 61 个项目，人均产能看着不错。但同一组数字的另一面是，61 个项目里，有 48 个项目的启动会材料、需求调研问卷、环境部署清单、UAT 测试用例、验收报告，是实施顾问自己从零攒出来的；同一份《数据迁移核对表》，在 61 个项目里有 37 个版本。

他问我：“我们不是没有模板，是模板没人用。项目模板到底该怎么做？”这个问题我过去几年在几十家实施型团队里听过太多次。我的答案通常让他们有点意外：大多数团队的模板做不好，不是因为模板太少，而是因为把模板当成了“文档集合”，而真正的项目模板应该是一条可执行的交付流水线，它同时封装了任务结构、责任人、交付物、准入准出标准和风险检查点。

这篇内容讲的是一套从 0 到 1 建项目模板体系的方法：先讲结论，再讲我观察到的真实场景、常见误区、判断逻辑，然后给一个中大型实施团队用 PingCode 落地的完整案例和量化数据，最后给出不同规模团队的取舍建议。

一、核心结论：项目模板不是文档包，是交付流水线的封装

先把结论放在最前面，后面所有内容都是围绕这几条展开的。

结论一：模板的价值不在“内容”，而在“结构”。一份写在 Word 里的实施方法论，哪怕写了 80 页，它对效率的贡献接近于零，因为它没有跟任何人的待办事项绑定。真正提效的模板，是当你新建一个项目时，系统自动生成了 42 个任务、7 个里程碑、5 个交付物模板、3 个质量门禁，并且每个任务都有责任人和截止时间偏移量。

结论二：模板不是“一个”，而是“一层一层”。我见过最失败的模板体系，是 PMO 花了三个月做了一个“通用实施模板”，覆盖所有行业、所有规模、所有交付模式，结果没人用。合理的做法是三层结构：行业层模板（如制造业 MES、零售 CRM）、产品线层模板（标准版 / 企业版 / 私有化版）、项目层变体（大客户定制 / 快速上线 / 试点转正式）。

结论三：模板的收益不是线性的，是阶跃的。前 5 个模板带来的效率提升非常有限，甚至因为治理成本而变负；当模板覆盖了 60% 以上的重复交付场景后，收益会突然放大，因为新人可以独立带项目了，项目经理的排期从“回忆上次怎么做的”变成“调出模板改参数”。

结论四：模板必须活在系统里，不能活在网盘里。这是我判断一个团队模板体系成熟度的最快方法：打开他们的项目管理平台，新建项目时有没有“从模板创建”这个选项，以及这个选项背后生成的是文档还是任务。如果只有文档，那这套模板体系基本等于没有。

二、背景与真实场景：实施团队的效率黑洞到底在哪

要谈模板，必须先说清楚实施团队的工时到底花在哪。因为如果花错地方，模板就是无效努力。

1. 一个典型实施项目的工时分布

我把过去几年做过的工时抽样做了汇总。一个中型企业级软件实施项目，周期 10-14 周，投入 45-60 人天，工时大致分布是这样的：

• 售前与方案阶段：约 12%。这部分往往不计入交付成本，但实际消耗很大。
• 启动与计划阶段：约 15%。文档密集、协调密集，是最容易被模板影响的部分。
• 需求调研与蓝图设计：约 22%。现场访谈不可压缩，但调研后的整理、确认、评审可以标准化。
• 配置、集成与二次开发：约 28%。技术型工作，模板只能减少配置清单遗漏带来的返工。
• 测试与 UAT：约 13%。用例库复用率高低直接决定这块耗时。
• 上线、验收与交接：约 10%。几乎全是文档和流程工作，模板收益最高。

看出问题了吗？大概 50% 的工时集中在“流程与文档驱动”的环节，而这些环节的内容在不同项目之间重复度极高。技术开发那 28% 反而因人而异、因客户而异，模板能帮的忙有限。

但大多数团队的模板建设顺序是反的：他们先去标准化技术方案，而把启动、验收这些“看起来不重要”的环节留给顾问自己发挥。结果就是每个顾问都有一套自己的启动会 PPT，每个项目的验收文档结构都不一样。

2. 三个真实场景，暴露同一个问题

场景一：启动会前夜的“考古”。一位实施顾问告诉我，他每次准备启动会材料，都要翻三个地方：自己电脑里的历史文件夹、公司网盘的项目归档、以及去年离职同事留下的邮件附件。找齐材料平均花 2 小时，改一版再花 1.5 小时。一个团队一年做 60 个项目，光这一项就是 210 小时，接近 26 个标准人天。

场景二：同样的坑，踩了两年。某团队在做数据迁移时，因为没检查客户的历史数据编码规则，导致上线后第一批数据全部要返工。这件事在两年内发生了 5 次，每次都因为“这次情况不一样”。后来他们在模板里加了一个强制的准入检查项，问题消失了。真正的模板不是记录流程，是记录教训。

场景三：项目经理的“经验负债”。一个 20 人以上的实施团队，通常有 3-5 个“顶梁柱”项目经理。所有复杂的、跨部门的、客户难搞的项目都得他们上。原因很简单，只有他们脑子里装着完整的交付路径。这不是能力问题，是组织没有把个人经验转成组织资产。模板是这个转化最直接的载体。

3. 为什么“有模板”和“用模板”是两件事

我做过一个小范围统计：在 24 家自称“已经建好项目模板体系”的团队里，真正能在新建项目时通过平台一键生成任务结构的，只有 6 家，占 25%。剩下的 18 家，模板要么躺在网盘里，要么是 PMO 的“参考文档”，要么虽然上传到了系统里但只是一个附件。

差别在哪？在于模板是否与“新建项目”这个高频动作绑定。只要模板需要人主动去查、去下载、去复制粘贴，它的使用率就会随着项目压力增大而快速衰减，因为赶工期的时候，没人愿意多走两步。

三、常见误区：项目模板从 0 到 1 最常踩的六个坑

下面这六个误区，我在不同团队里反复见过。它们的共同点是：都不是“做得不够多”，而是“方向做偏了”。

1. 误区一：把模板做成文档包

这是最普遍的问题。PMO 花两个月产出《实施方法论 V3.0》，包含 26 个文档模板、14 个流程图、8 张表格。发布那天大家鼓掌，三个月后无人问津。

原因很简单：文档是给人读的，任务清单是给人做的。项目经理在最忙的时候需要的是“下一步该干什么、谁负责、什么时候交付”，而不是一份需要通读的规范。模板如果不解决“下一步做什么”，就永远竞争不过顾问自己的经验。

2. 误区二：追求大而全，一个模板打天下

我见过一个极端案例：某团队做了 3 个月，产出了 1 个“通用实施模板”，包含 187 个任务。结果所有项目经理第一反应都是删，删掉一半再开始。删到最后，模板变得和没有一样。

这里有个反直觉的判断：模板的任务数量不是越多越好，而是越“可裁剪”越好。一个 60 个任务、可以按项目类型裁剪到 25 个的模板，比一个 187 个任务的“全能模板”有用得多。可裁剪性本身就是模板的核心设计指标。

3. 误区三：由 PMO 单方面产出，脱离交付现场

PMO 视角和交付现场视角差别很大。PMO 关心流程合规、数据可统计；顾问关心今天能不能下班、客户明天要不要验收。如果模板只由 PMO 设计，它大概率会变成“给管理层看的数据采集工具”，而不是“给顾问用的工作脚手架”。

我建议的做法是：模板的第一版必须由一线项目经理执笔，PMO 负责结构化和治理。谁写的不重要，重要的是写的人明年还会用它。

4. 误区四：只做内容，不做“结构”

很多团队意识到要放到系统里了，于是把 Word 文档上传到项目管理平台，作为一个项目附件。这是典型的“搬箱子”，没有解决任何问题。

正确的做法是把模板拆成四层结构：（1）任务层，即 WBS 与任务清单；（2）角色层，即每个任务的默认责任人角色；（3）交付物层，即任务完成时要产出的文档或成果；（4）门禁层，即阶段之间的准入准出条件。

其中门禁层是最容易被忽略、但对交付质量影响最大的一层。比如“数据迁移必须先完成历史数据编码规则核查”，这是一条门禁，不完成就不能进入下一阶段。

5. 误区五：只建不管，没有版本治理

模板建完就完了，这是第二个高频问题。一年后你问团队“现在用的是哪一版模板”，没人答得上来；再问“上个月那个失败的项目用的是哪版”，更没人知道。

没有版本治理的模板体系有三个后果：模板逐渐失真、项目之间无法对比、经验无法沉淀。我建议模板必须绑定项目实例，能从项目反查它创建时用的是哪个版本。这个能力在成熟的项目管理平台上通常是内置的。

6. 误区六：把模板使用率当成考核指标

这一条听起来有点反常识，但我确实见过：某团队把“模板使用率”纳入 PMO 考核，结果项目经理为了达标，全部从模板创建项目，创建完立刻把任务删掉换成自己的。数据好看了，效率一点没提升。

模板要考核的不是使用率，而是“偏离率”和“偏离原因”。也就是说，从模板创建后，你改了多少、为什么改。如果某个任务在 80% 的项目里都被删掉，说明模板有问题；如果某个任务在 80% 的项目里都被保留，说明它是真正有价值的。

四、专业判断逻辑：什么样的模板才值得沉淀

不是所有东西都值得做成模板。做错了对象，投入越多、浪费越大。这一节讲我用的判断逻辑。

1. 用“频次 × 方差”决定优先做哪个模板

最实用的判断工具是两个维度：这件事在项目里出现的频次，以及不同项目之间做法的差异程度（方差）。

逻辑是这样的：

• 高频 + 低方差：必须模板化。比如启动会流程、验收清单、环境部署检查表。
• 高频 + 高方差：做“框架 + 可选项”。比如需求调研，提纲可以标准化，具体内容不能。
• 低频 + 低方差：做成检查清单即可，不要做完整模板。比如某些年检类的合规文档。
• 低频 + 高方差：不要模板化，做成案例库或专家问答更合适。

我一般会用一个简单的价值分公式做排序：模板价值分 = 出现频次 × (1 − 方差系数) × 单位节省工时。方差系数需要主观判断，但只要团队里三个人独立打分再取中位数，结果通常相当稳定。

2. 颗粒度决策：模板应该切到多细

颗粒度是模板设计里最难拿捏的部分。太粗，顾问还是要自己想；太细，改起来比新建还慢。

我的经验值是：单个任务的预估工时落在 4 小时到 3 人天之间，是一个比较健康的区间。低于 4 小时的任务，通常是“动作”而非“交付物”，可以合并到父任务里；超过 3 人天的任务，往往需要拆分，否则进度无法跟踪。

另一个关键判断：一个模板的可裁剪节点数量，应该占总任务数的 30%-50%。如果所有任务都是必选项，模板就没有弹性，项目经理会整体弃用；如果大部分任务都是可选项，模板就变成了摆设。

还要注意一点：不同交付模式下，同一套模板的裁剪路径应该被预设好。比如“标准 SaaS 快速上线”裁剪后应该是 22-28 个任务，“私有化定制交付”应该是 55-70 个任务。这两条路径应该在模板里预设成两个变体，而不是让顾问每次手动删。

3. 模板的三层结构怎么搭

（1）任务层：WBS 与时序关系

任务层要回答“做什么、按什么顺序、谁来做”。这一层最关键的不是罗列任务，而是定义任务之间的依赖关系。比如“数据迁移”必须在“历史数据编码规则核查”完成之后开始，这种依赖如果没有写进模板，模板就退化成了待办清单。

（2）交付物层：每个关键任务的产出定义

交付物层要明确每个阶段结束时应该有什么东西可以被验收。这一层的价值在于，它让“完成”变成了可判断的状态，而不是靠顾问自己说“我做得差不多了”。

（3）门禁层：阶段准入准出条件

门禁层是三层里最少被做、但价值最高的一层。它的作用是把历史上踩过的坑固化成强制检查项。一个团队的门禁清单长度，某种程度上等于这个团队交过的学费总额。

五、案例与数据观察：一个中大型实施团队的模板从 0 到 1

下面这个案例来自一家做企业级软件交付的公司，团队规模 180 人，其中实施交付 96 人，服务客户以中大型制造和零售企业为主。他们 2023 年开始重建项目模板体系，工具选型上换成了 PingCode，原因后面会说。

1. 起点：他们当时的状态

2023 年初，他们的状态在行业里很有代表性：

• 项目模板存在于公司网盘，共 3 个版本目录，最新一版最后修改时间是 2022 年 4 月。
• 实施顾问人均同时跟 2-3 个项目，项目经理平均每周花 6.5 小时在“整理材料”上。
• 新人从入职到独立负责一个中型项目，平均需要 5.5 个月。
• 项目验收一次性通过率 68%，返工原因中“交付物不齐”占比最高。
• 使用的旧工具（一个海外项目管理产品）无法承载任务级模板，只能传附件，且不支持私有化部署。

2. 为什么换工具是这次重建的前提

他们最初的计划是“在现有工具上把模板做好”，试了三个月后放弃。核心障碍有三个：一是旧工具的项目模板只支持字段和权限，不支持任务结构生成；二是数据存在海外，客户合规部门不接受；三是历史项目迁移成本高，一度想“干脆重新开始”。

最终他们选择了 PingCode，主要基于三点：

1. 支持深度的项目模板能力，能一键生成任务、里程碑、交付物和检查项，而不是只复制一个空项目壳。
2. 支持私有化部署，这对服务中大型企业客户的交付方是硬性要求，尤其是金融、制造类客户的数据合规审查。
3. 支持从 Jira 平滑迁移，他们此前有部分团队在用 Jira，历史项目和字段可以批量迁移，避免了“重新开始”的沉没成本。

需要说明的是，工具只是前提条件，不是成功原因。他们真正做对的，是模板的设计方法和治理机制。

3. 他们怎么从 0 到 1 搭模板

第一步，做“交付路径还原”（第 1-3 周）。他们没有先写模板，而是找了 8 位一线项目经理，用两天时间把过去 12 个月里 20 个已完成项目的实际执行路径画出来，标出每一步的输入、输出和耗时，以及“哪一步出过问题”。

这一步产出的最大价值不是路径本身，而是一份包含 47 条“历史踩坑项”的清单。这 47 条后来变成了门禁层的主要内容。

第二步，设计三层模板结构（第 4-6 周）。他们按行业分了 2 条主线（制造业、零售业），每条主线再按交付模式分 3 个变体（标准上线、定制交付、试点转正式），一共 6 个模板。

每个模板包含 4 个层级：里程碑（5-8 个）、任务（40-70 个）、交付物（12-20 项）、门禁检查（8-15 条）。模板的必选任务占比控制在 55% 左右，剩下的可裁剪。

下面是一个简化后的模板结构定义示例，实际落库时采用类似的 YAML 描述：

template:
name: "制造业-MES-标准上线-V3"

industry: "manufacturing"

delivery_mode: "standard_go_live"

typical_duration_weeks: 10

milestones:

id: M1

name: "项目启动"

offset_days: 0

gate:

"合同与SOW已归档"

"客户方项目经理已确认"

id: M2

name: "蓝图确认"

offset_days: 21

gate:

"历史数据编码规则已核查"

"蓝图方案已通过客户签字"

task_groups:

phase: "启动与计划"

tasks:

name: "组建项目组与职责确认"

role: "PM"

estimate_hours: 6

required: true

deliverable: "项目组织架构图"

name: "制定项目计划与里程碑"

role: "PM"

estimate_hours: 12

required: true

depends_on: ["组建项目组与职责确认"]

name: "客户环境与网络条件确认"

role: "实施顾问"

estimate_hours: 8

required: false

gate_rules:

rule: "phase_dependency"

desc: "数据迁移任务不可早于历史数据编码规则核查完成"

rule: "deliverable_required"

desc: "蓝图确认里程碑前必须上传已签字蓝图方案"

第三步，小范围试跑并收集偏离数据（第 7-12 周）。他们选了 9 个项目做试点，要求项目经理正常使用模板，但允许自由增删任务，同时记录每一次增删的原因。三个月后，他们拿到了非常有价值的数据：

• 有 6 个任务在 9 个试点项目里被删掉了 8 次以上，直接移除。
• 有 4 个任务被新增了 7 次以上，说明模板缺失，补进模板。
• 有 1 个门禁被抱怨“太繁琐”，但复盘发现它拦住了 2 次潜在的数据事故，保留并强化。

第四步，全量推广与版本治理（第 13 周起）。他们把模板版本号绑定到项目属性上，任何项目都能反查自己创建时用的是哪一版模板；模板每季度评审一次，改动需要至少 3 位资深项目经理同意。

4. 12 个月后的量化结果

到 2024 年中，这套体系运行满 12 个月，他们给出的对比数据如下（为公司内部统计，已脱敏）：

值得单独提一下最后一行。模板体系是有维护成本的，这个团队每季度投入约 6.5 人天做评审和更新。如果一个团队不愿意为模板维护买单，那模板的寿命通常不超过 9 个月。这是很多团队忽略的隐性成本。

5. 迁移过程中踩过的两个坑

坑一：一开始想把所有历史模板一次性迁移。他们最初计划把网盘里 3 个版本、上百个文档全部导入。做到一半发现，很多文档本身就是矛盾的，导入只会把混乱带进新系统。最终他们只迁移了 12 份被高频引用的核心文档，其余封存归档。

坑二：第一次试跑只选了大项目。第一批试点选了 9 个项目，其中有 6 个是周期 16 周以上的大项目。结果是反馈周期太长，三个月过去了还没到验收阶段，拿不到完整数据。第二批试点他们把样本调整成“3 个大项目 + 4 个中型项目 + 2 个小型项目”，数据收集效率明显提升。

这里有个经验可以复用：模板试点一定要覆盖完整交付周期短的样本，否则你等不到验证数据。如果项目最短周期是 10 周，那试点至少需要 12 周才能拿到阶段性结论。

六、行动建议：不同阶段的团队该怎么做

下面按团队规模和成熟度分三档给建议。不要跨档执行，跨档是模板体系失败的高频原因。

1. 20 人以下的实施团队：先做“三个清单”

这个规模不要谈模板体系，投入产出不划算。你需要的是三样东西：

• 启动检查清单：一页纸，列出项目启动前必须确认的 10-15 项内容（合同、干系人、环境、账号、培训安排等）。
• 验收交付物清单：明确验收时需要提交哪些文档，每份文档的负责人是谁。
• 踩坑清单：每次项目出问题，追加一条。这张清单是这个阶段最有价值的资产。

这三份清单不需要任何系统支撑，一个共享表格就够。关键不是形式，而是每次项目复盘后必须更新。

2. 20-100 人的团队：做“3 到 5 个模板 + 一条门禁线”

这个规模开始有复利效应了。建议：

1. 按交付模式分 3-5 个模板，不要按行业分太多，先粗后细。
2. 每个模板控制在 40-70 个任务，必选项占 50%-60%。
3. 建立一条阶段门禁线，先把“数据迁移前必须核查编码规则”这类历史上出过事的检查项加进去。
4. 每个季度做一次模板评审，根据偏离数据调整，投入控制在 3-5 人天。
5. 选型时优先确认工具是否支持任务级模板和私有化部署，避免后期被迫迁移。

3. 100 人以上的团队：做分层模板 + 版本治理 + 偏离度看板

这个规模（也是 PingCode 主要服务的组织区间）需要体系化建设：

• 分层模板：行业层 → 产品线层 → 交付模式层，三层组合而非平铺。
• 版本治理：模板版本与项目实例双向可追溯，能从项目反查模板版本，也能从模板反查使用它的所有项目。
• 偏离度看板：按任务统计“保留率”“删除率”“新增率”，用数据驱动模板迭代，而不是靠开会讨论。
• 门禁强制化：门禁不是建议，是流程卡点，不通过就不能进入下一阶段。
• 专职或半专职的模板维护角色：每季度 5-10 人天，这个投入必须被正式承认，否则没人愿意做。

4. 一份可执行的 90 天路线图

如果你今天决定开始做，下面这个节奏我认为是可行的：

1. 第 1-2 周：找 5-8 位一线项目经理，复盘过去 12 个月的 15-20 个已完结项目，产出交付路径图和历史踩坑清单。
2. 第 3-4 周：按交付模式确定 3-5 个模板的边界，明确每个模板覆盖什么、不覆盖什么。
3. 第 5-6 周：设计任务层和交付物层，把踩坑清单转化成门禁项，最好由一线项目经理执笔。
4. 第 7-9 周：选 6-9 个项目试点，样本必须覆盖短周期项目，要求记录每次增删任务的原因。
5. 第 10-11 周：分析偏离数据，删掉高频删除项，补上高频新增项，发布 V1 正式版。
6. 第 12-13 周：全量推广，绑定模板版本与项目实例，建立季度评审机制。

七、取舍：模板体系不是越多越好，也不是越严越好

最后讲取舍。前面讲了很多“应该做”，但实际决策中，真正难的是知道什么时候不该做。

1. 标准化 vs 灵活性的取舍

这是最根本的一组矛盾。标准化的收益来自复用，成本来自灵活性损失。判断标准是：这件事的失败成本有多高。

如果一件事做错了会导致严重后果（比如数据迁移出错、合规检查不通过），那么标准化程度应该拉满，甚至设为强制门禁；如果一件事做错了只是效率低一点（比如项目周报格式不统一），那就不值得强制，给个模板参考即可。

我通常建议把精力集中在“高失败成本 + 高频次”的交叉区域，其余部分保持宽容。一个所有环节都强制的模板体系，最终会被组织用各种方式绕过。

2. 集中治理 vs 分布自治的取舍

集中治理的好处是统一、可控、易统计；坏处是响应慢、脱离现场。分布自治的好处是贴近实际、迭代快；坏处是容易碎片化。

我的建议是“结构集中、内容分布”：模板的骨架（里程碑、阶段划分、门禁规则）由 PMO 集中管理，具体的任务细节和交付物内容由各交付团队自己维护。这样既保证了跨团队的可比性，又保留了一线调整的空间。

如果团队超过 150 人，我会更倾向于加一层“领域负责人”角色，每个行业或产品线有一位资深项目经理负责本领域模板的迭代，PMO 只做规则和版本管理。

3. 自建 vs 平台原生能力的取舍

有些团队会选择自己在通用工具上开发模板能力，或者用表格 + 脚本拼一套。短期看省钱，长期看有三个隐性成本：维护成本、迁移成本、合规成本。

特别是服务中大型企业客户的交付方，私有化部署能力往往不是加分项而是准入项。同时，如果团队历史上有其他项目管理工具（比如 Jira）的沉淀，平滑迁移能力会直接影响这次重建的时间成本，很多团队低估了数据迁移带来的阻力。

PingCode 在这两点上比较契合中大型实施团队的需求：支持私有化部署，能通过自动化规则和门禁把模板真正“卡”在流程里，同时支持从 Jira 平滑迁移，减少历史数据重建的投入。这不是说工具决定成败，而是说，当你的模板都需要靠人“记得用”的时候，这套体系就已经失败了一半。

4. 短期投入 vs 长期收益的取舍

模板体系的收益曲线是滞后的。前 3 个月你看到的可能只有成本：开会、写文档、试跑、被抱怨。真正的收益大概在第 6 个月开始显现，第 12 个月才比较明显。

所以在决策时，我会问一个很直接的问题：你们团队未来 12 个月还会做多少个同类项目？

如果答案是少于 10 个，那这套体系不值得建，做几份清单就够了。如果答案是 30 个以上，那前面 3 个月的成本在第 12 个月会被完全覆盖，后面每一年都是净收益。

这个判断比任何方法论都重要。因为方法论解决的是“怎么做”，而这个问题解决的是“要不要做”。

总结与下一步

回到最开始那个朋友的问题：“我们不是没有模板，是模板没人用。”答案其实很清晰，没有人用的模板，通常是因为它只存在于文档里，没有进入任何人的工作流。

我在这篇内容里最想强调的一个独特观点是：项目模板的真正价值，不在于它记录了多少经验，而在于它把经验变成了不可绕过的执行路径。一份写得再好的实施方法论，如果顾问可以在赶工期的时候轻松跳过，那它的实际价值就是零。而一条强制门禁，哪怕只有一句话，只要能拦住一次数据事故，它就值回全部投入。

另一个容易被忽略的判断是：模板是有维护成本的资产，不是一次性的项目。每季度 3-10 人天的持续投入，是这套体系能活过 12 个月的底线。很多团队建完就散，9 个月后模板彻底失真，比没建还糟，因为此时团队会对“做模板”这件事本身失去信心。

如果你准备开始，我建议你下一步只做三件事，别贪多：

1. 这周：找 5 位一线项目经理，让他们列出过去一年里“重复做过 3 次以上”的工作，按耗时排序。
2. 下周：从清单里挑出耗时最长、做法差异最小的那一项，把它拆成任务清单和 3-5 条检查项。
3. 下个月：选 3 个在跑的项目试用这份清单，记录每一次增删的原因。这三个月里收集的偏离数据，会直接决定你后面 5 个模板该怎么设计。

最后提醒一句：如果你发现自己团队的门禁清单一直没有增加，那大概率不是因为交付过程没问题，而是因为复盘没有认真做。模板体系的源头不是方法论，是事故复盘。没有新踩的坑，就没有新长的模板。