复制项目最佳实践：管理层项目模板实操方法，常见问题

2023 年 4 月，我接手一个 60 人研发组织的”项目模板标准化”专项。第一版模板上线 45 天，真实使用率只有 31%，项目经理平均每周花 2.5 小时去改模板里的字段和状态，比不用模板还累；第二版我把它砍成”三个默认值 + 一条例外通道”，第 90 天真实使用率到 87%，从项目立项到排期定稿的平均耗时从 9.6 天压到 4.1 天，跨部门返工工单从每月 23 张降到 7 张。

两次的差别不在工具，而在我对”复制项目”这件事的理解。第一版我复制的是上一个项目的任务表；第二版我复制的，是管理层每周都在重复做的那几个决策。前者是搬砖，后者才是模板。这篇文章就把这套方法完整拆开，包括我踩过的七个坑、四步设计逻辑，以及在一个 120 人研发组织里用 PingCode 落地的真实数据。

一、核心结论：项目模板复制的不是任务清单，而是决策节奏

先给结论，再讲过程。如果你只想要一句话：管理层做项目模板，真正要复制的是”决策节奏”，不是”任务清单”。节奏指的是，什么时候必须有人拍板、拍板需要哪些信息、拍完板之后谁在什么时限内响应。任务清单只是这个节奏的副产品。

1. 结论一：模板的复用单位是”决策点”，不是”任务”

我统计过自己经手的 11 个中大型项目，一个 3 个月周期的项目，任务条目大约 400，700 条，但真正需要管理层介入的决策点只有 18，26 个。绝大多数任务是可以由团队自行拆解的，真正卡住项目的，永远是那 20 来个决策点：需求范围冻结、架构方案选型、测试准入标准、上线窗口、回滚责任人。

一份好的项目模板，会把这 20 来个决策点做成一等公民，让它们成为必填字段、必经状态、必有责任人的对象；而把 400 条任务留给执行层自由填充。把精力花在任务清单上的模板，注定被绕过。

2. 结论二：管理层该管的是”边界”，不是”细节”

我在第二版里做的最重要的动作，是把模板从”60 个字段”砍到”14 个字段”。砍掉的都是执行细节（比如具体工时估算、单个子任务的依赖），保留的全是边界条件：这个项目的验收标准是谁签字、变更超过多少工作量必须升级、延期几天会触发预警、谁有权关闭项目。

这背后的判断是：管理层的注意力是最稀缺资源，模板一旦超过 20 个必填字段，填写就会退化成形式主义。我不是凭感觉说的，第一版模板 60 个字段时，抽样 200 个项目的字段完整率是 68%，第二版 14 个字段时，完整率是 96%。

3. 结论三：模板的价值不在第一次使用，而在第三次修改之后

一个刚建好的模板，价值接近于零，因为它是根据过去的项目猜的。模板真正的价值拐点，出现在它被使用并修改过至少 3 次之后，那时你才能看出哪些字段是所有人都在改的（说明默认值错了），哪些字段是所有人都不填的（说明这个字段本身没有决策价值）。

所以我给出的一个硬性机制是：模板每被复用 5 次，必须做一次字段级的复盘，看修改日志和填写日志。没有这条机制，模板会在 6 个月内自然腐烂成一张没人看的表单。

4. 一条底线：每个字段都必须能被证伪

这是我个人用得最顺手的一条筛选标准。所谓”能被证伪”，意思是这个字段填错会导致一个明确的、可观察的后果。如果填错和没填没有任何区别，这个字段就该删。

举例：”项目优先级”这个字段，如果它不会影响任何排期、资源分配或预警规则，那它就是一个装饰字段。反过来，”预期的最大变更工作量（人天）”能被证伪，因为它直接绑定了一条自动化规则：超过阈值自动升级到项目管理办公室。前者删掉，后者保留。

二、背景和真实场景：为什么管理层最容易把模板做废

模板这件事的吊诡之处在于：越是管理层推动，越容易做废。因为管理层的视角天然是”总结过去”，而模板要解决的是”未来一次还没发生的事”。这两个视角经常打架。

1. 触发模板复制的三类真实场景

我在过去 5 年里见过、也亲身经历过三类典型触发场景，它们的解法差别很大，不能混为一谈。

• 规模化触发：团队从 1 条业务线扩到 3 条，项目经理从 2 人变成 8 人，交付质量开始飘。这时要复制的是”流程骨架”和”角色定义”。
• 合规触发：要过审计、要交付给外部客户、要做等保或行业认证，必须有可追溯的评审记录。这时要复制的是”证据链”，而不是效率。
• 交接触发：核心项目经理离职或轮岗，新接手的人 3 个月摸不清项目全貌。这时要复制的是”上下文”，也就是项目为什么立项、边界在哪、谁做过什么决定。

很多组织的失败在于：用合规触发的思路（尽可能全）去解决规模化触发的问题（尽可能快），结果做出一个又重又慢的模板，两头都不讨好。先确认你属于哪一类触发，再决定模板的复杂度上限。

2. 我踩过的第一个坑：把上个项目的 WBS 原样搬过去

2019 年我做过一个金融行业的交付项目，周期长、结构清晰，我自认为做得很漂亮。第二年公司接了一个结构相似的客户，我直接把这套 WBS 加上里程碑复制过去，连任务依赖关系都没改。

结果第 3 周就出事了。原项目有一个”第三方接口联调”的里程碑，依赖外部厂商，而新项目的接口方是我们的合作方，可以提前介入。团队按照模板的排期等了两周，白白浪费 14 个人天。项目经理后来跟我说了一句让我记到现在的话：”模板让我们做了一件本来不需要做的事。”

这件事让我确立了一条原则：任何从上一个项目复制过来的内容，都必须经过一次”这条在新项目里还成立吗”的显式确认，否则不准进模板。

3. 第二个坑：模板建好了，没人用

第一版模板我把字段做得很细，还在启动会上专门讲了 40 分钟。两个月后我抽查，发现真实使用率只有 31%。我去问项目经理为什么不填，得到的回答很一致：”填了也没人看，评审时还是靠口头汇报。”

这句话点破了模板失效的真正原因：模板没有接入管理动作，就等于自愿填表。后来我做的第一件事，是把模板里的”风险等级”字段和管理层的周会看板绑定，只有填了风险等级的项目，才会出现在周会材料里。两周之后，这个字段的填写率从 42% 涨到 98%。

这就是我说的”模板必须有下游消费者”。没有消费者的字段，一定会被填成假的。

4. 一个关键观察：模板复用率和项目规模的关系

我在自己接触过的四个组织里做过一个粗略统计，结论不太符合直觉：模板复用率并不是越高越好。当复用率超过 85% 时，项目的”个性化调整”空间被压得太死，反而会出现团队偷偷在模板外开 Excel 表格的情况。

一个比较健康的区间是 60%，80%。在这个区间内，模板提供了骨架，但保留了两到三成的项目特有内容，团队对模板的信任度反而更高。判断模板是否健康，不只看复用率，还要看”模板外真实工作载体”的数量。如果你发现团队还在用大量表格和文档做补充，说明模板漏掉了关键决策点。

三、拆解七个常见误区

下面这七个误区，全部来自我实际见过或亲历过的失败案例。我把它们按”发生时有多难发现”排序，越靠前的越隐蔽。

1. 误区一：把模板当成 SOP 文档

最常见的一种做法是，把一份 30 页的流程文档塞进模板的说明字段。结果是没人看，而且流程一改，模板说明就过期，形成双重维护负担。

我的判断是：模板里只能放”需要被系统读取”的信息，文档放说明和培训的地方。能被自动化规则、看板、报表消费的字段才进模板，纯解释性内容一律外链。

2. 误区二：颗粒度越细越好

有些管理层喜欢把任务拆到 0.5 人天，认为这样最可控。真实结果是：项目初期拆得越细，后期变更越频繁，团队把大量时间花在维护计划本身，而不是交付。

我给出的经验阈值是：模板中的任务颗粒度不应低于 2 人天，管理层视角的结构分解不应超过 3 层。再细的拆分应该由执行团队在使用过程中自己补，而不是由模板预先规定。

3. 误区三：一次性建大而全的模板库

我见过一个组织上线了 47 套项目模板，覆盖各种业务场景。半年后，只有 6 套还有人用，其余 41 套因为没人维护，字段和实际流程严重脱节，成了组织里的”技术债”。

正确的做法是反过来的：先建 2，3 套覆盖 80% 场景的模板，剩下的用”模板继承”或”字段可选”来扩展。每新增一套模板，都要指定一个明确的维护责任人，否则不准新增。

4. 误区四：忽略权限与可见性设计

这是个容易被忽视但影响极大的问题。如果模板里包含了项目预算、人力成本、客户敏感信息，而权限没有区分开，团队会本能地选择不填。我遇到过一次，某项目因为预算字段全员可见，项目经理连续 4 个月填的都是一个保守估算值，导致资源规划完全失真。

权限设计不是安全需求，是数据质量需求。字段级权限没做好，模板数据的可信度就无从谈起。

5. 误区五：模板与度量脱节

一个模板如果没有对应的度量看板，管理层就无法从中获得决策价值，自然也不会维护它。我见过做得好的组织，模板上线第一天就配好了三张报表：项目健康度、风险分布、里程碑达成率。这三张报表就是模板的”消费者”。

反过来，如果一个字段从来不进任何报表，它大概率会被慢慢废弃。这是自发的演化规律，不需要人为干预。

6. 误区六：不做版本管理

模板也是资产，需要版本。我在 2022 年遇到过一次很尴尬的事：一个进行中的项目突然发现排期口径变了，排查半天才确认是有人直接改了模板，导致后续项目用的是新口径，而老项目还在用旧口径，两批数据无法对比。

后来我们定了一条规则：模板的每次变更必须留版本号、变更说明和影响范围；进行中的项目默认不跟随变更，新立项项目才用新版本。

7. 误区七：强制全员使用同一套模板

强制统一是管理层最容易做的决定，也是最容易反弹的决定。不同业务线的交付节奏差异巨大，研发迭代以两周为单位，交付实施以月为单位，市场活动以天为单位。硬用一套模板，必然出现”填了但没用”的情况。

我的建议是：统一”决策骨架”，允许”执行外壳”差异化。也就是说，风险升级规则、验收标准、里程碑定义这些必须统一；而具体的工作项类型、状态流转，允许按业务线定制。

四、专业判断逻辑：模板复制的四步设计法

讲完误区，讲方法。我把这套方法总结成四步，顺序不能颠倒，因为后一步依赖前一步的输出。

1. 第一步：识别”重复决策点”

具体做法是，把过去 6 个月内所有项目的会议纪要、评审记录、变更单拿出来，找那些”反复出现、且判断逻辑相似”的决策。比如”这个需求要不要插队”、”这个延期是否需要上报”、”这个缺陷是否可以带病上线”。

判断标准有三条：出现频次高、判断逻辑稳定、错了有明确后果。三条都满足的，才是候选决策点。我通常能从 6 个月的历史材料里筛出 15，25 个候选，最终落进模板的通常是 10，14 个。

2. 第二步：区分”必须固化”与”必须留白”

这是最考验判断力的一步。我的经验法则是：凡是涉及责任归属、风险披露、对外承诺的，必须固化；凡是涉及技术方案、实现路径、人员分工的，必须留白。

原因很简单：前者一旦模糊，出问题就无人负责；后者一旦固化，就会限制团队的专业判断，而且环境一变就失效。很多模板失败，就是把这两类搞反了，技术路径写得极其详细，责任归属却含糊其辞。

3. 第三步：设计默认值 + 例外通道

模板要能”默认就能用”，同时允许”有理由地偏离”。我在 PingCode 里做这件事的方式是：把核心字段设成带默认值的必填项，默认值来自历史项目的中位数，然后配一条自动化规则，当项目负责人把某个字段改成偏离默认值的选项时，必须填写偏离理由，超过阈值自动通知管理层。

这套机制的好处是双向的：默认值降低了 90% 的填写成本，例外通道又保留了 10% 场景的灵活性。上线后我观察到，真正走例外通道的项目大概占 14%，这个比例很健康。

下面是我们当时用到的模板字段配置片段，脱敏后大致长这样：

project_template:
name: "标准交付项目模板 v2.3"

fields:

key: acceptance_owner # 验收签字人

type: user

required: true

default: null # 无默认值，必须显式指定

key: max_change_effort # 允许的最大变更工作量

type: number

unit: person_day

required: true

default: 15 # 历史项目中位数

alert_rule: "if value > 25 then notify PMO"

key: risk_level

type: enum

options: [L1, L2, L3]

default: L1

downstream: "weekly_dashboard, escalation_matrix"

key: tech_approach # 技术路径，刻意留白

type: text

required: false

version_policy:

in_flight_projects: lock # 进行中项目锁定旧版本

new_projects: follow_latest

注意最后那段 version_policy，这是我踩过坑之后加的。没有它，模板一改，所有在跑的项目数据口径全乱。

4. 第四步：建立模板的回收与迭代机制

模板建成只是开始。我要求每个模板都有三个数字必须被定期看：字段填写率、字段修改率、模板外工作载体数量。填写率低说明字段没价值，修改率高说明默认值错了，模板外载体多说明漏了关键决策点。

通常我会按季度做一次模板复盘，每次只动 2，3 个字段，避免大幅震荡。这套机制运行一年后，我们的主模板从 v1.0 迭代到 v2.3，字段数从 60 降到 14，再回到 19，最后这 5 个字段是使用过程中被”重新发现”的，它们比我当初设计的任何字段都更贴合真实决策场景。

五、具体案例与数据观察：一个 120 人研发组织的落地实操

下面这部分是我参与最深的一个案例，数据来自 2024 年 3 月到 6 月的真实运营记录，脱敏后分享。

1. 案例背景

这家公司是中大型企业，研发组织约 120 人，分 5 个交付小组，同时运行的项目常年维持在 18，25 个。他们此前面临的问题很典型：项目模板有三套，但没有一套被完整使用；管理层每周要看 7 份格式不同的汇报；项目延期率在 34% 左右，而且没人说得清延期的真实原因。

选型阶段他们评估过几类方案，最终选择了 PingCode。主要考虑三点：一是支持私有化部署，源码可控，符合他们的数据合规要求；二是支持从 Jira 平滑迁移，历史项目数据和工作项关系能保留；三是度量能力内建，不需要再额外搭一套报表系统。

2. 模板结构怎么搭

我们最终只建了 3 套模板：标准交付项目、敏捷迭代项目、预研项目。每套模板的必填字段控制在 14 个以内，其中 6 个是”决策边界字段”（验收责任人、变更升级阈值、风险等级、里程碑定义、上线窗口、回滚责任人），8 个是”上下文字段”。

关键动作是把这 14 个字段和下游动作绑定。比如”风险等级”直接驱动周会看板，”变更升级阈值”直接触发自动化通知，”里程碑定义”直接接入度量报表。模板的每个字段都有一个明确的”消费者”，这是它活下来的根本原因。

3. Jira 迁移与私有化部署的真实考量

迁移这件事，我要多说两句，因为很多团队在这一点上低估了工作量。他们的历史数据大约 4.7 万个工作项、280 个项目。迁移过程中最容易出问题的不是数据量，而是字段语义映射，原来的自定义字段里有一堆含义不明、多年没人维护的项，如果原样搬过来，新系统第一天就会变成一个垃圾场。

我们的做法是：迁移前先做字段审计，把 5 年没人填过的字段直接丢弃，把语义重复的字段合并，最终字段数从 87 个压到 31 个。这一步花了两周，但它让后面所有的模板工作都轻松了一倍。私有化部署方面，主要成本在环境准备和权限模型设计，尤其是和生产系统的网络策略对接，需要提前和运维对齐窗口。

4. 上线 90 天的数据变化

下面这些数字是 3 个月内的实际记录。需要说明的是，这些变化是模板治理、流程梳理、工具切换多个因素共同作用的结果，不能全部归因于模板本身，但模板是其中最关键的一个变量。

我最看重的其实不是延期率那 15 个百分点，而是最后一行：模板外的补充表格从 17 个降到 4 个。这说明团队真的愿意留在主系统里工作了。只要还有大量影子表格存在，主系统的数据就永远是”不完全可信”的。

5. 一个反直觉的细节：管理层最常用的字段不是进度

上线三个月后我看了字段访问日志，发现管理层访问频次最高的三个字段是：变更升级阈值、风险等级、回滚责任人。而”任务完成百分比”的访问频次排在第七位。

这个观察强化了我的判断：管理层要看的不是”事情做到哪了”，而是”出了问题谁负责、什么时候必须有人拍板”。如果你的模板把 80% 的字段用来描述进度，它本质上是一个项目经理的模板，不是管理层的模板。

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

方法论讲完，接下来按组织规模给出可直接执行的建议。我用”人数”作分层，是因为它和决策复杂度、沟通成本的相关性最高。

1. 20，50 人团队：只做一套模板，别做模板库

这个规模的组织，沟通成本还很低，模板的核心价值是”让新人不迷路”。我的建议是只建一套主模板，必填字段控制在 8，10 个，重点放上下文类字段：项目目标、边界、验收责任人、关键里程碑。

不要在这个阶段追求度量体系，也不要引入多套模板。你真正需要的是一份所有人闭着眼都能填完的模板，而不是一套精致的流程框架。工具上，这个规模用轻量方案即可，不必上重型平台。

2. 100，500 人团队：3 套模板 + 强制下游消费

这是模板价值最明显的区间，也是我那个 120 人案例所处的阶段。核心动作有三个：按项目类型建 3 套模板；每个必填字段绑定至少一个下游消费者（报表、看板、自动化规则）；建立季度复盘机制。

这个阶段最容易犯的错是模板数量失控。我建议设定一条硬规则：新增一套模板必须同时指定维护人，并且说明它不能被现有模板覆盖的理由。没有这两条，一律不批。

工具选择上，这个阶段开始需要私有化部署能力、字段级权限、以及与既有研发流程的深度集成。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，模板继承、字段权限、度量看板这些能力是内建的，不需要另外拼装。如果团队原本在用 Jira，迁移路径也相对成熟，历史工作项和关系可以保留。

3. 500 人以上 / 多业务单元：统一骨架，分权外壳

这个规模的组织，最忌讳的是总部统一建一套模板强行推给所有业务单元。正确做法是分两层：集团层定义”决策骨架”（风险分级标准、升级路径、验收口径），业务单元层定义”执行外壳”（工作项类型、状态流转、迭代节奏）。

同时要建立模板治理委员会之类的机制，明确谁有权改骨架字段。我见过一个组织，因为没有明确的变更权归属，一年内骨架字段被改了 14 次，导致跨年数据完全无法对比。

4. 从其他工具迁移过来的情况：先做字段审计，再谈模板

如果你正准备迁移，我给你一个明确的顺序建议：字段审计 → 数据清洗 → 模板设计 → 迁移执行 → 灰度验证。很多人把顺序搞反了，先设计模板再迁移，结果旧数据带进来一堆无意义字段，模板第一天就被污染。

字段审计阶段，我通常用三个问题做筛选：这个字段最近一年有人填吗？填了之后有下游动作吗？它的语义能被一句话说清吗？三个问题有一个答不上来，就合并或删除。

七、不同情况下的取舍

模板这件事没有最优解，只有权衡。下面五组取舍是我在实践中最常需要做判断的地方。

1. 标准化 vs 灵活性

标准化的收益是可比性和可预测性，代价是应变速度。我的建议是按”错误成本”来分：错了代价高的环节必须标准化，错了代价低的环节尽量留白。

比如上线回滚流程，错了可能导致生产事故，必须严格标准化；而日常任务拆解方式，错了最多影响一周效率，就交给团队自己决定。用同一个标准去要求所有环节，是模板设计里最常见的错误。

2. 管理层视角 vs 执行层视角

这两个视角经常冲突。管理层想要汇总视图和风险预警，执行层想要灵活的工作台和自由的任务结构。我的处理方式是分层：管理层用决策字段和度量看板，执行层用自己的工作项视图，两者通过少量关键字段打通。

关键是打通字段要少。我曾经试过用 20 个字段做双向同步，结果是两边都觉得负担重。后来压到 6 个，反而两边都愿意维护。

3. 自建 vs 采购

自建的优势是完全贴合业务，劣势是维护成本被严重低估。我见过一个团队自研了项目管理模板系统，前 6 个月很好用，第 18 个月因为核心开发离职，系统基本停更。

我的判断标准是：如果模板逻辑是你的核心竞争力（比如特殊的交付方法论），可以考虑自建；如果只是通用项目管理，采购成熟平台更划算。大多数组织的模板逻辑属于后者。

4. 一次性重构 vs 渐进演化

一次性重构看起来干净利落，但风险极高，所有进行中的项目都要迁移，任何设计缺陷都会被立刻放大。我倾向于渐进演化：新立项项目用新模板，进行中的项目锁定旧版本，跑完生命周期自然淘汰。

代价是会有半年左右的”双轨期”，数据口径不统一。这个代价我认为是值得的，因为它把风险分散到了时间维度上。

5. 私有化部署 vs SaaS

这个取舍主要由数据合规要求和运维能力决定，不是技术优劣问题。如果组织有明确的数据不出内网要求，或者有成熟的运维团队，私有化部署是合理选择；如果团队精干、更看重迭代速度和零运维，SaaS 更合适。

需要注意的是，私有化部署的隐性成本主要在版本升级和权限模型维护上，这两块要在预算里单独留出人力。我通常建议按”每 100 名用户 0.5 个运维人力”来做粗算。

八、常见问题

1. 项目模板应该由谁来建和维护？

我的建议是”管理层定义边界、项目管理办公室建模板、一线团队做反馈”的三方分工。管理层只负责确认哪些决策点必须固化；项目管理办公室负责字段设计、版本管理和复盘；一线团队负责反馈哪些字段不合理。

最忌讳的是让一线团队自己建模板，他们往往会建出一个很贴合执行、但管理层完全用不上的东西。也忌讳管理层直接下场建模板，那通常会得到一个又重又没人用的表单。

2. 模板应该包含多少个必填字段？

根据我的实践，100 人以上组织的必填字段控制在 12，16 个比较合适，20 个是警戒线。超过 20 个之后，填写质量会断崖式下降。

如果你不确定从哪减，就用那条”可证伪”标准：填错了会不会有明确后果？不会的，删掉。我通常能用这一条砍掉三分之一以上的字段。

3. 模板用了一段时间没人用了，怎么救？

先别急着推广，先查三个数字：字段填写率、字段修改率、模板外工作载体数量。填写率低是字段没价值，修改率高是默认值错了，模板外载体多是漏了关键决策点。

绝大多数”没人用”的根因不是团队不配合，而是模板没有下游消费者，填了没人看，自然就不填了。先把模板接到一个真实的管理动作上（比如周会看板），问题往往自己就解决了。

4. 从旧工具迁移时，历史模板要一起搬吗？

模板本身不建议搬，历史数据建议搬。原因是旧模板承载的是旧流程和旧口径，直接搬过来会把历史包袱一起带进新系统。

我的做法是：历史数据做清洗后迁移，用于复盘和追溯；模板重新设计，只保留被验证过依然成立的决策点。迁移前一定要做字段审计，这一步省下来的时间，会在后面半年里成倍还给你。

5. 怎么判断一套模板是不是做成功了？

我会看四个信号：一是新项目立项到排期定稿的耗时有明显下降；二是管理层周会材料准备时间下降；三是模板外的补充表格数量在减少；四是有没有人主动提模板修改建议。

最后一条最容易被忽略，但它最有价值。当一线团队开始主动挑模板的毛病时，说明模板真的进入了工作流；如果没人提意见，通常意味着没人在用。

6. 私有化部署的项目管理平台，在模板能力上有什么实际差别？

主要差别在字段级权限和自定义流程的深度上。私有化部署方案通常支持更细的权限模型和更灵活的工作项类型定义，这对大型组织的模板治理很重要，因为字段可见性和流程可定制性，直接决定了模板能不能适配多条业务线。

代价是运维成本。选择这类方案前，要确认自己有版本升级和权限维护的人力储备，否则模板治理做到一半，会因为系统维护跟不上而停滞。

结语：模板是管理层的判断力容器，不是流程的复印件

回到开头那句话。我见过太多组织在做”复制项目”这件事时，实际做的是复制上一份文档。真正有效的做法，是把管理层每次都要重复做的那 20 来个决策，提前固化成一小组可被系统读取、可被下游消费、可被定期证伪的字段。

这件事的价值不在效率，而在一致性。当 5 个项目经理面对同一个风险时给出相近的判断，组织的交付质量才会稳定。模板就是这个一致性的载体。

给你一个可以明天就执行的动作清单。第一，把过去 6 个月的会议纪要和变更单拿出来，列出反复出现的决策，目标 15，25 个。第二，用”可证伪”标准筛掉一半，剩下 10，14 个作为候选字段。第三，为每个字段指定一个下游消费者，没有消费者的一律不进模板。第四，建 2，3 套模板，设好版本策略，进行中项目锁定，新项目跟随最新版。第五，90 天后回来看字段填写率、修改率和模板外表格数量这三个数字。

如果这五步做完，你的模板还是没人用，那问题大概率不在模板本身，而在于你没有给模板接上一个真实的管理动作。先修那个动作，再修模板。