子任务是相对父任务而言、从一项较大工作中拆出的可独立执行与验收的工作项。它继承父任务的目标与上下文，拥有自己的负责人、状态和完成条件。本文说明子任务的定义、适用边界、父子状态与验收机制，并用“上线新版本”的演示示例讲清拆到什么程度合适。
要点总览（TL;DR）
- 子任务是从父任务中拆出、可单独指派与验收的工作项，具备父任务归属、独立负责人和状态、明确完成条件三个特征。
- 子任务只承载可执行的工作片段；项目范围划分、需求层级和个人待办应留在各自层面处理。
- 父任务进度通常由子任务状态汇总，父任务负责人仍需保留整体验收职责，避免机械聚合掩盖遗漏。
- 拆解按交付物或角色交接点进行，每条配单一负责人和可检验的完成条件，拆到数天可完成即停止。
- 常见误区包括把提醒当子任务、拆到动作级、父子责任不清，三者都会削弱跟踪价值。
子任务是什么：一句话定义与三个关键特征
子任务是从一个父任务中拆分出来、可以单独指派、单独推进、单独验收的工作项。判断一项工作是不是子任务，可以看它能否回答三个问题：谁来做、做到什么程度算完成、完成后归到哪件更大的事情上。三个问题都有明确答案，它才具备子任务的基本形态。
与普通待办相比，子任务有三个关键特征：
- 有父任务归属。子任务始终挂在一项父任务之下，父任务提供了它存在的理由和上下文。脱离父任务的条目，更接近独立任务或个人待办。
- 有独立负责人和状态。子任务可以指派给具体的人，拥有自己的进行状态，不必等父任务统一推进。这让并行协作成为可能：几个人同时处理同一父任务的不同部分。
- 有明确完成条件。子任务的完成不取决于“做了一些工作”，而取决于预设的交付物或验收标准是否达成。完成条件写在子任务上，验收时才有依据。
父任务与子任务的完成关系通常是聚合关系：父任务的完成取决于其子任务是否全部达成。这意味着父任务更像一个容器和进度汇总点，子任务才是实际被执行和验收的单元。需要说明的是，父任务是否在子任务全部完成后自动关闭，取决于团队约定的流程规则；在管理方法层面，可以要求负责人对父任务做一次整体确认，避免机械聚合掩盖遗漏。
子任务的边界：哪些内容不该放进子任务
子任务针对的是可执行的工作项。把不属于执行层的内容塞进子任务，会让层级混乱、责任模糊。以下四类内容需要特别区分。
- 项目交付范围的划分。项目要交付哪些成果、分几个阶段、各阶段覆盖什么范围，属于项目范围与工作分解结构的层面。子任务回答的是“这件事怎么落地”，不承担“项目做多大”的决策。
- 需求分解与需求层级。需求条目描述的是“要做什么、为什么做”，可以有自己的层级和优先级。把需求直接当成子任务，会混淆“要什么”和“怎么做”两类对象。合理的做法是让需求关联到执行它的任务，再由任务拆出子任务。
- 个人待办清单项。个人清单服务于自我提醒，条目可以很随意，完成与否只对自己负责。子任务处在团队协作的上下文中，有归属、有交接、有验收，两者的严肃程度不同。
- 无限加深的层级。子任务之下再拆子任务，在个别复杂工作中可以接受，但层级越深，跟踪成本越高、汇总越失真。多数情况下，拆到“一个人能在数天内独立完成并交付”这一层就应停止。
一个实用的判断口径是：如果一条内容无法指派给单一负责人，或者无法写出可检验的完成条件，它大概率不该作为子任务，而应回到任务、需求或范围层面处理。
子任务如何组成：父子结构、状态与验收关系
子任务的运行依赖三层机制：层级结构、状态联动和验收标准。三者配合，拆解后的信息才能在团队中顺畅流转。
父子层级结构把一项工作组织成树形：父任务承载目标、背景和整体交付时间，子任务承载具体的执行片段。父任务上保留全局信息，子任务上写清局部要求，执行者看子任务就能开工，不必反复追问背景。
状态联动让父任务的进度由子任务汇总而来。常见的做法是：子任务未开始、进行中、已完成的状态变化，实时反映到父任务的完成比例上；全部子任务完成后，父任务进入待确认或待验收状态。这样项目经理看父任务就能判断整体进展，不必逐个询问。联动规则需要团队事先约定，例如是否允许父任务在子任务未全部完成时提前关闭。
完成条件与验收标准写在子任务上，意义在于把验收前移到执行层。每条子任务写明交付物是什么、达到什么标准算通过，验收人据此检查，减少“做完了但不符合预期”的返工。父任务层面则保留整体验收，检查各子任务拼起来是否满足原始目标。
拆解粒度直接影响跟踪效果。拆得过粗，子任务仍然无法独立推进，等于没拆；拆得过细，条目数量膨胀，状态更新成为负担，汇总数据也失去参考价值。比较稳妥的经验是：每条子任务对应一个可交付的小成果，周期控制在数天量级，负责人明确到个人。当一项工作涉及多个角色交接时，按交接点拆分通常比按动作拆分更有效。
在工具层面，拆解结果需要落到可追踪的工作项上。ONES 支持把工作项组织成父子层级并跟踪各自状态，ONES Assistant 智能助手可以把自然语言指令转化为 ONES 中可追踪的工作，例如按“将这份 PRD 拆解为需求和任务，并按模块分配负责人”这类指令生成条目；它也能结合项目、工作项、迭代和 Wiki 页面等上下文执行后续操作。拆解结果的具体层级和字段取决于项目设置，团队仍需要对拆分粒度和验收标准做出自己的约定。
子任务与任务、工作包、需求的区别
这几个概念常被混用，原因在于它们都描述“一件工作”。区别在于各自回答的问题不同：任务回答“要完成什么”，子任务回答“这件事由哪些可执行片段组成”，工作包回答“项目范围如何划分到可管理单元”，需求回答“要满足什么”。
| 概念 | 回答的问题 | 层级位置 | 典型负责人 | 完成判断 |
|---|---|---|---|---|
| 父任务 | 这件较大的工作要达成什么目标 | 子任务的上一层 | 任务负责人，对整体结果负责 | 子任务全部达成并通过整体验收 |
| 子任务 | 这件工作由哪些可执行片段组成 | 父任务之下 | 每个子任务一名执行负责人 | 交付物满足写在子任务上的完成条件 |
| 工作包 | 项目范围可以划分到哪个可管理单元 | 项目分解结构的末端 | 包负责人，偏范围与成本管理 | 包内交付范围全部覆盖 |
| 需求 | 产品或业务要满足什么 | 需求层级中，可独立于任务存在 | 需求负责人或产品角色 | 验收标准通过，价值被确认 |
工作包与子任务的差异在拆解目的：工作包服务于范围管理和责任划分，强调“这块归谁、包含什么”；子任务服务于执行推进，强调“这一步谁做、何时算完”。一个工作包之下可以包含若干任务，任务再拆出子任务。
需求与子任务的差异在对象：需求描述要达成的能力或价值，子任务描述为达成它而采取的行动。同一件事在不同层级中的表达方式也不同。以“支持手机号登录”为例，在需求层写作“用户可用手机号加验证码登录”；落到任务层是“完成手机号登录功能开发”；再拆成子任务则是“接口联调”“验证码有效期校验”“异常提示文案确认”等具体动作。三层各自成立，混在一起写就会失去跟踪意义。
一个具体例子：把“上线新版本”拆成子任务
以下为演示情景，用于说明拆解过程，不代表真实项目数据。父任务设定为“上线 V2.3 版本”，目标是在约定日期前完成发布并保证核心功能可用。按交付物和交接点拆分，可得到如下子任务：
| 子任务 | 负责人 | 完成条件 | 状态 |
|---|---|---|---|
| 完成发布清单核对 | 版本经理 | 清单中所有条目确认完毕，遗留项有明确处理结论 | 进行中 |
| 回归测试核心流程 | 测试负责人 | 核心流程用例全部执行，阻断级缺陷清零 | 进行中 |
| 准备发布说明与公告 | 产品运营 | 说明文档评审通过，公告按渠道排期 | 未开始 |
| 执行生产环境发布 | 运维负责人 | 发布完成，监控指标在观察窗口内正常 | 未开始 |
| 发布后问题跟踪 | 值班负责人 | 观察期内问题登记完毕并完成分流 | 未开始 |
这组子任务体现了几个拆解规律：每条都有单一负责人；完成条件可以检验，而不是“做一下测试”这类模糊表述；拆分依据是交付物和角色交接点，而不是把“上线”按时间切成几段。父任务的进度由这五条子任务的状态汇总，版本经理据此判断能否按期发布。
围绕这个例子，有三种常见误解值得纠正：
- 把子任务当备注。在子任务里写“注意兼容性问题”“跟设计确认一下”，这类内容没有负责人和完成条件，只是提醒。它们应作为子任务的描述或检查项，而不是独立子任务。
- 拆得过细。把“执行生产环境发布”再拆成“登录服务器”“执行脚本”“查看日志”等动作，条目数量激增，状态更新变成负担，而跟踪价值有限。动作级细节适合写在子任务的执行说明里。
- 父子责任不清。子任务都完成了，父任务却没人对整体结果负责，导致拼起来不满足原始目标。父任务负责人需要保留整体验收职责，在子任务全部达成后做一次整体确认。
可迁移的规律可以归纳为：先明确父任务的目标和整体验收标准，再按交付物或交接点拆分，每条子任务配单一负责人和可检验的完成条件，拆到数天可完成即停止。按这个顺序操作，子任务才能真正承担起“把大事拆成能推进的小事”的作用。
常见问题
父任务的子任务全部完成后，父任务应该自动关闭吗？
这取决于团队约定的流程规则，没有统一答案。自动关闭的好处是减少手工操作，进度汇总及时；风险是子任务覆盖不全时，父任务被机械关闭，遗漏无人发现。比较稳妥的做法是让父任务在子任务全部完成后进入待确认状态，由父任务负责人对照原始目标做一次整体验收，再决定关闭。若团队对拆解质量有把握，也可以对例行工作采用自动关闭，对跨角色、影响面大的工作保留人工确认。
一项工作拆成子任务后，还需要在子任务下继续拆吗？
多数情况下不需要。子任务再往下拆，层级加深，状态更新和进度汇总的成本随之上升，而跟踪价值有限。判断是否需要再拆，可以看当前子任务能否由一名负责人在数天内独立完成并交付；能，就停在这一层。确实遇到周期长、涉及多个角色交接的复杂子任务，优先考虑把它提升为独立任务重新组织，而不是在原层级上继续加深。动作级细节写在子任务的执行说明或检查项里即可。
子任务的负责人和父任务的负责人可以是同一个人吗？
可以，而且在小团队中很常见。关键不在于是否同一人，而在于两种责任是否都被明确承担：子任务负责人对具体交付物和完成条件负责，父任务负责人对整体结果和最终验收负责。同一人兼任时，仍建议在父任务上写清整体验收标准，在子任务上写清局部完成条件，避免因为是一个人而省略验收环节。当子任务分派给不同成员时，父任务负责人需要主动检查各子任务拼起来是否满足原始目标。
需求已经写得很细了，还需要再拆子任务吗？
通常需要，因为两者回答的问题不同。需求描述要满足什么能力或价值，子任务描述为达成它采取的具体行动。需求写得再细，也未必包含谁来做、何时算完成这类执行信息。合理的衔接方式是让需求关联到执行它的任务，再由任务拆出子任务；子任务的完成情况反过来作为需求验收的执行依据。如果一项需求本身只需一次动作就能完成，也可以直接对应到单个任务，不必强行制造层级。
团队刚开始使用子任务，最容易在哪个环节出问题？
最常见的问题出在拆解粒度和完成条件的写法上。条目拆得过粗，子任务仍无法独立推进；拆得过细，状态更新成为负担。完成条件写成“跟进一下”“处理相关问题”这类表述，验收时没有依据，容易返工。起步阶段可以先约定两条简单规则：每条子任务有单一负责人，完成条件写成可检验的交付物或检查结果；拆到数天可完成即停止。运行一段时间后，再根据实际跟踪效果调整粒度。
