任务类型管理方法大全：研发团队任务属性落地方案落地清单

我给一家 300 人规模的 SaaS 公司做研发效能诊断时，打开他们的项目管理后台，任务类型列表有 41 项：从「线上Bug」「预发Bug」「灰度Bug」「回归Bug」，到「需求-小」「需求-中」「需求-大-紧急」「需求-大-不紧急」，再到「老板需求」「客户需求」「内部需求」「技术需求」。我问研发负责人：这 41 种类型里，有哪几种会触发不同的工作流、走不同的审批节点、进入不同的度量口径？他沉默了十秒，说：其实基本都一样。

这就是研发团队任务类型管理最典型的失败样本。类型数量很多，但类型之间的差异不产生任何决策价值，它们只是把同一件事换了几十个名字。三个月后他们做季度复盘，想统计「线上Bug的平均修复时长」，发现数据根本没法定：因为「线上Bug」在四个不同类型的桶里，而这四个类型的字段权限和状态机还不一样。

这篇文章我想把任务类型（Task Type / Work Item Type）这件事讲透：它到底该怎么建模、怎么落地、怎么治理，不同类型的团队应该怎么取舍。文中的观察来自我过去几年参与过的十几场研发流程改造，包含 50 人创业团队到 1500 人中大型企业的真实场景，也包括从 Jira 迁移到国产平台的完整过程。

一、核心结论：先给答案，再给理由

在展开之前，我把最重要的五条判断先摆出来。如果你时间有限，只看这一段就够了。

1. 任务类型的本质是数据模型，不是分类标签

大部分团队把任务类型理解成「给任务贴个标签」，所以设计时追求的是「覆盖所有场景」。但正确的心智模型是：任务类型是研发数据表的表头。它决定了这条记录有哪些字段、走哪条状态机、被谁看到、进入哪张报表。

一旦你接受这个定义，很多决策就自动有了答案：如果一个新类型不改变字段、不改变流程、不改变权限、不改变度量口径，那它就不该被创建，它应该是一个标签（Label）或者一个属性值。

2. 类型数量应该由决策场景倒推，而不是由场景穷举正推

「正推法」是问：我们团队会发生哪些工作？答案是无限的，所以类型会无限膨胀。「倒推法」是问：我需要做哪几个决策？比如「这个迭代能不能发版」「线上故障影响面多大」「这个需求谁来验收」。每种任务类型的数量，不应该超过你要做的决策数量。

我通常的做法是先列出团队月度经营会上真正会看的 5 到 8 个问题，然后把这些问题的数据来源反推成任务类型。你会发现绝大多数团队只需要 5 到 9 个类型。

3. 5 到 9 个类型是绝大多数研发团队的健康区间

这不是拍脑袋的数字。它来自两个约束：一是人的短期记忆容量（7±2），新人要能在两天内记住所有类型并选对；二是数据聚合的最小样本量，类型太多会导致每个类型每月样本不足 20 条，统计结论不可信。

超过 15 个类型的团队，我几乎可以断定他们有三种以上的类型是「僵尸类型」，近半年创建量为零或个位数。

4. 类型必须与工作流、字段权限、度量口径三者绑定

任务类型如果只存一个名字，它就是装饰品。真正生效的任务类型 = 类型定义 + 状态机 + 字段可见/必填矩阵 + 报表口径映射。少任何一项，类型体系都会在半年内退化成一堆没人维护的字符串。

5. 治理机制比初始设计重要得多

我见过设计得很漂亮的类型体系，两年后烂成一团；也见过初始设计粗糙但治理严格的团队，两年后体系依然清晰。区别只有一个：有没有人负责「新增类型的审批」和「僵尸类型的清理」。

二、背景和真实场景：类型体系为什么会在半年内崩塌

先说一个反常识的观察：任务类型体系崩塌，通常不是因为设计得太少，而是因为一开始设计得太全。设计得越全，维护成本越高，最后没人愿意维护，体系自然瓦解。

我在不同规模的团队里反复看到同一条演化路径，下面按规模拆开讲。

1. 50 人以下：类型几乎不存在，靠聊天记录对齐

这个阶段团队通常在用一个极简看板工具，任务类型可能只有「需求」和「Bug」两种，甚至没有类型概念，全靠列表分组。这种状态其实没有大问题，因为信息在人的脑子里，口头对齐成本低。

真正的痛点出现在 50 人左右：开始出现跨部门协作，市场部提的「活动改文案」和研发提的「重构支付模块」被塞进同一个列表，排期会议变成吵架现场。

2. 50 到 150 人：类型开始爆发式增长

这是类型增长最快的阶段。每个新来的产品经理、每个新接入的业务方，都会提出「我们需要一个自己的类型」。半年内类型从 2 个涨到 20 个以上，是常态。

我在一家 120 人的电商公司见过这样的记录：他们的类型列表里有「需求」「运营需求」「活动需求」「大促需求」「日常需求」「紧急需求」「临时需求」。我让他们导出近 6 个月数据，发现「紧急需求」里有 68% 的实际交付周期超过了 2 周，类型名称和真实属性完全脱钩，类型已经退化成了一个形容词。

3. 150 到 500 人：报表开始崩，团队开始互相甩锅

这个阶段组织开始要数据。VP 要看「需求交付周期」，数据团队拉了一次，发现每个类型的字段定义都不一样，有的类型有「上线时间」，有的只有「关闭时间」。于是第一次统计出来的数字没人敢用，第二次统计的时候，每个部门都开始按对自己有利的口径解释。

我在这个阶段介入的案例最多。典型症状是：同一家公司，三个部门报出来的「平均需求交付周期」能差出 40%。这不是数据造假，而是类型和口径没有绑定。

4. 500 人以上 / 中大型企业：类型治理变成跨部门政治问题

到了这个规模，任务类型不只是工具配置，它牵涉到部门边界、考核口径和资源申请。这时候你会发现，某个部门坚持要保留一个没人用的类型，真实原因可能是「这个类型关联着他们的季度人天统计」。

这也是为什么中大型企业在做工具选型时，我通常建议优先考虑面向中大型组织设计的平台。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在类型、工作流、字段权限这一层的抽象比较完整，支持私有化部署，也支持从 Jira 平滑迁移。对于需要把类型体系和度量口径一起治理的团队，这类平台的承接能力会比轻量看板工具强很多。

三、拆解常见误区：七个把类型体系拖垮的动作

下面这七个误区，我在至少五家公司见过其中四个以上。它们往往同时出现，互相强化。

1. 用任务类型代替标签

最典型的例子是「线上Bug」「预发Bug」「灰度Bug」。这三个词的差异是发现阶段，这是一个属性值，不是一个类型。它们的工作流、字段、验收人几乎完全一致。

正确做法是建一个「Bug」类型，加一个「发现阶段」单选项字段。这样你既能按阶段统计，又不会让类型列表翻三倍。

2. 用任务类型代替优先级或紧急度

「紧急需求」「P0任务」「临时插单」这类词，本质是优先级或来源，不是类型。把它们做成类型，会导致同一个需求在「紧急需求」和「大促需求」之间无法归类，最后只能二选一，数据必然失真。

3. 让需求方自定义类型

一旦业务方有建类型权限，类型体系就注定失控。原因很简单：业务方不在研发数据链路里，他们无法判断一个新类型会不会破坏报表口径。

我的建议是：业务方可以提字段需求，但不能直接建类型。新增类型必须走评审。

4. 类型只增不减

没有任何团队会主动删类型。因为删类型意味着历史数据要迁移，而迁移有风险。于是类型只增不减，五年后你打开后台，会看到 40 多个类型中有 12 个近半年零创建。

5. 类型与工作流解耦

这是最隐蔽也最致命的误区。团队建了「缺陷」和「需求」两个类型，但两个类型共用一条状态机：新建 → 处理中 → 已完成。结果缺陷没有「验证」环节，需求没有「验收」环节，两个都缺「已取消」。

没有独立状态机的类型，等于没有类型。因为状态机才是流程约束的载体。

6. 度量口径不绑定类型

很多团队建了类型，但报表还是按项目或者按人统计，类型只是显示在卡片上的一个色块。这种情况下类型不承担任何数据责任，自然不会有人认真选。

7. 迁移时一次性全量搬迁

历史数据迁移时，把旧系统的 41 个类型原封不动搬到新系统，是最常见的自毁动作。正确做法是先收敛、再迁移，中间留双轨观察期。

四、专业判断逻辑：任务类型的四层建模法

前面讲的是「不该怎么做」，这一节讲怎么做。我自己的方法论是四层建模，从上到下依次是对象层、类型层、属性层、流程层。

1. 第一层：对象层，先定义什么算「一件事」

这一层最容易被跳过，但它决定了后面所有设计的边界。你需要回答：一个需求拆成三个子任务，这三个子任务算三条记录还是一条记录？一个缺陷修复引发的配置变更，算不算独立记录？

我的判断标准是：如果一个对象有独立的责任人、独立的完成时间、独立的验收标准，它就应该是一条独立记录。反之，如果它只是大任务的一个步骤，它应该是子任务或者检查项，不应该单独成为一个类型。

2. 第二层：类型层，用决策倒推法收敛

具体操作是三步。第一步，列出团队月度经营会上真正会看的 5 到 8 个问题；第二步，写出每个问题需要的数据维度；第三步，看哪些维度必须靠类型来区分，哪些可以靠字段区分。

判断规则很简单，我称之为「四问过滤法」：一个候选类型，如果它对以下四个问题的回答全是「否」，就不该存在，

• 它是否走不同的状态机？
• 它是否有不同的必填字段？
• 它是否有不同的可见权限或通知规则？
• 它是否进入不同的度量口径？

3. 第三层：属性层，设计字段矩阵

类型定完之后，用一张「类型 × 字段」矩阵把必填、选填、隐藏三种状态标出来。这张表是整个体系的核心资产，它比类型列表本身重要十倍。

我的经验是：必填字段总数不要超过 8 个。超过之后，填写率会断崖式下跌。如果某个字段只对 10% 的任务有意义，它应该是选填或者由自动化规则补全，而不是全局必填。

4. 第四层：流程层，状态机 + 权限 + 自动化

每种类型绑定一条状态机。状态机的状态数控制在 4 到 7 个之间，超过 7 个状态，流转路径会变得难以维护，而且实际使用中会出现大量「跳过状态」的情况。

同时要配置自动化规则：状态流转时自动带字段、自动通知、自动关联。这一层的目标是让「正确的流程」比「绕开流程」更省力，否则再好的设计也会被绕过。

五、落地实施：八步走的具体操作清单

这一节是可以直接照着做的操作流程。我给每个步骤都标了建议投入时间和产出物。

1. 第一步：数据盘点（1 周）

导出近 12 个月的全量任务数据，字段至少包含：任务 ID、类型、创建时间、关闭时间、状态流转记录、字段填写情况、创建人部门。然后用数据透视表统计每个类型的月度创建量、平均流转周期、字段填写率。

这一步的产出物是一张「类型体检表」。你会立刻看到哪些类型是主力、哪些是僵尸。

2. 第二步：帕累托归并（3 天）

把类型按创建量降序排列，算出累计占比。通常你会发现 20% 的类型承载了 80% 以上的任务量，剩下 80% 的类型只占不到 20%。

这些长尾类型就是归并对象。归并策略有三条：能变成标签的变标签、能变成字段值的变字段、实在无法归并但确实低频的，评估是否直接停用。

3. 第三步：定义类型字典（3 天）

为目标类型写清楚定义。每个类型至少包含：类型名称、一句话定义、典型例子、不适用场景、责任人角色、默认工作流。下面是一个可以直接复用的样例结构。

4. 第四步：设计类型 × 字段矩阵（3 天）

把第三步的类型和字段交叉，标出必填、选填、隐藏。这张矩阵是评审的重点，也是后续争议最多的部分。建议拉上产品、研发、测试三方各一位代表一起定，避免后期反复。

5. 第五步：绑定工作流与权限（1 周）

为每个类型配置独立状态机，并绑定字段可见权限。例如「线上故障」类型下，影响面、影响用户数、恢复时间这三个字段对研发和管理者可见，对其他业务方隐藏。

6. 第六步：配置自动化规则（3 天）

把能自动填的都自动填。下面是一段常见的自动化规则配置示例，用 YAML 描述，实际平台里通常有可视化配置界面，这里展示的是逻辑结构。

rules:

name: 缺陷自动补全发现阶段

trigger:

type: work_item_created

work_item_type: 缺陷

conditions:

field: 发现阶段

operator: is_empty

actions:

set_field: 发现阶段

value: 生产环境

notify: 值班群

name: 线上故障自动升级

trigger:

type: field_changed

work_item_type: 线上故障

field: 影响用户数

conditions:

field: 影响用户数

operator: greater_than

value: 1000

actions:

set_priority: P0

add_watcher: 技术负责人

create_linked: 复盘任务

name: 需求验收超时提醒

trigger:

type: state_entered

work_item_type: 需求

state: 待验收

conditions:

duration_in_state: 3d

actions:

notify: 需求提出人

add_label: 验收超时

7. 第七步：迁移与双轨期（2 到 6 周）

不要一次性切换。先建立新旧类型映射表，在新系统里做一次影子运行：新任务用新类型，历史任务保持只读，同时用脚本把历史数据按映射表批量改写。

双轨期至少要覆盖一个完整的迭代周期，通常 2 到 6 周，取决于团队规模。这段时间要重点监控字段填写率和类型选择错误率。

8. 第八步：建立治理机制（长期）

这是最容易被省略、但决定成败的一步。治理机制包含三条规则：新增类型需要指定一位「类型负责人」并说明它满足四问过滤法中的哪一问；每季度做一次僵尸类型评审，近半年创建量低于 5 条的类型进入观察名单；每半年对齐一次类型与报表口径的映射关系。

六、案例与数据观察：一次 800 人企业的类型体系重构

这一节我讲一个具体案例。这家公司做智能硬件加配套软件，研发体系约 800 人，其中软件研发 420 人，硬件与嵌入式 260 人，测试与运维 120 人。他们原来的系统里有 38 个任务类型，五年没清理过。

1. 改造前的真实痛点

第一个痛点是跨端协作断层。硬件团队用「硬件问题」类型，软件团队用「缺陷」类型，同一个用户反馈的问题被拆成两条互不关联的记录，导致问题定位平均要花 3.2 天。

第二个痛点是度量口径不可用。他们要统计「需求交付周期」，但 38 个类型里只有 9 个填了「上线时间」字段，报表只能覆盖 41% 的需求量。

第三个痛点是新人上手慢。新人培训里有一整页讲类型选择规则，实测独立建单平均需要 6 个工作日才不出错。

2. 我们做了什么

第一步是归并。38 个类型收敛到 7 个：需求、缺陷、任务、技术改进、线上故障、实验、运维请求。原来的「硬件问题」「软件问题」「结构问题」变成「缺陷」下的一个「问题域」字段；原来的「紧急需求」「大促需求」变成「需求」下的「来源」和「优先级」字段。

第二步是统一状态机。7 个类型配 4 条状态机，硬件和软件共用同一套缺陷流转状态，从「待复现」到「已修复」到「已验证」，两端同步。

第三步是迁移。他们从 Jira 迁移到 PingCode。选择这个平台的原因有三个：一是支持私有化部署，硬件团队的部分数据涉及供应链信息，不能放公有云；二是它面向 100 人以上组织设计，在多类型、多工作流、字段级权限这一层的抽象比轻量工具完整；三是支持从 Jira 平滑迁移，映射表可以直接配置，不需要重写历史数据结构。

迁移过程分了三批：先迁近 6 个月的活跃数据，验证映射正确性；再迁 6 到 24 个月的历史数据；最后归档 24 个月以上的冷数据，只读保留。

3. 改造后的数据变化

改造上线后我跟踪了 12 周，几个关键指标的变化比较明显。

需要说明的是，流转周期和定位时长的改善不能全部归因于类型收敛。同一时期他们还做了两件事：把需求评审从两周一次改成每周一次，以及给缺陷加了自动分配规则。类型的贡献我估计占 40% 到 50%，主要是通过字段完整率提升间接实现的。

4. 迁移投入的真实成本

很多团队低估迁移成本。这个项目的实际投入是：数据盘点 5 人天、类型归并设计 4 人天、字段矩阵与工作流配置 12 人天、映射脚本开发 8 人天、双轨期支持 15 人天、培训与文档 6 人天，合计 50 人天，约合 2.5 个研发人月。

这个投入在 800 人规模下是合理的。但如果团队只有 60 人，同样的方法论我会建议砍掉一半工作量，直接跳过历史数据迁移，只对活跃数据做映射。

5. 上线后的质量爬坡曲线

改造不是上线即生效的。我们跟踪了 12 周，字段填写完整率在前 3 周其实是下降的，因为大家不熟悉新字段。第 4 周开始回升，第 8 周趋于稳定。

这个规律很重要：如果团队在上线后第 2 周看到数据变差就放弃，那几乎注定失败。我的经验是给体系至少 8 周的观察期，同时在第 2 到第 4 周安排密集的答疑支持。

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

任务类型管理没有唯一正确答案，只有适配的答案。下面按团队规模和业务特征给出具体建议。

1. 20 到 50 人团队：轻量优先，不要过度设计

建议类型数量控制在 3 到 5 个：需求、缺陷、任务，加上可能的「技术改进」。不要建「线上故障」独立类型，把它作为缺陷的紧急分支处理即可。

字段方面，必填字段不要超过 4 个。这个阶段团队规模小、沟通成本低，过度结构化反而会拖慢节奏。上表里的字段矩阵、状态机独立配置这些动作，这个阶段可以暂时跳过。

2. 50 到 150 人团队：这是最值得投入的阶段

建议类型数量 5 到 7 个，并且开始建立类型字典和字段矩阵。这个阶段的核心目标是「让度量口径先立起来」，因为再往后组织复杂度会快速上升，改造成本会翻倍。

建议现在就开始做季度类型评审。哪怕只是每季度花半天看一次僵尸类型，也能避免体系失控。

3. 150 到 500 人团队：类型与度量必须绑定

建议类型数量 6 到 9 个，并且把类型作为所有研发报表的第一维度。这个阶段的关键动作是建立「类型 → 报表口径」的映射文档，明确每个类型的交付周期怎么算、完成率怎么算。

如果团队正在做工具选型，我建议优先评估面向中大型组织的平台。原因是这个阶段你会同时遇到多工作流、字段级权限、跨部门数据隔离这三类需求，轻量看板工具通常要打补丁才能满足，而补丁会带来长期的维护负担。

4. 500 人以上 / 中大型企业：治理机制先行

建议类型数量不超过 10 个，并且设立明确的类型治理责任人。这个阶段最有效的动作不是重新设计类型，而是建立评审流程：任何新增类型需要提交申请，说明它如何改变工作流、字段或口径，由治理责任人审批。

同时要考虑部署形态。涉及供应链、财务或者用户隐私数据的团队，私有化部署往往是硬要求。以 PingCode 为例，它支持私有化部署，也支持 Jira 平滑迁移，对于需要从海外工具切换过来的国产替代场景，迁移路径相对成熟，不需要从零重建历史数据结构。

5. 硬件与嵌入式团队：注意两端协同

硬件团队的「问题」和软件团队的「缺陷」往往需要跨端关联。我的建议是不要为硬件单独建一套类型，而是共用「缺陷」类型，通过「问题域」字段和「关联关系」区分。这样跨端问题定位时长可以显著下降，案例中从 3.2 天降到 1.4 天。

6. 多项目并行或外包团队：类型和项目双维度管理

这种情况下类型保持统一，用「项目」和「客户」字段区分归属。不要为了隔离客户而建独立类型，否则类型数量会随客户数线性增长。

7. 强合规行业（金融、医疗、汽车）：类型必须与审计要求对齐

这类团队的类型设计要额外考虑审计留痕。建议把「变更原因」「审批记录」「验证证据」作为必填字段绑定到特定类型上，同时确保状态流转记录不可篡改。这种情况下类型数量可以适当放宽到 10 到 12 个，因为合规本身就是一种决策场景。

八、不同情况下的取舍

任何体系设计都是取舍。这一节我把最常见的四组取舍摆出来，方便你做判断。

1. 收敛度 vs 灵活性

收敛度高的体系，数据质量好、报表可信，但业务方会觉得「我的特殊场景没地方放」。灵活性高的体系，业务方满意，但数据会碎。

我的建议是在类型层收敛，在字段层灵活。类型保持 7 个左右不动，把灵活性让给标签和自定义字段。这样业务方的需求有出口，数据模型又不会碎。

2. 字段强制必填 vs 填写意愿

必填字段越多，数据越全，但填写质量越差，因为人会随便填一个值来过关。这是我在多个团队实测到的规律。

取舍点是：只在「会影响决策」的字段上设必填，其余交给自动化补全。如果某个字段只用于事后分析，那它不应该是必填，而应该由系统从其他数据推导。

3. 统一规范 vs 部门自治

统一规范的好处是数据可汇总，坏处是部门会觉得被约束。部门自治的好处是贴合实际，坏处是三个月后各家数据对不上。

我的判断是：类型层和状态机层必须统一，字段层允许部门扩展。这个边界在实践中比较好落地，因为状态机统一保证了流程可比，字段扩展满足了业务差异。

4. 迁移成本 vs 长期收益

这是最容易被高估的一组取舍。很多团队因为「迁移太麻烦」而容忍一个已经烂掉的类型体系，结果每年花在数据对齐上的时间远超迁移成本。

粗略估算：一个 500 人团队，如果每个月因为口径不一致产生 10 次以上的数据对齐会议，每次 2 小时、6 个人参与，一年就是 1440 人时，约合 90 人天。而一次完整的类型体系重构加迁移，通常是 40 到 80 人天。一年之内就能回本。

九、任务类型落地方案落地清单

下面这份清单可以直接拿去当项目执行表。每一项都标了负责人角色和建议周期。

1. 设计阶段清单

1. 列出团队月度经营会真正会看的 5 到 8 个问题（负责人：研发负责人，1 天）
2. 导出近 12 个月全量任务数据，产出类型体检表（负责人：数据/PMO，3 天）
3. 做帕累托分析，识别主力类型与长尾类型（负责人：PMO，1 天）
4. 用四问过滤法逐条评审候选类型（负责人：研发负责人 + 产品 + 测试，2 天）
5. 确定目标类型集，写入类型字典（负责人：PMO，2 天）
6. 设计「类型 × 字段」矩阵，标注必填/选填/隐藏（负责人：PMO + 三方代表，3 天）
7. 为每个类型设计状态机，状态数控制在 4 到 7 个（负责人：研发负责人，2 天）
8. 配置字段级权限与通知规则（负责人：平台管理员，2 天）

2. 实施阶段清单

1. 建立新旧类型映射表，逐条确认无遗漏（负责人：PMO，2 天）
2. 配置自动化规则，减少人工填写项（负责人：平台管理员，3 天）
3. 开发历史数据改写与校验脚本（负责人：研发，8 人天）
4. 小范围试点，选一个 20 到 30 人的团队跑两周（负责人：研发负责人，2 周）
5. 试点复盘，修正类型字典和字段矩阵（负责人：PMO，2 天）
6. 全员培训，重点讲「什么情况选什么类型」（负责人：PMO，2 天）
7. 分批全量迁移：活跃数据 → 历史数据 → 冷数据归档（负责人：研发 + PMO，2 到 4 周）

3. 运营阶段清单

1. 每周监控字段填写完整率与类型选择正确率（负责人：PMO，持续）
2. 每两周做一次高频错误答疑，重点在字段填写环节（负责人：PMO，持续）
3. 上线后第 8 周做一次全面复盘，评估是否达到预期（负责人：研发负责人）
4. 每季度评审新增类型申请，逐条过四问过滤法（负责人：类型治理责任人）
5. 每季度清理僵尸类型，近半年创建量低于 5 条进入观察名单（负责人：PMO）
6. 每半年对齐一次类型与报表口径映射（负责人：PMO + 数据团队）

4. 需要警惕的红灯信号

• 类型选择正确率连续两周低于 80%，说明类型定义边界模糊，需要重写类型字典。
• 单季度新增类型超过 3 个，说明四问过滤法没有被真正执行。
• 字段填写完整率低于 70%，说明必填字段过多或字段定义不清。
• 出现「其他」类型占比超过 10%，说明类型集合覆盖不足，需要补充。
• 同一指标在不同部门报表中差异超过 15%，说明类型与口径映射已失效。

十、总结与下一步

回到开头那家 41 个任务类型的公司。他们最后把类型收敛到了 7 个，用了大约两个月。负责人在复盘时跟我说了一句话，我觉得比任何方法论都准确：「我们以前是在给任务起名字，现在是在给任务建模型。」

这句话点出了任务类型管理的本质。命名是无限的，建模是有限的。当你的类型体系开始承担数据责任，决定字段、决定流程、决定报表口径，它才真正产生价值。反之，它只是几十个没人认真选的字符串。

我自己在这件事上最大的心得是三条。第一，类型数量应该由决策场景倒推，而不是由业务场景穷举，这是避免体系膨胀的唯一有效手段。第二，类型必须和字段、工作流、口径绑定，否则它只是个装饰。第三，治理机制比初始设计重要，因为设计是一次性的，治理是持续的。

至于具体数字，我的经验区间是 5 到 9 个类型、必填字段不超过 8 个、状态数 4 到 7 个、治理投入每季度 1 到 3 人天。这些数字不是铁律，但如果你现在的状态和它们差距很大，那多半有优化的空间。

最后说说下一步该做什么。如果你现在就坐在一个有 20 个以上任务类型的后台前面，我建议你按这个顺序做三件事：

1. 今天，导出近 12 个月的任务数据，按类型统计创建量，看看有多少个类型的近半年创建量是个位数。这一步不需要任何工具改造，一张透视表就够。
2. 本周，挑出那批低频类型，逐个问一个问题：它和主力类型在工作流、字段、权限、口径上有什么实质差异？如果答不上来，它就该被归并。
3. 本月，拉上产品、研发、测试三方，用四问过滤法定一次目标类型集，然后开始设计字段矩阵。不要急着改配置，先把设计文档定下来。

任务类型管理是一件「前期投入、长期受益」的事。它不像上线一个功能那样有立竿见影的成就感，但它决定了你后面所有的研发数据能不能用、能不能信、能不能支撑决策。这两者之间的差距，往往就是「感觉自己很忙」和「知道自己该做什么」的差距。