需求父子关联要解决的问题是：一条需求在什么范围内可以被独立交付和验收，以及拆出来的部分如何仍然归属于原来的整体。做法上先定层级深度和拆分粒度，再约定字段与状态规则，明确拆分和确认的角色，最后用检查清单验证父子关系是否闭合。本文聚焦需求层级本身，任务拆解和跨对象追溯不在展开范围内。
要点总览（TL;DR）
- 需求父子关联用“整体—部分”的归属关系表达需求层级，判断拆分粒度的标准是子需求能否独立交付、独立验收。
- 层级深度按交付节奏和验收边界确定，常见两到三层；层数越多，字段维护和状态同步成本越高。
- 拆分责任归产品经理，确认责任归需求负责人，研发和测试分别把关技术可行性与验收条件覆盖。
- 状态联动建议约定为子需求全部完成后父需求才进入待验收，防止父需求提前关闭。
- 用层级完整性、孤儿需求、粒度可验收、字段与状态一致性、变更同步六项检查判断父子关联是否可用，出现阻断项需返工。
需求父子关联的核心做法与操作步骤
建立需求父子关联可以按建层、拆分、挂接、确认四步推进。每一步都要有明确输入、动作、输出和完成标志，否则父子关系容易停留在“看起来挂上了”，实际无法支撑排期和验收。
第一步：确定层级深度与拆分粒度
层级深度按交付节奏和验收边界确定。常见做法是两到三层：顶层是面向业务或用户的目标需求，中间层是可独立排期的功能需求，底层是可独立验收的细分需求。层数越多，字段维护和状态同步的成本越高，三层以上需要有明确的必要性，例如同一功能需要按渠道或终端分别验收。
拆分粒度用“能否独立验收”判断。一条子需求应当有独立的验收标准、独立的完成定义，并且可以在不依赖兄弟需求的情况下判断是否做完。无法独立验收的条目，要么继续拆分，要么并入上级需求，不单独建层。输入是父需求的验收标准和交付范围，输出是一份层级草图，完成标志是每个层级都能说清“这一层交付什么、由谁验收”。
第二步：约定父需求与子需求的字段
父子两层承担不同职责，字段约定要区分开。父需求侧重范围与目标，子需求侧重执行与验收。建议至少约定以下字段：
| 字段 | 父需求 | 子需求 |
|---|---|---|
| 标题 | 描述业务目标或用户价值 | 描述可独立交付的功能点 |
| 验收标准 | 整体验收口径 | 本条子需求自己的验收条件 |
| 负责人 | 需求负责人 | 子需求负责人 |
| 优先级 | 按业务价值排序 | 继承或按父需求内顺序细化 |
| 状态 | 按父需求整体推进 | 按子需求自身进度流转 |
| 关联关系 | 指向所属子需求列表 | 指向父需求 |
字段约定完成后，要明确哪些字段子需求必须填写、哪些允许留空。输入是团队现有的需求模板，输出是父子两套字段规范，完成标志是新建子需求时能按规范填全关键字段。
第三步：挂接子需求并定义状态联动
挂接动作是把拆分出的子需求建立到父需求之下，形成“整体—部分”的归属关系。挂接时要检查三件事：子需求的父级指向唯一、子需求之间不重复覆盖同一范围、父需求的验收标准能由子需求共同支撑。
状态联动规则需要提前写清楚。常见规则是：子需求全部进入完成状态后，父需求才允许进入待验收；任一子需求被阻塞或退回时，父需求保持进行中。这条规则的作用是防止父需求在子需求未完成时提前关闭。输入是层级草图和字段规范，输出是挂接完成的父子结构，完成标志是每条子需求都能从父需求追溯到，且状态规则已配置或已书面约定。
第四步：确认父子关系
确认由需求负责人组织，产品、研发、测试共同参与。确认内容包括层级是否合理、粒度是否可验收、字段是否填全、状态规则是否被理解。确认的输出是一份可执行的父子结构，完成标志是参与方对“拆到哪一层、每层谁验收”达成一致。确认之后，父子关系进入维护阶段，后续变更按角色分工处理。
在工具承载上，ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；同时支持按实际场景自定义工作流，用于规范需求流转。层级深度上限、字段继承和父子状态联动的默认规则，需要按团队实际配置核验后再写入规范。
角色分工与各层交付物
父子关联能否长期维护，取决于每个角色是否清楚自己拆什么、确认什么、交什么。以下分工适用于以需求为交付主线的研发团队，角色名称可按组织实际调整。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求负责人 | 确定父需求范围与整体验收标准，组织父子关系确认，裁决拆分争议 | 父需求条目、整体验收标准、确认记录 |
| 产品经理 | 把父需求拆成可独立验收的子需求，编写子需求验收条件，维护优先级 | 子需求列表、每条子需求的验收条件、优先级排序 |
| 研发负责人 | 评估子需求的技术可行性和拆分合理性，确认子需求之间的依赖，反馈无法独立交付的条目 | 技术可行性意见、依赖说明、拆分调整建议 |
| 测试负责人 | 检查每条子需求是否具备可验证的验收条件，确认父需求验收标准能被覆盖 | 验收条件评审意见、覆盖情况说明 |
拆分责任归产品经理，确认责任归需求负责人，两者分开可以避免“自己拆自己确认”。评审时，产品经理说明拆分依据，研发负责人指出依赖和实现风险，测试负责人核对验收条件，需求负责人对是否进入开发做出结论。变更时，子需求范围内的调整由产品经理提出、需求负责人确认；涉及父需求范围或验收标准变化的，需要重新组织评审，并同步更新受影响的子需求。
父需求与子需求的交付物也要区分：父需求交付的是整体范围和验收口径，子需求交付的是可独立验收的功能结果。父需求不重复描述子需求的实现细节，子需求不擅自扩大父需求未包含的范围。
示例：一条父需求拆成子需求的完整过程
以下为演示情景，用于说明字段填写和状态变化，不代表真实项目数据。
假设父需求为“支持企业客户在线申请发票”，整体验收标准是：客户可在订单页提交开票申请，系统生成开票记录，财务可在后台查看并处理。产品经理按可独立验收的边界拆成三条子需求：
- 子需求 A：订单页增加开票申请入口与表单，验收条件为表单字段完整、提交后有成功提示。
- 子需求 B：生成开票记录并展示申请状态，验收条件为记录可在客户侧查询、状态与实际处理一致。
- 子需求 C：财务后台开票记录列表与处理操作，验收条件为财务可按条件筛选并完成处理。
字段填写上，父需求填写整体验收标准和需求负责人；三条子需求分别填写自己的验收条件、子需求负责人和优先级，父级字段统一指向该父需求。状态变化过程是：父需求进入进行中，三条子需求分别进入开发中；A、B 完成后，C 仍在开发中，父需求保持进行中；C 完成后，三条子需求全部完成，父需求才允许进入待验收。
一次变更演示：开发过程中发现子需求 B 需要增加“开票失败原因展示”，这属于 B 的验收条件变化。产品经理更新 B 的验收条件并通知测试负责人，需求负责人确认该变化不影响父需求整体范围，父需求验收标准不变。若变更涉及新增开票类型，超出父需求原范围，则应新建子需求或调整父需求范围，并重新组织确认，而不是直接改在已有子需求里。
完成检查：父子关联是否可用的核对项
父子关联建立后，用以下清单逐项核对，判断结构是否闭合、可追溯、可维护。检查可在需求进入开发前做一次，在迭代结束前再复核一次。
| 检查项 | 核对内容 | 不通过时的处理 |
|---|---|---|
| 层级完整性 | 每条子需求都有唯一父需求，父需求下的子需求覆盖其验收标准 | 补齐父级指向或补充缺失子需求 |
| 孤儿需求 | 不存在无父级、也不属于任何顶层需求的子需求 | 归入对应父需求或提升为顶层需求 |
| 粒度可验收 | 每条子需求都有独立验收条件，可单独判断完成 | 继续拆分或并入上级需求 |
| 字段一致性 | 关键字段填写完整，父子字段口径不冲突 | 按字段规范补填并统一口径 |
| 状态一致性 | 父需求状态与子需求完成情况相符，未提前关闭 | 回退父需求状态，等待子需求完成 |
| 变更同步 | 子需求变更后，父需求范围和验收标准已同步更新 | 补充同步记录，必要时重新确认 |
阻断项包括：存在孤儿需求、父需求验收标准无法由现有子需求覆盖、子需求无验收条件、父需求在子需求未完成时已关闭。出现任一阻断项，父子关联不能视为可用，需要返工后再进入下一环节。返工条件是阻断项清零，且变更同步记录完整。
在需求池和迭代规划场景中，ONES 可通过业务需求池、产品需求池与工单系统联动业务反馈与产品开发，产品负责人可按优先级把需求规划到迭代，并在迭代计划会议上与团队评审需求。把上述检查项放进评审和迭代复核环节，父子关联才能从一次性拆分变成可持续维护的机制。
常见问题
子需求拆分到什么程度算合适？拆得太细会有什么问题？
判断标准是能否独立验收：一条子需求应当有自己的验收条件，并且在不依赖兄弟需求的情况下可以判断是否做完。拆得太细会带来两类成本：一是字段填写、状态流转和评审的工作量随条目数量增加；二是子需求之间的依赖变多，父需求的状态更难收敛。如果某条内容无法独立验收，可以继续拆分，也可以并入上级需求，不必强行建层。
父需求已经进入开发，中途发现需要新增一块内容，应该新建子需求还是改原有子需求？
看新增内容是否落在父需求原有验收标准之内。属于某条子需求验收条件细化的，由产品经理更新该子需求的验收条件，通知测试负责人，并由需求负责人确认不影响父需求整体范围。超出父需求原范围的新增内容，应新建子需求或调整父需求范围，并重新组织确认，避免把范围扩张悄悄写进已有子需求。
父子关联建立后，日常维护中最容易出问题的地方是什么？
常见问题集中在三处：子需求变更后父需求的验收标准没有同步更新；父需求在子需求未全部完成时被提前关闭；拆分过程中产生没有父级指向的孤儿需求。这三类问题都可以通过迭代结束前的复核发现，处理方式分别是补充同步记录、回退父需求状态、把孤儿需求归入对应父需求或提升为顶层需求。
团队规模较小、需求数量不多时，还需要建立完整的多层父子结构吗？
层级深度按实际交付和验收需要确定，需求数量少、交付边界清晰的团队用两层结构通常就够。层级的价值在于让每条需求都有明确的归属和验收口径，层数本身不是目标。当同一功能需要按渠道、终端或客户类型分别验收时，再考虑增加一层；没有这种需要时，保持较浅的层级可以减少维护成本。
在工具中落地父子关联时，哪些配置需要提前核验？
ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务，也支持按实际场景自定义工作流。落地前建议核验三项配置：层级深度是否有上限、子需求是否继承父需求字段、父子状态联动规则如何设置。这些细节会直接影响前面约定的字段规范和状态规则能否在工具中执行，核验后再写入团队规范更稳妥。
