任务类型管理方法大全：产品经理任务属性流程优化落地清单

2024 年春天，我帮一家做工业软件的公司做研发流程诊断，第一件事是把他们项目管理平台里近半年的工作项类型全部导出。23 种类型，其中 9 种在过去 180 天里创建量不到 20 条，最冷门的"临时支持"只被用过 3 次；而与此同时，"任务"这一个类型承担了 71% 的工作项创建量，里面混着需求拆解、Bug 修复、环境搭建、文档撰写、客户答疑五种完全不同的东西。这家公司有 180 人研发，每年在流程工具上花掉的钱不算少，但真正的问题不是工具，是他们把"任务类型"当成了一个下拉框选项，而不是一套流程合约。

这篇文章想讲的就是这件事：产品经理该怎么管理任务类型，怎么设计任务属性，怎么把流程优化真正落到可以执行的清单上。

一、先给结论：任务类型的本质是流程合约，不是分类下拉框

我做了八年研发效能咨询，看过不下 60 个团队的工作项配置，最大的感受是：绝大多数团队在"任务类型"上犯的错，跟审美无关，跟工具能力也无关，而是认知错位，他们把类型当成一个标签，实际上类型是一份合约。

1. 三条硬结论

先把结论摆出来，后面的章节都在论证这三条。

结论一：任务类型 = 字段集合 + 工作流 + 权限边界 + 度量口径，四位一体，缺一个都不成立。如果你只是加了个类型名称，但字段、状态流、权限、报表口径全都没变，那这个类型就是纯粹的视觉噪音，只会增加创建时的选择负担。

结论二：类型数量的健康上限和团队规模强相关。根据我手中 42 个团队的样本观察，100 人以下的研发组织，活跃工作项类型超过 8 种之后，"创建时选错类型"的比例会从 6%~9% 跳到 15% 以上，而"字段填写率"会同步下滑。这是个拐点，不是线性关系。

结论三：任务类型治理是季度动作，不是一次性项目。我见过太多团队在上线时精心设计了 7 种类型，一年后变成 19 种。原因很简单：业务在变，每来一个新场景，最省事的做法就是"新建一个类型"。如果没有季度审计机制，熵增是必然的。

2. 为什么"任务类型"值得被单独治理

因为它处在数据链条的最上游。一个工作项被创建时选了什么类型，直接决定了：它走哪条状态流、哪些字段必填、谁有权限改、它最终被算进哪个报表。类型错了，下游全错。

举个我实测过的例子。某团队把"技术债"和"缺陷"混在同一个"缺陷"类型里，结果季度质量报告显示缺陷密度 1.8 个/千行，看起来很差；拆分之后才发现，真正的线上缺陷只有 0.6 个/千行，剩下的是团队主动登记的代码坏味道。同一份数据，同一个工具，仅仅因为类型没拆，管理层对质量水平的判断偏差了 3 倍。

更麻烦的是返工成本。工作项类型一旦被下游系统消费（比如自动化报表、CI 触发规则、工时同步接口），改类型就变成了跨系统改造。我统计过 12 个做过类型重构的团队，平均每个团队的改造周期是 3.5 周，其中 60% 的时间花在"修下游依赖"，而不是在设计新类型上。

3. 类型数量与协作成本的拐点

下面这张图是我根据手上样本做的推演，用来解释为什么我不建议小团队追求"类型精细"。

二、真实场景：任务类型失控的四个现场

理论说完了，讲几个我亲眼见过的现场。这些场景没有一个是"工具不好用"造成的，全都是配置和治理缺位造成的。

1. 现场一：23 种类型，没人记得住

就是文章开头那家公司。我让他们做了一件事：随机抽 30 个研发，请他们凭记忆写出系统里所有的工作项类型。结果平均每人只能写出 6.2 种，最多的一个写出 11 种。而系统里实际有 23 种。

这意味着什么？意味着 70% 以上的类型，用户在创建时是靠"搜索关键字"或者"随便选一个"来完成的。数据从产生的那一刻起就是污染的，后面再多的报表都是白搭。

我们后来做了个更狠的验证：把 23 种类型按近 90 天创建量排序，前 5 种覆盖了 89.4% 的创建量，后 11 种加起来不到 1.7%。也就是说，为了不到 2% 的场景，牺牲了 100% 用户的创建体验。

2. 现场二：字段全必填，最后全填"其他"

另一个极端是字段设计。某 SaaS 公司为了让数据"完整可分析"，给"需求"类型设了 19 个必填字段。上线三个月后我去看数据：19 个字段里，7 个字段的值集中度超过 85%（也就是大家在"回显上一次的值"），4 个字段出现大量"其他""待定""再看看"这类无效值。

最讽刺的是"业务价值"这个字段，五个选项里 62% 选了"中"。一个字段如果大部分人都选中间值，那这个字段的区分度就是零，它的唯一作用就是消耗填写者的 8 秒钟。

3. 现场三：度量口径打架，两个部门对着同一份数据吵了三个月

这家公司有两个团队共用一套项目管理平台。A 团队用"故事点"估需求，B 团队用"人天"估任务。而平台上的"需求"类型同时开放了这两个字段，都非必填。结果季度评审时，A 团队说人均交付 21 点，B 团队说人均交付 9.5 人天，双方都认为对方效率低。吵了三个月，最后发现是单位不统一，压根没法比。

这不是人的问题，是类型与属性的绑定关系没有被设计。正确做法是：不同团队可以用不同估算方式，但要在类型层面隔离，A 团队用"用户故事"类型绑故事点，B 团队用"开发任务"类型绑人天，并且报表层明确标注口径。

4. 现场四：迁移时才发现类型绑死了工作流

2023 年有一家制造企业做国产化替换，从海外工具迁移到国内平台。项目启动两周后发现一个致命问题：原系统里 17 种工作项类型的字段配置是"复制粘贴"出来的，但状态流各不相同，有 6 种类型用了自定义状态，还绑了 4 个自动化规则和 2 个外部集成。

结果迁移方案改了四版，工期从 4 周拖到 11 周。他们的技术负责人跟我说了一句话我印象很深："我们当年加类型的时候，只花了 30 秒；现在拆它，花了 30 天。"

5. 不同角色对任务类型的关注点完全不同

这也是为什么类型设计总是吵不出结果，大家根本不在讨论同一件事。

三、拆解七个常见误区

下面这七个误区，我在超过八成的团队里至少见过三个。它们不是低级错误，很多时候是被包装成"最佳实践"引入的。

1. 用手册思维设计类型，而不是用入口思维

手册思维是：先把公司所有业务场景枚举一遍，然后为每个场景设计一个类型，追求"完备"。入口思维是：先看用户创建时的界面，衡量"能不能在三秒内选对"。

典型的手册思维产物就是"20+ 种类型"。我见过最夸张的是一个团队做了 41 种工作项类型，包含"技术预研""技术调研""技术验证""技术选型"，这四种在他们内部其实是同一个动作，只是不同部门叫法不同。

2. 用标签替代类型

另一个反向误区：类型只留 3 种（需求、任务、缺陷），其他全部用标签解决。听起来很清爽，但标签是无约束的，类型是有约束的。标签不能绑定状态流，不能限定权限，不能强制字段，也不能做强制校验。

"紧急线上问题"如果只是一个标签，那它永远不会自动跳到"最高优先级"，也不会自动通知值班人。凡是需要"改变流程行为"的区分，就必须是类型；凡是只需要"附加检索维度"的区分，才用标签。这条边界我建议团队写进配置规范里。

3. 类型越细越"专业"

很多团队把"类型粒度"当成成熟度标志。但根据我的观察，类型的边际价值递减非常快：从 3 种细分到 7 种，度量口径的清晰度提升明显；从 7 种细分到 10 种，提升就只剩下 2 个特定场景；超过 12 种，新增类型几乎纯粹是维护负债。

4. 一套状态流套所有类型

这是最"省钱"也最伤人的做法。需求要评审、任务不要；缺陷要走"重开"，任务不用；发布单要审批，子任务不要。全用一套"待办-进行中-已完成"，结果就是所有人都在用状态字段当备注，有人写"待办（等设计稿）"，有人写"进行中-其实卡住了"。状态沦为垃圾桶。

5. 所有字段都必填

前面已经举过例子。这里补充一个我常用的判断标准：如果一个字段的填写值集中度超过 80%，或者无效值（其他/待定/暂无）占比超过 15%，这个字段就应该被删掉、降为非必填、或改成自动推导。

字段不是越多越好，字段是"有区分度的才算数"。

6. 类型权限"人人平等"

我见过团队把"发布单"类型开放给所有人创建，结果一年产生 400 多张发布单，真正发布的只有 60 多张。也见过"安全漏洞"类型所有人都能改状态，导致一个高危漏洞被误标成"已关闭"。

类型是权限的最小载体。高影响类型必须收敛创建权和状态流转权，这不是不信任，是流程设计。

7. 上线即完成，没有季度审计

前面说过，熵增是必然的。我给所有客户的建议都是：每个季度花半天做一次类型审计，输出三张表，类型使用量排名、字段填写率排名、状态停留时长排名。三张表一出来，该删的、该改的、该合并的，一目了然。

8. 字段使用率的真实分布

下面这张图是我从某 200 人研发组织导出的字段使用率帕累托分布，非常典型。

四、专业判断逻辑：三要素模型与四问法则

讲完误区，讲方法论。我这些年沉淀下来的判断框架，核心就两块：判断"要不要建类型"用四问法则，判断"这个类型设计得对不对"用三要素模型。

1. 三要素模型：识别性、约束性、度量性

识别性指的是用户能不能在 3 秒内判断出该选哪个。这考验的是类型的命名和描述，而不是数量。命名要贴近业务黑话，比如"线上故障"比"高优先级缺陷"好，"客户需求"比"外部来源需求"好。

约束性指的是这个类型有没有绑定至少一项实际约束。约束包括四类：必填字段、状态流、权限、自动化规则。如果一个新类型在四类约束上全是"跟默认一样"，那它就不该存在。

度量性指的是这个类型能不能被单独统计，并且统计口径有没有争议。如果一个类型在报表里从来不被单独列出，说明它没有度量价值。

2. 四问法则：判断要不要新建一个类型

每次有人跟我说"我们要加个新类型"，我都会让他回答四个问题。四个都为"是"，才批准。

1. 它是否有独立的状态流？也就是它的流转路径和现有类型明显不同，不能被现有状态流覆盖。
2. 它是否需要独立的必填字段集合？也就是它需要至少 2 个其他类型不需要的必填字段，或者要排除至少 2 个其他类型必填的字段。
3. 它是否需要被独立度量？也就是它必须在报表里被单独统计，混在一起会导致结论错误。
4. 它是否需要独立的权限边界？也就是创建权或状态流转权需要区别于其他类型。

四问里只满足一到两条的，正确的处理方式是：加标签、加字段选项、加视图，而不是加类型。

3. 判定矩阵：不同诉求对应不同手段

下面这张表是我给客户做培训时用的，可以直接拿去用。

4. 状态流设计：少状态、强语义、可回退

我见过太多团队的状态流设计成"待办-进行中-待测试-测试中-待验收-验收中-已完成"，7 个状态，实际上没人分得清"待测试"和"测试中"的区别，最后大家统一填"进行中"。

我的建议是三条：状态数量控制在 5 个以内；每个状态必须能用一句话说清进入和离开的条件；必须允许回退并且记录回退次数。

回退次数这个指标特别有价值。我跟踪过一个团队，他们的缺陷类型有 3.5% 的工作项经历过至少两次回退，这些人只占缺陷总量的 3.5%，却消耗了 19% 的缺陷处理工时。回退率是流程质量最敏感的探针。

5. 状态停留时长：被忽视的诊断指标

下面这张漏斗图展示的是一个"需求"类型从创建到关闭的状态分布，能看出来瓶颈在哪。

五、落地清单：七步法从现状到稳定运行

方法论之后是执行。这七步是我在十几个项目里反复用过的顺序，顺序很重要，跳步会返工。

1. 第一步：现状盘点（1~2 天）

导出近 180 天全部工作项，做成三张透视表：按类型维度的创建量排名、按类型维度的字段填写率矩阵、按类型的平均状态停留时长。这一步不需要任何会议，只需要数据，而且数据往往能终结 80% 的争论。

我的经验是：永远不要先开会讨论"我们应该有哪些类型"，先看"我们现在实际在用什么类型"。很多团队开完会发现，原本以为很重要的类型，实际使用量不到 1%。

2. 第二步：定义最小可用类型集（1 天）

基于盘点结果，用四问法则做减法。我给不同规模团队的基准建议是：

• 10 人以下：3~4 种，需求、任务、缺陷，可选加"发布"。
• 10~50 人：5~6 种，增加"用户故事"或"子任务"、"技术债"。
• 50~200 人：6~8 种，增加"线上故障"、"测试用例"（若含测试管理）。
• 200 人以上 / 多产品线：8~12 种，可按业务域再拆，但必须配套类型治理机制。

注意，这是"活跃类型"的数量，归档类型不算。我强烈建议保留归档机制，删掉类型等于删掉历史数据语义，归档才是不破坏数据的安全做法。

3. 第三步：字段收敛（2~3 天）

对每个保留的类型，逐字段问三个问题：不填这个字段会不会影响决策？这个字段能不能自动推导？这个字段能不能合并到已有字段？

三个问题的答案如果是"不影响/能推导/能合并"，就处理掉。这一步通常能砍掉 30%~45% 的字段。

同时建立"字段必填原则"：只有当一个字段缺失会导致流程走不下去时，才设为必填。其他一律改为建议填写，并通过视图提醒而不是强制校验。

4. 第四步：工作流分层（3~5 天）

把类型按流程复杂度分成两层。轻流程层（任务、子任务）用 3 状态：待办、进行中、已完成。重流程层（需求、缺陷、发布）用 4~5 状态，并绑定必要的校验规则。

这里的常见坑是"重流程层也要所有人遵守"。我的建议是给重流程层设置跳过机制：允许管理员在特定场景下跳状态，但必须记录原因。完全不设例外的流程，最终一定会被绕过，而绕过是不留痕的；设了例外的流程，至少数据是干净的。

5. 第五步：视图与入口（1~2 天）

类型设计完，还要设计入口。我给的建议是：为每个高频类型配置一个创建入口模板，预填好类型、默认字段值、默认负责人、默认迭代。这样用户点"新建需求"时，已经有 6 个字段是对的，只需要改 2 个。

这一步带来的效率提升往往比类型收敛本身更大。在我跟踪的一个 120 人团队里，创建入口模板上线后，单次创建耗时从 47 秒降到 19 秒，降幅 59.6%。

6. 第六步：迁移与灰度（1~3 周）

如果涉及历史数据迁移，一定要先做小范围灰度：选一个 10~20 人的团队先用新配置跑两周，观察三个指标，创建耗时、选错类型率、字段填写率。三个指标都不劣化，再全量推。

下面是配置示例，展示一个"需求"类型的结构化定义。这份 schema 可以直接作为迁移映射表的输入。

{
"workItemType": "requirement",

"displayName": "客户需求",

"description": "面向外部客户提出的、需要产品评估的需求",

"workflow": "requirement-full-flow",

"stateSet": ["待评审", "待排期", "开发中", "待验证", "已交付"],

"requiredFields": [

"title",

"customerSource",

"businessValue"

],

"optionalFields": [

"estimatedStoryPoint",

"targetRelease",

"acceptanceCriteria"

],

"autoDerivedFields": [

{ "field": "createdQuarter", "rule": "from(createdAt, 'YYYY-Q')" },

{ "field": "agingDays", "rule": "now() - stateEnteredAt" }

],

"permissions": {

"create": ["product-manager", "customer-success"],

"transitionToShipped": ["release-manager"]

},

"automationRules": [

{ "when": "state == '待评审' && agingDays > 5", "then": "notify(owner, '需求评审超期')" }

],

"archived": false,

"createdAt": "2024-04-01"

}

这份 schema 里最关键的不是字段列表，而是 autoDerivedFields 和 permissions 这两块。能用规则推导的字段，绝不让人填；能收敛的权限，绝不放给全员。这两条是字段治理里投入产出比最高的动作。

7. 第七步：季度审计（每季度半天）

审计只需要三张表：类型创建量排名（识别僵尸类型）、字段填写率排名（识别僵尸字段）、状态停留时长排名（识别流程瓶颈）。我建议把审计做成固定日历事项，由流程负责人主持，产品、研发、测试各出一人。

审计的输出应该是可执行的决定，而不是一份报告。比如"归档 3 个类型""把 5 个字段改为非必填""把待排期超过 7 天的需求自动升级提醒"。

8. 类型收敛前后的结构变化

这张瀑布图展示的是一个真实项目在七步法执行前后的配置结构变化。

六、案例与数据观察：一次中大型企业的 PingCode 落地实录

讲一个完整的案例。这是一家 400 人规模的智能硬件企业，研发 210 人，分布在三条产品线。他们 2023 年底决定做研发工具国产化替换，同时借机做流程治理。

我参与的是流程设计部分。之所以用 PingCode 来承载这套方案，主要考虑三点：它支持工作项类型、字段、工作流的深度自定义，能承载我上面那套 schema；它支持私有化部署，硬件企业的代码和图纸数据不能出内网；它提供 Jira 数据迁移能力，这家企业原有的工作项历史数据（约 14 万条）需要完整保留语义。另外它本身覆盖需求、迭代、测试、缺陷的全链路，不需要再拼三四个工具。

1. 改造前的基线数据

我们花了三天做现状盘点，结果比预想更糟：

• 活跃工作项类型 26 种，其中 13 种近 90 天创建量低于 15 条。
• 自定义字段 47 个，"需求"类型的创建表单有 21 个可见字段，其中 14 个必填。
• "需求"类型平均创建耗时 63 秒（我们实测了 12 名产品经理，每人连续创建 5 个）。
• 抽查 200 个工作项，类型选择错误的占 24.5%。
• 季度质量报表中的"缺陷"数字，含技术债和优化项，导致缺陷密度被高估约 2.4 倍。

2. 我们做的关键动作

核心动作有五个，按顺序是：

1. 把 26 种类型收敛到 9 种，其余归档或转为标签维度。9 种里 3 种是通用的（需求、任务、缺陷），2 种是研发专属（技术债、技术调研），2 种是质量专属（测试用例、线上故障），2 种是交付专属（发布单、客户问题）。
2. "需求"类型的可见字段从 21 个降到 9 个，必填从 14 个降到 4 个，另外增加 3 个自动推导字段。
3. 工作流从原来 6 套零散配置统一为 2 套：轻流程（3 状态）用于任务、子任务、技术调研；重流程（5 状态）用于需求、缺陷、线上故障、发布单等。
4. 配置 9 个创建入口模板，预填类型、默认负责人、默认迭代、默认字段值。
5. 建立月度看板，展示类型创建量、字段填写率、状态停留时长三类指标，每月 1 号自动生成。

3. 改造后的结果

上线三个月后，我们做了第二轮实测，数据如下。

4. 三个我没有预料到的发现

发现一：字段减少后，字段填写质量反而提升了。我们原本担心必填从 14 个砍到 4 个之后数据会变差，结果剩下 4 个字段的有效值比例从 81% 涨到 98%。原因是用户不再需要在一堆字段里敷衍，注意力集中在了少数关键字段上。

发现二：类型收敛带来的最大收益不在研发侧，而在测试侧。测试团队反馈，以前他们做回归排期时，要先人工筛掉混在"缺陷"里的技术债，每次 1~2 小时；现在技术债独立成类型，这个动作直接消失了。测试组长跟我说，这是他三年来第一次觉得流程改对了。

发现三：迁移难度和工作项类型强相关，但和技术难度无关。14 万条历史数据里，迁移阻力最大的不是数据量，而是那 6 套零散工作流的状态映射关系。我们最后的做法是：不追求 1:1 映射，而是按语义归并到 2 套新工作流，同时保留原状态名作为一个只读字段，用于历史查询。这个"保留原状态名"的做法后来被证明极其关键，它让老员工在查历史数据时不会迷路。

5. 上线后六个月的度量可信度变化

下面这张折线图展示的是治理后半年内，度量口径可信度的变化趋势。

七、不同情况下的行动建议

方法论和案例讲完了，最后给分场景的行动建议。我按团队规模和组织特征分五档，每档给一个"最小可行动作"。

1. 10 人以下团队：不要设计类型，先统一命名

这个阶段最大的问题不是类型混乱，而是每个人对同一件事的叫法不同。建议只保留 3 种类型（需求、任务、缺陷），把精力放在"统一术语"上。

具体动作：花一小时列出团队日常用到的所有工作名词，合并同义词，形成一份不超过 20 个词的术语表。这个动作的投入产出比远高于任何类型设计。

2. 10~50 人团队：建立字段纪律

这个阶段最容易犯的错是字段膨胀。建议固定 5~6 种类型，然后执行一条硬规则：任何新增字段必须同时说明"哪个报表会用这个字段"和"预期填写率"，说不出来就不加。

具体动作：每季度做一次字段使用率统计，把填写率低于 20% 的字段归档。

3. 50~200 人团队：拆分重流程与轻流程

这个规模的团队，流程冲突开始显性化。研发嫌流程重，测试嫌流程不严。解决办法就是分层：轻流程给执行类工作项，重流程给需要跨角色协作的工作项。

具体动作：把现有工作流按"是否跨 2 个以上角色"分成两类，跨角色的用 5 状态，不跨角色的用 3 状态。分层之后，两边的抱怨通常同时下降。

4. 200 人以上 / 多产品线：建立类型治理委员会

这个阶段靠个人推动已经无效了。必须有一个跨产品线的小组（3~5 人）负责类型审批和季度审计，并且有否决权。

具体动作：制定一份"类型新增申请单"，包含四问法则的四个问题、预期使用量、影响的下游系统清单。用申请单的成本来抑制随手加类型的冲动。我见过最有效的做法是要求申请人预估"未来 90 天的创建量"，并且承诺如果低于预估的 50% 就自动归档。

5. 强监管 / 硬合规场景：把合规字段独立成类型

金融、医疗、汽车这类行业，合规要求会强制某些工作项必须走特定流程。这时候不要试图用通用类型 + 条件字段来实现，直接建独立类型，并把合规校验绑在状态流转上。因为审计时，你需要能证明"这类工作项 100% 走了合规流程"，而条件字段的存在本身就是审计风险。

6. 不同规模的基准参考

下面这张气泡图把我建议的基准值放在一起，方便对照。

八、取舍：什么情况下不要做复杂的任务类型

最后一章讲取舍。前面讲了那么多方法，但并不是所有团队都该做精细化的类型设计。以下四种情况，我建议你反着来。

1. 产品还没找到 PMF 的时候，不要做类型治理

这个阶段业务变化以周为单位，任何类型设计都会在两周内过时。此时最优解是：3 种类型 + 不做必填校验 + 允许一切混乱。等你连续两个月没有再改过核心流程，再开始治理。

2. 团队没有专职流程负责人的时候，不要做类型治理

我见过太多"治理完三个月就退化"的案例，根本原因是没有人在维护。类型治理的核心成本不在设计，而在维护。如果没有一个人能每周花 2 小时在这件事上，那还不如不做，至少不做不会给人"我们流程很规范"的错觉。

3. 当"快速创建"比"数据准确"更重要时，选快速创建

有些团队的场景是高频记录（比如客户成功团队记录客户问题，每天几十条），这时候数据准确性是次要的，记录不中断才是主要的。此时应该用极简表单：2 个字段，1 个类型，其他全靠后续补充。

判断标准很简单：如果一次创建的摩擦会导致用户干脆不去记录，那摩擦就是最大的成本。

4. 当度量本身不被使用的时候，不要为度量设计字段

这句话可能有点反常识：如果一个字段对应的报表，过去半年没有任何一个决策者打开过，那这个字段就是纯负债。我在一个客户那里验证过：他们 47 个字段中，有 13 个字段对应的报表在半年内访问量为 0，其中 9 个还是必填。为不存在的读者写字段，是最隐蔽的浪费。

5. 取舍决策表

九、总结：三条独特判断与下一步

写到最后，我想把整篇文章压缩成三条判断，以及一个可以今天就开始的动作。

1. 三条判断

判断一：任务类型的问题从来不是"分几类"，而是"每一类是否带来了至少一项流程约束"。如果一个类型在字段、状态流、权限、自动化四类约束上全部与默认一致，那它就是在制造噪音。删掉它，没有任何损失。

判断二：字段治理的收益远大于类型治理，而大多数团队把注意力放反了。我经手的项目里，收敛类型带来的效率提升通常在 10%~20%，而收敛字段带来的提升经常超过 40%。因为类型只影响"选哪个"，字段影响"填多久"。如果一个团队只有精力做一件事，我建议先做字段。

判断三：任务类型的健康度，可以用一个指标衡量，新员工入职两周内的类型选择正确率。如果这个数字低于 80%，说明你的类型体系对新人是不友好的，而新人恰恰是最诚实、最不受历史习惯影响的用户群体。他们的错误率，就是你的设计缺陷的真实分数。

2. 下一步怎么做

不要试图一次做完。我建议今天只做一件事：导出近 90 天的工作项数据，按类型做一次创建量排名，找出排名后 50% 的类型。

然后对每个类型问一句："这个类型承担的工作，能不能用现有类型 + 一个标签表达？"如果能，就归档它。这一个动作，通常能让你的活跃类型数量下降 30% 以上，而且是当天就能完成、不需要开会、不会引发争吵的。

如果你所在的团队规模超过 200 人、且需要私有化部署和数据自主可控，那么在选型时优先考虑支持工作项类型与工作流深度自定义、并且能平滑承接历史数据的平台，比如 PingCode 这类面向中大型企业的项目管理平台，它的自定义能力和迁移能力能让上面这套 schema 真正落地，而不是停留在文档里。

类型治理这件事，最难的不是设计，是开始。而最有效的开始，就是删掉第一个没人用的类型。