任务分类的目标，是让每个可执行工作项都能被稳定归入一个类别，从而支撑分派、排序、统计和复盘。做法可以概括为：先确定分类要解决的管理问题，再选一个主维度作为一级分类，把其他维度降为标签或属性字段，然后为每类写明判定标准和流转规则，用少量真实任务试分类、修正歧义后再全量推行。本文讨论的范围限于可执行工作项的分类；项目交付范围的WBS划分、需求层级与需求分解分别属于项目范围管理和需求分解主题，这里不展开。在ONES中落地时，分类结果通常由工作项的类型、字段和状态流转来承载。
要点总览（TL;DR）
- 任务分类先定目的：分派、排序、统计还是复盘，目的决定一级分类选哪个主维度。
- 一级分类只保留一个主维度（如工作类型），交付对象、紧急程度等降为字段或标签，避免交叉归类。
- 每类都要写判定标准和易混边界，并约定新建、变更、关闭、歧义四种情形的处理规则。
- 分类由规则制定者、审批者、创建人、负责人和维护者分工承担，维护者需有明确的调整触发条件。
- 用少量真实任务试分类两到四周，修正歧义后再全量推行，并按清单定期复查。
先定分类目的：任务分类要解决哪个管理问题
分类本身不产生价值，价值来自分类之后能做什么。动手建分类表之前，先写清一句话：这套分类要支撑哪个动作。不同的目的会指向不同的主维度，选错主维度，后面的字段和规则都会跟着别扭。
常见目的与主维度的对应关系如下：
| 分类目的 | 分类后要发生的动作 | 更适合的主维度 |
|---|---|---|
| 把任务分给对的角色 | 按类别自动指派负责人或责任组 | 工作类型（如开发、测试、运维、文档） |
| 决定先做哪一批 | 按类别设定排序规则和准入条件 | 工作类型或紧急程度 |
| 统计投入与产出 | 按类别汇总数量、工时、完成率 | 交付对象或工作类型 |
| 复盘问题来源 | 按类别分析缺陷、返工、阻塞的分布 | 工作类型或问题来源 |
一个团队往往同时有多个诉求，但一级分类只能有一个主维度。判断方法是问：哪个动作最频繁、最依赖分类结果？把它对应的维度定为主维度，其余诉求用标签或属性字段承接。例如以分派为主要目的时，一级分类按工作类型划分；需要看交付对象时，用“所属模块”字段筛选，而不是再建一套并行分类。
如果目的暂时说不清，不要急着全量推行。挑一个小组、一批真实任务先试分类，观察分类结果是否真的被用于分派或统计。试分类阶段产出的结论，就是分类目的说明的初稿。
本节交付物是一份分类目的说明，至少包含三项内容：用途（支撑哪个动作）、使用者（谁看分类结果）、期望支撑的决策（分类后要做出什么判断）。这份说明是后续所有取舍的依据。
任务分类的核心步骤：从维度选择到规则落地
分类机制的建设可以拆成五步，每步都有明确的输入、动作、输出和完成标志。按顺序推进，避免在维度还没定的时候就开始配字段。
第一步：列出候选维度，选出唯一主维度
输入是分类目的说明和团队近期的真实任务清单。动作是把可能的分类维度全部列出来，常见的有工作类型、交付对象、紧急程度、来源渠道、所属阶段。然后对照目的说明，选出与主要动作最匹配的一个作为一级分类，其余维度标注为“降级为标签或字段”。输出是一张候选维度表，每个维度注明保留或降级的理由。完成标志是：团队对“一级分类只有一个”达成一致，没有并列主维度。
第二步：定义每类的判定标准与边界
输入是选定的主维度和它的候选类别。动作是为每个类别写一句可操作的判定标准，说明“什么情况下归入此类”，并专门处理容易混淆的边界情形。例如“缺陷修复”和“功能优化”容易混，就写明：对外表现为功能不符合预期、需要纠正的归缺陷修复；在功能正常前提下提升体验的归优化。输出是分类维度表，包含类别名称、判定标准、典型例子、易混情形说明。完成标志是：拿三条历史任务对照标准，不同人能得出相同归类。
第三步：设置标签、优先级、负责人等辅助字段
输入是第一步中被降级的维度和分类目的说明。动作是把辅助维度转成字段：交付对象用单选或关联字段，紧急程度用优先级字段，责任归属用负责人或责任组字段，跨类别的临时标记用标签。字段数量控制在必要范围内，每加一个字段都要能回答“它支撑哪个动作”。输出是字段清单，注明字段名称、类型、是否必填、取值范围。完成标志是：新建一条任务时，必填字段能在合理时间内填完，且每个字段都有明确用途。
第四步：确定新建、变更、关闭时的分类规则
输入是分类维度表和字段清单。动作是规定三个时点的分类行为：新建时由创建人选定一级分类并填写必填字段；执行过程中类别发生变化时，由谁改、是否需要说明理由、改动是否通知相关负责人；关闭时检查分类是否与实际工作一致，不一致的由负责人修正。同时约定歧义任务的处理路径，例如无法判断类别时先归入“待定”，由分类维护者在约定时间内裁定。输出是分类规则说明。完成标志是：规则覆盖了新建、变更、关闭和歧义四种情形，且每种情形都有明确的责任人。
第五步：小范围试分类并修正歧义
输入是前四步的全部产出。动作是选一个小组，用两到四周的真实任务按规则分类，期间记录每次归类犹豫、争议或返工的情况。试分类结束后集中复盘：哪些类别从未被使用，哪些类别频繁混淆，哪些字段没人填。据此调整类别名称、判定标准或字段设置。输出是试分类结论和修订后的分类方案。完成标志是：修订后的方案在试分类样本上归类一致率达到团队可接受的水平，且分类结果已被实际用于至少一次分派或统计。
角色与交付物：谁定分类、谁维护、谁执行
分类规则失效，多数时候不是规则本身不好，而是没有人对它负责。把角色、动作、交付物和交接点写清楚，分类机制才能持续运转。
| 角色 | 主要动作 | 交付物 | 交接对象 |
|---|---|---|---|
| 分类规则制定者 | 起草分类目的说明、维度表、判定标准和字段清单 | 分类方案初稿 | 审批者 |
| 审批者（通常是团队负责人） | 确认分类目的与主维度，批准字段和规则 | 签发的分类规则说明 | 全体执行者、维护者 |
| 任务创建人 | 新建任务时选定一级分类、填写必填字段 | 分类准确的任务记录 | 任务负责人 |
| 任务负责人 | 执行中维护分类准确性，关闭前核对分类 | 修正后的任务分类 | 分类维护者（仅争议情形） |
| 分类体系维护者 | 裁定歧义任务，收集分类问题，定期复查 | 歧义裁定记录、复查报告、修订建议 | 审批者 |
维护者的调整触发条件需要提前写明，常见的有：某类别连续一段时间没有新任务归入；同一批任务反复出现归类争议；团队的业务范围发生变化，出现现有类别覆盖不了的任务；分类结果不再被用于原先设定的分派或统计动作。触发后由维护者提出修订建议，经审批者确认后发布，并同步更新判定标准。
交接点集中在两处：一是试分类结束到全量推行之间，维护者把修订后的方案交回审批者确认；二是定期复查后，维护者把修订建议交给审批者决定是否调整。两处交接都应有书面记录，避免规则在口头传递中变形。
示例：一个研发团队的任务分类落地过程
以下为一个演示情景，用于说明分类从设计到执行的过程，不代表特定团队的真实数据。
某研发团队此前的任务记录混在一起，分派靠负责人凭经验判断，统计时说不清投入分布。团队确定的分类目的是“支撑分派和投入统计”，使用者是技术负责人和项目经理，期望支撑的决策是“新任务该派给谁”和“各类工作各占多少”。据此选定工作类型作为唯一主维度，划分为需求开发、缺陷修复、技术优化、运维支持、文档与协作五类；交付对象降为“所属模块”字段，紧急程度用优先级字段，临时事项用标签标记。
判定标准上，团队重点澄清了两组易混情形：缺陷修复与需求开发的边界，以“是否符合已确认的需求预期”为准；技术优化与运维支持的边界，以“是否由线上问题触发”为准。字段设置为：所属模块必填，优先级必填，负责人由分派时填写。
一条真实任务的流转过程如下：测试同学发现某模块导出功能在特定条件下报错，创建任务时选“缺陷修复”，填写所属模块和优先级；负责人接单后执行修复，过程中发现根因是历史代码结构问题，需要顺带重构，于是把任务拆出一条“技术优化”类的新任务并关联原任务；原任务关闭前，负责人核对分类仍为缺陷修复，确认无误后关闭。整个过程分类动作发生在创建、拆分和关闭三个时点。
试分类阶段发现两个问题：一是“文档与协作”类几乎无人使用，会议纪要、跨组协调都被塞进需求开发；二是“技术优化”和“缺陷修复”在根因类问题上反复争议。修正方式是：把“文档与协作”改名为“协作与支持”并补充典型例子，明确会议纪要、跨组协调归入此类；对根因类问题增加一条规则，以“是否已有用户可见的异常表现”区分，有异常表现的归缺陷修复，无异常表现的归技术优化。修订后重新试分类两周，归类一致性明显改善，方案随后全量推行。
完成检查：分类体系是否可用的判断标准
分类体系是否可用，可以用下面这份清单逐项核对。每项都给出通过标准，全部通过即可进入常态运行。
| 检查项 | 通过标准 |
|---|---|
| 类别互斥 | 任意一条任务按判定标准只能归入一个类别，抽查历史任务无跨类争议 |
| 覆盖常见任务 | 近期的真实任务中，无法归类的比例很低，且“待定”类任务有明确处理时限 |
| 归类耗时 | 新建任务时，创建人能在短时间内完成一级分类和必填字段，不需要反复查规则 |
| 支撑既定动作 | 分类结果已被实际用于至少一次分派或一次统计，且结果被使用者认可 |
| 歧义处理路径 | 无法判断类别时有明确的暂归方式和裁定人，裁定结果有记录 |
| 维护与复查 | 维护者已指定，复查时点已约定，调整触发条件已写明 |
复查时点建议与团队的工作节奏对齐，例如在每个迭代结束或每月固定时间做一次轻量检查，重点看未使用类别、高频争议和字段填写率。检查发现的问题按维护流程处理，避免分类表长期不更新而逐渐失去参考价值。
在ONES中，这套分类机制可以依托工作项的类型、自定义字段和状态流转来承载：一级分类对应工作项类型或单选字段，辅助维度对应标签和属性字段，新建、变更、关闭时的分类动作则通过工作流规则和必填校验固化下来。具体字段类型和流转配置能力以实际使用的产品版本为准。
常见问题
团队同时有分派、统计和复盘多个诉求，一级分类该怎么定？
先判断哪个动作最频繁、最依赖分类结果，把它对应的维度定为一级分类，其余诉求用字段或标签承接。例如以分派为主时，一级分类按工作类型划分；需要看交付对象时，用“所属模块”字段筛选，不再建一套并行分类。多个诉求并存时，一级分类保持单一主维度，是保证归类稳定的前提。
试分类要跑多久、样本多大才算够？
没有统一标准，常用做法是选一个小组，用两到四周的真实任务按规则分类，期间记录每次归类犹豫、争议和返工。判断是否够用的依据是：修订后的方案在试分类样本上归类一致率达到团队可接受的水平，并且分类结果已被实际用于至少一次分派或统计。样本太少或时间太短，容易漏掉边界情形。
执行中发现任务归错类，应该由谁改、要不要留记录？
执行过程中的分类准确性由任务负责人维护，关闭前核对分类是否与实际工作一致。改动规则需要提前写明：谁有权改、是否需要说明理由、是否通知相关负责人。涉及类别判定争议的，交给分类维护者裁定并留下记录，避免同类问题反复争论。
分类表用了一段时间后没人更新，怎么判断该调整了？
提前写明调整触发条件，常见的有：某类别连续一段时间没有新任务归入；同一批任务反复出现归类争议；业务范围变化后出现现有类别覆盖不了的任务；分类结果不再被用于原先设定的分派或统计动作。触发后由维护者提出修订建议，经审批者确认后发布，并同步更新判定标准。
任务分类和需求层级、WBS 划分是什么关系？
本文讨论的任务分类只针对可执行工作项，解决的是单个任务归入哪个类别，以支撑分派、排序、统计和复盘。项目交付范围的 WBS 划分属于项目范围管理，需求层级与需求分解属于需求管理主题，它们处理的是工作内容的分解结构。两者可以配合使用，但分类维度和判定标准应各自独立设计，避免把层级结构直接当成任务类别。
