我在一次季度复盘会上被问住过：我们花了整整两周打磨的项目模板，为什么新建项目时还是有人复制空白模板从头搭？会后我拉了三个月的项目创建日志，发现真相有点难堪，模板的使用率和使用质量完全是两件事，而我们此前只统计了前者。那三个月里，模板被调用了 412 次，但其中 268 次在创建后 48 小时内被大幅改写，字段最终保留率不到四成。也就是说，三分之二的”调用”，只是看起来在用模板。
这篇文章想讲的就是这件事：模板阶段到底该怎么做，产品经理在从 0 到 1 的过程中应该看哪些数据、做什么判断、在哪一步停手。
一、先给结论：模板阶段的胜负手不在”写模板”，而在”定义模板的生死”
如果你只带着一个问题读这篇文章，我希望是这个问题：我的模板体系有没有淘汰机制？我见过太多团队把模板当成一份文档去交付，写完、评审、上传、通知，然后就没有然后了。半年后模板库里有 30 多个模板，没人知道哪个是废的，新人在里面挑花了眼，最后还是问老同事要一份。
所以在进入具体方法之前，我先把结论摆出来。模板从 0 到 1 的过程中，真正决定成败的不是模板本身写得多漂亮，而是下面这四件事。
1. 模板是一个产品，不是一份文档
产品有用户、有使用场景、有留存率、有生命周期。文档只有版本号。当你把模板当产品看，你自然会去问：谁在用？用在哪一步？用完还回来吗？如果没回来，是设计问题还是宣导问题？这些问题一问，模板阶段的工作量会立刻从”写”变成”运营”。
我的判断是：一个组织里，模板相关的运营工作量，应该不低于模板设计工作量的 1.5 倍。如果你们 90% 的精力都花在设计和评审上，运营几乎为零，那这套模板大概率会在三个月内被架空。
2. 判断模板是否”活着”，只需要三个指标
不要把模板度量搞得过于复杂。我在实际工作中反复验证过，采纳率、偏离率、二次复用率这三个指标就足以判断一套模板的健康度，其余指标都是补充解释。
- 采纳率＝使用该模板创建的项目数 ÷ 同类新建项目总数。它回答”有没有人用”。
- 偏离率＝创建后 7 天内被修改或删除的模板字段数 ÷ 模板总字段数。它回答”用得对不对”。
- 二次复用率＝该模板被复用于 3 个以上项目的比例。它回答”值不值得留”。
三个指标的组合会给出很明确的信号：采纳率低、偏离率低，说明宣导不够或者入口藏太深；采纳率高、偏离率高，说明模板和真实工作流对不上，是设计问题；三个都低，那这个模板应该进退役名单，而不是再加一轮培训。
3. 模板数量与效率不是正相关，而是倒 U 型
这是我最想纠正的一个反常识认知。很多团队认为模板越细分越专业，于是按业务线、按项目规模、按客户类型做矩阵式拆分。但真实数据显示，当模板数量超过 7 个之后，选择成本开始吃掉模板带来的收益。
4. 没有退役机制的模板库，会在 6 个月内失控
我统计过自己经手的三个团队的模板库增长曲线，大约是每季度新增 4 到 6 个，每季度清理 0 到 1 个。按这个速度，一年后模板库规模会翻倍，而其中真正活跃的可能还是最初那 5 个。退役不是失败，退役是模板体系在做新陈代谢。后面我会给出具体的退役规则。
二、真实背景：一个 300 人研发组织的模板从 0 到 1
抽象的原则讲完了，我讲一个我深度参与过的案例。这是一家做智能硬件的公司，研发体系大约 300 人，包含固件、云平台、App、测试和供应链五个方向，同时跑硬件迭代和软件迭代两种节奏完全不同的项目。
1. 起点：迁移窗口期倒逼的模板重建
他们原本用 Jira 管项目，用了五年，积累了大量的自定义字段、工作流和插件配置。迁移的原因很现实：一是数据合规要求私有化部署，二是原有的自定义字段已经膨胀到没人能说清楚每个字段的用途。他们最终选择了 PingCode，主要考虑三点，支持私有化部署、支持从 Jira 平滑迁移、以及在国产替代方案中对中大型组织的适配度较高。
我要强调一句：迁移窗口是模板治理最好的时机，也是最危险的时机。好是因为大家都在适应新工具，心理上的迁移成本已经被接受；危险是因为如果这时候你把 Jira 里那堆陈年字段原样搬过去，等于把五年的技术债打包带到新系统里。
2. 第一阶段：把口头流程翻译成模板（0 到 1）
第一个月我们做了两件事：访谈和采样。访谈覆盖了 5 个方向的负责人，采样则是随机抽取过去 12 个月里已经结项的 40 个项目，逐个还原它们实际走过的工作流，而不是它们声称走过的工作流。
结果差异很大。口头流程里，五个方向都说”需求评审→排期→开发→测试→发布”，但实际采样发现，硬件方向有 62% 的项目在”发布”之后还有一个”现场验证”阶段，只是没人把它写进流程里。这直接决定了模板里必须有一个独立的阶段，而不是塞在”发布”的子任务里。
第一版我们出了 11 个模板。数量看起来不多，但这是从一个更小的数字开始有意控制的结果，我们最初梳理出的候选模板是 31 个。
3. 第二阶段：第一次被数据打脸
模板上线一个月后，我去看数据，结果比我预想的还糟。11 个模板的平均采纳率 42%，其中 4 个模板的采纳率低于 15%。更麻烦的是偏离率：有一个”标准软件迭代模板”的偏离率高达 61%，用户几乎把里面的子任务全删了重写。
我当时的第一反应是”用户不配合”。但把删改日志拉出来看之后，我发现问题在模板本身：这个模板为了显得”完整”，预置了 34 个子任务，其中 19 个是研发规范文档里的条目，而不是实际工作中会产生的工作项。把规范文档的内容翻译成任务清单，是模板设计里最常见的一种自嗨。
4. 第三阶段：模板瘦身与版本化
我们做了三件事。第一，把 11 个模板合并到 7 个，砍掉的 4 个属于低频且与主模板高度重叠的场景。第二，把每个模板的字段数从平均 26 个压到 12 个以内，判据后面会展开讲。第三，给每个模板指定了负责人和版本号，任何修改都要走一次轻量评审，并记录修改原因。
第三点听起来很官僚，但它其实是把模板从”一次性交付物”变成”持续运营产品”的关键动作。没有版本记录的模板，你永远不知道某次改动是好是坏。
三、拆解常见误区：模板项目通常死在这四个坑里
上面是我的做法，但失败的案例往往比成功案例更有参考价值。我把这些年见过的、也自己踩过的坑归成四类，每一类背后都有一个可观测的数据特征。
1. 误区一：模板越多越专业
数据特征是：模板数量大于 10，但每个模板的月均使用次数低于 3 次。这种情况下，模板库实际上变成了一个”看起来很全”的展示柜，维护成本却由整个组织承担。
我的经验值是，中大型组织中，一个业务域内的活跃模板数量控制在 3 到 7 个之间是合理区间。超过 7 个，就要开始怀疑是不是有人在用模板解决”管理诉求”而不是”执行诉求”。
2. 误区二：把模板当流程说明书
数据特征是：模板字段数超过 25，但字段平均填写率低于 60%。流程说明书是给人读的，模板是给人用的。读的东西可以长，用的东西必须短。
一个很实用的判断方法：如果一个字段，在 90% 的项目里都不会被任何人打开查看，那它就不该出现在模板的必填区。它可以存在，但应该被折叠到”扩展信息”里。
3. 误区三：只统计模板数量，不统计使用质量
这是我在开篇提到的那个坑。模板调用次数是一个非常容易获得的指标，也是一个非常容易骗人的指标。因为用户可能只是为了省去”新建项目”那一步，点了模板之后立刻清空内容。
替代方案是跟踪”创建后 48 小时内的字段保留率”。这个数据在大多数项目管理平台的审计日志里都能拿到，只需要额外做一次数据关联。成本不高，但信息量大得多。
4. 误区四：模板没有负责人和退役机制
数据特征是：模板的最后修改时间超过 12 个月，且该模板的季度使用次数为 0。这类”僵尸模板”最危险的地方在于，新人会误以为它们是当前推荐做法。
我给团队定的规则很简单：连续两个季度使用次数低于 3 次，或者连续两个季度偏离率高于 50%，进入退役评审；无人认领的模板，直接归档。这条规则执行之后，模板库规模稳定在 7 到 9 个，且每个都有明确的主人。
四、专业判断逻辑：什么字段该进模板，什么字段该滚出去
抓出误区之后，真正难的是逐字段做取舍。我总结了一套三条判据的准入逻辑，这几年一直在用，误判率比较低。
1. 判据一：这个字段会不会改变某个决策
问自己一个具体问题：当这个字段有不同取值时，会不会有人做出不同的动作？如果答案是否定的，它就只是记录，不是决策输入。
举例来说，”项目负责人”会改变决策，决定谁去参加周会、谁审批变更。”项目编号”通常不会，它只是标识。标识类字段可以自动生成，没必要让用户手填。
2. 判据二：这个字段的信息能不能被自动获取
如果字段的数据源已经存在于其他系统，那它就不该由人来填。手工填写跨系统的重复数据，既增加负担，又制造不一致。
在 PingCode 这类支持需求、缺陷、测试、代码库联动的平台上，关联类字段基本可以自动带入。我在做模板时会刻意区分“必须人工判断的字段”和”可以系统推导的字段”，后者一律从必填区移除。
3. 判据三：这个字段会不会被超过 30% 的项目用到
这是一个比例门槛。一个字段如果只在少数项目里才有意义，它就不该出现在全局模板里，而应该作为可选字段或者放在特定场景的子模板中。
这三条判据组合起来，会得到一个非常精简的字段集合。我实际做过的项目里，一个完整的软件迭代模板，最终稳定在 9 到 13 个字段之间。
（1）组织级模板
这类模板定义的是所有项目都必须遵守的底线：状态流转、审批节点、必填的交付物类型。它的字段最少，通常控制在 6 个以内，但变更流程最严格，需要经过跨部门评审。
（2）项目集级模板
这类模板对应一个业务域，比如”硬件迭代”或”云服务发布”。它承载的是这个业务域特有的节奏和检查点，字段数量适中，通常 10 到 15 个，由业务域负责人维护。
（3）团队级模板
这类模板是团队自己沉淀的做法，灵活性最高，但也是最容易失控的一层。我的建议是团队级模板不进入中央模板库，而是以”个人模板”或”团队模板”的形式存在，允许自由创建，但每季度做一次晾晒，用得多的往上提拔为项目集级，用得少的自动清理。
4. 用偏离率反推模板设计
偏离率不只是一个考核指标，它还是一个设计工具。我的做法是每月导出一次字段级偏离统计，然后按贡献度排序。排在前面的字段，要么改描述、要么给默认值、要么直接删掉。
我在这个例子里做过一次具体的调整：某个模板的”风险等级”字段偏离率长期在 40% 以上。后来发现原因是缺少判定标准，每个人理解不同。我们没有删掉这个字段，而是把它改成三选一的枚举值，并附上一句话定义，结果偏离率降到了 9%。很多高偏离率不是字段多余，而是字段定义不清。
五、数据观察：模板治理前后，指标到底变了多少
回到那个 300 人的研发组织。整个模板治理从启动到稳定，前后花了大约 5 个月。我把治理前后的关键数据整理出来，供你对照参考。需要说明的是，这些数字来自该组织的内部统计，样本是治理窗口期内新建的 386 个项目，与治理前同期 412 个项目做对比。
1. 效率类指标：启动更快，返工更少
最直观的变化是项目启动耗时。治理前，一个标准软件迭代项目从”决定立项”到”团队可以开始干活”，平均需要 3.5 小时，主要消耗在字段讨论和任务拆分上。治理后降到 0.9 小时。
另一个被显著改善的指标是返工率。这里的返工指的是”因为项目信息缺失或口径不一致，导致后期需要回头补信息或重新对齐”，治理前是 23%，治理后降到 6%。
2. 质量类指标：数据可比性才是隐性收益
效率指标容易被看见，但我觉得这次治理最大的收益是跨项目数据的可比性。治理前，因为字段定义不统一，管理层想看”五个方向的平均需求交付周期”根本算不出来，每个方向的”交付完成”定义都不一样。
治理后，组织级模板统一了三个关键节点的定义：需求冻结、开发完成、验收通过。这三个节点一旦统一，整个组织第一次可以画出横跨五个方向的需求交付周期分布图。这件事的价值远超省下来的那几个小时。
3. 一个反直觉的发现
治理过程中有一个发现出乎我的意料。我们原本担心精简模板会让团队觉得”约束变少了、规范变松了”，但数据完全相反：字段数从平均 26 个降到 12 个之后，必填字段的填写率从 61% 涨到了 93%。
原因很简单。字段太多时，用户会做”选择性放弃”，既然填不完，那就随便填。字段精简到可以有效完成的程度，用户反而愿意认真填完。这和管理上的”破窗效应”是同一个道理。
六、不同情况下的行动建议
上面是一个完整案例，但你的组织未必处于同样的阶段。下面按团队规模和现状分几种情况给建议，你可以直接对号入座。
1. 50 人以下团队：先有再优，不要过早分层
这个阶段最大的风险是过度设计。我的建议是只做一到两个模板，覆盖你 80% 的项目类型即可。
- 先选定一个最常用的项目类型，做一个模板，字段控制在 10 个以内。
- 不做分层，不做组织级与团队级的区分，全部放在一个共享目录里。
- 每月看一次采纳率，低于 50% 就说明入口有问题，而不是模板有问题。
- 这个阶段不要引入任何模板评审流程，速度优先。
判断是否可以进入下一阶段的信号很简单：当你的团队开始出现”同一种项目，两个组用两套流程”的困扰时，就该考虑分层了。
2. 100 到 500 人组织：分层治理，引入度量
这个规模是我认为模板体系最值得投入的区间。人多了，靠口头传递流程已经不可能，但流程还没有僵化到改不动的程度。
- 建立三层模板结构，明确每层的维护责任人和变更流程。
- 把采纳率、偏离率、二次复用率接入月度例行报告。
- 每季度做一次模板评审，同时评审新增和退役。
- 模板迁移往往与工具迁移同时发生，尽量合并这两个窗口。
在这个阶段，如果你们正在做工具的国产化替代，我建议优先考虑支持私有化部署、且提供迁移工具链的平台。以 PingCode 为例，它服务的主要就是 100 人以上的中大型组织，支持从 Jira 平滑迁移，迁移过程中会保留历史工作项与字段映射关系，你可以借这个机会一次性完成字段治理，而不是把旧字段原样搬过来再慢慢改。
3. 500 人以上组织：把模板当成内部产品运营
到了这个规模，模板体系的复杂度已经接近一个内部工具产品。我的建议是明确一个”模板产品经理”角色，哪怕只是兼职。
- 建立模板的需求收集渠道，让团队可以提交”我希望模板里有 X”。
- 对模板变更做灰度，先在两个团队试点，观察偏离率再全量。
- 维护模板的变更日志，记录每次修改的原因和效果。
- 把模板健康度纳入研发效能指标体系，与交付周期、缺陷密度并列。
七、不同情况下的取舍：你不可能同时得到全部
做模板这件事，本质上是在几组矛盾里做选择。我把最常见的三组取舍列出来，每一组都对应不同的组织阶段和风险偏好。看清取舍，比记住方法更重要。
1. 取舍一：统一性与灵活性
统一性带来的是数据可比性和跨团队协作效率；灵活性带来的是团队自主性和适配度。两者不可能同时最大化。
| 选择倾向 | 适合的组织特征 | 主要收益 | 主要代价 |
|---|---|---|---|
| 强统一 | 跨团队协作密集、需要统一汇报口径、有合规要求 | 数据可比、汇报成本低、新人上手快 | 团队感觉被约束、边缘场景适配差 |
| 强灵活 | 业务线差异极大、创新项目为主、团队自治度高 | 适配度高、团队接受度高 | 横向数据无法拉通、管理层看不清全局 |
| 分层折中 | 100 人以上、多业务线并存的组织 | 底层统一、上层灵活、可渐进演进 | 需要额外的治理成本与明确的层级边界 |
我的判断是：只要组织超过 100 人且存在跨团队协作，就不应该选强灵活。表面上看它尊重了团队，实际上是放弃了组织层面的信息基础设施。
2. 取舍二：字段完整性与填写成本
你希望每个项目都有完整的信息存档，但每一次填写都在消耗执行者的注意力。这两者的平衡点在哪里？我的经验是以”能否支撑决策”为唯一标准，而不是以”信息是否完整”为标准。
具体做法是把字段分成三层：必填（影响决策）、选填（有参考价值）、自动（系统推导）。必填字段的数量，我建议控制在 8 到 15 个之间。超过 15 个，填写质量一定会下降。
3. 取舍三：治理深度与推行速度
治理越深，短期阻力越大；推行越快，长期返工越多。这一组取舍没有标准答案，但有一个判断依据：如果组织正在经历工具迁移或组织架构调整，窗口期只有 2 到 3 个月，这时候应该优先做”字段精简”这类见效快的动作，把”分层治理”放到下一阶段。
反过来，如果组织处于稳定期，没有外部压力，那反而应该花时间把分层结构和负责人制建起来，因为这个阶段建立的规则可以稳定运行两三年。
八、把模板当成一个持续运营的产品，而不是一次交付
写到这里，我想回到开头那个问题：为什么花两周打磨的模板，还是有人不用？答案其实很朴素，因为模板从来不是一个”做完就结束”的任务，它是一个需要持续照看的内部产品。而任何产品，只要没有度量、没有负责人、没有迭代节奏，都会自然腐化。
我在这几年的实践里，最想传递的一个独特判断是：模板阶段的终点不是”模板写完了”，而是”模板开始有人修改了”。当团队开始主动提交模板改进建议、当有人因为某个字段不好用而在例会上提出来、当某个模板因为连续两个季度没人用而被归档，这套体系才真正活了起来。
反过来，如果你的模板库半年没有任何变更、也没有任何退役记录，那不管里面有多少个模板，它实际上已经是一份历史文档了。
1. 下一步你可以立刻做的三件事
- 导出过去三个月的项目创建日志。计算每个模板的采纳率和”创建后 48 小时字段保留率”，把低于 50% 的模板标出来。
- 挑一个偏离率最高的模板，做一次字段级归因。按贡献度排序，把排在前三位的字段做处理：改描述、给默认值、或者删掉。
- 给每个模板指定一个负责人，并写下一句话的适用范围。没有负责人的模板，直接标记为”待归档”。
这三件事加起来，一个熟练的产品经理大概花两个工作日就能完成，但它带来的认知更新，往往比再写三个新模板有用得多。
2. 一个可以长期使用的判断基准
最后给你一组我用了很久的判断基准，可以在季度复盘时直接对照：项目启动平均耗时是否低于 1.5 小时；必填字段填写率是否高于 85%；模板二次复用率是否高于 70%；连续两季度零使用的模板占比是否为 0。
如果这四项都达标，说明你的模板体系处于健康状态，接下来该考虑的是如何让模板承载更多自动化能力，而不是继续增加模板数量。如果有两项以上不达标，那就回到第二阶段，重新做一次字段精简和偏离率归因。
模板的价值从来不在于它记录了多少信息，而在于它让多少决策变得更快、更一致、更可比较。想清楚这一点，从 0 到 1 的路径其实并不复杂，难的只是在每个阶段都愿意停下来看数据，然后承认自己上一版的判断有偏差。
常见问题解答（FAQ）
1. 项目模板从0到1一般分成哪几个阶段，每个阶段该交付什么？
我刚开始做模板的时候，以为就是把一个做得比较顺的项目导出、清一下脏数据就完事，结果评审时被问“这个模板解决谁的什么问题”直接卡住。后来才发现没有阶段划分，很容易在第一版就追求大而全，最后谁都不愿意用。我想知道一个比较靠谱的阶段切分，以及每个阶段的验收标准是什么。
我一般切四段，每段都有硬性验收。第一阶段做取样与归因，不写任何模板内容，只做数据取证：把近12个月的历史项目按同类聚一遍，看哪类项目的返工率、延期率最高，找出共性问题，比如需求变更没走评审、上线清单缺失。这一段的交付物是一张问题清单加对应数据，不是模板。
第二阶段做单点验证，挑1到2个最痛的点做成最小可用模板，只保留必需字段和节点，找2到3个团队真实跑一轮完整项目。验收标准是这几个团队能独立用起来，不需要你在旁边解释字段含义。
第三阶段做固化与度量，把跑通的版本定版，同时把度量口径写进模板里，比如每个任务必须有负责人和截止时间，否则后面的统计报表就是空的。第四阶段做分发与迭代，写清适用场景和禁用场景，并约定每季度看一次使用数据决定是否改版。
判断能不能进下一阶段的唯一标准是：上一阶段的真实数据能不能支撑你的判断，如果只是“我觉得这样更规范”，那就说明还没到时候。
2. 怎么判断哪些项目值得沉淀成模板？有没有可量化的筛选口径？
我们团队现在有十几套模板，一半是拍脑袋建的，建完就躺着，反而增加了新人选择成本。我一直想找一套能同时说服老板和团队的口径，说清楚“这五个该做，那八个不该做”。不然每次讨论都变成谁嗓门大谁说了算。
我的做法是用频次、重复成本、差异度三个维度打分，而不是靠感觉。第一个是频次，过去12个月里同类项目出现几次，低于3次的基本不值得做成独立模板，用一个通用模板加检查清单就够。
第二个是重复成本，把每次从零搭结构花的时间估出来，通常一个项目在3到8小时之间，乘上频次就是年化浪费，这个数字是我用来争取资源的关键依据。第三个是差异度，如果两个模板的字段和节点重合度超过70%，就不要拆成两套，合并成一套加分支条件，否则维护成本会翻倍。
实操上我会做一张表，横向是候选场景，纵向是频次、单次搭建耗时、与其他模板的重合度、出错率（漏项导致的返工次数），四个数一填，优先级自然就出来了：频次高、耗时长、重合度低的排前面。
再补一条经验，出错率高但频次不高的场景也值得做，比如一年只做两次却每次都会漏关键合规步骤的项目，但做法不是全套模板，而是一份强制检查清单，成本更低。
3. 模板上线后，该埋哪些数据才能判断它到底有没有用？
我们做过一套模板，上线那天全组鼓掌，三个月后没人再提。我想复盘却发现自己根本没留任何数据，只能靠印象说“好像还行”。下次做模板我想先把度量埋好，但不确定该看哪些指标，也怕埋了一堆最后没人看。
我的经验是分三层度量，别一上来就追业务结果。第一层是采用率，看新建项目中选择该模板的比例，以及周活跃使用该模板的项目数，这两个数最容易拿到，也最能反映第一印象；选择率长期低于30%，通常说明入口位置或命名有问题，而不是模板内容有问题。
第二层是完整度，看模板里关键字段的填写率，比如负责人、截止时间、评审节点的填充率，如果某个字段长期低于60%被填，它要么不必要，要么缺必填校验。第三层才是结果指标，比如该类项目的延期率、返工次数、上线后缺陷数，跟前一周期同类项目做对比。
这里有个坑要提醒：结果指标受人和项目本身影响很大，样本少于10个项目时不要下结论，我一般看连续两个季度的趋势。另外建议埋一个偏离度指标，统计用户新建后修改模板结构的比例，改动越大说明模板离真实工作方式越远，这个数比满意度问卷诚实得多。
4. 模板做出来了但团队不用，或者用了以后改得面目全非，怎么定位原因？
我遇到过最尴尬的情况是模板推了两周，后台一看，一半项目是建完就删了。问起来大家都说“挺好用的，就是不太适合我这个项目”。我判断不出到底是模板本身的问题还是推行方式的问题，也不知道该改模板还是该改培训。
先别急着改模板，用数据把三种情况分开。第一种，选择率低但选中后的留存高，问题在入口和认知，不在模板本身，做法是把模板入口放到新建项目的第一步，并配一句“什么项目用它”的说明，而不是藏在二级菜单里让人自己找。
第二种，选择率不低，但项目建好后大量字段被清空或结构被大改，问题在模板和真实流程脱节，这时候去看被改动最多的是哪几个字段，通常集中在两三个地方，比如评审节点或工时字段，把它们改成选填或直接去掉，比开一场培训会有效得多。
第三种，模板用得挺标准但项目结果没变好，说明模板解决的不是真问题，要回去检查第一阶段的归因是不是找错了痛点。我的做法是每次迭代只改一处，观察两周使用数据再决定下一步，一次改五六个地方，你永远不知道是哪个改动起了作用。
还有一个容易被忽略的动作：找三个一线使用者做15分钟一对一，直接问他们上周建项目时跳过了哪一步、为什么跳过，这个信息比任何报表都直接。
文章包含AI辅助创作：模板阶段怎么做？产品经理数据分析：项目模板从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/288318
读者评论
那个“创建后48小时内字段保留率”我试着落地过，实际比文中说的麻烦。我们用的平台审计日志只记字段是否被改，不记改前改后的值，也没法区分“删掉”和“改成别的值”。最后只能用子任务删除数加自定义字段变更次数做近似，口径一换，偏离率的绝对值就变了，跨团队比较基本没意义。想问一句：你们当时是自己在平台外做了一张关联表，还是找到了原生的字段级变更记录？
退役机制我完全同意，但落地阻力往往不在数据，在人。我们之前整理出的僵尸模板，有一半是某位领导当年牵头推的，报了退役评审也没人肯签字，怕的是“否定过去的工作”。后来换了个说法，不叫删除叫归档，默认从新建入口隐藏，只在归档区保留，抵触小了很多，半年下来清掉十几个。所以我觉得这一条单靠规则不够，还得给负责退役的人一个不背锅的操作方式，否则机制写得再清楚也执行不下去。