制定子任务拆分规则，核心是回答四个问题：拆到哪一层为止、每个子任务拆多细、由谁拆分和审核、拆分结果如何验收。本文聚焦可执行工作项的拆分，给出一套从零制定规则的方法，包含颗粒度判断标准、角色分工、填写示例和完成检查清单。项目交付范围的WBS编制和需求层级管理属于其他管理范畴，本文不展开。
要点总览（TL;DR）
- 子任务拆分规则要同时规定四件事：层级上限、颗粒度标准、命名与字段规范、责任与验收方式，缺一项执行时就会走样。
- 颗粒度的基本单元是“一个可交付结果、一名负责人、一次可判断完成的验收”，完成周期以1至3个工作日、产出可检查结果为参考线，过粗继续拆、过细合并。
- 层级以任务—子任务两级为主，更细的执行步骤写入子任务描述或验收标准，跨任务范围与需求分解归入其他管理范畴。
- 任务负责人拆分并填字段，评审人核对颗粒度与验收标准，项目管理者维护规则并审批例外；检查不通过的子任务不进入执行队列。
- 规则发布前用典型任务试拆验证，试运行1至2个迭代后统计退回原因，据此修订颗粒度参考线和字段要求。
子任务拆分规则的核心答案与制定步骤
一套可执行的子任务拆分规则由四项内容构成：层级上限、颗粒度标准、命名与字段规范、责任与验收方式。四项缺一不可——只规定层级不规定颗粒度，拆分结果会粗细不一；只规定颗粒度不规定字段，执行时仍要靠口头补充信息。规则的作用是把“怎么拆”从个人经验变成团队可对照、可检查的统一做法。
制定规则建议按以下六步推进，每一步都明确输入、动作和输出，避免规则停留在讨论层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 盘点现有任务清单 | 近1至2个迭代或近期项目的任务列表 | 统计现有任务的层级深度、字段填写情况、常见拆分问题 | 问题清单，如“层级过深”“子任务无验收标准” | 能列出3至5类高频问题 |
| 2. 确定层级上限 | 问题清单、团队现有协作习惯 | 约定任务—子任务两级为主，超出部分归入项目范围或需求层级 | 层级边界说明 | 团队对“拆到哪层停”有统一答案 |
| 3. 定义颗粒度判断标准 | 典型任务样本 | 以可交付结果、单一负责人、可判断完成为基本单元，确定1至3个工作日的参考线 | 可勾选的颗粒度判断问题 | 用样本任务试判，结论一致 |
| 4. 设计字段与命名 | 颗粒度标准 | 规定子任务必填字段：负责人、验收标准、依赖、截止时间；约定命名格式 | 字段清单与命名示例 | 任取一个子任务，信息可独立读懂 |
| 5. 确定拆分与评审流程 | 字段清单、角色设置 | 明确谁拆、谁审、何时审、不通过如何退回 | 流程说明与角色职责 | 每个环节有明确责任人和交付物 |
| 6. 发布并试运行 | 规则草案 | 选取1至2个任务按规则试拆，收集执行反馈后修订发布 | 正式规则文档 | 试拆任务通过检查清单 |
规则文档本身应包含以下条目：适用范围（哪些工作项需要按此规则拆分）、层级边界、颗粒度判断问题、必填字段及填写要求、命名规范、角色职责、评审与例外审批方式、检查清单。条目写得越具体，执行时的解释空间越小。
颗粒度与层级：子任务拆到多细才算合适
颗粒度的基本单元可以概括为一句话：一个子任务对应一个可交付结果、一名负责人、一次可判断完成的验收。三个条件同时满足，子任务才具备独立跟踪和交接的基础。缺少任何一项，都会导致执行中责任不清或完成状态无法判断。
在基本单元之上，用完成周期作为参考线：子任务以能在1至3个工作日内完成并产出可检查结果为宜。这个区间是参考值，需要结合任务类型调整——调研类任务可能以“输出调研结论文档”为完成标志，周期略长也合理；配置类任务可能半天完成，同样合格。关键是周期与可检查结果绑定，而非单纯看天数。
拆分过粗和过细都有可识别的信号，处理方式不同：
- 过粗的信号：子任务需要多人协作完成、完成状态需要靠主观判断、执行超过参考周期仍无中间产出。处理方式是继续拆分，直到每个部分满足基本单元条件。
- 过细的信号：子任务无法独立验收、必须与其他子任务合并才有业务意义、拆分后字段填写成本高于执行成本。处理方式是合并为上一个层级的子任务，细节放入子任务描述或检查项。
层级方面，以任务—子任务两级为主。更细的执行步骤不设为独立工作项，而是写入子任务描述或验收标准；跨任务的范围划分归入项目范围管理，需求本身的分解归入需求层级管理，两者不在子任务规则中处理。这样做的目的是让任务列表保持可读，避免层级过深导致状态汇总失真。
颗粒度标准建议写成可勾选的判断问题，便于评审时逐项核对：
- 这个子任务是否有明确的可交付结果？
- 是否只有一名负责人？
- 完成与否能否由第三方根据验收标准判断？
- 预计完成时间是否在1至3个工作日的参考区间内？
- 是否可以在不依赖其他子任务完成的情况下独立验收？
- 它是否已经是任务层级下最合适的拆分粒度，无需再拆或合并？
角色分工与交付物：谁拆、谁审、谁验收
规则落地依赖三类角色：任务负责人、评审人、项目管理者。任务负责人最了解执行细节，承担拆分和字段填写；评审人从技术和业务角度检查颗粒度与验收标准是否成立；项目管理者维护层级边界和规则本身，并处理例外。三类角色在不同环节的交付物如下表。
| 环节 | 角色 | 主要动作 | 交付物 |
|---|---|---|---|
| 拆分 | 任务负责人 | 按颗粒度标准拆分子任务，填写负责人、验收标准、依赖、截止时间 | 字段完整的子任务列表 |
| 评审 | 技术或业务评审人 | 逐项核对颗粒度判断问题，检查验收标准是否可判断 | 评审意见，通过或退回修改 |
| 执行 | 子任务负责人 | 按验收标准推进，依赖变化时及时更新字段 | 执行记录与状态更新 |
| 验收 | 任务负责人或指定验收人 | 对照验收标准判断完成，记录结论 | 验收结论 |
| 规则维护 | 项目管理者 | 维护层级边界与字段规范，处理例外申请 | 规则版本更新、例外审批记录 |
例外审批的责任归属需要单独说明：当任务确实无法按标准颗粒度拆分（例如探索性任务结果不确定），由任务负责人向规则维护人提出例外申请，说明原因和替代的跟踪方式，经批准后记录在案。例外记录本身也是规则迭代的输入——同类例外反复出现，说明标准需要调整。
规则落到工具层面时，层级、字段和验收状态需要有对应的承载方式。在ONES中，任务与子任务可以作为不同层级的工作项组织，负责人、截止时间等字段随工作项填写，完成状态按工作项分别记录，评审和验收结论也可以留存在工作项上。这样拆分规则中的字段要求和检查动作就能在日常协作中直接执行，而不必依赖额外的表格维护。具体字段配置方式以团队实际使用的版本为准。
示例：一个任务如何按规则拆成子任务
以一个典型任务“完成订单查询接口的性能优化”为例，演示规则的应用过程。该任务初始只有一个负责人和一句描述，按规则需要先判断是否需要拆分。
用颗粒度判断问题逐项核对：该任务包含问题定位、方案设计、代码改造、压测验证多个环节，需要不同角色参与，完成状态无法由单一验收标准判断，预计周期超过3个工作日——满足继续拆分的条件。拆分后的子任务及字段填写如下：
| 子任务 | 负责人 | 验收标准 | 依赖 | 截止时间 |
|---|---|---|---|---|
| 输出订单查询接口性能瓶颈分析报告 | 后端工程师A | 报告列出慢查询与耗时分布，经评审人确认结论成立 | 无 | 第2个工作日 |
| 完成查询语句与索引优化改造 | 后端工程师A | 改造后单次查询耗时下降，代码通过评审合并 | 依赖瓶颈分析报告 | 第4个工作日 |
| 完成优化后压测并输出压测报告 | 测试工程师B | 压测报告包含优化前后对比数据，达到约定指标 | 依赖优化改造完成 | 第5个工作日 |
拆分前后对照可以看出规则的作用：原任务中的“性能优化”被拆为三个可独立验收的子任务，每个子任务只有一名负责人和一条验收标准，依赖关系明确。原任务描述中提到的“评估是否需要调整缓存策略”属于方案层面的判断，写入第一个子任务的描述作为分析内容，不单独设为工作项；如果评估结论需要新增改造范围，则归入项目范围变更流程处理，不在子任务层级自行扩展。
这个示例的可检查性体现在：任取一个子任务，评审人都能对照验收标准判断是否完成，也能根据依赖和截止时间判断排期是否合理。规则是否被正确执行，用下一节的检查清单即可验证。
完成检查：拆分规则是否可执行的核对项
检查清单有两个使用场景：规则发布前，用典型任务试拆并逐项核对，验证规则本身是否可执行；日常拆分后，由评审人核对，判断本次拆分是否合格。核对项如下：
- 层级是否控制在任务—子任务两级，是否存在第三级工作项？
- 每个子任务是否只有一名负责人？
- 每个子任务是否只有一条可判断完成的验收标准？
- 颗粒度是否落在1至3个工作日的参考区间？超出区间的子任务是否已继续拆分或说明理由？
- 明显过小的子任务是否已合并？
- 负责人、验收标准、依赖、截止时间四个字段是否全部填写？
- 命名是否统一、可区分，能否从名称看出可交付结果？
- 子任务之间是否存在循环依赖或遗漏的前置条件？
检查不通过时的处理动作需要提前约定，避免评审流于形式：字段缺失或验收标准不可判断的，退回任务负责人补充后重新提交；层级超出的，将多余层级内容移入子任务描述或提交项目范围管理处理；颗粒度明显偏离的，要求继续拆分或合并；存在循环依赖的，由任务负责人调整拆分方式后重新评审。上述问题未处理完成的子任务不进入执行队列，这是检查的阻断条件。
规则试运行1至2个迭代后，建议统计检查不通过的常见原因。如果某一核对项反复触发退回，说明对应的规则条目需要细化，例如颗粒度参考线不适合当前任务类型，或字段要求过重。规则维护人据此修订并发布新版本，让拆分规则随团队实际执行情况持续校准。
常见问题
团队任务类型差异很大，颗粒度参考线需要统一吗？
参考线可以统一，判断方式需要留出调整空间。1至3个工作日是通用起点，调研、探索类任务以“输出可评审的结论文档”为完成标志，周期略长同样合格；配置、脚本类任务半天完成也不违规。规则里建议写明：周期与可检查结果绑定，超出参考区间的子任务需在评审时说明理由，而不是简单按天数一刀切。
探索性任务结果不确定，无法按标准拆分怎么办？
这类任务走例外审批：由任务负责人向规则维护人说明原因，提出替代的跟踪方式，例如以阶段性结论或时间盒作为检查点，批准后记录在案。例外记录要定期回看，同类例外反复出现时，说明颗粒度标准或验收方式需要针对该任务类型补充条款，而不是长期靠个案审批维持。
拆分规则发布后，如何判断它真的在被执行？
看两个可观察的信号：评审退回的原因分布，以及子任务字段的完整率。如果退回集中在“验收标准不可判断”或“字段缺失”，说明规则条目本身清楚但执行不到位，需要加强评审环节；如果退回集中在颗粒度判断上，说明参考线不适合当前任务类型，应修订规则。试运行1至2个迭代后做一次统计，比凭感觉判断更可靠。
子任务执行中范围变大，是否可以在子任务层级继续拆？
不建议在子任务层级自行扩展。执行中发现新增改造范围时，先判断它是否属于原任务的目标：属于原目标内的细化工作，写入子任务描述或验收标准；超出原任务范围的，提交项目范围变更流程处理，由项目管理者决定是否新增任务。这样能保持任务—子任务两级结构稳定，避免层级越拆越深导致状态汇总失真。
小团队也需要这么完整的规则文档吗？
规则的四项构成可以保留，文档形式可以简化。小团队可以把层级边界、颗粒度判断问题和必填字段写成一页说明，评审环节由任务负责人之间互查代替专门评审人，例外审批由项目管理者兼任。关键是四项内容都有明确答案，并且检查清单能实际用起来；随着团队规模扩大，再补充角色分工和流程细节。
