任务分类要能直接支撑派工、排序和复盘，做法是先确定用途，再选择一套主维度固定为任务属性，辅以标签记录场景，并为每类任务定义命名规则、颗粒度上限和完成标准。本文给出维度选择、字段设计、操作步骤、角色分工与检查清单，并用一次迭代场景示范落地过程。
要点总览（TL;DR）
- 任务分类先定用途：派工看责任角色与动作类型，排序看优先级与紧急度，复盘看交付物类型与动作类型。
- 固定一套主维度作为任务属性，例如交付物类型，场景信息用标签补充，保证统计口径稳定。
- 必填字段控制在支撑派工与排序的最小集合：任务名称、交付物类型、负责人、优先级、完成标准。
- 颗粒度以一个人在一个迭代内可完成、完成标准可验证为上限，超出则拆成子任务。
- 复核时点设在任务进入待办前，字段完整性与颗粒度可执行是阻断项，不通过不进入迭代计划。
先定用途：任务分类要解决派工、排序还是复盘
任务分类的第一步是明确它要服务的管理动作。分类结果用于派工时，维度要能回答“这类任务交给谁、需要什么技能”；用于排序时，维度要能回答“先做哪件、哪件可以等”；用于复盘时，维度要能回答“时间花在哪类任务上、哪类任务反复延期”。用途不同，维度的取舍就不同，先定用途可以避免把字段越加越多却没人使用。
三类常见用途对应的维度选择如下：
| 管理用途 | 核心问题 | 优先维度 | 辅助信息 |
|---|---|---|---|
| 派工 | 谁来做、需要什么能力 | 责任角色、动作类型 | 技能标签、协作角色 |
| 排序 | 先做什么、什么可以延后 | 优先级与紧急度 | 依赖关系、交付物类型 |
| 复盘 | 投入分布如何、哪类任务易延期 | 交付物类型、动作类型 | 场景标签、延期原因 |
实际工作中三类用途往往同时存在，但字段设计仍需有主次。建议固定一套主维度作为任务属性，例如以“交付物类型”为主维度，保证每个任务都有唯一归属；派工需要的角色、排序需要的优先级作为必填属性；场景、客户、系统等描述性信息用标签补充。主维度只保留一套，标签可以多选，这样统计口径稳定，临时场景也能记录。
判断用途是否明确，可以用一个简单测试：拿分类结果去回答“这个任务该派给谁”“下周先做哪些”“上个迭代哪类任务最多”三个问题，如果其中某个问题无法从现有字段得到答案，说明用途与维度尚未对齐，应先补用途再补字段。
四类常用分类维度及字段设计
可落地的任务分类通常围绕四类维度展开：交付物类型、动作类型、优先级与紧急度、责任角色。四类维度回答的问题不同，字段写法也有区别。
交付物类型与动作类型的区别。交付物类型描述任务最终产出什么，例如文档、设计稿、代码变更、数据报表、会议结论；动作类型描述完成任务的主要工作性质，例如分析、编写、评审、沟通、测试。两者可以组合使用：交付物类型适合做统计和复盘的主维度，动作类型适合判断所需技能和工时估算。一个任务只有一个交付物类型，动作类型可以有一个主类型。
优先级与紧急度的字段取值。优先级表达业务重要程度，紧急度表达时间压力，两者分开设置可以避免“所有任务都标最高”的常见问题。优先级建议用三到四档，例如高、中、低；紧急度用两到三档，例如紧急、常规。排序时先看优先级，再看紧急度，最后看依赖关系。
责任角色与协作角色的区分。责任角色是任务的第一负责人，对完成结果负责，每个任务只能有一个；协作角色是参与或提供输入的人，可以有多个。字段上分别设置“负责人”和“协作人”，避免出现多人负责却无人推进的情况。
必填与选填的划分。必填字段应控制在能支持派工和排序的最小集合，通常包括任务名称、交付物类型、负责人、优先级、完成标准；选填字段包括协作人、紧急度、场景标签、预计工时。必填过多会拖慢录入，必填过少则分类结果无法使用。
| 字段名 | 取值 | 必填 | 示例 |
|---|---|---|---|
| 任务名称 | 动作+对象，短语描述 | 是 | 编写登录接口测试用例 |
| 交付物类型 | 文档、设计稿、代码变更、数据报表、会议结论等 | 是 | 文档 |
| 动作类型 | 分析、编写、评审、沟通、测试等 | 是 | 编写 |
| 优先级 | 高、中、低 | 是 | 高 |
| 紧急度 | 紧急、常规 | 否 | 常规 |
| 负责人 | 单个成员 | 是 | 张工 |
| 协作人 | 一个或多个成员 | 否 | 李工 |
| 完成标准 | 可验证的完成条件 | 是 | 用例覆盖全部登录分支并通过评审 |
| 场景标签 | 自定义多选 | 否 | 移动端、支付 |
字段设计完成后应固定一段时间不再频繁调整。取值口径变化会让历史数据失去可比性，确需新增取值时，先在小范围试用，再统一替换。
分类操作步骤：从任务清单到可执行任务
分类执行按固定顺序推进，每一步都有明确的输入和输出，完成标志清晰，便于多人协作时保持一致。
第一步：收集与去重任务清单。输入是需求、会议记录、缺陷、临时请求等来源；动作是把待办事项汇总到一张清单，合并重复项，删除已取消项；输出是一份去重后的原始任务清单；完成标志是每个条目都能追溯到来源，且没有明显重复。
第二步：判定主维度。输入是原始任务清单；动作是按固定判断顺序确定每个任务的交付物类型：先看最终产出是什么，再看产出服务于哪个环节，最后确认是否已有同类任务；输出是带交付物类型的任务清单；完成标志是每个任务都有且只有一个交付物类型。
第三步：拆分颗粒度。输入是已判定类型的任务；动作是检查任务能否独立派工、能否判断完成，不能则继续拆分。颗粒度上限建议以“一个人在一个迭代内可完成、完成标准可验证”为准，超出则拆成子任务；输出是拆分后的任务列表；完成标志是每个任务都有明确负责人和完成标准。
第四步：命名与标注。输入是拆分后的任务；动作是按“动作+对象”的规则命名，例如“编写登录接口测试用例”，并补充优先级、协作人、场景标签；输出是字段完整的任务条目；完成标志是名称能独立看懂，必填字段无空缺。
第五步：进入待办。输入是字段完整的任务；动作是确认完成标准、负责人和优先级后放入待办列表，等待排期；输出是待办列表中的可执行任务；完成标志是任务可被直接领取或排入迭代，无需再次补充信息。
五步中，拆分颗粒度最容易反复。判断标准可以简化为两个问题：这个任务能否交给一个人独立完成？完成后能否用一句话判断是否达标？两个问题都回答“是”，颗粒度即可接受；任一回答“否”，继续拆分。
角色分工与交付物：谁定规则、谁分类、谁复核
任务分类机制需要有人维护规则、有人执行分类、有人检查结果，三类职责分开，机制才能持续运转。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 规则制定与维护者 | 确定主维度、字段取值、命名规则和颗粒度标准；处理例外申请；定期检查取值是否仍适用 | 分类规则说明、字段定义表、例外记录 |
| 任务提出者 | 提交任务时说明交付物、完成标准和期望时间；配合补充场景标签 | 任务来源说明、完成标准初稿 |
| 任务执行者 | 确认任务可执行，补充动作类型和协作人；发现颗粒度过大时提出拆分 | 字段完整的任务条目、拆分建议 |
| 复核者 | 在任务进入待办前或迭代计划会上检查字段完整性、取值一致性和颗粒度 | 复核记录、退回修改清单 |
规则制定者通常由团队负责人或项目管理角色承担，维护频率可以按迭代检查一次，重点看是否有大量任务落在“其他”类、是否有字段长期空缺。任务提出者和执行者共同承担分类责任：提出者负责说清交付物和完成标准，执行者负责确认可执行性并补齐动作类型。复核时点建议设在任务进入待办前，检查内容包括必填字段是否齐全、交付物类型取值是否在既定范围内、任务是否可独立派工；迭代计划会上再做一次抽样复核，重点看优先级分布是否合理。
当分类结果需要落到工作项上时，可以在 ONES 中把交付物类型、优先级、负责人设为工作项属性，用标签记录场景信息，让派工、排序和迭代复盘读取同一套字段，减少在多个表格之间同步口径的工作。
示例：一次迭代内的任务分类落地
以下为演示情景，用于说明分类过程，不代表真实项目数据。某团队在迭代准备阶段收集到一份原始任务清单，包含“登录功能测试”“接口文档整理”“支付流程评审”“修复列表页加载慢”“准备周会材料”等条目。
按主维度判定交付物类型后，“登录功能测试”归为测试用例，“接口文档整理”归为文档，“支付流程评审”归为会议结论，“修复列表页加载慢”归为代码变更，“准备周会材料”归为文档。其中“登录功能测试”原始描述覆盖范围过大，拆分前无法判断完成标准；拆分为“编写登录接口测试用例”和“执行登录回归测试”两个任务后，前者完成标准为“用例覆盖全部登录分支并通过评审”，后者为“回归用例全部执行并记录结果”。
| 任务名称 | 交付物类型 | 动作类型 | 优先级 | 负责人 | 完成标准 |
|---|---|---|---|---|---|
| 编写登录接口测试用例 | 测试用例 | 编写 | 高 | 张工 | 覆盖全部登录分支并通过评审 |
| 执行登录回归测试 | 测试用例 | 测试 | 高 | 李工 | 回归用例全部执行并记录结果 |
| 整理接口文档 | 文档 | 编写 | 中 | 王工 | 接口字段与最新版本一致 |
| 组织支付流程评审 | 会议结论 | 评审 | 中 | 赵工 | 评审结论形成待办并分配到人 |
| 修复列表页加载慢 | 代码变更 | 分析 | 高 | 陈工 | 加载时间恢复到约定阈值内 |
复核时发现两个问题：一是“整理接口文档”缺少协作人，实际需要后端开发提供字段说明，补充协作人后任务才可执行；二是“修复列表页加载慢”动作类型标为“分析”，但任务实际包含定位和修改两个阶段，复核后拆为“定位列表页加载瓶颈”和“修改列表页查询逻辑”两个任务，前者完成标准为“输出瓶颈定位结论”，后者为“修改上线并通过验证”。修正后，全部任务字段完整，可进入待办排期。
完成检查：分类是否可用的判断标准
分类机制是否达到可用状态，可以按以下清单逐项核对。每项给出通过标准，未通过则需返工。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 字段完整性 | 必填字段无空缺，任务名称、交付物类型、负责人、优先级、完成标准齐全 | 退回任务提出者或执行者补充 |
| 取值一致性 | 交付物类型、优先级等字段取值均在既定范围内，无自造选项 | 统一替换为规则内取值，记录例外 |
| 支持派工 | 每个任务有唯一负责人，协作人信息足以判断所需技能 | 补充负责人或拆分任务 |
| 支持排序 | 优先级与紧急度可区分先后，依赖关系已标注 | 重新评估优先级，补充依赖说明 |
| 颗粒度可执行 | 任务可独立派工，完成标准可验证，无跨迭代超大任务 | 继续拆分并补充完成标准 |
| 规则维护 | 规则有明确维护者，例外有记录，取值定期检查 | 指定维护者，建立例外记录 |
其中字段完整性和颗粒度可执行属于阻断项：任一任务不满足，不应进入待办或迭代计划，需先返工。取值一致性和支持排序属于迭代内可修正项，可在计划会上集中调整。规则维护属于机制层面的检查，建议每个迭代结束前确认一次例外记录是否已处理，避免例外逐渐变成事实上的新规则。
检查通过后，分类结果应能直接回答三个问题：任务派给谁、下周先做哪些、上个迭代哪类任务投入最多。三个问题都能从字段和标签中得到答案，说明分类机制已经可用，后续只需按迭代节奏维护取值和例外记录。
常见问题
团队任务类型很多，主维度选交付物类型还是动作类型？
两种都可以作为主维度，选择取决于分类结果主要服务什么。若主要用于复盘投入分布、统计各类产出，交付物类型更合适，因为它描述任务最终产出什么，归类相对稳定；若主要用于判断所需技能和估算工时，动作类型更直接。无论选哪种，主维度只保留一套，另一个维度作为必填属性或辅助标签记录，避免两套维度并行导致同一任务出现多个归属。
任务分类字段已经建好，但大家录入时经常留空，怎么处理？
先区分是字段太多还是规则不清。必填字段只保留支撑派工和排序的最小集合，其余改为选填或标签；同时把复核时点前移到任务进入待办之前，字段不齐的任务退回补充，不进入排期。规则维护者可以每个迭代检查一次空缺分布，若某个字段长期大面积空缺，说明它当前的管理用途不明确，应考虑降为选填或删除，而不是反复强调填写要求。
临时插入的紧急任务怎么分类，是否要单独设一类？
临时任务仍按既有主维度归类，紧急程度用紧急度字段表达，不必为临时任务新开交付物类型。若临时任务频繁出现，可以在标签中记录来源场景，便于复盘时统计临时插入对计划的影响。只有当某类临时任务长期占据较高比例、且现有交付物类型无法准确描述其产出时，才考虑新增取值，并先在小范围试用再统一替换。
分类规则运行一段时间后，历史任务和新取值对不上怎么办？
取值口径变化会让历史数据失去可比性，因此新增或修改取值要谨慎。确需调整时，先明确新旧取值的映射关系，对历史任务做批量替换或保留旧值并标注生效时间，避免同一含义出现两种写法。复盘时以映射后的口径统计，并在规则说明中记录变更时间和原因，让后续查看数据的人能理解口径差异。
小团队也需要设置规则维护者和复核者吗？
需要，但可以由同一人兼任。小团队里规则维护和复核可以合并到团队负责人或项目管理角色，重点是明确谁对取值口径负责、谁在任务进入待办前检查字段。任务提出者和执行者仍各自承担分类责任：提出者说清交付物和完成标准，执行者确认可执行性并补齐动作类型。职责清晰比人数多少更重要，避免出现字段无人维护、分类结果无人校验的情况。
