任务分类要解决的是工作项能否被快速找到、正确分派和稳定统计。本文限定在可执行工作项层面，先帮你确定分类目的与主维度，再给出从维度设计到字段落地的步骤、角色分工、一个迭代内的应用示例和验收清单，便于团队直接照做。
要点总览（TL;DR）
- 任务分类先写清用途：检索定位、分派责任、统计投入或区分优先级，不同目的对应不同主维度。
- 一个团队同一时期只设一个主维度，辅助维度不超过两个，维度越多填写准确率越低。
- 落地按四步走：筛选主维度、定义取值字典、配置任务字段与命名规则、设定必填与默认值。
- 职责分三类：规则制定者定字典与审批变更，创建者按规则填写，维护者按月检查“其他”占比与失效取值。
- 验收看六项：覆盖度、必填生效、检索可用、统计可信、维护责任明确、边界分歧可解释。
先定分类目的：任务分类要解决哪个管理问题
任务分类的第一步是写清用途。分类本身不产生价值，它服务于某个管理动作：有人要在几十条任务里找到自己该做的那几条，有人要按模块统计投入，有人要在排期时区分轻重缓急。用途不同，需要的主维度就不同。先写下“这套分类主要支撑哪一个动作”，再决定字段，能避免把能想到的维度全部堆上去。
常见目的与对应主维度的关系可以这样理解：
- 检索定位：成员需要按模块、产品线或功能区域找到任务，主维度选“所属模块/产品”，辅助维度可用工作类型。
- 分派责任：需要明确谁承接、谁协作，主维度选“执行角色”或“负责团队”，配合负责人字段使用。
- 统计投入：需要看各类工作的时间与数量分布，主维度选“工作类型”，如需求实现、缺陷修复、技术支持、内部改进。
- 区分优先级：需要在排期和日常处理中排序，主维度选“优先级”，但优先级通常变化频繁，更适合作为辅助维度而非唯一分类依据。
一个团队在同一时期最好只设一个主目的。若检索和统计都重要，可以选一个主维度加一个辅助维度，而不是并列四五个维度。分类范围也要提前说清：本文讨论的是可执行工作项，即能被一个人或一个小组在有限时间内完成并交付结果的任务；项目交付范围的WBS划分、需求分解与需求层级管理属于另外的管理动作，不在本文展开。
本节的交付物是一份简短的分类目的说明，建议包含三句话：这套分类主要支撑什么动作、选定的主维度是什么、辅助维度是什么。写完后让两三位日常使用任务清单的成员读一遍，确认他们能理解用途，再进入下一步。
任务分类的核心步骤：从维度选择到字段落地
从目的到可用的分类规则，可以按四步推进。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，避免边设计边改字段造成返工。
第一步：列出候选维度并筛选主维度
输入是上一步的分类目的说明和现有任务清单。动作是把团队能想到的维度全部列出来，例如工作类型、所属模块、优先级、任务来源、执行角色、客户或项目、预计工时区间等，然后对照目的逐项判断：这个维度是否直接支撑主要用途，取值是否稳定，填写是否容易。输出是一份候选维度清单，标注保留、备选和放弃。完成标志是主维度只剩一个，辅助维度不超过两个，且每个被放弃的维度都写明了原因。
第二步：定义每个分类值的名称、含义与边界
输入是筛选后的维度清单。动作是为每个维度的每个取值写出名称、一句话含义和典型例子，尤其要写清容易混淆的边界。例如“缺陷修复”指已交付功能出现的错误，“内部改进”指不直接面向外部交付的效率或质量改进。输出是一份分类值字典。完成标志是任意两条任务放在一起，两名成员能独立判断出相同的分类结果；对判断不一致的例子，补充说明直到分歧消除。
第三步：把分类落到任务字段与命名规则
输入是分类值字典。动作是在任务清单中建立对应字段，字段类型与取值方式要和维度特性匹配：取值有限的维度用单选，需要多选的场景谨慎使用多选，避免一条任务挂多个同类标签导致统计重复。命名规则统一采用“维度名+取值”的固定写法，例如“类型：缺陷修复”“模块：订单中心”，不使用同义词混写。输出是字段配置说明和命名规则。完成标志是新建一条任务时，成员能在字段中找到全部取值，且不需要口头询问该填什么。
第四步：设定默认值与必填规则
输入是字段配置说明。动作是确定哪些字段必填、哪些给默认值。主维度字段建议必填；辅助维度可以给默认值，例如来源默认“内部提出”，但默认值要定期抽查，防止成员不修改导致数据失真。输出是字段规则表，写明字段名、是否必填、默认值、可选取值和修改权限。完成标志是用一条测试任务走完创建流程，必填校验生效，默认值符合预期。
在工具层面，任务字段需要能被视图和筛选直接使用，分类才有检索和统计价值。ONES 的工作项支持自定义字段与视图筛选，可以把上述维度配置成字段，并通过视图按模块、类型或优先级查看任务分布；具体字段类型和视图配置以团队实际使用的版本为准。
分类维度怎么选：常用维度与适用条件
维度选择的核心判断是：这个维度能否稳定填写、是否直接支撑主要用途、维护成本是否可接受。下表对照几类常用维度的用途、代价与适用条件，便于取舍。
| 维度 | 主要用途 | 代价与风险 | 适用条件 |
|---|---|---|---|
| 工作类型 | 统计投入结构，区分需求实现、缺陷修复、技术支持、内部改进 | 边界易混，需要字典和示例支撑 | 需要看人力分布或做复盘时 |
| 所属模块/产品 | 检索定位，按功能区域分派和汇总 | 模块划分随产品演进而变化，需要维护清单 | 产品有相对稳定的功能分区时 |
| 优先级 | 排期与日常处理排序 | 变化频繁，历史统计意义有限 | 作为辅助维度，配合排期流程使用 |
| 来源 | 区分客户反馈、内部提出、线上问题等入口 | 取值容易随手填写，需要默认值与抽查 | 需要追踪任务入口和响应情况时 |
| 执行角色 | 分派责任，识别角色负载 | 一人多角色时取值不唯一 | 角色边界清晰、任务以角色为单位分派时 |
维度数量与维护成本直接相关。每增加一个必填维度，创建任务时多一次判断，分类值字典多一份维护，统计口径多一层解释。经验上，一个团队的主维度加辅助维度控制在两到三个，超过这个数量后，填写准确率往往下降，分类反而失去可信度。主维度承担检索或统计的主要任务，辅助维度用于补充说明，两者不要表达同一件事。例如“工作类型”里已有“缺陷修复”，就不必再设一个“是否缺陷”的字段，否则同一含义出现两次，统计时容易重复计算或口径冲突。
本节的交付物是最终选定的维度清单，写明主维度、辅助维度、每个维度的取值数量和负责人。清单确定后，短期内不再新增维度，新增需求先记录，按季度评估。
角色与交付物：谁定义、谁填写、谁维护
分类规则能否长期可用，取决于职责是否落到具体角色。建议至少区分三类职责：规则制定、日常填写、定期维护。小团队可以由同一人兼任，但职责本身要写清楚，避免出现“大家都觉得该有人管”的空档。
| 角色 | 职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 分类规则制定者 | 确定分类目的、主维度与取值字典，审批维度变更 | 分类目的说明、分类值字典、字段规则表 | 在团队例会上宣讲，规则文档放在团队可访问的位置 |
| 审批者 | 确认规则与现有流程不冲突，批准上线 | 审批记录与生效日期 | 审批通过后由制定者发布规则版本 |
| 任务创建者 | 创建任务时按规则填写主维度，必要时补充辅助维度 | 带完整分类字段的任务条目 | 任务进入清单即完成填写，缺必填项无法提交 |
| 任务执行者 | 执行中发现分类错误时提出修正，不擅自新增取值 | 修正记录或变更申请 | 通过任务评论或变更申请提交给维护者 |
| 分类维护者 | 定期检查“其他”类占比、失效取值和默认值使用情况，清理或合并取值 | 分类维护清单与月度检查记录 | 检查结果同步给规则制定者，重大调整走审批 |
维护节奏建议按月或按迭代进行。检查内容包括：新增任务中“其他”或空值的比例、长期未使用的取值、因组织调整而失效的模块名。维护者不直接删除已被历史任务使用的取值，先停用再观察，保留历史统计的可追溯性。角色职责表和维护清单应作为团队规则文档的一部分，新成员加入时随任务流程一并了解。
示例：一个迭代内的任务分类落地
以下为演示情景，用于说明规则如何应用，数据为示意。某产品团队有八名成员，迭代周期两周，任务清单约四十条。团队确定的分类目的是“支撑按模块检索和按工作类型统计投入”，主维度为“所属模块”，辅助维度为“工作类型”，优先级作为排期字段保留但不纳入分类统计。
落地过程分三步。第一步，维护者把模块清单整理为订单、支付、会员、基础设置四个取值，工作类型设为需求实现、缺陷修复、技术支持、内部改进四类，并为每类写一句含义和一个例子。第二步，迭代启动会上用十条历史任务做试填，两名成员独立分类后对照，发现“支付回调超时排查”被分别归入缺陷修复和技术支持，于是补充说明：已上线功能不符合预期归缺陷修复，面向使用方的答疑与配置协助归技术支持。第三步，正式建单时主维度必填，工作类型默认“需求实现”，创建者按实际修改。
迭代结束后检查效果：按模块视图能在一分钟内列出各模块的在办任务，分派时直接按模块找到对应负责人；按工作类型统计，缺陷修复占比约三成，与团队体感基本一致。暴露的问题是“内部改进”只有两条，其中一条实际是环境搭建，说明该取值边界仍偏窄，维护者在下个迭代补充了示例。另一处是三条任务的工作类型停留在默认值，抽查后确认其中两条应为技术支持，随后在周会上提醒创建者核对默认值。
这个示例说明，分类规则的价值在第一次使用时就会显现：检索是否顺手、统计是否可信、分歧是否可解释。发现问题时优先补充字典和示例，而不是立刻增加新维度。
完成检查：任务分类是否可用的验收项
分类机制上线后，用下面这份清单逐项核对。每项都给出判断标准和未通过时的处理方式，避免凭感觉判断“差不多能用”。
- 覆盖度：抽查最近一个迭代的任务，主维度中“其他”或空值占比是否低于一成。若超出，检查是取值缺失还是填写习惯问题，前者补充取值，后者补充示例和提醒。
- 必填与默认值生效：新建任务时主维度无法跳过，默认值符合规则表。若校验未生效，回到字段配置修正，并重新走一遍测试任务。
- 检索可用：任选一个模块或工作类型，能否在视图或筛选中一次列出对应任务，结果与预期一致。若结果混杂，检查是否存在同义取值或命名不统一。
- 统计可信：按主维度统计的数量分布与团队实际投入大致吻合，无明显重复计数。若偏差大，检查是否使用了多选字段或存在含义重叠的维度。
- 维护责任明确：维护者、检查频率和变更审批方式已写入规则文档，且有人实际执行过至少一次检查。
- 分歧可解释：抽取五条边界任务，两名成员独立分类结果一致，或分歧能依据字典说明解决。
任何一项未通过，先定位是规则问题还是执行问题：规则问题修改字典或字段配置并重新发布版本，执行问题通过示例宣讲和抽查纠正。全部通过后，分类机制进入常规维护，按既定节奏检查，不再频繁调整维度。
常见问题
团队任务量不大，还需要专门做任务分类吗？
任务量小时，分类可以简化，但不宜完全省略。至少保留一个主维度，让成员能按模块或工作类型找到任务。判断标准是：当有人需要在一屏之外翻找任务，或需要回答“这个迭代各类工作各占多少”时，分类就开始产生价值。小团队可先只设主维度必填，辅助维度选填，等任务量增长再补充。
分类值定好后，成员经常选错或随手填默认值，怎么处理？
先区分是规则问题还是执行问题。若多名成员对同一类任务判断不一致，说明取值边界不清，应补充含义说明和典型例子，必要时合并含义重叠的取值。若只是懒得改默认值，可在周会上抽查几条任务当场核对，并把默认值改为更中性的选项，减少误填。连续两个检查周期“其他”占比仍偏高，再考虑调整维度设计。
业务调整后，旧的分类值还能直接删除吗？
不建议直接删除已被历史任务使用的取值。更稳妥的做法是先停用，让新任务无法再选，历史任务保留原值，统计口径仍可追溯。观察一到两个周期后，若确认无统计需要，再评估是否合并到新取值。删除前应确认没有报表或复盘依赖该取值，避免历史数据出现断档。
优先级适合作为任务分类的主维度吗？
通常更适合作为辅助维度或排期字段。优先级随排期和外部变化频繁调整，用它做分类主维度会让历史统计失去稳定口径，同一任务在不同时间落入不同类别。若团队主要目的是排期排序，可以把优先级保留为独立字段，分类主维度另选工作类型或所属模块，两者配合使用。
分类规则上线后，多久评估一次是否需要调整？
建议按月或按迭代做一次轻量检查，重点看新增任务中“其他”或空值的比例、长期未使用的取值、因组织调整失效的模块名。维度层面的增删按季度评估，新增需求先记录再统一讨论。频繁调整维度会让成员难以形成填写习惯，也会打断统计口径的连续性，因此规则稳定比追求一次设计到位更重要。
