子任务是相对父任务而言的下一级可执行工作项，用来把父任务要达成的结果拆成若干可独立交付、可指派、可判断完成的小工作项，并继承父任务的目标与上下文。本文围绕定义、判定条件、适用边界、组成结构与一个拆分示例展开，帮助初次接触任务管理的读者准确使用这个概念。
要点总览（TL;DR）
- 子任务是父任务下一级的可执行工作项，继承父任务的目标与上下文，回答“这件事具体怎么落地执行”。
- 合格子任务需同时满足可执行、可指派、可独立判断完成三个条件，缺一项就会在流转或验收时出问题。
- 子任务面向执行推进；项目交付范围的分解归WBS与项目范围管理，需求层级归需求管理，逐条核对归检查项。
- 子任务通常保持两到三层，包含负责人、截止时间、优先级、验收标准和依赖关系；完成情况汇总为父任务进度。
- 拆分粒度以“拿到就能动手”为准，把操作步骤设为子任务会让进度汇总失真，步骤级内容放进检查项更合适。
子任务是什么：一句话定义与三个判定条件
子任务是父任务的下级工作项。父任务描述“要达成什么结果”，子任务回答“这件事具体怎么落地执行”。一个父任务可以对应多个子任务，这些子任务合起来构成父任务的执行路径；子任务从属于父任务，脱离父任务单独存在时，它往往就变成了一个普通任务。
判断一个工作项是否构成合格的子任务，可以看三个条件是否同时成立：
- 可执行：拿到这个工作项的人知道第一步做什么、产出什么，不需要再向下拆一层才能动手。
- 可指派：有明确且唯一的负责人，能够落到具体的人或角色上，而不是“大家一起做”。
- 可独立判断完成：存在一个清晰的完成标志，比如交付物已提交、评审已通过、配置已生效，负责人和验收方对“做完了没有”能形成一致判断。
三个条件缺一不可。只满足可执行但无人负责，工作项会在流转中悬空；只满足可指派但没有完成标准，父任务就无法判断进度。除这三个条件外，子任务还继承父任务的目标与上下文：它服务于父任务要达成的结果，并沿用父任务所处的项目、迭代、优先级背景，避免执行时偏离方向。
子任务的边界：哪些内容不该放进子任务
子任务面向可执行的工作项，它的作用范围止于“把一件已确定要做的事拆到能动手的程度”。超出这个范围的内容，属于其他管理对象，放进子任务会造成职责混淆。
项目交付范围的分解归项目范围管理。工作分解结构（WBS）回答的是“项目要交付哪些东西”，它的分解对象是交付物、阶段或目标，产出的是范围基线与进度计划的依据。子任务不承担范围基线的建立与维护，也不负责范围变更的审批。把 WBS 的层级直接当作子任务层级使用，会让执行层的工作项背负范围管理的职责，变更时难以区分是范围调整还是执行调整。
需求层级归需求分解与需求管理。需求条目描述“系统应当具备什么能力”，需求分解处理的是需求之间的父子关系、优先级与变更影响。子任务是需求落地过程中的执行动作，一个需求条目可能对应多个子任务，但子任务本身不构成需求层级的一环，也不承担需求变更的评审与追溯职责。
可以用一份排除清单帮助判断：
- 交付物清单、阶段划分、范围基线——归项目范围管理。
- 需求条目、需求父子关系、需求变更记录——归需求管理。
- 验收清单中的逐条勾选项——归检查项，不单独设为子任务。
- 会议纪要、背景说明、参考链接——作为子任务的描述或附件，不构成独立子任务。
子任务如何组成：层级、字段与状态流转
在任务结构中，父任务与子任务构成上下级关系。常见做法是保持两到三层：父任务下挂子任务，子任务一般不再继续向下拆；如果某个子任务仍然无法直接执行，说明拆分粒度还不够，应回到父任务层面重新划分，而不是无限加深层级。层级过深会让进度汇总和责任归属变得难以追踪。
一个可用的子任务通常包含以下要素：
| 要素 | 作用 | 写法提示 |
|---|---|---|
| 负责人 | 明确由谁推进 | 落到具体的人或角色，避免多人共同负责 |
| 截止时间 | 约束完成节奏 | 与父任务的交付时间对齐，留出汇总与验收余量 |
| 优先级 | 支持多子任务并行时的排序 | 相对父任务内部排序，不必与全项目优先级混用 |
| 验收标准 | 判断是否完成 | 写成可核验的结果，如“接口联调通过并留存记录” |
| 依赖关系 | 标明子任务之间的先后 | 强依赖要显式标注，避免并行推进时互相等待 |
状态与进度方面，子任务的完成情况汇总为父任务的进度。常见处理方式是：父任务进度由子任务完成比例推算，全部子任务完成后父任务才具备完成条件；父任务的状态不因单个子任务完成而直接关闭，但可以在子任务全部完成时提示进入验收。父子状态是否自动联动，取决于团队采用的工具与流程约定，关键是让“子任务完成”和“父任务可交付”之间的判断口径保持一致，避免子任务全部打勾而父任务实际结果未达成。
当团队在工具中承载这套结构时，需要的是工作项的父子关系、负责人指派与进度反馈能够连贯运转。ONES Project 支持围绕项目计划、工作项和迭代安排协同工作，帮助团队及时了解任务状态、项目进展和待处理事项；其任务工时统计可用于估算任务持续时间，看板、燃尽图等工具用于掌握当前进度。ONES 瀑布项目管理方案提供从项目到任务的多层级管理能力，支持自下而上的进度反馈和自上而下的进度监控，并可为任务设置前后置依赖。这些能力对应的是拆分之后的执行与跟踪环节，拆分规则本身仍由团队按上述判定条件确定。
子任务与WBS工作包、需求条目、检查项的区别
这几个概念经常被混用，原因在于它们都表现为“把大东西拆成小东西”。区别在于管理目的和归属不同，用同一口径对照更容易看清。
| 对照项 | 管理目的 | 归属 | 完成判定 |
|---|---|---|---|
| 子任务 | 把父任务的执行落地到人 | 任务管理 | 验收标准达成，负责人交付结果 |
| WBS 工作包 | 界定项目交付范围与计划依据 | 项目范围与进度管理 | 工作包对应的交付物完成并纳入基线 |
| 需求条目 | 描述系统应具备的能力及其层级 | 需求管理 | 需求验收通过，变更受控 |
| 检查项 | 核对某个动作是否逐条落实 | 任务内部的清单 | 逐条勾选，通常不单独指派 |
粒度上，子任务要求可指派、可独立判断完成；检查项更细，往往依附于某个子任务内部，用于确认步骤是否执行到位，一般不单独设置负责人和截止时间。层级上，需求条目可以有自己的父子结构，子任务则挂在任务之下，两者不在同一棵树上。管理目的上，WBS 工作包服务于范围基线与计划编制，子任务服务于日常执行推进。
同一件事在不同管理对象下有不同表达。以“上线新支付方式”为例：在范围管理中，它是一个工作包，对应交付物“支付方式上线”；在需求管理中，它可能拆为“支持新支付渠道”“支持退款”等需求条目；在执行层面，它被拆为若干子任务，如“完成渠道对接开发”“完成支付回归测试”。选用时先问自己要解决什么问题：定范围用 WBS，管能力用需求条目，推执行用子任务，做核对用检查项。
一个具体例子：把“上线新支付方式”拆成子任务
以下为演示情景，用于说明拆分过程，不代表真实项目。
父任务描述为：“上线新支付方式，使线上订单可使用该方式完成支付，并在上线后一周内支付成功率达到约定水平。”这个描述给出了结果和判断口径，但没有说明谁在什么时候做什么，需要拆成子任务。
一种可行的拆分如下：
- 完成支付渠道接口对接，负责人为后端开发，完成标准为联调环境下单支付成功并留存日志。
- 完成收银台页面改造，负责人为前端开发，完成标准为收银台展示新方式并通过交互验收。
- 完成支付回归测试，负责人为测试，完成标准为回归用例全部执行、缺陷关闭并输出测试报告。
- 完成上线配置与灰度发布，负责人为运维，完成标准为配置生效、灰度订单支付成功。
- 完成上线后支付成功率监控，负责人为数据或运营，完成标准为监控看板可查看并按约定口径输出首周数据。
判断粒度是否合适，可以逐个检查：每个子任务是否有唯一负责人、是否有可核验的完成标准、是否还需要再拆一层才能动手。如果“完成支付回归测试”仍然让人不知道从哪开始，可以把它拆为“编写回归用例”和“执行回归并跟踪缺陷”，但拆到这一步就应停止，继续细化为“打开测试环境”“点击支付按钮”就进入了检查项的范围。
这个例子也对应几类常见误解：
- 把子任务当备注。“注意支付安全”“关注用户体验”不是子任务，它们没有负责人和完成标准，应写入父任务描述或验收要求。
- 拆得过细。把每个操作步骤都设为子任务，会让进度汇总失真、维护成本上升；步骤级内容放进检查项更合适。
- 强依赖未标注。回归测试依赖接口对接完成，灰度发布依赖测试通过，如果不标注依赖，多个子任务并行推进时会出现等待与返工。
- 子任务与父任务目标脱节。拆出的子任务如果无法回答“它为父任务的哪个结果服务”，说明拆分偏离了父任务的目标与上下文，需要回到父任务重新确认。
按上述条件拆完后，父任务的进度就有了可汇总的依据：各子任务按负责人推进，完成标准逐项核验，父任务在全部子任务达成后进入验收。团队若在 ONES 中承载这类结构，可借助工作项的多层级管理与进度反馈，把子任务的完成情况汇总到父任务和项目层面，使拆分结果在后续跟踪中保持可读。
常见问题
父任务只有一个子任务，还有必要拆吗？
可以拆，但要先确认拆分带来了什么。如果这个子任务有独立的负责人、独立的完成标准，并且需要与父任务的其他工作分开跟踪，那么单独设一个子任务是有意义的，父任务的进度也能因此获得明确的反馈点。
如果拆出来的子任务与父任务在负责人、完成标准上完全一致，只是换了个说法，那么它没有增加管理信息，直接保留父任务即可。判断标准是：拆完后是否多出了可指派的对象或可核验的完成标志。
子任务之间互相等待，进度一直卡住怎么办？
先确认依赖是否被显式标注。子任务之间的强依赖如果没有写出来，执行者会按各自节奏推进，等到需要对方产出时才发现阻塞。把“谁等谁”写进依赖关系，是解决这类问题的第一步。
其次看拆分是否合理。如果多个子任务串成一条长链，任何一环延迟都会传导到父任务，可以考虑把可以并行的部分独立出来，或把长链中的关键环节提前安排。依赖关系本身不会消除等待，它的作用是让等待变得可见、可提前协调。
子任务全部完成了，父任务可以直接关闭吗？
不建议直接关闭。子任务完成说明各项执行动作已交付，父任务是否达成还要回到它自己的目标描述去核对：父任务要求的结果是否已经出现，验收标准是否满足。
常见做法是子任务全部完成后，父任务进入验收环节，由父任务的负责人或验收方确认结果，再关闭父任务。这样能避免出现子任务逐项打勾、父任务的实际结果却没有达成的错位。
需求变更后，已经拆好的子任务怎么处理？
先判断变更影响的是需求本身还是执行方式。如果需求条目发生实质性调整，受影响的子任务需要重新确认目标与验收标准，无法继续服务的子任务应关闭或改写，而不是在原工作项上勉强推进。
如果只是执行方式变化，比如换一种实现路径，子任务的目标和完成标准通常仍然成立，调整负责人或截止时间即可。需求变更的评审与追溯归需求管理，子任务层面承接的是变更后的执行安排。
团队刚开始用子任务，有没有简单的落地顺序？
可以先从少量父任务试点：挑选目标描述清楚、交付结果可判断的任务，按可执行、可指派、可独立判断完成三个条件拆一次，观察拆分后的跟踪是否顺畅。
试点阶段重点确认两件事：子任务的完成标准是否被负责人和验收方一致理解，父任务进度是否能从子任务完成情况中读出来。这两点稳定后，再逐步扩大适用范围，并约定层级深度和依赖标注的团队习惯。
