去年年底，我帮一家 400 人规模的研发组织做项目管理复盘，翻出一份很有意思的记录：这个团队在三年的时间里正式发布过四版项目模板，每一版都在评审会上拿到了超过 90% 的赞成票，但真正在项目里被完整使用的比例，从未超过 30%。更微妙的是，第四版模板的存活周期只有 11 周，比第三版还短了 6 周。这件事让我确认了一个判断：模板落地失败，几乎从来不是模板本身写得不好，而是没有人给模板配一套制度。
这份复盘后来变成了我在多个组织里反复使用的一套方法论。它不讨论”项目模板应该包含哪些字段”这种文档层面的问题，而是回答一个更前置的问题：谁有权改模板、谁能不遵守模板、违反之后发生什么、模板多久复盘一次。这些问题的答案合在一起，就是本文要讲的”模板流程落地方案”。
一、先把结论说清楚：模板落地的成败，取决于制度而非文档
在展开案例之前，我先把几个可能有点反直觉的结论摆出来，后面所有内容都是围绕这几条展开的。
1. 模板的价值不在”统一格式”，而在”降低决策成本”
很多项目经理做模板时，出发点是把格式统一起来，让汇报材料看起来整齐。但从我跟踪过的十几个团队来看，真正让成员愿意用模板的原因只有一个：照着模板做，比不照着做更省事。
如果模板要求填写的字段，成员在实际工作中本来就要想清楚，那模板是在帮他做决策；如果模板要求填的字段，他本来不需要想，那模板就是在给他增加负担。前者会自我强化，后者会被悄悄绕过。
2. 模板的强制程度必须有梯度，不能一刀切
“全部强制”和”全部可选”是两种最常见的失败设计。全部强制会让模板在复杂度上升后被整体抛弃，全部可选会让模板退化成一份没人看的参考文档。我见过的可持续设计，都是把模板切成三层：必须填的、建议填的、可以留空的，并且每层的边界由项目风险等级决定，而不是由模板作者的好恶决定。
3. 模板是需要维护期的资产，不是一次性交付物
我统计过自己参与过的 9 个模板落地项目，模板在发布后的前 90 天内，如果没有任何一次小版本迭代，其在第 6 个月的完整使用率平均只有 19%；而在这 90 天内做过至少两次迭代的模板，第 6 个月的完整使用率平均能到 61%。模板的第一次迭代速度，比模板初稿的质量更能预测它能不能活下来。
4. 模板的治理成本必须显性化
我见过太多项目把模板治理当成”顺手做的事”，结果就是没人做。一个健康的模板制度，应该明确写出维护它需要多少人力投入，并且把这个投入写进某个人或某个角色的职责里。
根据我自己的记录，一个 200 人左右的研发组织，维护一套覆盖 4 类项目类型的模板体系，稳态下大约需要每年 8 到 14 个人天，分布上大约是每季度 2 到 3 个人天。这个数字听起来不大，但如果没有被显性化，它就会在第一个季度之后归零。
二、背景与真实场景：我亲历的三次模板落地
下面这三个场景都来自我实际参与的项目，涉及的组织规模从 60 人到 500 人不等。我会把当时的具体做法、观察到的数据和最后的结局都写出来。
1. 场景一：200 人研发组织的”模板大礼包”
这家公司做企业软件，研发加产品大约 210 人，分为 4 条业务线。2021 年，他们的 PMO 花了两周时间，参考外部资料做了一份包含 46 个字段的项目立项模板，覆盖范围、里程碑、风险、干系人、预算等模块。
上线方式是全员邮件加一次 90 分钟的培训。第一周，新立项的 7 个项目里有 6 个使用了模板。第三周，这个数字变成 2 个。到第九周，只有 1 个项目还在用完整模板，其余项目要么只填了前 10 个字段，要么干脆在项目群里用几句话说明。
我后来做了归因访谈，成员给出的理由高度集中在两条：一是填写一次要花 30 到 40 分钟，但其中至少一半字段在立项时根本不知道答案；二是填完了也没人看，没有任何反馈。这两条都是制度问题，不是模板问题。
2. 场景二：60 人团队的”轻模板”为什么反而活了
另一家做 SaaS 的公司，研发加产品只有 58 人，单业务线。他们的做法完全不同：立项模板只有 9 个字段，其中 3 个必填（目标、成功标准、负责人），6 个选填。必填字段要求在项目创建后 24 小时内填完。
关键差异在后面。他们规定每两周的项目例会必须回看模板里的”成功标准”字段，如果发现当初写得不清楚，就在会上当场改，改完记进模板变更日志。一年下来，这份模板从 9 个字段长到了 14 个，又缩回到 11 个，最终稳定在 12 个字段。
我跟踪的这项制度执行到第 12 个月时，新项目立项后的模板完整填写率是 71%，而且团队成员普遍反馈”不填反而更麻烦”，因为例会要用。
3. 场景三：工具迁移时被忽略的模板断层
第三个场景是我印象最深的。一家 500 人规模的制造企业研发中心，原来用的是海外项目管理工具，后来因为合规和数据主权要求，需要迁移到支持私有化部署的国产平台。
迁移项目组做了大量数据映射工作，工单、缺陷、需求都迁得很干净。但他们忽略了一件事：原平台上的项目模板，是靠大量自定义字段和工作流状态拼出来的，迁过去之后字段还在，但字段之间的联动规则和触发逻辑没有同步重建。
结果是迁移完成后，新项目的模板表面上看和旧的差不多，但填完之后不会像以前那样自动分配审批人、也不会自动推进状态。团队用了三个月才发现这个问题，期间积压了大约 140 个”填了但没生效”的项目记录，清理花了整整 9 个人天。
三、拆解常见误区
在讲怎么设计制度之前，有必要先把几个高频误区说透。这些误区我自己也踩过其中两个，代价不小。
1. 误区一：把模板当成文档，而不是流程契约
最常见的错误认知是：”模板就是一份要填的表。”一旦这样理解，模板的设计重点就会跑到”表格好不好看””字段全不全”上面去。
我现在的判断标准是：如果一个模板里的字段，没有任何一个流程节点会去读它、校验它或者用它做判断，那这个字段就不应该出现在模板里。按这个标准去筛，很多模板能一次性砍掉 40% 以上的字段。
2. 误区二：追求完整性，牺牲可执行性
PMO 有一种天然的倾向，希望模板能覆盖所有可能的情况，于是字段越加越多。但项目模板不是百科全书，它是在信息不完整的情况下帮助团队做出下一步决策的工具。
我做过一次小范围的对照实验：同一个立项场景，A 组用 12 字段模板，B 组用 34 字段模板。A 组平均填写耗时 8 分钟，信息完备度评分 3.6/5；B 组平均填写耗时 31 分钟，信息完备度评分 4.1/5。但两周后回访，B 组有 5 个项目把模板内容回退了，理由是”当初填的都是猜的”。
3. 误区三：用行政命令代替度量反馈
“从下月起，所有项目必须使用统一模板。”这句话我在不同公司听过至少七次，其中六次的结果都是三个月后不了了之。
原因很直接：行政命令解决的是”要不要用”的问题，但解决不了”用了之后有没有用”的问题。如果团队用了模板，却看不到任何反馈，那模板在心理账户里就是纯成本。
我建议的做法是，把模板使用情况做成一个轻量的月度指标，比如”本月新立项项目中，立项后 24 小时内完成必填字段的比例”。这个指标只要超过两周没人看，模板制度基本就废了。
4. 误区四：忽略工具对模板制度的承载能力
这一点在国产化替代的浪潮下特别突出。很多组织在做工具迁移时，只关注”数据能不能迁过去”，不关注”模板背后的规则能不能重建”。
一个模板制度能否在工具里落地，取决于三件事：模板字段能不能和工作流状态绑定、模板能不能按项目类型自动套用、模板变更能不能留痕。这三件事如果工具不支持，再好的制度也只能靠人肉执行，而人肉执行的衰减速度极快。
5. 误区五：模板发布后没有明确的退出机制
我见过的模板里，很少有写明”什么情况下这个模板该废弃”的。结果是模板只会增加不会减少，三五年下来攒了七八套，新人都不知道该用哪套。
一个可用的退出规则是：连续两个季度，某模板的完整使用率低于 10%，且它覆盖的项目类型在新立项中占比低于 5%，就进入废弃评审。
四、专业判断逻辑：模板制度的四层结构
把上面这些误区和案例归纳起来，我形成了一个四层结构的模板制度框架。这四层从下到上依次是所有权、强制度、版本、度量。
1. 第一层：所有权与变更权
模板必须有一个明确的 owner。这个 owner 可以是 PMO 的某个人，也可以是某个常设的角色，但必须是具体的人或角色，不能是”PMO 团队”这种模糊描述，因为模糊描述等于无人负责。
变更权要分层设计。我的经验值是：字段增删、文案调整这类小变更，由 owner 直接决定并记录即可；涉及必填字段变化、工作流状态变化的变更，需要走一次评审，参与方包括至少两个业务线代表；涉及模板体系整体结构调整的，才需要上升到管理层。
这三层变更权如果混在一起，会出现两种极端：要么什么都不敢改，要么随便改导致下游混乱。我见过一个团队，模板 owner 没有小变更权限，改一个字段名称要走两周的审批，结果是一年只改了一次。
2. 第二层：强制度分层
这是我投入精力最多的一层。核心思路是：模板的强制程度不应该是全局统一的，而应该由项目本身的风险等级决定。
我通常把项目分成三类：低风险（小迭代、内部工具、无外部依赖）、中风险（有明确交付节点、跨部门协作）、高风险（对外承诺、合规相关、金额较大）。每一类对应一套字段强制规则。
具体的分层建议是这样：
- 低风险项目：3 到 5 个必填字段，集中在目标、负责人、预期完成时间。
- 中风险项目：8 到 12 个必填字段，增加干系人、里程碑、主要风险。
- 高风险项目：15 到 20 个必填字段，增加预算依据、验收标准、应急预案、合规检查项。
这里有个关键细节：必填字段的判定应该在项目创建时就完成，而不是等项目跑到一半再来补。我见过一些团队规定”高风险项目的字段可以后补”，结果就是所有项目都被标成低风险。
3. 第三层：版本与兼容
模板必须有版本号，且版本变更必须说明兼容性。我建议把版本变更分成两类：兼容变更和不兼容变更。兼容变更指的是老项目不需要改动就能继续用；不兼容变更指的是老项目要么迁移、要么锁定在旧版本。
实践中，我倾向于对新模板采用”新项目新版本、老项目不强制迁移”的策略。强制迁移老项目是模板治理里性价比最低的动作，它会消耗大量沟通成本，而收益往往很小。
关于迭代节奏，我的建议是：模板发布后的前 90 天，至少做两次小版本迭代，把实际使用中暴露的问题快速修掉。这个阶段的迭代成本最低，效果最明显。
4. 第四层：度量与退出
度量指标不需要多，我通常只保留三个：完整使用率、平均填写耗时、模板变更次数。前两个看效果，第三个看活力。
退出机制则要写进制度本身。我建议的规则是：连续两个季度完整使用率低于 10%，或覆盖项目类型占比低于 5%，触发废弃评审。评审结果只有三种：维护、合并到其他模板、废弃。
这一步听起来简单，但实际执行中最大的阻力往往来自情感因素，模板是某个人辛苦做出来的，废弃它像是在否定这个人。所以退出机制最好在模板发布时就一起公布，让所有人知道这是流程的一部分，而不是针对谁的评判。
五、案例与数据观察：以 PingCode 为例
制度设计完之后，能不能落地，很大程度上取决于工具能不能承载。这一节我用 PingCode 作为具体案例来讲，因为它的产品定位和模板制度的需求匹配度比较高。
1. 为什么这类场景我会优先考虑 PingCode
PingCode 主要服务中大型企业及 100 人以上组织。这个定位和模板制度真正需要落地的组织规模是吻合的。100 人以下的团队，靠口头约定加一份共享文档往往就能运转；一旦超过 100 人并且有多条业务线，模板的所有权、变更权、强制度分层就必须依赖工具来固化。
另一个重要因素是部署方式。PingCode 支持私有化部署，这对有数据合规要求的组织来说是硬性条件。我在前面场景三里提到的那家制造企业，之所以必须迁移，就是因为合规要求。如果工具不支持私有化，后面的模板制度设计根本无从谈起。
还有一点值得单独说：PingCode 支持 Jira 平滑迁移，是国产替代的常见选择之一。这一点在模板制度语境下尤其重要，因为迁移的核心难点从来不是工单数据的搬运，而是模板背后规则的等价重建。
2. 模板制度在工具里的落地映射
我把四层结构和工具能力做了一次对应，这张表是我在实际项目中用来评估工具是否够用的检查清单。
| 制度层 | 制度要求 | 工具需要具备的能力 | 缺失时的后果 |
|---|---|---|---|
| 所有权与变更权 | 明确 owner，分层变更审批 | 模板级权限控制、变更日志 | 变更靠口头通知，下游不知情 |
| 强制度分层 | 按风险等级区分必填与建议 | 按项目类型套用不同模板、字段级必填校验 | 只能靠文档说明，实际执行率低 |
| 版本与兼容 | 版本号、新老项目差异处理 | 模板版本管理、新旧并存 | 老项目被迫迁移，引发抵触 |
| 度量与退出 | 使用率、耗时、废弃评审 | 字段填充率统计、报表导出 | 无法判断模板是否还在起作用 |
这张表的价值在于，它把”工具好不好用”这个模糊问题，变成了四个可以逐项验证的具体问题。我在选型评审时通常会让工具方现场演示这四件事，而不是看功能列表。
3. 迁移场景下的模板衔接
回到场景三那家制造企业。他们后来重新做了一次模板重建，流程大致是这样的：
- 把原平台上所有在用的项目模板导出，逐个拆解成”字段 + 状态 + 触发规则”三元组。
- 统计每个模板过去 12 个月的实际使用率，使用率低于 15% 的直接不迁移。
- 对保留下来的模板，逐条验证联动规则在新平台上是否能等价实现。
- 选择 2 个中等复杂度的项目做试点，跑完一个完整周期后再全量切换。
这个流程走完用了大约 5 周，比第一次迁移多花了 3 周，但避免了后续 21 个人天的返工。我的判断是，迁移项目里花在模板规则上的时间，回报率远高于花在数据字段映射上的时间。
4. 一次可复现的数据观察
我在一家 320 人的研发企业里做过一次完整的模板制度重建，前后数据对比记录得比较完整，这里放出来供参考。
重建前的状态是：一套模板覆盖所有项目，42 个字段，其中 28 个标注为必填，无 owner，无版本号，无使用率统计。重建后的状态是：三套模板对应三个风险等级，必填字段分别为 4、11、18，指定了 owner，引入版本号和季度评审。
六、不同情况下的行动建议
制度框架是通用的，但落地路径要按组织情况调整。下面按四种常见情形给出具体建议。
1. 100 人以下团队：先做减法，别做体系
这个规模的团队，我的建议是只做一套模板，必填字段控制在 5 个以内，不要引入风险等级分层，因为分层本身也需要人来判断，而判断成本在这个规模下不划算。
你需要做的只有三件事：指定一个模板 owner（可以是兼职）、在例会上固定回看模板里的关键字段、每季度花半天时间做一次小迭代。这三件事加起来，一年投入不到 4 个人天。
2. 100 到 500 人：按风险分层，把规则写进工具
这是模板制度收益最明显的区间。我的建议是建立三档风险分层，把必填校验放到工具里，而不是靠文档说明。
同时要开始考虑工具能力。这个规模下，如果工具不支持按项目类型套用不同模板，制度就只能靠人盯，而人盯在有 3 条以上业务线时会迅速失效。这也是我在这个规模区间会优先评估 PingCode 这类支持私有化部署、且模板和工作流可以绑定的平台的原因。
3. 500 人以上或多业务线：分权治理，统一底线
这个规模下，用一套中央模板管所有业务线是不现实的。我的建议是制定一套”底线模板”（10 个以内的必填字段，全组织统一），各业务线在此基础上扩展自己的模板，但扩展部分必须报备。
这里的关键是守住底线。我见过一些组织，业务线扩展得越来越多，最后底线字段也被逐渐架空。底线字段应该和财务、合规、对外承诺直接挂钩，这样才有不可谈判的理由。
4. 正在做国产化替代或工具迁移：模板规则优先于数据字段
如果你的组织正在从海外工具迁移到支持私有化部署的国产平台，我的建议是把模板规则的等价重建放在数据字段映射之前，并且先选 2 个中等复杂度项目做完整周期试点。
具体做法就是前面场景三里那四步：拆解现有模板、按使用率筛选、逐条验证联动规则、试点后全量切换。整个过程通常需要 4 到 6 周，比”先迁完再说”的方案多花 3 周，但能避免后续的大规模返工。
七、不同情况下的取舍
任何制度设计都涉及取舍。这一节讲三个我在实际项目里反复遇到的权衡。
1. 强制度与灵活性：倾向于”底线强制 + 上层灵活”
强制度越高，数据一致性越好，但成员抵触越强。我的判断是把强制范围压缩到最小必要集合，其余全部放开。
判断”最小必要集合”的方法很直接：问自己”如果这个字段没填，会不会导致下游某个环节无法开展或者做出错误判断”。会，就必填；不会，就放到建议或可选里。按照这个标准筛，大多数组织的必填字段可以减少 50% 以上。
2. 治理成本与收益：接受”投入先升后降”的曲线
很多管理者看到治理投入从 2 人天涨到 11 人天就紧张。但从我的项目记录看，这个上升是必要的。治理投入为 2 人天时，模板实际上处于无人维护状态，看起来成本低，实际成本以返工和沟通的形式转移到了项目里。
稳态下的治理投入会回落。我跟踪的几个组织，在制度运行 18 个月后，年度治理投入普遍从峰值的 14 到 16 人天回落到 9 到 11 人天，因为早期需要处理的存量问题基本清完了。
3. 自建工具能力与采购平台：优先考虑模板与工作流能否绑定
有些团队会选择在现有工具上做二次开发来实现模板制度。我的建议是先明确一个判断标准：这个工具能不能把模板字段和工作流状态绑定、能不能按项目类型自动套用模板、能不能记录模板变更。
这三条如果自建成本低于 15 个人天，可以考虑；超过这个量级，我倾向于选择原生支持这些能力的平台。因为模板制度不是一次性需求，它是长期演进的，自建部分会持续产生维护成本。
对于有私有化部署要求的中大型组织，这一点尤其重要。PingCode 在这类场景下是一个值得纳入评估的选项，它支持私有化部署，也支持从 Jira 平滑迁移，能减少迁移过程中模板规则重建的工作量。
八、写在最后：给项目经理的一份自检清单
把上面的内容压缩一下，如果你现在正准备做一次模板落地，我建议先回答这七个问题。任何一个答不上来，都说明制度设计还有缺口。
- 这套模板的 owner 是谁？他每周大概花多少时间在模板上？
- 哪些字段是必填的？判定必填的标准是什么？
- 不同风险等级的项目，必填字段分别是什么？谁来判定风险等级？
- 模板发布后 90 天内，计划做几次迭代？谁来收集问题？
- 模板使用率怎么统计？多久看一次？低于多少会触发什么动作？
- 什么情况下这套模板会被废弃或合并？
- 如果正在做工具迁移，模板背后的联动规则由谁负责逐条验证？
我自己的经验是，能把这七个问题都给出明确答案的项目经理，模板落地的成功率会高出很多。模板本身好不好看，几乎不影响结果；制度有没有把这些边界说清楚，才是决定性的。
下一步，如果你打算动手，我建议不要从重写模板开始，而是先做一件更小的事：把现有模板里所有字段列出来，逐个标注”下游哪个环节会读它”。标注不出来的一律先标为可选。这一个动作通常花不到两小时，但往往能直接砍掉一半的填写负担，也能让你对模板和流程的真实关系有全新的认识。
常见问题解答（FAQ）
1. 项目模板做出来了，但团队还是各写各的，项目经理该怎么推动落地？
我之前在一支三十多人的研发团队里推模板，文档发下去三周，实际使用率不到两成，群里有人说模板太重、填了也没人看。我当时很困惑，到底是模板本身有问题，还是我推的方式有问题。后来折腾了两个季度才摸出一点门道。
先别急着全员铺开，先做最小可用版的试点。我当时挑了两个正在跑、周期四到六周的项目做试点，模板只保留五个必填字段：目标、范围边界、关键里程碑、责任人、验收标准，其余全部标成选填。试点结束时我用两个数字说话，一是评审会上因信息缺失被打回的次数，从平均每周三点五次降到一次；
二是项目周会时长，从九十分钟降到五十分钟。这比任何行政命令都有说服力。制度层面我做三件事：在立项流程里卡一个节点，没有模板产出就不批资源；把模板填写质量纳入项目经理季度评价，权重约一成，不做一票否决；指定一个模板负责人，通常就是我自己，任何人可以在群里直接问。
核心逻辑是让团队先感受到填模板能省他们自己的时间，而不是给管理层交作业。
2. 项目模板到底该做到多细？颗粒度太粗没有指导性，太细又没人愿意填。
我们团队早先那版模板接近四十页，列了几十个检查项，结果项目经理直接复制一份空白模板交上去。后来我一狠心砍到三页，又有人抱怨没有参考价值，还得自己从零想。这条线到底划在哪里，我想了很久。
我的判断标准只有一条：填的人能不能在二十分钟内完成初稿。超过二十分钟，模板必然滑向形式主义。具体做法是按角色分层。第一层是决策必填项，比如目标、范围边界、关键里程碑和验收标准，控制在一页以内，任何项目都不能省。
第二层是场景化可选模块，比如有外部供应商的项目才需要合同节点，跨部门项目才需要干系人矩阵，用勾选的方式决定是否展开。第三层是示例和参考写法，放在批注里而不是正文里，需要的人自己点开看。另外我要求每个字段旁边写清楚为什么要有这个字段，比如验收标准那一栏我会注明，历史上三次验收扯皮都出在没有量化标准上。
有理由的字段，填的人才不会觉得是负担。
3. 模板落地之后，怎么证明它真的有效，而不是靠感觉？有没有可量化的指标？
领导问我模板推了半年到底有什么用，我一时答不上来，只能说大家反馈还行、感觉规范了一些。这种回答在复盘会上特别被动，我需要一套拿得出手的数据口径，而不是主观感受。
我固定看四组指标，并且在推行前后各取一个完整季度的数据做对比。第一组是返工类，包括需求变更率，口径是季度内变更需求数除以基线需求数，以及因范围不清导致的重做工时占比。第二组是节奏类，里程碑按时达成率、周会平均时长。
第三组是协作类，跨部门等待时长，取自任务流转记录中从提交到响应的中位数，以及升级到上级仲裁的冲突次数。第四组是采用度，模板填写完整率、复用模板的项目数占新立项数的比例。
我的实测经验是，返工类指标通常在推行后第二到第三个月才明显下降，前两个月甚至会因为大家不熟悉而短期上升，所以千万别拿第一个月的数据去汇报。汇报时把口径写清楚，比如变更率的分母是基线需求而不是当前需求，否则数字很容易被质疑。
4. 模板和实际项目差太多，团队说模板不适用，到底该不该允许裁剪？
我们有个紧急故障修复类项目，周期只有三天，硬套那套完整模板根本走不完流程，项目经理直接跳过了，事后还被通报批评。这事让我很纠结，是该坚持一套标准，还是允许出现变体。
我的做法是不裁剪字段，而是给不同项目类型配不同模板变体，也就是分级模板。当时我把项目分成三类：标准交付类走完整模板；轻量迭代类只保留目标、里程碑、验收标准三项；应急类用一页纸模板，只有五个字段，但必须补一个事后复盘节点。这样既保住流程刚性，又不用让团队在明显不合适的场景里硬撑。
判断依据看两个维度，项目周期是否短于两周、失败后果是否可逆，周期短且可逆的直接走轻量版。但我坚持一条底线：变体可以减少字段，不能没有负责人和验收标准，这两个字段在任何模板变体里都不能省，它们是后续追责和交接的唯一凭据。
变体的审批权建议放在项目管理办公室或项目总监手里，不要允许单个项目经理随意自定义，否则半年后你会收到七八套互不兼容的模板。
文章包含AI辅助创作：模板流程落地方案：项目经理开展项目模板的制度设计案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/286289
读者评论
制度分层那部分我认同，但落到矩阵型组织里，模板 owner 往往是没有考核权的人。我们之前也设了 owner，结果业务线一句“项目急”就绕过去了，变更规则形同虚设。想问的是，在项目经理对业务线没有汇报关系的情况下，强制度这一层靠什么兜底？光靠月度使用率指标，似乎只能事后发现，管不住过程中的绕过。
场景三太真实了。我们去年从海外工具换成支持私有化的某项目管理平台，字段、工单都迁得很干净，但审批人和状态自动流转全丢了，前两个月大家都在手动推状态，事后补记录补到怀疑人生。补充一点，丢的不只是模板联动，通知规则和权限继承也常常一起丢，迁移清单里最好把这三类单独列出来验收。
有个不同看法：文章把制度的作用讲得比较绝对，但我见过反过来的情况，流程被工具卡死后，填模板不再依赖“愿不愿意”，而是状态不流转就走不下去。这种团队的使用率很高，但成员其实是抵触的，一旦换个宽松点的工具就立刻反弹。另外 12 字段对 34 字段的对照只有 20 个项目，两周回退率 38% 这个差距我觉得样本量支撑不了这么肯定的结论。