任务分组要解决的是工作项数量增加后派工、跟踪和复盘失焦的问题。做法是先明确分组服务于哪个管理动作，再选一个主维度，把可执行工作项归入互斥且覆盖完整的分组，统一命名与字段规则，最后用一次真实迭代试跑。分组规则可以沉淀在文档中，也可以落到工作项字段与分组视图里，ONES 可作为承载方式之一。
要点总览（TL;DR）
- 任务分组先写清分组要支撑的管理动作，再选一个主维度：按交付物、按阶段、按角色、按优先级或按类型，多维度并列会让工作项归属不清。
- 操作按五步走：盘点并清洗工作项、确定层级与分组数量上限、建立命名与编码规则、逐条归组并处理边界项、设置负责人与状态流转规则。
- 规则文档由项目负责人维护，归组清单由任务负责人维护，校验记录由校验人保存；边界项无人拍板和规则改了清单没同步是两个常见断点。
- 分组完成后用互斥覆盖、命名统一、负责人明确、支持派工、跟踪与复盘、变更可维护七项检查，不满足时回到对应环节修正。
- 分组规则可落到工作项字段与分组视图中，ONES 可作为承载方式之一，具体功能范围以实际开通版本为准。
先定分组目的，再选分组维度
任务分组的第一步是回答“分完组要拿它做什么”。目的不同，合适的维度也不同：为了让每个人清楚自己该做什么，按角色分组更直接；为了看清交付进度，按交付物分组更有效；为了识别瓶颈，按阶段分组更合适；为了排优先级，按优先级分组更贴近决策。先写下一句目的描述，例如“让本周迭代的派工和每日站会按交付物对齐”，维度选择就有了判断依据。
常用维度可以归纳为五类，各有适用条件：
| 分组维度 | 适合的管理动作 | 适用条件 | 需要注意 |
|---|---|---|---|
| 按交付物 | 跟踪交付进度、对齐验收范围 | 任务与明确产出物对应，交付物数量可控 | 跨交付物的公共任务需要单独归属规则 |
| 按阶段 | 识别流程瓶颈、安排阶段评审 | 工作流程相对固定，阶段边界清晰 | 同一任务跨阶段时需确定当前归属 |
| 按角色 | 派工、平衡负载 | 角色分工稳定，任务责任人明确 | 一人多角色时容易重复归组 |
| 按优先级 | 排期、决定先做什么 | 优先级判定标准已达成共识 | 优先级变化频繁时分组会反复调整 |
| 按类型 | 区分需求、缺陷、技术任务等类别 | 类型定义清晰，团队对分类口径一致 | 类型过多会退化成标签堆叠 |
单一主维度优先。多维度混用会让同一个工作项同时属于多个分组，派工时无法判断唯一归属，统计口径也会失真。如果确实需要第二层信息，把它做成工作项上的字段或标签，而不是再建一套并列分组。团队规模小、任务量少时，一个主维度加少量标签就够用；任务量增大、参与角色增多后，可以增加一层子分组，但主维度保持不变。
任务分组的具体操作步骤
下面按输入、动作、输出和完成标志拆解一次分组落地过程，适用于一个迭代或一个项目周期的范围。
第一步：盘点待分组工作项并清洗命名
输入是当前任务清单，来源可能是需求文档、会议记录或已有任务列表。动作是逐条检查工作项是否可执行：标题是否说明动作和对象，是否存在重复条目，是否有明显不属于本周期范围的条目。把“优化一下”“跟进相关事项”这类无法判断完成状态的标题改写为具体动作，例如“完成登录页错误提示文案修改”。输出是一份去重、命名清晰的工作项清单。完成标志是每条工作项都能被一个责任人独立执行并判断完成与否。
第二步：确定分组层级与分组数量上限
输入是第一步的清单和已确定的主维度。动作是统计该维度下的自然类别数量，设定分组层级：通常一层分组足够，任务量较大时增加一层子分组。同时设定分组数量上限，例如主分组控制在五到八个，避免出现大量只有一两条任务的分组。输出是分组结构草图，标明层级和每组预计容纳的任务量。完成标志是每个分组都有足够的工作项支撑，且没有为个别任务单独设组。
第三步：建立分组命名与编码规则
输入是分组结构草图。动作是统一命名格式，例如“交付物名称＋序号”或“阶段名称”，并约定编码规则，使分组在列表、报表和文档中可以被一致引用。命名要避免同义词混用，例如“前端开发”和“前端”只保留一种写法。输出是一份分组命名与编码规则说明。完成标志是任何人拿到规则后，都能为同类工作项写出相同的分组名称。
第四步：把工作项归入分组并处理边界项
输入是工作项清单和命名规则。动作是逐条归组，遇到同时符合两个分组的边界项时，按事先约定的规则处理：以主要交付物归属为准，或归入承担主要工作量的角色，或单设“公共支撑”兜底分组。边界项的处理结论要记录，供后续同类情况参考。输出是归组完成的分组清单。完成标志是所有工作项都有唯一归属，没有遗留未分组条目。
第五步：设置负责人、状态与流转规则
输入是分组清单。动作是为每个分组指定负责人，明确组内工作项的状态取值和流转条件，例如从“待处理”到“进行中”需要责任人认领，从“进行中”到“已完成”需要验收确认。输出是带负责人和状态规则的分组配置。完成标志是每个分组都能直接用于派工，状态变化有明确触发条件。
角色分工与各环节交付物
分组能否持续可用，取决于规则制定、日常归组和定期校验三类职责是否有人承担。角色划分不必复杂，但要避免同一环节无人负责或多人重复操作。
| 角色 | 主要职责 | 交付物 | 参与环节 |
|---|---|---|---|
| 项目负责人 | 确定分组目的与主维度，审批分组结构 | 分组规则文档（含维度、层级、命名编码规则） | 第一至第三步，变更评审 |
| 任务负责人 | 按规则归组，处理边界项，维护组内状态 | 分组清单、边界项处理记录 | 第四至第五步，日常维护 |
| 团队成员 | 按分组接收任务，反馈归属不清的情况 | 归属异议记录 | 执行过程 |
| 项目负责人或指定校验人 | 定期检查分组完整性与一致性 | 校验记录、修正清单 | 分组完成后及每次迭代结束 |
规则文档由项目负责人维护，归组清单由任务负责人维护，校验记录由校验人保存。评审与变更时，新增分组或调整主维度需要项目负责人确认，日常归组调整由任务负责人直接处理并留痕。容易出问题的环节通常有两个：一是边界项无人拍板，导致长期挂在未分组状态；二是分组规则改了但清单没有同步，统计口径出现偏差。为这两个环节指定明确责任人，比增加更多审批更有效。
规则文档、分组清单和校验记录适合放在团队共用的知识库中，便于版本追溯。ONES Wiki 支持页面组关联项目、文档关联任务，并提供页面模板与版本记录，可作为承载分组规则文档的方式之一，具体能力以实际开通版本为准。
一个迭代的任务分组示例
以下为演示情景，用于说明归组过程，不代表真实项目数据。
某团队进入一个为期两周的迭代，原始任务清单包含：登录页错误提示文案修改、支付接口联调、订单列表分页修复、用户反馈整理、支付失败重试逻辑、登录日志埋点、帮助中心文档更新、支付对账脚本编写。团队此前的痛点是站会时说不清每个交付物进展到哪一步，因此确定分组目的为“按交付物跟踪进度并派工”，主维度选择按交付物。
归组过程：登录页错误提示文案修改、登录日志埋点归入“登录体验”；支付接口联调、支付失败重试逻辑、支付对账脚本编写归入“支付链路”；订单列表分页修复归入“订单管理”；用户反馈整理和帮助中心文档更新同时涉及多个交付物，属于边界项，按“主要服务对象”规则分别归入“登录体验”和“订单管理”，并在处理记录中注明依据。
| 工作项 | 归组结果 | 处理说明 |
|---|---|---|
| 登录页错误提示文案修改 | 登录体验 | 直接归组 |
| 登录日志埋点 | 登录体验 | 直接归组 |
| 支付接口联调 | 支付链路 | 直接归组 |
| 支付失败重试逻辑 | 支付链路 | 直接归组 |
| 支付对账脚本编写 | 支付链路 | 直接归组 |
| 订单列表分页修复 | 订单管理 | 直接归组 |
| 用户反馈整理 | 登录体验 | 边界项，按主要服务对象归属 |
| 帮助中心文档更新 | 订单管理 | 边界项，按主要服务对象归属 |
分组后，每个交付物指定一名负责人，站会按分组依次过进度，派工时直接按组分配，复盘时按组统计完成情况。可迁移的规律是：先确定分组要支撑的管理动作，再选维度；边界项用一条固定规则处理并留痕；分组数量控制在团队一次能看完的范围内。
分组完成后的检查项
分组是否可用，可以用下面这份清单逐项判断。任何一项不满足，都回到对应环节修正，而不是在结果上打补丁。
| 检查项 | 判断标准 | 不满足时的修正动作 |
|---|---|---|
| 互斥且覆盖完整 | 每个工作项有且只有一个归属，没有未分组条目 | 补充边界项归属规则，或增设兜底分组 |
| 命名与编码统一 | 同类分组使用同一写法，编码可被一致引用 | 回到命名规则环节统一口径，批量修正清单 |
| 负责人明确 | 每个分组都有指定负责人，且负责人知情 | 补指定负责人并同步确认 |
| 支持派工 | 拿到分组即可分配任务，无需再次判断归属 | 检查分组粒度是否过粗或过细，调整层级 |
| 支持进度跟踪 | 按分组能看出各交付物或阶段的完成情况 | 补充状态规则，确保状态变化可统计 |
| 支持复盘 | 迭代结束后能按分组统计完成量与遗留项 | 补齐历史工作项的归属，统一统计口径 |
| 变更可维护 | 新增或调整分组有明确触发条件和审批人 | 在规则文档中补充变更流程与记录方式 |
分组变更的维护方式建议与迭代节奏对齐：每个迭代结束时校验一次分组完整性，主维度调整需项目负责人确认，日常新增工作项由任务负责人按现有规则归组。分组规则落地到工作项字段和分组视图后，派工、跟踪与复盘可以共用同一套口径；ONES 的任务管理能力可承载字段与视图配置，具体功能范围以实际版本为准。
常见问题
任务分组和任务拆解是什么关系，应该先做哪一个？
两者解决不同问题：拆解是把一个较大的工作项切成可执行的小任务，分组是把已有的可执行工作项按某个维度归到一起。通常先完成拆解，让每条任务都能被独立执行和判断完成，再做分组；如果任务标题还停留在“优化一下”这类无法判断完成状态的表述，归组后派工仍然会卡住。分组过程中如果发现某个分组下的任务明显偏大，可以就地补一次拆解，再回到归组。
团队同时需要按交付物看进度、按角色派工，是否要建两套分组？
不建议建两套并列分组。并列分组会让同一个工作项出现两个归属，统计口径和派工判断都会失真。更常见的做法是保留一个主维度作为分组结构，把另一个维度的信息做成工作项上的字段或标签，例如主分组按交付物，责任人字段承担按角色查看的需求。如果确实需要两层结构，可以增加一层子分组，但主维度保持不变，避免每次调整都要重建整套分组。
边界工作项反复出现，每次都临时讨论归属怎么办？
说明边界规则还没有固定下来。可以在规则文档中补一条可复用的判定顺序，例如先看主要交付物，再看承担主要工作量的角色，两者都不明确时归入单设的“公共支撑”分组。每次处理完边界项，把结论记入处理记录，后续遇到同类情况直接套用。规则文档适合放在团队共用的知识库中便于版本追溯，ONES Wiki 支持页面组关联项目、文档关联任务，并提供页面模板与版本记录，可作为承载方式之一，具体能力以实际开通版本为准。
分组数量控制在多少合适，任务量变大后要不要加深层级？
分组数量以团队一次能看完为准，主分组通常控制在五到八个，避免出现大量只有一两条任务的分组。任务量增大、参与角色增多后，可以增加一层子分组，但主维度保持不变，否则历史统计无法对比。层级加深后要同步检查命名与编码规则是否还能一致引用，以及每个新增分组是否都有明确负责人。产品本身对分组数量或层级是否有上限，需以实际开通版本为准。
分组做完后，迭代中途新增的任务怎么归？
按现有规则直接归组，由任务负责人处理并留痕，不必每次走评审。需要评审的是主维度调整、新增主分组或合并分组这类结构性变更，由项目负责人确认后在规则文档中更新，并同步修正已有清单。每个迭代结束时做一次完整性校验，检查是否有未分组条目和命名不一致的情况，把修正结果记入校验记录，下一轮迭代沿用同一套口径。
