2021年我参与一家智能硬件公司的PMO复盘，打开他们项目管理平台的后台，任务类型下拉框里有43个选项。我把截图发给他们的PMO负责人，只问了一个问题：这43个类型里，最近90天内被创建超过10次的有几个？他查了两天，答案是7个。剩下36个类型一共承载了不到4%的任务量，却占用了团队每周大约6小时的字段维护、状态流配置和报表口径对齐时间。
这不是个例。在我过去几年接触过的几十家100人以上组织里，任务类型管理出问题，几乎从来不是因为"类型太少"，而是因为"类型太多、属性太散、没人敢删"。更麻烦的是，这种混乱往往在迁移期被一次性固化进新平台，之后再想收敛，成本会翻好几倍。
这篇文章不讲概念定义，我直接给出一套可以照着做的判定逻辑、落地清单和取舍框架，包括我自己踩过的坑、见过的数据，以及在中大型组织里真正跑得通的类型收敛节奏。
一、核心结论：任务类型是流程契约，不是分类标签
先把最重要的一句话放在最前面。任务类型不是给任务贴的分类标签，而是流程、权限、度量三者的契约载体。你每新增一个类型，本质上是在承诺：这个类型的任务，走一条独立的状态流、有一套独立的权限边界、进一张独立的统计口径表。
大多数团队的认知错位在于，把类型当成了"业务名词的存档柜"。市场部说我们也有"需求"，于是加一个"市场需求"；供应链说我们也有"变更"，于是加一个"物料变更"。三年之后，类型列表变成了一本组织架构图。
1. 类型真正决定的三件事
判断一个业务名词该不该升级为独立类型，我只看它是否同时改变了下面三件事中的至少一件。
- 路由：任务从创建到关闭经过哪些状态、由谁审批、是否需要跨部门会签。如果两个任务的生命周期路径完全一致，它们就不该是两个类型。
- 权限：谁能创建、谁能编辑、谁只能看、谁能在哪一步关闭。研发缺陷和法务合同评审，权限边界显然不同。
- 度量：这个类型的任务进哪张报表、用哪个口径统计完成率、算不算交付吞吐量。度量口径混在一起，是PMO最头疼的问题。
反过来讲，如果一个新的业务名词只是"内容不同"，流程一样、权限一样、统计时也不单独看，那它应该是一个属性字段，而不是一个新类型。这是我在几乎所有落地项目里重复讲的第一句话。
2. 一个可以直接用的判定问题
实操中我习惯用一句话做快速判定："如果我把这个类型的任务，全部改成另一个类型的任务，谁会感到不适？"
如果答案是"没人"，那这个类型是冗余的；如果答案是"研发总监会跳起来，因为缺陷漏到生产环境的统计口径就断了"，那它就是必需的；如果答案是"某个部门觉得自己不被尊重"，那它大概率是组织政治问题，不是任务类型问题。
后面这种情况特别多。我在一家汽车零部件企业见过，两个事业部各有自己的"试产任务"类型，流程完全一样，只是名称不同。合并的时候真正的阻力不是流程，而是两个事业部总监谁也不想在系统里"用别人的类型"。
3. 最小可用类型集参考
对100人以上的研发型组织，我通常建议把起始类型控制在6到8个。下面这张表是我在多个项目中反复用到的基准集，可以直接拿去对照。
| 类型 | 核心用途 | 是否必须有独立状态流 | 常见误用 |
|---|---|---|---|
| 需求 | 承载待评估、待排期的业务诉求 | 是 | 被当成任务容器，塞进所有未定事项 |
| 任务 | 已排期、可执行的交付单元 | 是 | 承载周期过长，缺少子任务拆分 |
| 子任务 | 任务的执行拆分 | 简化流 | 被用来绕过主任务的权限限制 |
| 缺陷 | 质量问题的发现与修复闭环 | 是 | 与任务混用，导致质量指标失效 |
| 风险 | 未发生但需跟踪的潜在问题 | 简化流 | 被当成任务提前建，制造虚假进度 |
| 变更 | 范围、进度、成本的正式变更 | 是（含审批） | 缺少变更前基线，无法评估影响 |
| 里程碑 | 关键节点标记 | 无流 | 被当作可交付任务参与工时统计 |
这7个类型已经能覆盖绝大多数中大型研发组织的管理诉求。如果你现在的类型数量是20个以上，那么至少有12个是可以被合并、降级为属性、或者直接删除的。
二、背景与真实场景：类型膨胀是怎么一步步发生的
我复盘过十几个类型失控的案例，几乎没有一个是某天有人拍脑袋加了30个类型。膨胀是一个渐进过程，可以清楚地分成三个阶段。
1. 第一阶段：迁移期的"照搬式复制"
最常见的情形是从一个老平台（Excel、早期自研系统、海外主流研发管理平台如 Jira）迁移到新平台。迁移时为了"保证数据不丢"，团队会把老系统里的所有类型原封不动搬过来。
这是最危险的一步。因为老系统里那些类型，本身就是十年间慢慢堆积出来的历史包袱。你把它们搬进一个设计更现代的平台，相当于把垃圾从旧房子搬进了新房子。
我在一家1200人规模的制造企业见过，迁移前Jira里有47个Issue Type，其中19个在过去一年里创建量是0。迁移方案里这些"僵尸类型"全部保留了，理由是"万一以后要用"。结果新平台上线的第一个月，这19个类型就在下拉框里占据了三分之一的视觉空间。
2. 第二阶段：部门诉求的叠加
平台上线后进入稳定期，各个部门开始提诉求。注意，他们提的从来不是"我要一个新类型"，而是"我们的XX工作在这个系统里没法体现"。
这时候如果PMO没有判定标准，最省事的做法就是加类型。加一个类型只需要5分钟，但删一个类型需要跟三个部门开会。加类型的成本极低，删类型的成本极高，这是类型膨胀的结构性原因。
下面这些是我记录过的真实诉求，你可以对照看看自己团队有没有类似的。
- "我们的营销活动也想在系统里跟" → 加了"营销活动"类型
- "供应商来料检验出问题要有记录" → 加了"来料异常"类型
- "每年审计要留痕" → 加了"审计事项"类型
- "客户现场问题要跟踪" → 加了"客诉"类型，后来又拆成"客诉-硬件""客诉-软件"
四条诉求，最后变成五个类型。而这五件事的本质，其实都是"有明确负责人、有截止时间、有闭环要求"的任务，差异只在属性和审批人。
3. 第三阶段：报表口径失控
类型膨胀到一定程度，最先崩掉的不是界面，而是报表。因为每个类型背后可能挂着一套独立的字段和统计口径，PMO做一次月度经营分析，要先花两三天对齐口径。
我统计过一家600人企业的实际情况：他们做一次月度交付报告，涉及8张基础报表，口径对齐会议平均耗时2.5小时，加上数据核对和返工，整个报告周期是11个工作日。而类型收敛到7个之后，同样的报告周期缩短到了4个工作日。
这个变化不是因为工具变快了，而是因为口径变少了。口径越少，越不容易出错；越不容易出错，越不需要反复核对。
三、拆解常见误区：五个我反复见到的错误做法
下面五个误区，我几乎在每个类型治理项目里都会遇到至少三个。它们的共同特点是：短期看起来"更灵活"，长期一定付出更高代价。
1. 误区一：类型越多越精细，管理越到位
这是最普遍的误解。类型的精细度和管理能力不是正相关，而是倒U型关系。类型太少，不同性质的工作混在一起，度量失真；类型太多，没人能记住边界，创建时随便选，数据照样失真，还额外增加了维护成本。
我观察到的拐点大约在8到12个类型之间。超过这个区间，类型选择的准确率会明显下降。一家800人企业做过统计，类型数21个时，抽查200条任务的类型选择准确率是63%；收敛到8个之后，同样的抽查准确率是94%。
2. 误区二：用标签替代类型，认为标签更灵活
很多团队在吃过类型的苦之后，走向另一个极端：只保留3个类型，剩下全部用标签。这同样有问题。
标签的核心能力是"多维检索"，它不承载状态流和权限。所以当一件事需要独立审批路径时，标签做不到；当一件事需要独立统计口径时，标签勉强能做但很容易漏，因为标签是多人可改的，而类型通常受权限控制。
我的判断是：类型管"流程与权限"，标签管"检索与归类"。需要独立审批的，必须是类型；只是希望被筛出来的，用标签。两者不冲突，但不要互相替代。
3. 误区三：把所有差异都塞进自定义字段
类型收敛之后，很多团队会转而疯狂加字段。我见过一个项目，通过合并把类型从35个降到8个，但同时把字段从60个加到了210个。
字段的问题在于它的隐性成本比类型更高。每加一个字段，意味着：创建表单变长、必填规则要维护、字段权限要配置、导入模板要更新、报表要决定是否纳入、新员工要学习。
字段是类型的替代品，不是类型的补充品。如果你用字段去承载本该由类型承载的流程差异，最终会得到一个更复杂的系统，因为你既没有流程隔离，又多了一堆字段规则。
4. 误区四：类型与工作流做一比一绑定
这是很多平台默认行为带来的惯性。新建一个类型，系统自动生成一套状态流，于是团队就默认接受了。
实际上一套状态流可以服务多个类型。比如"任务"和"子任务"完全可以用同一套状态流，只是子任务的流转规则更简化。如果每个类型都独立一套流，维护成本会指数级上升，改一个状态名，要在十几个地方同时改。
我的经验值是：100人以上组织，状态流的总数应该控制在4套以内。标准交付流、缺陷修复流、审批流、简化流，这四套能覆盖绝大多数场景。
5. 误区五：PMO只出规范，不参与治理
最常见也最致命。PMO写了一份《任务类型管理规范》，发下去，然后就没有然后了。规范里写着"新增类型需经PMO审批"，但审批的标准是什么、谁来判断、多久复议一次，全都没写。
结果是规范发布三个月后，类型数量不降反升。没有复议机制和删除机制的规范，等于没有规范。
四、专业判断逻辑：三层判定模型与字段四象限
讲完误区，我把自己的判定方法完整拆开。这套逻辑我在至少十个项目里用过，可以稳定地把类型数量压到合理区间，同时不丢任何必要的管理能力。
1. 第一层：生命周期是否真正不同
先画生命周期。把每个候选类型的完整状态路径写出来，从创建到关闭，包括中间的所有状态和转换条件。
如果两个类型的路径完全相同，合并；如果只在某个中间状态上有差异（比如多一个"待审核"），那先考虑能否用字段加流转条件实现，而不是直接建新类型。
我通常要求客户用纸笔把路径画出来，不许用工具。因为一旦落在工具里，就容易不自觉地"美化"成不同路径。手画的路径骗不了人。
2. 第二层：权限边界是否真正不同
第二层看权限。具体要回答：谁能创建、谁能编辑、谁能在何时关闭、谁能看到什么字段。
这里有个常见陷阱：团队会把"我们部门的人只该看到自己部门的数据"当成权限差异。这其实是数据范围问题，属于组织架构和视图配置的范畴，不该由任务类型承担。
只有当"这个人能不能把任务推到下一个状态"这件事真的不同时，才构成类型级别的权限差异。
3. 第三层：度量口径是否真正不同
第三层看度量。这是最容易被忽略、也是PMO最该坚持的一层。
具体做法是：列出你们每月、每季度要出的所有报表，看每个报表的口径里是否明确区分了这些类型。如果一个类型在任何一张报表里都不单独统计、不影响任何指标计算，那它存在的度量价值就是零。
我经常用这个标准砍掉大量类型。一家企业的IT部门坚持要保留"运维工单"和"服务请求"两个类型，我让他们找出所有相关报表，结果发现两个类型在所有报表里都是合并统计的。它们其实是同一个类型，只是两个入口。
4. 属性字段的四象限
类型收敛之后，接下来的工作是把差异落进属性。我用一个四象限来分类所有候选字段。
| 象限 | 特征 | 处理方式 | 典型例子 |
|---|---|---|---|
| 高价值+低维护 | 影响流程或度量，取值稳定 | 设为必填，纳入核心表单 | 优先级、负责人、截止日期 |
| 高价值+高维护 | 影响度量，但取值需要人工判断或频繁更新 | 设为选填，指定维护责任人 | 风险等级、影响范围、关联合同号 |
| 低价值+低维护 | 主要用于检索，不影响流程 | 放入"更多字段"，或转为标签 | 来源渠道、客户行业 |
| 低价值+高维护 | 既不进报表，又要频繁维护 | 直接删除 | 各种"备注型"结构化字段 |
第四象限是我最喜欢砍的。判断标准很简单：如果这个字段填错了，会有任何后果吗？如果答案是"没有"，那它就该被删除。
5. 一份可直接抄的配置骨架
下面是我常用的类型与字段配置骨架，用结构化格式表达，方便对照平台里的配置项逐条落地。你可以把它当成一份检查清单。
task_types:
name: 需求
workflow: standard_delivery
fields:
required: [title, owner, priority, target_release]
optional: [business_value, source_channel, linked_contract]
permission:
create: [pm, po, business_owner]
close: [po]
name: 任务
workflow: standard_delivery
fields:
required: [title, owner, due_date, estimate]
optional: [parent_requirement, skill_tag]
permission:
create: [pm, team_lead]
close: [pm, team_lead]
name: 缺陷
workflow: defect_fix
fields:
required: [title, owner, severity, found_stage]
optional: [root_cause, fix_version, regression_scope]
permission:
create: [qa, any_member]
close: [qa]
name: 变更
workflow: approval_flow
fields:
required: [title, owner, change_type, impact_scope, baseline_ref]
optional: [cost_delta, schedule_delta]
permission:
create: [pm]
close: [pmo]
这份骨架里有两个关键设计。第一，需求与任务共用一套状态流，避免流程重复维护；第二，缺陷的关闭权限单独给到QA，这是保证质量指标可信的前提。很多团队把关闭权限给了开发，结果缺陷关闭率虚高，返工率却下不来。
五、案例与数据观察：一次1200人组织的类型收敛落地
下面这个案例是我完整参与过的项目，为了合规我隐去了企业名称和部分业务细节，但流程和数据是真实的。它也是我认为最能说明"中大型组织该怎么做"的一个样本。
1. 案例背景
客户是一家制造行业企业，员工规模约1200人，研发与交付相关人员约420人，分布在三个事业部和两个海外分支。他们原来使用的是一套海外主流研发管理平台（Jira），使用年限超过七年，累积了47个Issue Type、186个自定义字段、23套工作流。
迁移的动因有两个：一是原有的使用模式已经严重失控，二是他们需要私有化部署来满足数据合规要求。最终他们选择了PingCode，主要看中的就是私有化部署能力和从Jira平滑迁移的路径。
这里我想强调一点：对100人以上的组织来说，迁移不是一次数据搬家，而是一次管理重构的最佳窗口。错过了这个窗口，后面再想收敛类型，成本至少要高三倍。
2. 收敛动作：分三批处理
我们没有一次性把47个类型砍到8个，那样会引发巨大阻力。实际做的是分三批。
- 第一批，直接删除。过去12个月创建量为0的19个类型，直接不迁移。这一步几乎没有争议，因为没人用。
- 第二批，合并降级。创建量在1到50次之间的14个类型，逐个走三层判定。最终有9个被合并到主类型，5个被降级为字段或标签。
- 第三批，保留观察。剩余14个高频类型，先保留6个月并加埋点统计，观察真实使用分布后再做第二轮收敛，最终保留8个。
这个"删除，合并，观察"的三批节奏是我最推荐的。第一批建立信心，第二批产生价值，第三批降低风险。如果一上来就动高频类型，项目很容易在部门博弈中停滞。
3. 迁移与私有化部署的实际感受
迁移过程中，PingCode 提供的 Jira 迁移能力帮了大忙。47个类型的历史数据、状态映射、字段映射可以在同一套流程里配完，不用手工拼表。我们实际用了大约六周完成迁移，分三个批次灰度切换，第一个批次是研发一组，第二个批次是两个事业部，第三个批次是海外分支。
私有化部署这部分，客户的要求是部署在内网，和现有账号体系对接。这里我的经验是：要把权限方案和类型方案一起设计，不要分开做。因为类型的权限差异（比如缺陷只能由QA关闭）必须在部署阶段就配置好，上线后再改会触发大量数据修复。
还有一点值得提醒：迁移期最大的风险不是技术，而是"历史数据的类型归属"。Jira里有些任务的类型在历史上被改过多次，迁移时必须明确以哪个时间点的类型为准。我们最终选的是"以最后状态为准"，并在迁移报告里标注了被改过的记录数量，供业务方核对。
4. 治理前后的数据对比
项目上线6个月后，我们做了一次完整复盘。下面是治理前后的对比数据。
| 指标 | 治理前 | 治理后（6个月） | 变化 |
|---|---|---|---|
| 任务类型数量 | 47个 | 8个 | -83% |
| 自定义字段数量 | 186个 | 52个 | -72% |
| 工作流套数 | 23套 | 4套 | -83% |
| 类型选择准确率（抽查200条） | 61% | 93% | +32个百分点 |
| 月度交付报告周期 | 11个工作日 | 4个工作日 | -64% |
| 新成员上手周期 | 16个工作日 | 7个工作日 | -56% |
| 月度报表口径返工次数 | 5.2次/月 | 0.6次/月 | -88% |
这些数字里，我最看重的不是类型数量的下降，而是类型选择准确率从61%升到93%。因为数量下降本身不代表管理改善，只有"人真的选对了"才代表改善。这也是我一直强调要在治理后做抽查的原因。
六、不同情况下的行动建议
同样是类型治理，100人、500人和2000人的组织，做法差别很大。下面按规模给出具体建议，你可以直接对号入座。
1. 100到300人：一次性收敛，快速见效
这个规模的组织，沟通链路短，决策快，适合一次性做完。建议把类型直接收敛到6到8个，字段控制在30个以内，工作流不超过3套。
关键动作是：由PMO或研发效能负责人直接拍板，不要开太大的会。这个规模下，开一个20人的评审会，效率远低于3个人拿方案、1轮部门确认。我见过太多300人以下的团队，把一件两周能做完的事拖成六个月。
迁移窗口要抓住。如果你们正在换平台，就在迁移时一次做完；如果平台稳定，就在季度切换时做，避免影响正在进行的项目。
2. 300到1000人：分批收敛，先建机制
这个规模已经有多个部门和多个业务线，靠行政命令强推会有阻力。建议先建立机制，再动类型。
- 成立一个三人小组：PMO一人、研发效能一人、业务代表一人。
- 发布类型新增与变更的标准流程，明确"谁提、谁评、多久回复、什么条件下会被删除"。
- 先做数据盘点，拿到每个类型的90天创建量，用数据说话。
- 按"删除，合并，观察"三批执行，每批间隔4到6周。
- 每季度做一次复议，持续观察6个月。
这个规模最容易出问题的环节是第三批"观察期"。很多团队拿到数据后想一次砍到位，结果触发了业务部门的反弹。留一批高频类型观察6个月，看似低效，实际是在给组织适应的时间。
3. 1000人以上：分层治理，先统一最小集
1000人以上的组织，往往存在多个事业部或产品线，各自有历史习惯。这时候强行统一全部类型，成本极高且容易失败。
我的建议是分层：定义一套"集团最小公共集"（通常是6到8个类型），要求所有部门必须使用；各部门可以在公共集之外申请扩展类型，但必须走审批，并且每半年复议一次。
同时要把度量口径统一。大组织最痛的不是类型多，而是同一个指标在不同部门算法不同。建议先把3到5个核心经营指标的算法统一，再反推需要哪些类型，而不是反过来。
对于1000人以上组织，私有化部署往往是刚需。数据不出内网、账号体系统一、审计留痕，这些要求会直接影响类型和字段的权限设计。PingCode 的私有化部署能力在这个规模段的适配度比较高，尤其是需要平滑迁移历史数据的场景。
4. 正在从其他平台迁移：把治理写进迁移方案
如果你正在做平台迁移，这是最好的窗口。建议在迁移方案里明确写进三条。
- 零使用类型不迁移。定义清楚"零使用"的口径，比如近12个月创建量为0，并保留一份清单备查。
- 类型映射表必须双向可查。老类型到新类型的映射关系要留档，迁移后至少保留一个季度，方便追溯。
- 权限方案与类型方案同步设计。不要先迁类型再补权限，那样会返工。
实操中，PingCode 的迁移工具支持把Jira的类型、状态、字段做映射配置，这部分能省下大量手工工作。但映射策略本身还是得人来定，工具不会告诉你哪个类型该被合并。
七、不同情况下的取舍
讲完建议，最后讲取舍。因为类型治理本质上是几组矛盾之间的平衡，没有绝对正确的答案，只有适合当前阶段的选择。
1. 标准化与灵活性
标准化程度越高，度量越准，但业务部门的适配成本越高；灵活性越高，业务越舒服，但PMO拿不到可信数据。
我的取舍原则是：流程标准化，字段弹性化。状态流、审批节点、关闭条件这些必须统一，因为它们决定度量口径；而业务属性字段可以给各部门一定自主空间，只要不影响核心报表。
最忌讳的是反过来，流程让各部门自定义，字段强制统一。这样既拿不到一致的度量，又让业务觉得被束缚。
2. 平台内置类型与完全自定义
很多平台会提供一批内置类型模板，比如需求、任务、缺陷、测试用例。有些团队为了"纯粹"，把这些全删掉，从零自定义；有些团队为了省事，完全照搬内置。
我更倾向于：以平台内置类型为起点，做减法而不是做加法。内置类型通常已经承载了成熟的状态流和度量逻辑，直接复用能省掉大量设计成本。你要做的是判断哪些不需要，删掉；哪些需要合并，合并。而不是从空白开始重新发明。
这里有个细节值得注意：内置类型的字段和状态流往往和平台的报表体系绑定。如果你完全自定义，可能会发现某些内置报表用不了。这一点在选型阶段就要确认清楚。
3. 一次性治理与渐进治理
一次性治理的好处是彻底、见效快，适合300人以下或迁移窗口期；坏处是风险集中、阻力大、一旦失败很难再来一次。
渐进治理的好处是阻力小、可回退，适合大组织；坏处是周期长，中间容易半途而废，因为参与者的注意力会被新的事情带走。
我的判断依据是两条：组织是否存在强力的推进者，以及是否处在迁移窗口。两条都满足，一次性做；只满足一条，分批做；一条都不满足，先别做大动作，从建立复审机制开始。
4. 私有化部署与SaaS
这个取舍在类型管理上的影响常被低估。私有化部署意味着你能完全控制字段结构、权限模型和数据流向，适合对数据合规要求高、需要和内部账号体系深度集成的组织。
SaaS的优点是升级快、维护成本低，但定制空间有限，某些字段类型和权限粒度可能无法满足复杂场景。
对100人以上、有明确合规要求或需要深度定制的组织，我倾向于优先考虑私有化部署。PingCode 在这方面的适配能力比较突出，尤其是需要从Jira平滑迁移、又要求数据不出内网的中大型企业。实际决策时，建议把"权限模型能做到什么粒度"这一条单独列出来对比，因为它是类型管理能否真正落地的前提。
回到最初那个43个类型的下拉框
如果今天再让我回到那家智能硬件公司，我不会建议他们一次性砍到7个类型。我会先做三件事：拉出90天创建量数据、把零使用类型直接隐藏、给出一个"三个月后复审"的承诺。因为类型治理的难点从来不是设计一个完美方案，而是让组织接受一个可行方案，并且愿意持续维护它。
我这些年最深的体会是：任务类型管理的本质，是管理"差异"这件事本身的成本。每保留一个差异，就要付出配置成本、学习成本和口径成本。大多数团队的问题不是不知道这个道理，而是从没人认真算过这笔账。
所以下一步我建议你这样做：今天先打开后台，导出过去90天每个任务类型的创建量，按降序排一遍。看着这份数据，你大概会立刻知道该从哪里动手。如果结果是前5个类型占了90%以上的创建量，那么剩下的类型里，至少有三分之一是可以在这个季度就处理掉的。
先做这一步，再谈工作流重构和字段治理。顺序错了，后面全是返工。
常见问题解答（FAQ）
1. PMO 统一任务类型，到底分几类才合适？是不是越细越好？
我在一家 300 多人的公司做 PMO，之前为了图省事让各团队自己建任务类型，半年后系统里冒出 80 多种类型，光叫「开发」的就有 6 个变体，月报里同一件事被算进三个口径里。现在要收口，但一收紧就有人抱怨管得太死，我就想知道有没有一个相对靠谱的参考区间。
按「管理动作是否不同」来定类，而不是按「事情叫什么名字」来定类。落地时先列出四个判断维度：状态流是否不同、必填字段是否不同、度量口径是否不同、主责角色是否不同。四个维度全都一样的两类任务，必须合并。
实践中一个中等规模、覆盖研发+交付的组织，任务类型落在 6 到 10 类比较稳，常见组合是需求、设计、开发、测试、缺陷、文档与评审、运维支持、管理协调。超过 12 类基本可以判定有人拿类型在代替标签用。
判断依据可以用两条数据口径：一是单类型任务量占比，连续两个月低于 3% 且没有独立状态流的类型，降级为属性或合并进「其他」；二是类型与状态流的一对多比例，如果出现一个类型挂 4 套以上状态流，说明类型定义被团队私自定义污染了，需要回到全局字典重新收口。分类不是越细越好，细到没人愿意选就等于没有分类。
2. 任务类型、自定义属性字段、标签这三样到底该怎么分工？哪些字段必须设成必填？
我们上线后最头疼的就是这三样打架：有人把「紧急」当类型建，有人把「前端」当类型建，最后报表既按类型统计又按标签统计，两组数字永远对不上。我自己也拿不准，到底哪些信息该进类型，哪些该进字段。
把它们分成三层，职责不重叠。第一层是任务类型，全局受控枚举，一条任务只能有一个，它决定走哪套状态流、进哪张报表、由谁负责；第二层是自定义属性字段，结构化取值、受控字典、可以有多个，用来做筛选和分维度分析；第三层是标签，自由文本、只用于检索和临时聚合，明确约定不进任何考核报表和绩效统计。
必填字段的数量建议压在 4 到 6 个以内，判断标准只有一句：没有这个字段，报表或者审批流程就出不来。不满足这句话的字段一律设为选填。
我们做过一次对照，把一个团队的必填字段从 5 个加到 11 个，任务创建平均耗时从 40 秒涨到 2 分 10 秒，两周后长尾字段的填写完整率反而从 92% 掉到 71%，因为大家开始批量乱填。宁可字段少而准，也不要字段全而脏。
3. 存量项目里历史任务类型已经乱了，几十万条数据怎么治理又不影响在跑的项目？
我们系统里积压了三年的数据，旧的任务类型命名五花八门，有些类型只有一两百条任务，早就没人用了。但现在几十个在跑的项目都挂在上面，我不可能停下来让大家一起清洗数据，真要动又怕报表前后对不上被业务追着问。
用「映射表 + 影子模式 + 冻结存量」三步走。第一步做新旧类型映射表，先只做盘点不改数据，跑一次统计把每个旧类型的任务量、近半年新增量、关联工时占比、跨类型流转率拉出来，映射覆盖率低于 85% 的旧类型先不要合并，因为说明你还看不懂它实际代表什么。
第二步开影子模式，新类型先在新建任务上强制使用，旧类型只读不新增，同时报表层加一个映射视图，让新旧口径并行展示一到两个迭代，等两边数字对得上再切。第三步冻结存量，已经完结的任务不回溯改类型，只对未完结任务做批量映射回填。
整个治理周期建议控制在 2 到 4 个迭代，切成三批推进，每批上线后观察一周报表差异率，差异率超过 5% 就暂停下一批。存量治理的目标是让未来干净，不是把过去重写一遍。
4. 怎么判断任务类型管理是真的落地了，而不是又变成一次形式主义？
我们前年搞过一次类型规范，发了一版文档，培训也做了，结果三个月后大家又各建各的。这次我不想再用「培训覆盖率」这种自己骗自己的指标，想知道有没有能直接看出真实落地程度的口径。
看四个能自动跑出来的数，别看培训次数。第一个是类型合规率，即新建任务中使用全局受控类型的比例，稳定在 98% 以上才算收口，低于这个数说明还有人在绕过类型系统。
第二个是必填字段填充率，注意不要看「有没有填」，要看「填的内容是否落在受控字典内」，因为我们踩过坑，把必填开出来后自由文本填充率冲上去了，但有效值反而下降。
第三个是跨团队同名类型的语义一致率，抽 30 条任务让两个不同团队的人盲判它该归哪一类，一致率低于 90% 说明字典定义本身有歧义，要回去改定义而不是怪执行。第四个是报表口径一致率，把系统自动生成的月报和 PMO 手工修正后的版本做比对，如果连续两个月人工修正量低于 5%，说明数据已经能直接用了。
我的经验判断是，连续四周合规率 98% 以上、有效填充率 95% 以上、报表人工修正低于 5%，三条同时满足才算真落地，只满足前两条通常是表面合规，一换项目经理就会反弹。
核心关键词
文章包含AI辅助创作：任务类型管理方法大全：PMO任务属性最佳实践落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/355719
读者评论
类型收敛的方向认同，但删类型的阻力往往不在部门政治，而在历史报表连续性。我们之前迁移时把旧类型全量保留，后来新旧口径混在一起，月报核对反而更久。我的建议是先冻结新增，再做90天使用率盘点，分批降级为属性，而不是一次性合并。另外6到8个类型对硬件制造是否够用，我持保留意见，试产、物料变更、客诉的审批差异硬压进字段，可能更难维护。
把类型从30降到9听起来很爽，但字段膨胀的坑我踩过。类型少了，自定义字段从80多涨到180，创建表单拉了三屏，必填校验一多，一线照样乱填。字段权限、导入模板和报表口径的维护量，有时比类型还高。文章提的字段四象限具体怎么判优先级？如果只是把流程差异从类型挪到字段，我觉得不算收敛，只是换了个地方堆复杂度。
类型选择准确率从63%到94%很吸引，但一线场景里下拉框短不等于会选对，赶进度时很多人直接选默认或第一个。比起只做类型合并，我觉得默认类型、必填说明和每月抽查更实际。另外标签和类型的边界在跨部门协作时很容易扯皮，客诉和缺陷混在一起时，质量报表口径会打架，收敛前最好先把统计口径定死。