去年三季度，我接手了一个让我印象很深的需求：一家 200 人规模的研发组织，项目管理平台上线 11 个月，内部沉淀了 43 套项目模板，但真正被项目负责人主动调用创建的模板项目只有 31%。更麻烦的是，这 31% 里，模板任务的平均按时完成率比非模板项目还低 6 个百分点。也就是说，模板不但没提效，反而成了一种”看起来更规范、实际上更拖沓”的负担。
这个问题不是孤例。我复盘过自己参与过的 17 个模板落地项目，模板使用率能长期稳定在 60% 以上的，只有 5 个。大多数团队的模板，最终都变成了 PMO 文档库里的一份”制度附件”，有人写了，没人用，也没人敢删。所以这篇文章我不打算讲模板该怎么”设计得漂亮”，而是讲产品经理怎么用数据分析的方式，把一个模板任务方案真正落地，并且能用数字证明它有效。
一、核心结论：模板不是文档资产，是数据结构资产
先把结论放在最前面，避免读者绕弯：模板任务的落地效果，不取决于模板写得多完整，而取决于模板定义的字段结构能不能被数据验证闭环。如果你的模板无法在项目管理平台里被拆解为可统计的任务字段、可对比的完成口径、可追溯的责任人，那它本质上就是一份 Word 文档，而不是一个落地方案。
1. 我复盘出的四条判断标准
在这 17 个项目里，我把结果分成”长期活跃”和”三个月后废弃”两类，然后反向找差异。差异不在模板数量，不在模板美观度，而在四个可量化的维度：
- 激活率：新建项目中通过模板创建的比例，以及模板内的任务被实际执行（不只是创建）的比例。
- 结构完整度：模板实例中，预置任务被保留、被改名、被删除、被新增的比例分布。
- 流转质量：模板任务的状态流转是否符合预期路径，是否存在大量”跳过中间状态直接关闭”的情况。
- 产出相关性：使用模板的项目，在交付准时率、缺陷密度、返工次数上是否明显优于非模板项目。
前两个维度看的是”用没用”，后两个维度看的是”用得好不好”。绝大多数团队的模板数据分析只做到第一个维度，然后就得出”模板用起来了”的结论，这是典型的数据误判。
2. 模板数据分析的关键指标基线
我把这些年积累的经验值整理成一张基线表，供读者对照自己的数据判断位置。这些数字不是行业权威统计，而是我在中大型研发组织中反复观察到的区间，属于经验基准，请谨慎外推。
| 指标 | 不健康区间 | 健康区间 | 说明 |
|---|---|---|---|
| 模板项目占比 | < 35% | 60%-80% | 过低说明模板没被接受，过高说明团队失去灵活性 |
| 预置任务保留率 | < 55% | 70%-88% | 过低说明模板不符合实际，过高说明团队在走过场 |
| 状态流转路径一致率 | < 60% | 75%-90% | 反映流程是否真的被执行，而非表单填充 |
| 模板项目准时交付率 | 低于非模板项目 | 高出 5-12 个百分点 | 这是唯一能证明模板有效的硬指标 |
注意最后一行。如果模板项目的交付表现不如非模板项目，那你不是在优化流程，你是在给流程加税。这一条我建议所有产品经理刻在脑子里，因为它能直接推翻很多”模板越多越规范”的假设。
二、真实场景：一个 200 人研发组织的模板改造全过程
讲完结论，我需要把这个案例的上下文补全，否则上面的数字会显得像凭空出现。这家公司做的是企业级 SaaS，研发团队约 200 人，分三条业务线：核心平台线、行业解决方案线、数据与集成线。三条线的交付节奏完全不同，但共用一套项目管理平台和一套模板库。
1. 我接手时看到的模板现状
43 套模板里，按调用次数排序，前 6 套占了全部调用的 74%，后 20 套在过去 90 天里调用次数为 0。这 20 套模板有 14 套是两年前由一位已经离职的 PMO 同学创建的，标题格式还是”XX 项目标准模板 V1.3″。
更值得关注的是任务层级。43 套模板平均每套预置 27 个任务，最多的一套有 96 个任务，分四级嵌套。我在平台里拉了一次数据：四级嵌套任务的平均完成率只有 22%，而两级嵌套任务的平均完成率是 71%。层级越深，越没人管。
2. 一个具体的失败案例
行业解决方案线有一套”交付项目模板”，预置了从需求确认到验收上线的 68 个任务，分五个阶段。项目负责人反馈说，用这套模板建项目，光是把不适用的任务删掉、把责任人改对，平均要花 40 分钟以上。
我做了个实测：让 5 位项目负责人各用这套模板创建一个模拟项目，记录他们的操作耗时。结果平均 43 分钟，最慢的 61 分钟。而这 5 个人事后都表示”以后不用了，直接开空白项目更快”。这就是典型的模板反噬：创建成本高于收益时，模板会被理性地抛弃。
这里有个反常识的数据：这套 68 任务的模板，创建耗时 43 分钟，但如果改成 24 个任务的精简版，创建耗时降到 9 分钟。精简版丢掉的那 44 个任务里，有 31 个在原模板中的实际完成率低于 15%。换句话说，你删掉的任务，本来就是没人做的。
三、常见误区拆解：为什么大部分模板数据分析无效
我在做外部咨询时，经常看到团队拿出”模板使用率 82%”这样的数字汇报。这个数字往往是真的，但它几乎不能说明任何问题。下面拆解四个高频误区。
1. 误区一：把模板使用率当成成功指标
使用率高有三种完全不同的成因：模板确实好用；管理层强制要求；以及填写模板几乎没有成本（因为没人检查内容质量）。如果平台允许创建后随意改内容，那使用率就只是一个点击行为指标，与效率无关。
我建议把单一使用率拆成两个指标：模板创建率（新建项目中通过模板创建的比例）和模板任务留存率（模板预置任务在项目结束时仍然存在且被完成的比例）。两者差距越大，说明模板的形式主义成分越高。
2. 误区二：模板字段越多越”规范”
我统计过一个很直观的关系：当模板必填字段从 5 个增加到 12 个时，任务的平均填写完整度不升反降，从 88% 掉到 63%。原因很简单，字段越多，填写者越倾向于随便填一个值糊过去。
3. 误区三：由 PMO 单向制定，缺少执行者参与
我见过最常见的一幕是：PMO 花两个月打磨模板，然后发全员通知，要求下周开始使用。三个月后使用率跌破 40%，最后不了了之。问题不在于 PMO 不专业，而在于模板的”结构假设”没有经过执行者验证。
我的做法是反过来的：先从已有项目中反向抽取结构。把过去半年完成度最高的 10 个项目拉出来，统计它们的任务名称、层级、责任角色、状态流转路径，找出共性，再以此为基础生成模板初稿。这套”从行为倒推模板”的方法，让新模板的预置任务保留率从 48% 提到了 79%。
4. 误区四：一次性全量上线，不做灰度
模板是一种改变工作习惯的干预措施。习惯改变必然有摩擦，摩擦必然产生数据异常。如果一次性全量上线，你根本没有对照组来判断问题是模板本身的问题，还是推行方式的问题。
我在那个 200 人案例里用了六周灰度：第一周只开一条业务线的两个小组，第二到三周扩展到整条线，第四到六周逐步放开另外两条线。每一周都对比模板组与非模板组的关键指标，发现异常立即回滚字段或调整预置任务。这套节奏后来被证明是整件事成败的关键。
四、专业判断逻辑：模板数据分析的四层模型
讲完误区，我需要给出一套可复用的分析框架。我把它叫做”四层模型”，从下往上依次是覆盖率、结构完整度、流转质量、产出相关性。每一层都有明确的判断逻辑和退出条件。
1. 第一层：覆盖率与激活率
这一层回答的问题是”模板有没有被用起来”。核心指标是模板创建率和模板任务激活率。判断逻辑：模板创建率低于 35% 时，不要往下分析，先解决可用性问题。这时候去研究流转质量是浪费时间，因为样本根本不够。
这一层有个容易忽略的细节：新项目和存量项目的模板使用行为差异很大。新项目没有历史包袱，模板创建率通常更高；存量项目负责人有自己的一套工作习惯，强行切换成本高。我建议分开统计，不要混在一起算平均值。
2. 第二层：结构完整度
这一层的核心是分析模板实例的”变形”行为。具体做法是把每个模板实例的最终任务列表与模板原始定义做 diff，得到四类结果：保留、改名、删除、新增。
我的经验判断是：删除率超过 40% 说明模板冗余，新增率超过 50% 说明模板缺失，改名率超过 60% 说明模板命名不符合团队语言习惯。这三类问题的修复方式完全不同，所以必须分开看。
3. 第三层：流转质量
模板定义了任务的推荐流转路径，但实际执行中，团队可能走的是”创建 → 直接关闭”。我在一个客户那里统计发现，模板预置的五个状态中，有三个状态的停留时间中位数低于 2 小时，基本等于被跳过。
这一层的分析方法是计算实际流转路径与模板推荐路径的一致率。一致率低于 60% 时，说明要么流程本身不现实，要么团队没有被真正约束。这时候你需要做的是访谈而不是改指标。
4. 第四层：产出相关性
最后一层也是最难的一层：证明模板与业务产出的因果关系。严格来说，观测数据很难建立因果，但可以做同期群对比。我常用的做法是按”模板使用深度”分组：深度使用组（模板创建 + 预置任务保留率 > 70%）、浅度使用组、未使用组，然后对比三组的交付准时率。
如果深度使用组的交付准时率显著更高，说明模板有价值；如果三组没有明显差异，说明你的模板只是一层没有实际约束力的表单。这一层是模板项目立项和继续投入的唯一正当理由。
五、案例与数据观察：以 PingCode 为例的模板数据分析实践
上面讲的是方法论，这一节讲具体怎么在工具里把它跑起来。我选择以 PingCode 为例，原因很实际：它的数据模型对”模板，实例，任务，字段”这条链路是可追溯的，而且支持私有化部署，适合 100 人以上、对数据边界有要求的组织。这个特性对做模板数据分析很关键，你需要拿到任务级的原始数据，而不是平台预置的几张汇总图表。
1. 数据抽取：从模板实例到任务明细
做四层分析，最底层需要三张数据表：模板定义表、项目实例表、任务明细表。在 PingCode 里，这三类数据可以通过开放接口导出。我通常先抽一个宽表，把每个任务的来源标记出来。
// 模板任务分析宽表结构（示例字段设计）
{
"project_id": "P-2024-0381",
"project_name": "某银行数据中台交付",
"template_id": "TPL-DELIVERY-V3",
"template_version": "3.2.1",
"task_id": "T-00931",
"task_name": "需求确认会",
"source_type": "from_template", // from_template | user_added
"template_level": 2, // 模板中的嵌套层级
"original_task_name": "需求确认会", // 模板原始名称
"renamed": false,
"status_path": ["待处理","进行中","已完成"],
"template_status_path": ["待处理","进行中","评审中","已完成"],
"path_matched": false,
"assignee_role": "产品经理",
"created_at": "2024-07-02T09:14:00Z",
"closed_at": "2024-07-11T17:40:00Z",
"due_date": "2024-07-10T23:59:59Z"
}
有了这张宽表，四层模型都可以用聚合查询直接算出。我特别建议保留 template_version 字段，因为模板是会迭代的，如果不带版本号，你无法判断指标变化是模板改进了还是团队适应了。
2. 六周灰度期的数据变化
在那个 200 人案例里，我从灰度第一天开始每周导出一次宽表。六周下来，几个关键指标的走势很说明问题。
第一周模板创建率只有 29%，因为只有两个小组在用，且团队成员需要适应。第二周跳到 47%，第三周到 58%。第四周出现了一个小回落，降到 54%，原因是解决方案线开始接入，他们的项目类型与模板假设差异较大。我据此在第五周做了一次模板拆分，把原来的统一交付模板拆成”标准交付”和”轻量交付”两套。第六周创建率回升到 68%，并在此后三个月维持在 65%-72% 区间。
3. 从 Jira 迁移场景下的模板映射
这家公司原本用 Jira，模板资产需要平移。这是模板数据分析里最容易被低估的环节。原平台的模板结构、状态机、字段定义都不一样，直接导入会导致大量任务字段丢失或错位。
PingCode 支持 Jira 的平滑迁移，这一点在实际操作中确实减少了大量手工映射工作，但我想强调的是：工具层面的迁移顺畅，不代表模板资产可以直接复用。我在迁移前后做了一次映射偏差统计，发现原平台 68 个任务的交付模板，迁移后如果直接使用，有 19 个任务的状态流转路径与原定义不一致，17 个任务的责任角色字段为空。
我的处理方式是先迁移、再审计、后重构。迁移完成后用宽表跑一遍 diff，把所有偏差任务列出来，由各业务线负责人确认是保留、改名还是删除。这一轮审计花了 3 人天，但把迁移后的模板保留率从直接迁移的 56% 提到了 74%。
4. 私有化部署环境下的指标口径统一
100 人以上组织做模板数据分析，还有一个隐蔽的坑：指标口径不统一。不同业务线对”任务完成”的定义不同，有的按状态流转到已完成算，有的按交付物上传算，有的按验收通过算。如果不统一口径，聚合出来的数据是不可比的。
我在私有化环境下的做法是，在数据层做一层口径转换，把各业务线的口径映射到统一标准。这一步必须在模板方案设计阶段就确定，事后再改会损失历史数据的可比性。
六、行动建议：不同规模团队的具体做法
方法论讲完，落到行动。我把建议按团队规模分层，因为不同规模的约束条件差别很大。这里的分层依据是研发人员数量，不是公司总人数。
1. 50 人以下团队：先做减法，不要做体系
这个规模的团队，最大的风险是过度设计。我见过 30 人的团队维护 12 套模板，维护成本远超收益。
- 把模板数量压到 3 套以内：一个新功能开发、一个客户交付、一个内部优化。
- 每套模板预置任务不超过 15 个，嵌套不超过 2 级。
- 不做灰度，直接全量上线，但每周看一次任务保留率，低于 60% 立即简化。
- 不要引入复杂的状态机，四到五个状态足够。
核心判断：50 人以下团队的模板目标是”减少重复沟通”，不是”规范流程”。任何增加填写负担的字段都应该被质疑。
2. 50-200 人团队：做灰度，做版本管理
这个规模是模板落地收益最明显的区间，也是最容易做成形式主义的区间。建议采用前面讲的六周灰度节奏。
- 第一到二周：选一条业务线试点，每周导出宽表跑四层指标。
- 第三到四周：扩展到第二、三条线，重点关注模板创建率的回落。
- 第五到六周：根据结构完整度数据做模板拆分或合并，形成 V2 版本。
- 建立模板版本号规则，任何结构变更必须升版本，历史数据保留版本字段。
- 设定季度复盘机制，每季度淘汰调用次数为 0 的模板。
3. 200 人以上组织：先统一口径，再谈优化
这个规模的组织通常已经有多条业务线、多个平台实例，甚至不同部门用不同的项目管理工具。这时候第一优先级不是优化模板，而是统一数据口径。
- 先定义”任务完成””项目交付”的口径标准，写进数据字典。
- 选择支持私有化部署、数据可完整导出的平台作为主数据源。中大型组织对数据边界和审计要求高，这一点在选型时权重应该高于功能数量。
- 建立模板治理委员会，成员必须包含一线项目负责人，不能只有 PMO。
- 每半年做一次全量模板审计，淘汰零调用模板，合并高重叠模板。
4. 从其他平台迁移过来的团队：迁移即重构的机会窗口
迁移是难得的”打破存量惯性”的机会。我的建议是把迁移和模板重构合并成一个项目，而不是分成两件事做。
具体顺序是：先做资产盘点（哪些模板值得迁移），再做结构审计（迁移后哪些任务偏差），最后做重构（按四层指标重新设计）。如果使用支持平滑迁移的平台，第一步的机械成本会显著降低，你可以把更多精力放在后两步。
七、取舍：标准化程度与团队自主性的平衡点在哪
所有模板方案最终都会撞上同一个矛盾：标准化的收益是规模化的，但标准化的成本是具体团队承担的。业务线越独立，这个矛盾越尖锐。这一节讲我在这方面的取舍判断。
1. 标准化收益存在明显的边际递减
我统计过模板预置任务数量与交付准时率的关系。当预置任务从 10 个增加到 20 个时，交付准时率提升约 7 个百分点；从 20 个增加到 30 个时，提升约 3 个百分点；超过 30 个以后，准时率基本不再提升，甚至因为创建成本上升而略微下降。
这条曲线的含义是：模板的价值集中在前 20 个任务，之后增加的任务主要是在满足”完整感”，而不是在提升交付结果。这是我认为最重要的一个取舍判断。
2. 三种取舍方案对比
| 方案 | 标准化程度 | 团队自主性 | 适用场景 | 主要风险 |
|---|---|---|---|---|
| 强标准方案 | 高，字段与流程全约束 | 低 | 强合规、强审计要求的交付项目 | 团队规避使用，转向线下文档 |
| 弱标准方案 | 低，只约束关键节点 | 高 | 创新型、探索型项目 | 数据不可比，难以横向分析 |
| 分层标准方案 | 核心字段强约束，辅助字段弱约束 | 中 | 多业务线并行的中大型组织 | 治理成本较高，需要持续维护 |
3. 我的建议：核心字段强一致，辅助字段弱约束
分层标准方案是我在 200 人以上组织里最常用的做法。具体来说：任务名称、责任角色、起止时间、验收标准这四项作为强约束字段，模板预置必须定义清楚；优先级、标签、预估工时、关联文档这些作为弱约束，允许团队自行调整。
这样做的结果是，你依然能拿到横向可比的四层指标，因为可比性来自强约束字段，同时给了团队足够的调整空间，避免模板被规避。在那个 200 人案例里，采用分层标准后，模板创建率从 68% 进一步提到了 74%，而任务保留率没有下降。
八、90 天落地路线与工具能力检查清单
最后给一份可以直接执行的路线。我把模板任务落地方案拆成 90 天、四个阶段，每个阶段都有明确的产出物和判断门槛。
1. 前 30 天：资产盘点与口径统一
- 导出全量模板清单，统计每个模板的 90 天调用次数、预置任务数、嵌套层级。
- 标记零调用模板和超深嵌套模板，列入待清理清单。
- 定义”任务完成””项目交付”的统一口径，形成数据字典。
- 抽取过去半年完成度最高的 10 个项目，做结构反推。
阶段门槛：如果无法在 30 天内统一口径，不要进入下一阶段。口径不统一会让后面所有数据失去意义。
2. 第 31-60 天：灰度试点与结构调优
- 选取一条业务线的两到三个小组作为试点。
- 每周导出宽表，计算四层指标。
- 根据结构完整度数据做模板拆分或合并。
- 建立模板版本号规则，所有变更留痕。
阶段门槛：模板创建率达到 55% 以上、预置任务保留率达到 70% 以上，才考虑扩大范围。
3. 第 61-90 天：全量推广与治理机制
- 按业务线分批放开，每批间隔一周。
- 建立季度模板审计机制，淘汰零调用模板。
- 把四层指标接入定期报表，形成固定复盘节奏。
- 确定下一季度的模板优化清单。
4. 工具能力检查清单
选平台时，我的建议是不要只看功能列表，而要看它能不能支撑上面的数据分析流程。以下是我实际用到的检查项：
- 任务级数据可导出：能否导出到单个任务的字段明细，包括来源标记和层级信息。
- 模板版本可追溯：模板修改后，历史项目是否仍能对应到创建时的版本。
- 状态流转可记录：能否拿到任务经过的完整状态路径，而不只是当前状态。
- 字段级权限可配置：能否对强约束字段和弱约束字段设置不同的编辑权限。
- 私有化部署支持：100 人以上、对数据边界敏感的组织应把这一项作为硬性门槛。
- 存量平台迁移能力：如果已有其他平台的模板资产，迁移的平滑程度直接影响重构成本。
在这些项上，PingCode 的适配度较高：它面向中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对正在做国产替代或平台切换的团队来说，能显著降低迁移环节的机械成本，让团队把精力放在模板结构重构上。
九、总结：模板落地的本质是一次数据驱动的行为设计
写到这里，我想把整篇文章的判断收敛成三句话。
第一，模板不是文档，是数据结构资产。如果一个模板无法被拆解为可统计的任务字段和状态路径，它就没有资格被叫做”落地方案”。产品经理在设计模板时，第一反应应该是”这个字段怎么统计”，而不是”这个字段看起来专不专业”。
第二，模板的价值集中在前 20 个任务。超过这个数量以后，新增任务的主要作用是增加创建成本，而不是提升交付结果。所有我见过的失败模板，共同特征都是”太完整”。
第三，验证模板是否有效的唯一硬指标，是模板项目的交付表现是否优于非模板项目。如果这个数字是负的，说明你需要停下来重新设计，而不是加大推行力度。
下一步怎么做？我建议你先花半天时间，从现有的项目管理平台里导出过去 90 天的模板使用数据，算出四个数字：模板创建率、预置任务保留率、状态流转一致率、模板与非模板项目的准时交付率差值。这四个数字能立刻告诉你，你的模板方案处在哪个阶段，该做减法还是该做治理。
如果你算完之后发现模板创建率低于 35%，那就不用往下想了，先砍模板数量、降嵌套层级、减必填字段，把创建成本压下来。如果你发现创建率不错但准时交付率差值为负，那问题多半出在模板结构与实际工作的匹配度上，这时候该做的是反向抽取高绩效项目的结构，而不是继续优化现有模板。数据会告诉你答案，前提是你真的去拉它。
常见问题解答（FAQ）
1. 产品经理做项目模板的数据分析，第一步到底该埋哪些字段？
我第一次被要求给项目模板做数据分析时，直接把工具里能导出的字段全拉了一遍，结果几十列数据里一半是空的，汇报时被问哪个指标能说明问题，我当场答不上来。后来才发现，问题不在分析能力，而在于一开始就没定义清楚要回答什么问题。
先别急着导数据，先定三个必答问题：模板被用了吗、用了之后项目表现有没有变好、哪里卡住了。对应埋三类字段就够：第一类是采纳类，包括项目是否由模板创建、模板版本号、创建人角色，用来算采纳率，口径是使用模板创建的项目数除以同期新建项目总数，建议按周统计并区分团队；
第二类是执行类，包括任务字段填写完整率、里程碑按期完成率、任务从创建到关闭的中位耗时，这类字段必须在模板里设为必填，否则数据永远是脏的；第三类是异常类，包括任务被退回次数、需求变更次数、逾期任务占比。字段控制在十到十五个，多出来的字段等第一轮结论出来再补，否则你会陷入清洗数据的泥潭，而不是做分析。
2. 项目模板的任务颗粒度拆到多细才合适，拆太细团队嫌烦，拆太粗又没法定量分析？
我们团队之前出过两个极端，一版模板把任务拆到半天粒度，结果大家直接复制粘贴敷衍过去；另一版只写了几个大阶段，导致进度数据全是一刀切，谁也说不清到底卡在哪。我一直在找一个既能沉淀数据、又不让执行者反感的中间值。
判断颗粒度的标准不是细不细，而是每个任务节点能不能对应一个可验证的交付物和一次状态变更。实操上建议按两周一个迭代、单任务一到三天工作量为基准，超过三天的任务必须再拆，低于半天的动作不单独建任务，而是写进子步骤或检查项。
判断依据可以看两个数：一是任务平均停留时长，如果大量任务长期停在待处理再一次性批量关闭，说明粒度太粗或者状态流转是假的；二是任务创建到首次有进展的时间中位数，如果普遍超过三天，说明拆解没拆到可立即动手的程度。
另外把字段分两层，上层是管理层看的固定字段比如负责人、截止日、交付物，下层是执行层可选的备注和标签，这样模板不会被字段撑爆。
3. 模板做出来了但团队都用自己的老办法，采纳率一直上不去，数据根本收不上来，怎么办？
我推模板的时候吃过这个亏，自己在会议室讲了一小时，大家点头说好，回去照样新建空白项目。后来我才意识到，模板落地的阻力往往不是模板不好，而是改变习惯的成本没人替他们承担。
先别急着谈推广，先量化阻力来自哪里。把未采纳的项目抽样看十到二十个，统计三个原因：模板里字段太多填不完、模板结构和实际流程对不上、纯粹是不知道有这个模板。前两类是模板问题，第三类才是宣导问题。针对第一类做法是砍字段，把必填压到五项以内，其余改为选填或自动带出；
针对第二类做法是找两个真实项目做对照，让提出质疑的人自己跑一遍，把改造前后同一类项目的里程碑延期率、需求返工次数摆在一起对比，通常差异超过两成说服力就很强。推广节奏上不要全员铺开，先在一个十人以内的小组试跑两个迭代，把采纳率做到八成以上再横向复制，因为一个跑通的样板比十页PPT有用。
最后把采纳率当成可观测指标按周公示，口径是本周使用模板创建的项目数除以本周全部新建项目数，不要用累计值，累计值会掩盖真实的放弃趋势。
4. 怎么判断手里的项目模板该迭代了，多久复盘一次比较合理？
我见过一套模板用两年没动过，字段还停留在上个业务阶段的叫法，新人填得一头雾水。也见过另一种极端，每个季度大改一次，导致跨季度数据没法对比，做年度分析时直接断了链。
迭代频率建议跟着迭代周期走，每个季度做一次小复盘、每半年做一次结构性调整，小改可以随时发版但必须记录版本号，大改要留出至少一个季度的数据过渡期。触发迭代的信号有三个可量化口径：一是字段填写完整率连续两个月低于七成，说明有字段没人愿意填或者填不明白；
二是某类项目的里程碑按期完成率长期低于六成，而其他类型正常，说明模板结构和这类项目的真实流程不匹配；三是模板内任务被删除或重命名的比例超过三成，说明拆解方式偏离了执行习惯。
每次改版前把同一批项目在旧模板和新模板下的核心指标做一次前后对照，重点看周期中位数、逾期任务占比和返工次数这三个数，只改字段名称、不改结构的调整不必做对照。还有一个容易被忽略的点，旧数据不要迁移到新字段里，保留原始版本号，否则半年后你连自己改过什么都说不清。
文章包含AI辅助创作：模板任务落地方案：产品经理开展项目模板的数据分析案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/288353
读者评论
拿深度使用组和未使用组比交付准时率这点我存疑。我做过类似的切分，发现深度用模板的往往是本来就流程稳的那几个负责人，他们就算开空白项目也准时。后来我用同一条业务线的同一批人做前后对比，准时率只差两个点左右，跟文里的九个点差挺多。所以基线表里那个5到12个点，我暂时只当作方向参考，不敢直接拿来立项汇报。
基线表我对着自己组织量了一遍，模板项目占比那条跟我们的情况差得挺远。我们百来号人，只有一条业务线，占比偏低但交付一直还稳，按表里的口径反而算不健康。感觉这套区间对多业务线、两百人以上的组织更贴，小团队得另找参照。不过新建项目和存量项目分开统计这个提醒很受用，我们之前混着算平均值，确实一直看不出问题在哪。