模板阶段最佳实践：项目负责人项目模板数据分析，常见问题

去年秋天，我参与一家 1200 人装备制造企业的项目管理平台迁移复盘，最先爆出问题的不是流程，也不是数据，而是模板。他们自称有 34 个“标准项目模板”，我把过去 12 个月的项目创建记录导出后发现有 26 个模板被使用的次数不超过 3 次，另有 4 个模板从来没有人主动选过，只在“复制历史项目”的场景里被动继承。

更刺眼的是字段。使用量最大的那个模板定义了 61 个字段，但平均每个项目真正被填写的只有 14 个，填充率 23%。而这 46 位项目负责人的自评数据显示，他们每周花在补字段、对齐状态、解释流程上的时间，平均是 3.2 小时。

模板阶段的问题从来不是“模板写得好不好看”，而是模板作为一个产品，它的用户（项目负责人）用脚投票的结果，你有没有读。这篇文章讲三件事：项目模板该采集哪些数据、这些数据说明什么、以及当数据指向不同结论时你该怎么取舍。所有判断都来自我参与过的模板治理项目，涉及平台能力时以 PingCode 为例，因为它在中大型组织和私有化场景下的模板配置颗粒度足够细，能承载这类分析。

一、核心结论：模板不是文档，是治理资产

1. 模板的第一指标不是“数量”，而是“结构性偏离率”

大多数组织在统计模板时只统计两件事：有多少个模板、有多少项目用了模板。这两个数字几乎没有决策价值。真正有判断力的是第三个数字：用模板创建的项目里，有多少项目在创建后 7 天内对模板自带的结构（字段、状态机、工作流、权限）做了修改。

我把这个比例叫结构性偏离率。它不是越低越好，也不是越高越好，它需要结合偏离的分布形态来解读。偏离集中在一两个字段上，说明模板缺一个分支；偏离散落在十几个字段上，说明模板约束过强或者宣贯不到位。这两种情况的处理方式是相反的。

2. 模板的“用户”是项目负责人，不是流程管理员

流程管理员设计模板，项目负责人使用模板。这两类人对“好模板”的定义天然冲突：前者希望覆盖全、口径统一、审计可追溯；后者希望填得少、改得快、不被卡住。

冲突本身不是问题，问题是很多组织只听到了前者的声音。模板评审会上坐着的是各业务线的流程接口人，而真正每周被模板折磨的项目负责人不在场。所以模板数据分析的本质，是把项目负责人的沉默抗议翻译成可读的数字。

3. 只需要 4 个核心指标 + 3 个诊断指标

我见过太多组织把模板统计做成 20 列的报表，最后没人看。实际能驱动决策的，是下面这组最小集合。

前四个指标构成日常看板，后三个指标只在季度治理会上用。这个划分很重要，诊断指标一旦进入日常看板，就会变成为了达标而做的形式主义。

4. 八成模板问题，根因不在模板本身

这是我的经验判断，也是我在复盘会上反复验证过的结论：模板问题的真实根因分布大致是，权限模型没设计好占一部分，报表口径没对齐占一部分，缺乏模板维护责任人占一部分，最后才是模板本身的字段设计问题。

所以当你发现“项目负责人不爱用模板”时，先别改模板。先去看他为什么改：是因为字段填了没人看（那要砍字段），还是因为他要的数据模板里没有（那要加字段），还是因为他改完不会被追责（那是权限和治理问题）。

二、背景与真实场景：模板阶段到底在治理什么

1. 模板阶段的准确定义

在项目管理平台里，模板阶段指的是从“新建项目”到“项目进入正常执行节奏”之间的这段配置窗口期。它通常只有几分钟到几十分钟，但决定了后面几个月的数据质量。

很多人把模板等同于文档模板，这是最大的误解。在企业级项目管理平台中，一个项目模板实际包含了至少六类配置：工作项类型与层级、字段定义与必填规则、状态机与流转条件、权限角色与可见范围、自动化规则、默认报表与视图。这六类配置中任何一类缺失，模板都会退化成一张空表。

2. 一个中大型组织的模板演进史

我复盘过六个 500 人以上组织的模板演进路径，形态高度相似，基本会经历五个阶段。

1. 草创期：3 到 5 个模板，字段 10 到 15 个，靠一两个懂业务的人拍脑袋定，反而好用。
2. 成长期：业务线开始提需求，模板增加到 10 个左右，字段涨到 25 到 30 个，出现第一批“没人用的模板”。
3. 扩张期：每个事业部都要自己的模板，模板数突破 25 个，字段平均 40 个以上，开始有人抱怨“填表比干活累”。
4. 失控期：模板变体数十个，同一个业务域里存在互相矛盾的状态定义，报表口径无法统一，治理会开成批斗会。
5. 治理期：用使用数据和偏离数据做减法，模板回落到 8 到 12 个，字段回到 20 个以内。

关键判断是：大部分组织在第三阶段就已经需要治理了，但通常会拖到第四阶段才动手，因为前三个阶段模板数量的增长被误认为“业务在被支持”。

3. 为什么项目负责人是模板数据的最佳观测点

模板数据可以来自很多角色：流程管理员能告诉你模板定义了什么，IT 能告诉你模板被创建了多少次，但只有项目负责人能告诉你模板哪里不好用。

项目负责人的行为数据有三个优势。第一，他们有明确的效率动机，改模板是为了省自己的事，不会为了面子改。第二，他们的修改动作天然留痕，字段增加、状态跳过、权限调整都会在系统里产生记录。第三，他们数量足够多，能形成统计意义上的分布，而不是单点抱怨。

所以模板治理的起点不该是“我们想要什么样的流程”，而该是“项目负责人已经在怎么改我们的模板”。

4. 模板失控的三个早期信号

信号一：同一业务域内出现两个状态名不同但语义相同的状态，例如“待评审”和“评审中”并存，说明模板在按人而不是按业务复制。

信号二：新建项目时，项目负责人第一件事是复制一个老项目而不是选模板。这通常意味着模板本身不可用，或者他记不住哪个模板对。

信号三：模板修订记录里，最近一次实质性修改超过 9 个月。流程已经变了，模板没变，模板的权威性正在流失。

三、常见误区拆解

1. 误区一：模板越多，支持的业务越灵活

这是最普遍也最致命的误区。模板数量的增长几乎总是来自“某个业务线要求特殊处理”，而不是来自业务模式的真实分化。

我做过一次核对：某企业 34 个模板里，有 11 个模板之间的差异只体现在 2 个字段的取值上，还有 6 个模板的状态机完全相同，只是名称换了。这些模板完全可以合并为一个模板加一组条件显示规则。

模板数量增加的速度，应该慢于业务模式分化的速度。如果两者同步增长，说明你把“部门差异”当成了“业务差异”。

2. 误区二：把字段设为必填，就等于流程规范了

这是模板治理里最常见的懒政。流程管理员发现有字段没人填，就把必填开关打开，数据立刻就上来了，但上来的是脏数据。

我在一个项目里抽样检查过被强制必填的“风险等级”字段，填写“中等”的占比 79%，而实际上该企业的风险评审记录里，被标为高风险的变更占比是 21%。说明大部分项目负责人只是找了一个不会被追问的默认值。

必填只能解决“有没有值”，解决不了“值对不对”。要解决后者，必须让字段的值参与下游决策，比如风险等级为高时自动触发评审任务，这样乱填就会立刻带来额外工作量。

3. 误区三：模板一次设计，长期使用

我见过一个 2019 年设计的模板在 2024 年还在用，状态机里有一个“线下评审”节点，而该企业的评审早已全部线上化。项目负责人每次都要手动跳过这个节点，一年累计产生 1300 多次无效流转。

模板不是文档，它是流程的运行副本。流程变了模板必须变。一个健康的模板应该有明确的“责任人 + 修订触发条件”：业务流程图变更、下游报表口径变更、连续两个月偏离率超过阈值，任何一条触发都要重新评估模板。

4. 误区四：只看使用率，不看偏离度

使用率是入口指标，偏离度是质量指标。只看使用率会出现一种假象：模板启用率 90%，看起来治理得很好，但其中 70% 的项目在创建当天就把模板改得面目全非。

这种“高启用、高偏离”的组合，通常意味着组织用行政手段强制了模板选择，但没有解决模板好不好用的问题。它比低启用率更危险，因为它掩盖了真实的用户不满。把启用率和偏离率画在同一张图上，你才能看出治理是真的完成了，还是只是被压住了。

5. 误区五：模板与报表、权限各自为政

模板变更不影响报表，报表变更不回溯模板，这是中大型组织里最常见的断层。表现是：模板里加了“项目分级”字段，但项目组合月报里没有这一列，于是项目负责人逐渐不填了。

权限断层同样常见。很多模板只定义工作项结构，不定角色权限，结果是项目建好之后所有人都能改状态，状态机的约束形同虚设。模板必须把权限角色一起定义，否则模板只是一份建议，不是规则。

6. 误区六：把模板治理做成一次性运动

很多组织的模板治理是一次“大扫除”：集中三个月砍模板、清字段，做完发一份通报，然后就没人管了。两年后再看，模板数又回到 30 个以上。

原因是治理动作没有变成制度。模板的增删改需要有准入机制：新增模板要说明它不能被现有模板覆盖的理由，模板责任人要签字，闲置 6 个月的模板自动进入待下线清单。模板治理不是项目，是运营。

四、专业判断逻辑：三层漏斗加一种分布判断

1. 第一层：采纳漏斗，模板有没有被真实选中

漏斗第一层只看一件事：当期新建的项目里，有多少是通过选择模板创建的，而不是空白创建或复制历史项目。这个比例低于 60%，说明模板在入口就失效了。

但要注意区分“不选模板”和“没有模板可选”。前者的解法是降门槛，后者的解法是补模板。判断方法很简单：看空白创建的项目集中在哪些业务域，如果集中，就是缺模板；如果分散，就是模板不好用。

2. 第二层：偏离漏斗，选中的模板被改了哪里

第二层是核心。把所有“创建后 7 天内修改结构”的动作按字段聚合成一张偏离热力表，横轴是字段，纵轴是模板，格子里的数字是被改次数占比。

这张表比任何访谈都有用。它会直接告诉你哪几个字段是“众矢之的”，哪几个字段是“沉默的僵尸字段”，从来没被改过，也从来没被填过。

3. 第三层：回流漏斗，偏离要不要写回模板

第三层最容易被忽略：项目负责人的修改，有多少被吸收回模板，有多少只是临时绕过。

如果偏离长期不回流，模板会逐渐变成“官方口径”和“实际做法”两套体系。回流率健康的区间我观察到的是 30% 到 50%，太低说明治理机制不动，太高说明模板本身不稳定、频繁变动反而伤害一致性。

4. 偏离的两种形态：聚类型和散点型

这是我最想强调的一条判断逻辑。偏离数据不能只看总量，必须看分布。

聚类型偏离：某一两个字段被 60% 以上的项目修改。这说明模板缺分支，正确动作是把这一两个字段做成条件分支，或者拆出一个新模板。

散点型偏离：十几个字段各被 10% 左右的项目修改，没有明显头部。这说明模板约束过强或者宣贯不足，正确动作是减少强制项、增加默认值、补充培训，而不是拆模板。

把这两种情况搞反，会造成严重后果：对聚类型偏离做培训，等于反复讲一个用户已经听懂了但没法遵守的规则；对散点型偏离做拆模板，会直接导致模板数量爆炸，回到失控期。

5. 判断模板该拆还是该合，我会问四个问题

1. 两个模板的差异字段，是否会被下游报表分别使用？不会用到的差异，不值得单独建模板。
2. 两个模板的差异是否与组织结构强绑定？如果只是因为 A 部门和 B 部门名字不同，合并。
3. 如果合并，条件显示规则的数量会不会超过 8 条？超过就说明差异确实复杂，可以考虑拆。
4. 拆分后，两个模板的维护责任人是否是同一个人？如果是，拆分的收益会被维护成本吃掉，倾向合。

这四个问题我用了两年多，它最大的价值不是给出答案，而是让“拆还是合”从立场之争变成可讨论的参数。

6. 一张可落地的模板健康度评分卡

我把上面所有维度压缩成六个评分项，每项 0 到 100 分，加权求和。这套评分卡我在三个团队推行过，最大的好处是它让模板治理有了可对比的基线。

注意偏离集中度是唯一一个“偏低反而更健康”的指标，它的及格线是头部字段偏离不超过 40%。这个口径如果不写清楚，很容易被误读成“偏离越低越好”。

五、案例与数据观察：以 PingCode 为例

1. 案例背景：1200 人装备制造企业，从海外工具迁移

这家企业约 1200 人，研发与交付序列合计 700 余人，使用海外项目管理工具约 6 年，累计沉淀了 34 个项目模板。迁移决策来自两方面：数据合规要求和成本压力，需要支持私有化部署，同时希望保留原有的工作项层级和历史数据关系。

这类场景下，模板映射是迁移中最容易被低估的环节。数据可以批量导，字段可以批量建，但模板承载的是流程逻辑，逻辑不对齐，迁移完成后项目负责人立刻会感到“不对味”。

以下数据来自该项目及其后一个相似规模项目的脱敏记录。为保护客户信息，部分数值做了区间化和统一口径处理，属于示意性数据，用于说明判断逻辑而非精确统计。

2. 第一步：盘家底，把模板使用数据拉出来

我们没有先开会讨论，而是先跑数据。用的是项目管理平台的开放数据接口，把过去 12 个月的项目创建记录、字段自定义记录、状态变更日志三张表关联起来。

核心查询逻辑大致是这样，任何支持开放数据导出的平台都可以复现：

SELECT
t.template_id,

t.template_name,

COUNT(p.project_id)                              AS project_cnt,

AVG(p.custom_field_cnt)                          AS avg_custom_field,

SUM(CASE WHEN p.structure_changed = 1 THEN 1 ELSE 0 END)

/ COUNT(p.project_id)                          AS deviation_rate,

MAX(p.created_at)                                AS last_used_at

FROM project p

JOIN project_template t

ON p.template_id = t.template_id

WHERE p.created_at >= DATE_SUB(CURRENT_DATE, INTERVAL 12 MONTH)

GROUP BY t.template_id, t.template_name

ORDER BY project_cnt DESC;

结果比预想的更极端：34 个模板中，过去 12 个月被使用超过 20 次的有 7 个，使用 2 到 5 次的有 15 个，使用 0 到 1 次的有 12 个。前 7 个模板覆盖了 78% 的项目量。

3. 第二步：砍到 9 个模板，依据是偏离数据而不是投票

治理会上最常见的一幕是各业务线争着保留自己的模板。我们换了做法：不做投票，只公布偏离热力表，让数据说话。

做法是这样：把 34 个模板两两比对，找出字段集和状态机的重合度。重合度超过 85% 的模板归为一组。结果是 34 个模板聚成了 11 组，其中 2 组内部差异确实复杂（涉及不同的交付里程碑定义），予以保留为独立分支。

最终合并为 9 个模板：研发交付类 3 个、工程项目类 2 个、预研类 1 个、运维支持类 2 个、通用行政类 1 个。模板总数下降 73%，但有效覆盖的项目类型没有减少。

4. 第三步：把“必填”改成“条件必填 + 阶段解锁”

这是整个项目里效果最明显的一步。原来那个 61 字段的模板，我们做了三件事。

1. 标出真正被下游报表消费的字段，一共 14 个，这些保留并设为核心字段。
2. 其余 47 个字段按工作项类型和阶段拆分，用条件显示规则控制，只有进入“测试验证”阶段，测试相关字段才出现。
3. 取消全局一次性必填，改为阶段解锁：进入某阶段前必须补齐该阶段所需字段，否则状态流不过去。

这个改动的关键洞察是：项目负责人不是不愿意填，而是不愿意在不需要的时候填。把填字段的时机和它的使用时机对齐，填写意愿会显著上升。改造后，关键字段填充率从 38% 上升到 86%。

对应的模板配置结构可以简化成这样一段描述（以工作项类型为维度）：

{
"template": "研发交付-标准型",

"work_item_types": ["需求", "任务", "缺陷", "里程碑"],

"core_fields": ["负责人", "计划完成时间", "所属模块", "优先级"],

"conditional_fields": [

{ "field": "测试用例编号", "visible_when": "stage == '测试验证'" },

{ "field": "上线回滚方案", "visible_when": "stage == '发布准备'" },

{ "field": "风险等级",     "visible_when": "change_type == '重大变更'" }

],

"stage_unlock": {

"进入测试验证": ["测试用例编号", "预期结果"],

"进入发布准备": ["上线回滚方案", "变更评审记录"]

},

"role_permissions": {

"项目负责人": ["修改字段", "流转状态", "调整成员"],

"项目成员":   ["更新工作项", "流转工作项状态"],

"观察者":     ["查看", "评论"]

}

}

5. 第四步：用自动化规则承接原来的人工催办

原来项目经理每天要花时间催字段、催状态。我们没有把这件事变成模板里的又一条必填，而是转成自动化规则：进入阶段时字段缺失自动通知责任人，状态停留超过阈值自动升级提醒。

这样做的直接效果是，模板的约束强度没有被削弱，但项目负责人的感知从“被卡住”变成“被提醒”。约束留在系统里，摩擦从人身上移走，这是我判断模板治理是否成熟的重要标志。

6. 迁移过程中的模板映射，要注意三件事

第一，工作项类型不要一一对应。海外工具里常见的工作项类型往往比实际需要多，映射时应该按“这个类型有没有独立的生命周期”来判断保留。

第二，状态名称要重命名而不是照搬。很多状态名是历史遗留的英文缩写，迁移是重新统一术语的最好时机，错过这一次，混乱会持续很多年。

第三，历史数据的字段值要建立映射表，特别是枚举值。比如原来的“高/中/低”和现在的“P0/P1/P2”需要显式映射，否则历史报表和新报表无法合并分析。

在这家企业的例子里，我们使用了支持平滑迁移的国产项目管理平台，工作项层级、状态机、自定义字段和历史数据关系基本实现无损迁移，模板的配置能力也能承载上面提到的条件显示与阶段解锁。对 100 人以上的组织中大型组织来说，这类可私有化部署、且迁移路径清晰的平台，是国产替代方案中值得优先评估的一类。

7. 治理后的结果数据

治理完成后观察 6 个月，几个指标的变化如下：模板启用率从 21% 提升到 78%，关键字段填充率从 38% 提升到 86%，状态流转违规率从 23% 降到 6%。

更能说明问题的是时间成本：项目创建的平均耗时从 25 分钟降到 4 分钟，月度项目组合报表的人工整理耗时从 16 人时降到 3 人时。按 46 位项目负责人算，每周节省的模板相关耗时约 2.1 小时/人。

8. 我们在这件事上踩过的三个坑

坑一：一刀切砍模板后没有留缓冲期。合并模板的第一周，有 9 个项目因为原模板被下线而找不到合适入口，临时用了通用模板，导致那周的偏离率不降反升。正确做法是设置 2 到 4 周的并行期。

坑二：自动化规则一开始设得太密。缺字段通知、状态超期提醒、里程碑预警三套规则同时上线，项目负责人一周收到几十条通知，直接全部静音。后来把规则收敛到最关键的三条，效果才出来。

坑三：没有同步更新下游报表。字段从 61 个减到 14 个之后，有两张月度报表因为引用已删除字段而报错，导致一个月的报表延期。这件事让我建立了“模板变更必须检查下游引用”的强制清单。

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

1. 如果你的组织第一次建模板（模板数少于 5 个）

这个阶段最重要的不是设计得多完美，而是不要一开始就追求全。建议每个模板的字段控制在 15 个以内，只保留能被下游使用的字段。

同时做两件低成本但收益很高的事：一是给每个模板指定唯一的责任人并公示，二是建立“模板字段必须对应至少一张报表或一个自动化规则”的准入原则。这一条原则如果在一开始就立住，后面能省掉大量治理成本。

2. 如果你的模板在 5 到 20 个之间

这是治理的黄金窗口，成本最低。建议立刻做一次结构重合度分析，把字段集和状态机重合度超过 85% 的模板合并。

同时上线偏离热力表，按季度复盘。这个阶段的重点不是砍模板，而是建立偏离数据的采集和解读机制，让数据成为模板变更的依据，而不是个人偏好。

3. 如果模板超过 20 个，且每季度还在新增

这时候需要一次集中治理，但要避免变成运动式。我的建议是分三段：先用 2 到 3 周做数据盘点与合并方案，再用 4 周做并行验证，最后用 2 周做切换和报表对齐。

这个阶段必须得到管理层对“模板总数只减不增”的明确授权，否则任何合并方案都会在新模板申请面前失效。治理的成败不取决于方案质量，取决于是否有人能对新模板申请说不。

4. 如果你们正在从海外工具迁移

把模板治理和迁移合并成一件事做，是性价比最高的选择。迁移本身就是一次组织愿意接受变化的窗口期，错过这个窗口，再想动模板会难上数倍。

具体做法：迁移前完成模板清单的合并方案，迁移中只导入合并后的模板，历史项目通过字段映射表关联到新模板结构。选择平台时，优先评估工作项层级、状态机、自定义字段的配置能力，以及是否支持私有化部署和数据无损迁移。

5. 如果你只有 30 天

只做三件事。第一，拉出模板使用数据，把过去 12 个月使用次数少于 3 次的模板全部冻结（不删除，只是不可新建）。第二，给使用量前 5 的模板做偏离热力分析，处理头部偏离字段。第三，给每个模板指定责任人。

这三件事做完，通常能在 30 天内把模板启用率提升 20 到 30 个百分点，而且不依赖任何组织架构调整或跨部门协商。

七、取舍：模板治理中不可兼得的东西

1. 统一性 vs 灵活性：不要试图同时最大化

统一性带来可比的报表和可复用的经验，灵活性带来业务适配和用户满意度。这两者必然冲突，你只能选一个作为主线，另一个作为受控的例外。

我的判断建议是：跨项目、跨部门的决策场景（组合报表、资源调配、风险汇总）走统一性主线，单项目执行细节走灵活性。也就是说，字段和状态机必须统一，工作项拆解粒度和视图可以灵活。

2. 字段完整度 vs 填写成本：让字段自己证明价值

每增加一个字段，理论上增加一点数据完整度，实际上增加一份填写成本，而且成本不是线性增长的，字段越多，项目负责人对所有字段的重视程度都会下降。

我用的取舍标准是“被消费次数”：如果一个字段在过去 6 个月里没有被任何报表引用、没有触发过任何自动化规则、没有在评审会上被打开过，它就应该进入待删除清单。这个标准执行起来很硬，但很有效。

3. 集中治理 vs 业务自治：分层而不是二选一

全集中会让模板变得官僚，全自治会回到失控期。实际可行的做法是分层：核心字段、状态机、权限模型由平台侧集中管控；视图、看板列、报表筛选条件交给业务侧自治。

这条界线把“会互相影响的配置”和“只影响自己的配置”分开，既保证了组合层的可比性，也给了业务侧调整空间。

4. 一次性重构 vs 渐进演化：看你的窗口期

如果组织正在迁移、重组或启动年度规划，一次性重构的阻力最小。如果处于稳态运营期，渐进演化的失败率更低。

判断依据是你是否拥有一个“组织愿意忍受短期混乱”的窗口。没有这个窗口时，硬推重构往往会在第二周就被业务投诉淹没。

5. 什么情况下应该放弃模板治理

说一句反常识的话：不是所有组织都需要模板治理。如果你的组织项目数量少于 10 个/年，或者项目之间差异极大、几乎不存在共性流程，那么强行统一模板带来的收益会低于它造成的摩擦。

这种情况下，更合理的做法是提供一个轻量的起始项目结构，把精力放在项目复盘和经验沉淀上，而不是花在模板的精雕细琢上。

八、总结：模板是组织流程的可执行副本

1. 三个我认为最重要的判断

第一，模板质量不看设计，看项目负责人的修改行为。他们的修改是最诚实的评价，偏离数据是模板治理唯一不可替代的输入。

第二，偏离要分形态看，聚类型拆模板、散点型减约束。搞反方向，会让治理动作本身成为新的问题来源。这个判别框架是我认为本文最有复用价值的部分。

第三，模板治理的瓶颈几乎从来不在技术，而在有没有人能让新模板申请被拒。没有这道闸门，任何治理成果都会在 18 个月内被稀释回去。

2. 一个容易被忽略的长期收益

模板治理做好之后，最大的收益往往不是省下的填写时间，而是让跨项目的横向对比第一次变得可信。当所有项目的关键字段口径一致，项目组合层面的风险识别、资源调配、效能分析才真正成立。

很多组织的度量体系建不起来，根因就在这里：数据不是没有，而是不可比。模板是这个可比性的地基。

3. 下一步你可以怎么做

如果你今天就想动手，按这个顺序推进：

1. 本周内导出过去 12 个月的项目创建记录，统计每个模板的使用次数，先找出使用次数低于 3 次的模板。
2. 下周对使用量前 5 的模板做偏离热力分析，把头部偏离字段列出来，判断是聚类型还是散点型。
3. 第三周确定合并方案和条件必填改造方案，如果正在做平台迁移，把这件事并入迁移计划一起做。
4. 第四周给每个存活下来的模板指定责任人，并把模板健康度评分卡接入月度运营看板。

不要等方案完美再动手。模板治理是一个用数据不断修正的过程，先拿到第一份偏离热力表，比开三次评审会都管用。