子任务拆分规则的核心，是让每个子任务成为一个人可以独立完成、可以验收、可以估算的工作项。本文用一个假设的“会员登录页改版”演示情景，给出一份从父任务到子任务的完整填写示例，逐项说明拆分依据、字段写法和常见错误，并总结可以迁移到其他任务的拆分规律与适用边界。示例为演示情景，不对应真实客户或实测效果。
要点总览（TL;DR）
- 子任务拆分规则的核心是三条：单一责任人、单一可交付产出、验收标准可逐条核对，本文用“会员登录页改版”演示情景给出完整填写范例。
- 示例把父任务拆成 8 个子任务，每个子任务标注名称、动作、产出、验收标准、估算、依赖和负责人角色，可直接替换内容照填。
- 拆分粒度以“一个角色在一个工作日内推进到可评审状态”为停止条件，继续下切会得到管理成本高于执行价值的碎片。
- 规则适用于目标已确认、产出可预先描述的可执行工作项；项目 WBS 与需求层级管理另属其他范畴，探索型任务可改用时间盒加结论说明。
示例目标：这份拆分示例要解决什么问题
这份示例要回答一个具体问题：拿到一个中等规模的父任务后，如何把它拆成一组字段填写完整、责任清晰、可以直接进入执行状态的子任务。读者照着示例中的表格结构，可以替换成自己的任务内容，得到一份可用的子任务清单。
演示情景设定如下：某产品的会员登录页需要改版，目标是支持手机号验证码登录、增加第三方账号登录入口、优化错误提示，并在改版后保持原有账号体系的兼容。父任务由产品经理提出，涉及设计、前端、后端、测试四个角色，计划在两周内完成。这个规模适合演示拆分方法：它足够复杂，需要多人协作；又足够具体，每个环节都有明确产出。
示例要展示的字段包括：子任务名称、动作描述、可交付产出、验收标准、估算、依赖关系和负责人角色。选择这些字段的原因是，它们共同回答了一个子任务能否被独立执行的问题——谁来做、做什么、做完是什么样、需要多久、受什么前置条件约束。示例还会标注哪些内容被刻意排除在子任务之外，帮助读者理解拆分边界。
完整示例：会员登录页改版拆成 8 个子任务
父任务“会员登录页改版”按可交付产出拆成 8 个子任务。拆分粒度控制在一个角色在一个工作日内可以推进到可评审状态，跨角色的交接点作为子任务边界。下表是填写完整的子任务清单，负责人角色按演示情景设定，实际使用时替换为具体人员。
| 编号 | 子任务名称 | 动作描述 | 可交付产出 | 验收标准 | 估算 | 依赖 | 负责人角色 |
|---|---|---|---|---|---|---|---|
| 1 | 登录页改版需求确认 | 梳理现有登录方式、账号体系约束和本次改版范围，与相关方确认 | 一页需求说明，含范围、不做的事项、兼容要求 | 相关方确认范围无遗漏，明确列出本次不做的内容 | 0.5 天 | 无 | 产品经理 |
| 2 | 登录页交互稿 | 设计手机号验证码登录、第三方登录入口和错误提示的交互流程 | 可点击的交互稿，覆盖正常与异常路径 | 覆盖验证码错误、手机号格式错误、第三方授权失败三类异常；评审通过 | 1 天 | 依赖 1 | 交互设计师 |
| 3 | 登录页视觉稿 | 基于交互稿输出视觉设计，含各状态样式 | 视觉稿及标注文件 | 标注包含间距、字号、颜色值；加载与错误状态齐全；评审通过 | 1 天 | 依赖 2 | 视觉设计师 |
| 4 | 验证码登录接口 | 实现验证码发送、校验和登录态签发接口 | 接口文档与可联调的服务端接口 | 接口文档含请求参数、返回码和错误场景；联调环境可调通 | 2 天 | 依赖 1 | 后端工程师 |
| 5 | 第三方登录接入 | 接入第三方账号授权流程，完成账号绑定与登录态映射 | 可用的第三方登录链路及接入说明 | 授权成功、授权失败、重复绑定三种场景均可正确处理 | 2 天 | 依赖 1 | 后端工程师 |
| 6 | 登录页前端实现 | 按视觉稿实现页面，对接验证码与第三方登录接口 | 可在测试环境访问的登录页 | 页面与视觉稿一致；三类异常提示按交互稿展示；主流浏览器可用 | 2 天 | 依赖 3、4、5 | 前端工程师 |
| 7 | 登录页测试用例与执行 | 编写测试用例并执行，覆盖正常登录、异常提示和兼容性 | 测试用例集与测试报告 | 用例覆盖三类异常路径；报告列出通过项与遗留问题 | 1.5 天 | 依赖 6 | 测试工程师 |
| 8 | 上线检查与发布说明 | 核对上线清单，编写发布说明和回滚方案 | 上线检查单与发布说明 | 检查单逐项确认；发布说明含变更范围与回滚步骤 | 0.5 天 | 依赖 7 | 产品经理、后端工程师 |
子任务之间的先后与并行关系可以这样理解：1 是全局前置，2 和 4、5 可以在 1 完成后并行推进，3 依赖 2，6 需要等 3、4、5 都完成，7 依赖 6，8 收尾。并行安排让设计线和后端线同时展开，缩短整体周期；6 作为汇合点，是风险最集中的位置，需要提前确认三条前置线不会延期。
逐项解释：每个子任务为什么这样拆
按可交付产出拆分，而不是按动作阶段拆分，是这份示例最基本的取舍。如果按“设计阶段、开发阶段、测试阶段”来切，每个子任务内部仍然混着多个角色的工作，验收时说不清谁对什么结果负责。示例中的每个子任务都对应一个可以拿给别人看的具体产出：一页需求说明、一份交互稿、一个可联调的接口。产出物存在，验收就有了对象。
验收标准写成可观察的结果，是第二个关键选择。以子任务 2 为例，“覆盖验证码错误、手机号格式错误、第三方授权失败三类异常”是可以逐条核对的，而“交互体验良好”无法判断是否完成。子任务 4 的验收标准落在“接口文档含请求参数、返回码和错误场景；联调环境可调通”，把文档完整性和可联调性分开写，避免用“接口开发完成”这种模糊表述掩盖未联调的状态。
依赖与阻塞项的标注方式，示例采用“依赖编号”而非文字描述。这样做的原因是依赖关系需要被快速识别：子任务 6 标注依赖 3、4、5，任何人看到编号就知道它前面有三条线，排期时不会误以为它可以提前开始。对于存在外部阻塞的子任务，例如第三方登录接入需要对方开放测试账号，可以在依赖栏补充“外部：第三方测试账号”，把内部依赖和外部阻塞区分开。
被刻意排除在子任务之外的内容同样重要。示例没有把“账号体系兼容性评估”单列为子任务，而是并入子任务 1 的需求确认，因为它是范围判断的一部分，单独拆出来会变成一个没有明确产出的讨论项。“登录页埋点”也没有进入本次拆分，原因是它属于改版后的运营需求，与本次上线的验收标准无关。把这类内容明确写进“不做的事项”，可以防止执行过程中范围悄悄扩大。
拆分后的子任务需要被承载和跟踪，才能让依赖关系、验收标准和负责人真正发挥作用。在 ONES 中，可以把父任务建为工作项，8 个子任务作为其下级工作项逐条录入，将上表中的产出、验收标准和估算写入对应字段，用依赖关系标注 6 对 3、4、5 的前置约束，并在评审时以验收标准逐项核对。这样拆分结果从一张表变成可流转的执行记录，状态变化和阻塞情况在同一处可见。
可迁移规律：换一个任务也能照着拆
从示例中可以提炼出三条基本规则，适用于大多数可执行工作项的拆分。第一条是单一责任人：每个子任务有且只有一个主要负责人，协作方可以列在描述里，但责任不摊薄。第二条是单一产出：一个子任务对应一个可以指认的交付物，产出是文档就交文档，是接口就交可联调的接口。第三条是可验收：验收标准写成别人可以逐条核对的结果，避免“完成”“优化”“完善”这类无法判断的表述。
拆分到多细算合适，示例给出的停止条件是：当一个子任务已经可以由一个角色在一个工作日内推进到可评审状态，并且验收标准可以逐条核对时，就停止继续拆分。继续往下切会得到“写一个函数”“调一次样式”这类管理成本高于执行价值的碎片。反过来，如果一个子任务需要两个以上角色接力、或者验收时要等另一件事完成才能判断，说明它还没有拆到位。
命名与字段填写有几点规范值得沿用。名称用“对象加动作”的结构，例如“登录页交互稿”“验证码登录接口”，读者看名称就知道产出是什么；动作描述写清楚做什么和不做什么；估算保留单位并注明是工作量而非日历时间；依赖只写真正的前置条件，不把所有相关任务都列为依赖。字段填写的共同目标是让一个没参与讨论的人也能读懂这个子任务。
拆分完成后可以用一份检查项自检：
- 每个子任务是否只有一个主要负责人；
- 每个子任务是否对应一个可以指认的产出物；
- 验收标准是否每一条都能被第三方核对；
- 依赖关系是否标注完整，是否存在循环依赖；
- 是否存在需要多个角色接力才能完成的子任务；
- “不做的事项”是否写明，范围边界是否清楚；
- 估算合计与父任务的预期周期是否大致吻合。
适用边界：哪些情况不该用这套拆法
这套规则适用于可执行工作项层面的拆分，也就是已经确定要做、需要分配给具体角色推进的任务。它的前提是目标相对清楚、产出可以预先描述。当任务还处在确定要不要做、做到什么范围的阶段，先用这套方法拆子任务，会把尚未想清楚的问题固化成看似明确的执行项。
项目交付范围的分解属于另一类工作。把整个项目拆成阶段、模块和交付物，形成工作分解结构，归项目范围管理，关注的是范围完整性和交付边界，与本文讨论的单个人可执行的工作项拆分处于不同层级。需求本身的分解与层级管理同样另属一类，它处理的是需求之间的父子关系和优先级，而不是执行分工。本文示例只在父任务已经确定的前提下，讨论如何向下拆到可执行粒度。
探索型任务和强不确定性任务需要替代处理方式。例如“验证某种登录方案是否可行”这类任务，在开始前无法准确描述产出和验收标准，可以改为按时间盒推进：设定一个固定的探索周期，周期结束时交付一份结论说明，写明验证了什么、得到什么证据、建议下一步做什么。用结论说明作为产出，比强行拆成若干执行子任务更符合这类工作的实际形态。对于依赖外部条件、短期内无法推进的部分，单独标注为阻塞项并说明解除条件，比把它拆成多个等待中的子任务更清晰。
判断是否适用这套拆法，可以看两个条件：任务目标是否已经确认，产出是否可以在开始前描述出来。两个条件都满足，按本文示例拆分；任一条件不满足，先解决目标确认或改用时间盒方式推进，再进入执行层面的拆分。
常见问题
子任务拆分到什么程度就该停下来？
可以用两个条件判断：一个子任务能由一个角色在一个工作日内推进到可评审状态，并且验收标准可以逐条核对，就停止继续拆分。继续往下切，会得到“写一个函数”“调一次样式”这类碎片，管理成本超过执行价值。反过来，如果一个子任务需要两个以上角色接力，或者验收时要等另一件事完成才能判断，说明拆得还不够。
验收标准怎么写才算可核对？
把结果写成别人能逐条对照检查的表述。示例中子任务 2 的验收标准是“覆盖验证码错误、手机号格式错误、第三方授权失败三类异常”，每一条都能核对；“交互体验良好”这类表述无法判断是否完成。涉及文档和联调时，把文档完整性与可联调性分开写，避免用“开发完成”掩盖未联调的状态。
外部依赖和内部依赖要分开标注吗？
建议分开。示例用依赖编号标注内部前置关系，例如子任务 6 依赖 3、4、5，排期时一眼能看出它前面有三条线。对于需要外部条件的部分，例如第三方登录接入需要对方开放测试账号，在依赖栏补充“外部：第三方测试账号”，把内部依赖和外部阻塞区分开，解除条件也更清楚。
探索型任务没法预先写清产出，还能用这套规则吗？
可以先确认目标，再决定拆法。这套规则的前提是目标已确认、产出能在开始前描述出来。像“验证某种登录方案是否可行”这类任务，可以改为按时间盒推进：设定固定探索周期，周期结束时交付一份结论说明，写明验证了什么、得到什么证据、建议下一步做什么。用结论说明作为产出，比强行拆成若干执行子任务更贴合实际。
拆分完成后，怎么让依赖和验收标准在执行中真正起作用？
把拆分结果录入可跟踪的工作项，而不是停留在表格里。父任务建为工作项，子任务作为下级工作项逐条录入，产出、验收标准和估算写入对应字段，依赖关系标注前置约束，评审时按验收标准逐项核对。这样状态变化和阻塞情况在同一处可见，拆分结果从一张表变成可流转的执行记录。
