任务类型管理方法大全：企业管理者任务属性入门指南落地清单

去年我帮一家 400 人规模的软硬件一体企业做研发效能复盘，从他们的项目管理平台里导出了一份 12 个月的任务清单，一共 12847 条任务。我以为重点会落在交付周期或返工率上，结果真正让我停下鼠标的是"任务类型"这个字段：一共有 37 个取值，其中 29 个取值全年使用次数不到 20 次，有 6 个取值只被一个人用过，还有一个叫"其他-临时"的类型占了全部任务的 23%。这家公司并不缺工具，他们用的是支持私有化部署、能自定义工作流的中大型企业级平台，缺的是对"任务类型到底该管什么"这件事的共识。

任务类型管理看起来是配置工作，实际上是组织把"我们的工作由哪几种东西构成"写成代码的过程。

一、核心结论：任务类型是任务属性的"宪法"，先定边界再谈灵活

我把过去六年做过的十几个任务体系治理项目做了一次归拢，结论比我预想的更收敛。任务类型管理的成败，几乎不取决于工具多强大，而取决于三件事有没有被提前说清楚：什么差异必须用新类型承载，什么差异只能用属性承载，以及类型什么时候可以退役。

下面这四条是我现在做任何任务体系设计时都会先写进方案首页的判断，它们构成了整篇文章的骨架，后面的场景、误区、清单都是围绕它们展开的。

1. 任务类型不是分类，而是一份流程契约

很多人把任务类型理解成"给任务贴个分类标签"，这是所有混乱的起点。分类是描述性的，贴错了不影响运转；契约是约束性的，它决定了这个任务要走哪些状态、谁能审批、什么时候算完成、算进哪个统计口径。

一个"缺陷"和一个"需求"的区别，不在于内容不同，而在于缺陷有严重程度和复现环境，走的是快速修复通道；需求有验收标准和排期评审，走的是计划通道。如果你给它们建了两个类型，却用同一套状态机、同一套完成定义，那这两个类型就是纯装饰，只会增加统计噪音。

2. 类型数量与报表可用性呈倒 U 型，不是越多越精细

我统计过手上 11 个团队的样本数据，把任务类型数量分成五档，去看它们最常用的三张管理报表（交付周期、缺陷密度、人效分布）的口径一致率。结果显示出一条非常清晰的倒 U 曲线：类型数量在 5 到 8 个之间时报表最干净，超过 15 个之后可用性断崖式下跌。

原因不复杂。类型一多，创建任务的人就要做判断，判断就有分歧，分歧就产生脏数据；而报表是按类型聚合的，脏数据会被放大成错误结论。管理者看到错误结论做出错误决策，然后反过来要求"再加一个类型区分清楚"，进入恶性循环。

3. 八成字段不该挂在类型上，属性要分四层

我在做任务体系评审时，最常问的一句话是："这个字段，是只有这一种任务才有，还是所有任务都可能填？" 如果答案是后者，它就不该跟着类型走。

把任务属性拆成四层之后，绝大多数争议会在十分钟内解决：身份属性（这是什么）、流程属性（它怎么走）、度量属性（怎么衡量它）、权限属性（谁能看谁不能看）。类型只应该由流程属性驱动，其余三层都应该做成平台级的通用能力，通过条件显示来控制填写负担。

4. 类型治理是季度动作，不是一次性项目

我见过太多团队花两个月把类型体系梳理得干干净净，然后半年后回到原点。原因是组织在变、业务在变、监管要求在变，新类型会不断被提出。所以真正有效的做法不是"设计一个完美的终态"，而是建立一套类型准入与退役的季度机制，让体系自己保持熵平衡。

二、背景与真实场景：类型失控通常从哪三个入口开始

任务类型失控不是随机发生的，它几乎总是从三个入口之一进入组织。我在复盘时会把这三个入口当作排查清单，命中率大概在八成以上。理解入口，比记住原则更有用，因为你可以提前在这些位置设置关卡。

1. 场景一：迁移照搬，37 个类型在三个月内崩掉

这是中大型企业最常见的情况。团队从旧的缺陷跟踪工具迁移到新的项目管理平台，为了"数据保真"，把原系统里的 37 个 issue type 一对一映射过来。迁移当天数据完美对齐，汇报也很漂亮。

问题从第二周开始。新平台的状态机和流程规则跟旧系统不一样，团队为了让流程跑通，开始给每个类型单独配一套工作流，配置量从 37 套状态机迅速膨胀到一百多个节点。三个月后，没有任何一个人能说清"研发任务"和"研发子任务"的区别，报表要靠数据团队写脚本洗。

我后来复盘这个案例时算过一笔账：迁移时为了保真保留的 28 个低频类型，在整个生命周期里被使用的总次数不到 400 次，但为此付出的配置和培训成本，大约相当于 2.5 个人月。这是一笔明显不划算的交易。

2. 场景二：类型变成部门名，跨部门协作直接断裂

第二个入口是把组织结构塞进任务类型。市场部建一个"市场任务"，供应链建一个"供应链任务"，研发建一个"研发任务"，客服建一个"客诉任务"。看起来清晰，实际后果是任务一旦需要跨部门流转，就必须重新创建一个新类型的任务。

于是同一个业务事项在系统里被拆成四条互不关联的记录，累计耗时算不出来，责任人算不清楚，最后管理者只能靠周会口头对齐。我在一家零售企业见过更极端的版本：一个促销活动在上线前被拆成了 11 条任务记录，分布在 5 个类型里，负责人说"我只能凭印象告诉你大概花了三周"。

3. 场景三：业务侧任务和研发任务混在一个池子

第三个入口是把工单类任务和研发类任务放在同一套类型体系里。很多团队会说"都是任务，为什么要分两套"。但当业务侧要按"响应时长"考核，研发侧要按"缺陷密度"考核时，两套度量口径挤在同一个类型上，必然有一方被牺牲。

我通常的处理方式是：类型体系分开设计，但聚合视图打通。也就是研发需求、研发缺陷走一条类型链，客服工单、运维变更走另一条类型链，但在管理层看板上用一个统一的"业务事项"视图把它们串起来。这样既保住了各自的流程特性，又不丢跨域视角。

4. 从场景到数字：类型膨胀对跨部门流转的拖累

我在一家 400 人企业跟踪过 12 个月的数据。他们在第 3 个月做了一次迁移，类型数量从 14 个涨到 37 个；到第 9 个月启动治理，回落到 11 个。跨部门任务的平均流转耗时，跟类型数量几乎是同步波动的：类型涨到 37 个时，流转耗时从 2.1 天涨到 6.5 天，类型回到 11 个之后回落到 2.6 天。

需要说明的是，这中间还叠加了流程调整和人员变动，所以我不能声称这是纯粹的因果关系。但把时间轴拉平之后，两条曲线的形态高度一致，作为一个管理信号已经足够有说服力。

三、拆解常见误区：六种做法看起来专业，实则在制造负债

下面这六种做法，我在评审中出现的频率最高，而且提出者往往是团队里最认真、最想把管理做细的人。也正因为出发点正确，它们特别难被推翻，造成的负债也特别隐蔽。

1. 把任务类型当标签用

典型表现是类型列表里出现"紧急需求""线上问题""优化类""技术债""客户定制"这类词。这些描述的其实是内容属性或优先级属性，不是流程属性。它们应该分别落在标签、优先级字段和技术债标记上。

判断方法很简单：如果一个类型的任务，它的状态流转和完成定义跟另一个类型完全一致，那它就不是类型。紧急需求和不紧急需求，走的都是同一套评审和上线流程，唯一区别是优先级，那就是优先级字段的活。

2. 把任务类型当看板列用

有些团队会建"待开发""开发中""测试中""已上线"这样的类型。这是把类型的职责和状态的职责搞混了。类型回答"这是什么"，状态回答"现在到哪了"。混用的直接后果是任务没法流转，因为改状态就要改类型，历史数据被割裂成互不衔接的片段。

3. 类型层级越挖越深，做成三级树

我见过最深的类型树是三级共 68 个叶子节点：一级分研发/业务/运维，二级分产品线，三级分工作内容。设计者的初衷是"任何任务都能精准归档"。

但实际运行中，创建一条任务平均要花 40 秒在类型选择上，而人一天要创建十几条任务。更要命的是，同一件事不同人归类不同，数据反而更乱。我的经验是：类型树最多两级，二级节点总数控制在 15 个以内。

4. 用权限割裂类型，制造数据孤岛

出于数据安全考虑，有些团队把类型和权限绑定，A 部门看不到 B 部门的类型。这在合规严格的行业（如金融、医疗）有合理性，但如果没做好聚合层，管理层的跨部门视图就会直接缺失。

我的建议是权限按"字段级 + 视图级"设计，而不是按类型级。类型的元数据可以全员可见（知道有这类工作存在），具体的内容字段按权限隐藏。这样既守住安全边界，又保住了统计口径的完整性。支持私有化部署的平台通常在这一层有更好的控制力，可以把权限规则写进内网策略里统一管理。

5. 类型只增不减，没有退役机制

新增类型的动议到处都有人提，但从来没有人为"这个类型是不是该取消了"负责。结果是类型体系单向膨胀。我在一家公司见过一个叫"专项支持"的类型，最后一次使用是 14 个月前，依然挂在列表里，每个新员工入职时都要花时间搞清它是什么。

6. 把优先级、严重程度、复杂度塞进类型名

比如"P0 缺陷""高优需求""简单任务"。这些字段所有任务通用，做成类型会导致类型数量按乘法膨胀：3 个优先级 × 4 个内容类别 = 12 个类型，而实际流程可能只有 3 种。这是最容易修复、也最容易反复出现的误区。

四、专业判断逻辑：任务属性的四层模型与三条准入规则

前面讲的是"不该怎么做"，接下来是我实际使用的判断框架。这套框架我用了三年多，最大的价值是把主观争论变成可回答的问题：一个新类型该不该建，不再取决于谁嗓门大，而是取决于三个问题有没有"是"的答案。

1. 四层属性模型：先分层，再决定归属

（1）身份属性：这是什么

包括任务类型、子类型、所属项目/产品。这一层回答"这是什么工作"，是任务的最小身份标识。我的原则是身份属性只保留一个主维度，类型。子类型只在真的存在流程分支时才启用，比如"需求"下面的"合规需求"要走额外的法务审批。

（2）流程属性：它怎么走

包括状态机、流转规则、审批节点、完成定义。这是唯一真正驱动类型细分的维度。如果两种工作的状态流转完全一样，它们就该是同一个类型；如果状态流转不同，那就是两个类型，没有中间地带。

（3）度量属性：怎么衡量它

包括工时、故事点、计划开始/结束时间、验收标准、缺陷严重程度。这一层的关键设计原则是按需显示：需求要故事点，缺陷要严重程度，运维变更要影响范围。用条件字段而不是新类型来实现这种差异，能省掉大量配置。

（4）权限属性：谁能看、谁能改

包括可见范围、编辑权限、审批权限、导出权限。这一层要尽量做成平台级策略，而不是跟类型绑定。当类型和权限耦合时，任何类型调整都会牵动权限重新配置，是运维成本的隐形黑洞。

2. 三条准入规则：新类型必须至少满足一条

我现在给所有团队的新类型申请都设一道闸，提案人必须回答三个问题。三个都是"否"，就走标签或自定义字段；有任意一个"是"，才进入正式的准入评审。

1. 状态机是否不同？ 如果新类型会走不同的状态节点或流转路径（例如需要额外的审批或验证环节），则建新类型。
2. 度量口径是否不同？ 如果新类型需要纳入不同的统计口径（例如缺陷密度 vs 交付周期），且无法用现有字段区分，则建新类型。
3. 权限边界是否不同？ 如果新类型对外部人员、合作方或监管审计有完全不同的可见性要求，且字段级权限无法满足，则建新类型。

这三条规则我实测下来，大约能把类型新增申请压缩掉七成以上。剩下的三成里，还有一部分会在季度评审中被合并。

五、真实案例：一家 400 人企业用 PingCode 做类型精简与 Jira 平滑迁移

接下来这个案例是我深度参与的，客户是一家 400 人左右、三条产品线并行的软硬件企业，属于 PingCode 典型服务的 100 人以上中大型组织。他们有比较严格的合规要求，最终选择了私有化部署。这里的数字都来自我和他们效能团队共同整理的上线前后对比，涉及公司信息的部分做了匿名处理。

1. 起点：37 个类型的迁移困局

他们原来的系统里有 37 个 issue type，其中 11 个是历史遗留，最后一次使用在一到三年前。团队一开始的诉求是"迁移要保真，一个都不能少"，原因是担心历史报表对不上。

我先做了一步数据摸底：把这 37 个类型按近 24 个月的使用频次和最近使用时间排了个序，发现前 9 个类型覆盖了 94.6% 的任务量，剩下 28 个类型合计占比 5.4%，其中 11 个已经超过 12 个月零使用。当这组数字摆在评审会上，迁移保真的坚持很快就松动了。

2. 迁移策略：类型精简 + 历史数据冻结映射

我们最终的策略是"新体系精简，历史数据保真但只读"。具体做法分三步。

第一步，把 37 个类型压缩到 11 个。压缩规则是：状态机相同且度量口径相同的合并；合并后的差异用自定义字段和标签承载。有 6 个类型的差异是纯粹的内容差异（比如"客户定制需求"和"标准需求"），直接变成标签。

第二步，选择 PingCode 的 Jira 平滑迁移能力做数据搬移。这一点很关键，因为他们的历史任务量接近 5 万条，人工导入不现实，而且业务上仍然需要能回溯两三年前的记录。迁移过程中我们建了一张映射表，把 37 个旧类型映射到 11 个新类型，并保留原始类型名作为一个只读属性字段，这样历史数据既归入了新体系，又保留了原始可追溯性。

第三步，用 PingCode 的工作项类型配置能力重建状态机。11 个类型最终只对应 4 套状态机，复用率大幅提升。以前每改一次流程要改十几处配置，现在改一套状态机就能覆盖三个类型。

另外，因为是私有化部署，他们的安全团队把字段级权限规则和审计日志策略写进了内网统一管控，客户数据的可见范围由平台策略统一约束，不再依赖每个类型单独配置。这部分在合规评审时是加分项。

3. 上线三个月后的数据观察

迁移上线后的第三个月，我们做了一次完整的数据对比。最明显的变化不是效率指标本身，而是数据质量的改善：必填字段完整率从 52% 涨到 89%，这个变化直接让管理报表变得可用了。

创建任务时的平均耗时从 51 秒降到 19 秒，看起来是小事，但按人均每天创建 6 条任务计算，一个 400 人团队一年能省下大约 1900 个小时，相当于 1.1 个人年。

跨部门任务的平均流转耗时从 6.5 天降到 2.4 天。这个数字我在前面提过，要谨慎归因，但至少可以确认：类型语义清晰之后，任务在部门之间"找不到归属"的扯皮明显减少了，这是他们效能团队在周会上反复确认过的定性反馈。

月度效能报表的产出周期从 6 天缩短到 1.5 天，因为不再需要数据团队手工清洗类型字段。这一项对管理者来说可能是最直接的收益：决策依据从"上个月的清洗后数据"变成"本月初的准实时数据"。

4. 一个反直觉的观察：精简之后，团队要求的"新类型"反而变少了

这是我在这个案例里最意外的发现。治理前，他们平均每季度收到 20 多份新增类型申请；治理后，季度申请量降到了 6 份左右，而且大多能被现有类型加标签解决。

我的解释是：当类型体系语义清晰、标签能力好用时，人们不再需要靠新类型来表达差异。多数新增类型的诉求，本质上是"我没有别的办法把这个信息表达出来"。把标签和自定义字段的能力补齐，诉求就自然消解了。

六、落地清单：八周从盘点走到新稳态

下面这份清单是我实际执行过三次以上、并做过迭代的版本。它不是理论框架，而是一份可以直接照着做的排期表。我把它设计成八周，是因为更短会导致草率、更长会让团队失去耐心。

1. 第 0 周：盘点，只做数据不做判断

这一周唯一的目标是把事实摆出来。导出近 24 个月的全部任务，按类型统计使用次数、最后使用时间、关联的任务量占比、平均停留时长。

• 输出《任务类型使用频次表》，按使用量降序排列
• 标注每个类型的最后使用日期，识别零使用类型
• 统计每个类型当前绑定的字段数量和状态机数量
• 访谈 5 到 8 位高频创建者，记录他们在类型选择上的困惑点

这一周不要做任何删减动作，也不要开"要不要保留某个类型"的讨论会。数据没摆齐之前，讨论只会变成立场之争。

2. 第 1 周：定义，用三条准入规则重跑一遍

把盘点出的类型逐个过一遍三条准入规则：状态机是否不同、度量口径是否不同、权限边界是否不同。三个都不同的保留，其余进入合并或转换清单。

同时确定目标类型数量。我的建议是：50 人以下组织不超过 5 个，50-200 人不超过 8 个，200-1000 人不超�过 12 个，1000 人以上不超过 18 个。这只是基准，允许有上下浮动，但超出的部分必须有明确理由。

3. 第 2-3 周：配置，先配状态机再配字段

配置顺序很重要，先做状态机再做字段，可以避免返工。具体步骤：

1. 按合并后的类型梳理出状态机清单，目标是让状态机数量远小于类型数量（经验值是 1:3 左右）
2. 为每套状态机定义流转规则和完成定义，明确"什么状态算完成"
3. 把度量字段做成条件显示，按类型自动切换字段集
4. 权限统一用字段级和视图级策略，不跟类型绑定
5. 建立旧类型到新类型的映射表，用于历史数据迁移和后续追溯

如果是迁移场景，这一步要额外注意历史数据的处理方式。我的做法是把原始类型名保留为一个只读属性字段，这样新旧体系可以并存追溯，迁移也不会因为映射误差导致数据丢失。支持 Jira 平滑迁移的平台通常能直接处理这类字段映射，可以把迁移工作量压缩到人工方式的十分之一以内。

4. 第 4 周：试点，选一个愿意配合的团队

试点团队的选择标准不是"最先进"，而是"最有代表性且愿意反馈"。我会优先选一个跨部门协作频繁、任务类型使用复杂度中等的团队，20 到 40 人规模最合适。

试点的验收标准建议定为三条：创建任务耗时是否下降、必填字段完整率是否超过 85%、试点团队是否愿意继续用。第三条最重要，如果试点团队想回退，说明设计有问题，宁可推迟推广。

5. 第 5-8 周：推广与退役并行

推广的同时必须同步做退役，否则旧类型会一直留在系统里成为噪音源。退役要分两步走：先冻结（不可新建），再观察一个完整业务周期，确认无人依赖后正式归档。

归档不等于删除，历史数据要保留可查。这一点在合规要求严格的行业尤其重要，审计时往往需要回溯两三年前的记录。

6. 持续：季度治理例会，15 分钟就够

我建议把类型治理做成一个固定议程，挂在季度研发效能例会上，15 分钟。议程只有三项：本季度新增了几类、哪些类型使用量低于阈值、有没有类型进入退役观察期。

把这 15 分钟坚持下去，比每两年做一次大治理要有效得多。我在两个团队验证过：有季度机制的团队，类型数量波动始终控制在 ±2 个以内；没有机制的团队，两年内平均膨胀 2.4 倍。

七、不同规模组织的行动建议

同一套方法，放在 30 人团队和 3000 人组织里，执行方式完全不同。下面是我按规模整理的实操建议，其中类型数量的基准值来自我手上 11 个团队的样本，属于经验区间而非行业统计。

1. 50 人以下：能不建体系就不建体系

这个阶段最大的风险是过度设计。我的建议是类型数量控制在 3 到 5 个，只保留流程差异最大的那几种，比如需求、缺陷、其他。不要配审批流，不要建类型树，不要设复杂权限。

这个阶段真正需要的是快速迭代和灵活调整，任何增加创建负担的配置都是负收益。等团队超过 50 人、出现明显的跨职能协作摩擦时，再开始做第一步治理。

2. 50-200 人：建立基础类型体系与命名规范

这是类型体系真正需要被设计的起点。建议类型数量 6 到 8 个，类型树不超过两级，并且在这个阶段就把命名规范定下来。

命名规范我的建议是用"动宾结构 + 交付物"的形式，比如"提交缺陷报告""交付需求方案"。这种命名自带判断依据，创建者读一遍就知道该不该放这里。相比之下，"研发任务""业务事项"这类命名没有任何判断力，就是混乱的来源。

这个阶段就要开始做季度治理，不然规模一上去就很难刹住。

3. 200-1000 人：分层设计，把权限和度量解耦

这个规模通常是多产品线、多职能并存，也是最容易出现类型爆炸的区间。我的建议是类型数量 9 到 12 个，且必须是"分层设计"而不是"分部门设计"。

具体来说，第一层按工作性质分（需求、缺陷、工单、变更、风险等），第二层只在该性质存在真实流程分支时才展开。部门和产品线的差异用组件字段或标签承载，绝不用类型承载。

权限这一层要重点投入。这个规模的组织的合规要求通常已经不低，字段级权限和审计日志是刚需。如果需要私有化部署来满足内网与数据合规要求，就把这一步放在选型阶段，不要等上线后再补。

4. 1000 人以上：治理机制比体系设计更重要

到了这个规模，你不可能设计出一个"一次到位"的类型体系，因为组织结构、业务线、监管要求都在持续变化。真正决定成败的是治理机制的运转效率：谁能提，谁审，多久审一次，退役怎么定。

我的建议是设一个虚拟的"任务体系治理小组"，由效能、质量、业务侧各一名代表组成，每季度开一次会，权力包括批准新增、批准合并和批准退役。这个小组不需要专职，但要有人真正负责。

八、取舍：五个必须提前想清楚的权衡

任务类型管理里没有"全都要"的选项。下面这五组取舍，我几乎在每个项目里都会遇到，提前想清楚能省掉大量返工。

1. 标准化 vs 灵活性

标准化让数据可比、报表可用；灵活性让团队按自己的方式工作、减少抵触。我的判断是类型必须标准化，属性和视图可以灵活。类型是全局的公共语言，一旦允许各团队自定义，跨团队聚合就失效了；而字段、看板视图、筛选器这些是团队内部的工具，允许灵活反而能提高采纳率。

2. 统一平台 vs 部门自治

中大型企业常有的争论是：研发用一套，业务用一套，还是全部统一。我的经验是平台统一，类型体系分区，聚合视图打通。完全统一会让某些部门的流程被扭曲，完全分开则管理层失去全局视角。三分开七统一，通常是更稳的解法。

3. 字段丰富 vs 填写成本

每个字段都有价值，也都有成本。我的取舍标准是：一个字段如果不能在三个月内被至少一次管理决策使用，就先不要加。这条规则能过滤掉大约一半的字段申请。字段加上去容易，让人持续填却很难，填不准的字段比没有字段更危险。

4. 迁移保真 vs 迁移精简

这是我参与过的迁移项目里最大的分歧点。保真派担心历史数据丢失，精简派希望借机瘦身。我的结论很明确：数据要保真，类型要精简。也就是所有历史记录一条不少地迁过来，但新体系用新的类型结构，旧类型作为只读属性字段保留。这样两边诉求都能满足，唯一的成本是迁移时多做一层字段映射。

支持 Jira 平滑迁移的平台在这一步能省下大量工作，尤其是历史任务量在几万条以上的时候。人工导入不仅慢，还容易在类型映射上出现错漏，而错漏的历史数据后面几乎无法修复。

5. 私有化部署 vs SaaS

这取决于合规要求和 IT 能力，不完全取决于规模。我的判断标准是三条：是否有数据不出内网的硬性要求、是否有等保或行业审计要求、是否有专职 IT 运维能力。三条中命中两条以上，就应该认真评估私有化部署。

反过来，如果团队只有几十人、IT 能力薄弱，强行私有化会带来持续的运维负担，反而拖慢迭代。这个取舍不该由效能团队单方面决定，应该拉上安全和 IT 一起评估。

九、总结与下一步：把类型治理变成组织的一项习惯

回到开头那 37 个类型。这件事最值得记住的不是"37 太多"，而是它背后的组织行为模式：每一个新类型被创建时，都曾是一个合理的、有具体场景的、被某个认真的人郑重提出的请求。失控不是因为有人乱来，而是因为没有人对"总量"负责。

所以我对任务类型管理的核心观点是：它不是一个设计问题，而是一个治理问题。设计能让你得到一个好起点，治理才能让你保持住。三条准入规则、四层属性模型、季度 15 分钟例会，这三样东西构成了我目前最有效的一套组合。

如果你打算现在就开始，我建议按这个顺序走第一步：

1. 今天：导出近 24 个月的任务数据，按类型统计使用频次和最后使用日期，不做任何判断，只看数字。
2. 本周内：把使用次数低于 20 次、且超过 12 个月未使用的类型列出来，这就是你的第一份退役候选清单。
3. 两周内：挑出使用量前 80% 的 5 到 9 个类型，逐条检查它们的状态机是否真的不同，把状态机相同的合并掉。
4. 一个月内：建立新旧类型映射，把被合并类型的差异转成标签或自定义字段，并保留原始类型名作为只读属性，确保历史数据可追溯。
5. 一个季度内：在季度例会上固定 15 分钟的类型治理议程，并跑完第一次准入评审。

最后提醒一句：不要指望一次做到完美。我在自己的团队里也经历过三次反复，第一次精简之后半年又长回来两个类型。但只要季度机制还在运转，体系就有回弹力。任务类型管理的目标从来不是零新增，而是让每一次新增都有据可依、每一次退役都有人负责。