需求层级图和任务分解图看起来都在“拆”，实际回答的是两个不同问题：前者说明一个需求由哪些子需求构成、归属哪条需求线，节点是需求；后者说明一项工作如何拆到可分配、可交付的粒度，节点是任务或工作项。本文按节点对象、拆分依据、父子关系含义和变更影响逐项对照，并给出两张图衔接与选用的方法。
要点总览（TL;DR）
- 需求层级图的节点是需求，按业务归属和需求粒度拆分，回答“这个需求由哪些子需求构成、归属哪条需求线”。
- 任务分解图的节点是任务或工作项，按可交付成果、执行步骤、责任人和工期拆分，回答“谁在什么时间做什么、依赖谁”。
- 两张图最容易被忽略的差别在父子关系含义：需求层级表达覆盖与归属，任务分解表达执行责任与依赖。
- 衔接方式是需求层级定范围、任务分解承接执行，一个需求对应多个任务，需求变更时先改层级再同步任务。
- 范围不清时先画需求层级图，进入排期执行时再画任务分解图，多数项目两者并用并按检查点核验对应关系。
一句话区分：节点对象与拆分依据不同
需求层级图的核心是“需求构成”。它把业务目标、产品需求、子需求按归属关系组织起来，读者看到的是范围：这条需求线覆盖了什么，某个需求属于哪个目标或主题，哪些子需求共同支撑父需求。拆分依据是业务归属和需求粒度，判断标准是子需求是否被父需求覆盖。
任务分解图的核心是“执行安排”。它把一项交付拆成若干可执行的工作项，读者看到的是责任与节奏：谁负责、预计多久、依赖哪项工作、完成到什么程度算交付。拆分依据是可交付成果、执行步骤、责任人和工期，判断标准是节点能否被分配、估算和验收。
两张图回答的问题不同：需求层级图回答“这个需求由哪些子需求构成、归属哪条需求线”，任务分解图回答“谁在什么时间做什么、依赖谁”。同一个需求可以出现在两张图里，但它在需求层级图中是范围节点，在任务分解图中则被展开为若干执行节点，两者身份不同。
同口径差异对照表
下表用同一组维度对照两张图，便于逐项核对。表中描述的是两类图的典型用法，具体层级深度和展示形式取决于团队约定与管理工具的实现，不宜当作固定标准。
| 对照维度 | 需求层级图 | 任务分解图 |
|---|---|---|
| 节点对象 | 需求、子需求，可上接目标或主题 | 任务、工作项，可细分为子任务 |
| 层级构成 | 通常为目标/主题层、需求层、子需求层，深度按需求复杂度确定 | 通常为交付物层、任务层、子任务层，深度按执行需要确定 |
| 父子关系含义 | 子需求被父需求覆盖，父需求完成以子需求交付为前提 | 父任务由子任务共同完成，子任务完成推动父任务推进 |
| 拆分依据 | 业务归属、需求粒度、覆盖范围 | 可交付成果、执行步骤、责任人、工期 |
| 变更影响 | 改动父需求或子需求会改变范围与覆盖关系，需要重新确认验收口径 | 改动任务会改变排期、责任分配和依赖关系，需要重新评估进度 |
| 主要使用角色 | 需求负责人、产品经理、业务方 | 执行负责人、设计研发测试人员、项目经理 |
| 常见误用 | 把任务塞进需求层级，导致范围图变成任务清单 | 把需求原样当任务，导致任务颗粒度过粗、无法分配 |
从表中可以看出，两张图在“父子关系含义”上的差别最容易被忽略：需求层级的父子关系表达覆盖与归属，任务分解的父子关系表达执行责任与依赖。把两者混用，往往会出现需求图里全是任务、任务图里全是需求标题的情况，两张图都失去判断价值。
需求层级图的层级构成与父子关系怎么表达
需求层级图通常按三层组织：目标或主题层说明为什么做、服务哪条业务线；需求层说明做什么，是范围管理的基本单位；子需求层说明一个复杂需求由哪些部分构成。层级数量按需求复杂度确定，简单需求可以只有需求层，复杂需求才向下展开子需求。
父子关系可以用三种方式表达，团队选一种并保持一致即可：
- 连线方向：从父需求指向子需求，表示归属与覆盖，避免双向箭头造成歧义。
- 编号或缩进：用层级编号（如 1、1.1、1.1.1）或缩进表达从属，适合文档和列表形式。
- 父子字段：在需求条目上直接填写父需求字段，适合在管理工具中维护，便于筛选和汇总。
父子关系的判定规则可以归纳为两条：子需求的交付内容应被父需求覆盖，父需求不应包含子需求之外未说明的范围；父需求的完成以子需求交付为前提，子需求未完成时父需求不能标记完成。按这两条检查，可以快速发现层级图中的挂错和漏挂。
需要区分的是，需求层级图讲的是归属关系，跨对象的需求追溯与覆盖管理涉及需求到设计、开发、测试的追踪，属于另一个主题，本文不展开。
任务分解图的拆分逻辑与常见误用
任务分解图按执行需要拆分，常见依据有四类：按可交付成果拆，每个节点对应一个可验收的产出；按执行步骤拆，按流程先后组织节点；按责任人拆，让每个节点有明确负责人；按工期拆，把长周期工作切成可跟踪的短周期任务。实际使用时往往组合其中两三类依据。
合格的节点应满足三个条件：可分配，有明确负责人；可估算，能给出工作量或工期；可验收，完成标准可以判断。只满足其中一两个条件的节点，通常还需要继续拆分或补充说明。
常见误用包括：
- 把需求层级原样当任务清单，需求标题直接变成任务，颗粒度过粗，无法分配和估算。
- 任务节点中混入需求节点，同一张图里既有范围又有执行，读者无法判断哪个节点代表交付。
- 层级过深，子任务套子任务，维护成本上升，进度汇总反而失真。
任务拆解的详细方法与团队组织方式属于另一个主题，本文只说明它与需求层级的边界：需求层级确定做什么和范围边界，任务分解确定怎么做和由谁做。
两张图如何衔接：从需求层级到执行分解
两张图在同一项目中的衔接关系可以概括为：需求层级确定范围，任务分解承接执行。一个需求通常对应多个任务，一个任务通常归属一个需求，这条对应关系是两张图保持一致的锚点。
衔接流程可以按以下步骤执行：
- 需求负责人先维护需求层级，确认父需求与子需求的覆盖关系，明确验收口径。
- 进入排期时，执行负责人按需求逐项拆分任务，为每个任务指定负责人、工期和依赖。
- 用关联字段或引用关系把任务挂到对应需求上，确保每个任务都能回溯到需求，每个进入执行的需求都有任务承接。
- 需求变更时，先修改需求层级，确认范围变化，再评估受影响的任务，调整任务分解和排期。
- 交付评审时，同时检查需求是否按层级完成、任务是否按对应关系关闭。
角色分工上，需求负责人维护层级与范围，执行负责人维护任务分解与进度，两者在需求变更和排期节点上对齐。以 ONES 为例，复杂需求可利用「子工作项」拆解并关联研发和测试任务，迭代规划阶段设计、研发、测试人员可用子任务拆分需求，团队成员围绕迭代需求完成自己拆解的任务并通过看板管理状态。这类能力承载的是需求与任务之间的关联管理动作，具体关联字段的配置方式需按团队实际设置确定。
适配场景与选择建议
需求范围不清、多个业务方对归属有分歧、需要对齐“这条需求线覆盖什么”时，优先画需求层级图。它的产出是范围共识：目标、需求、子需求的覆盖关系，以及每个需求的验收口径。
进入排期与执行、需要分配责任与工期、需要跟踪依赖和进度时，优先画任务分解图。它的产出是执行计划：任务清单、负责人、工期、依赖关系和完成标准。
多数项目需要两者并用，维护顺序建议为：先定需求层级，再拆任务；需求变更时先改层级，再同步任务。并用时设置三个检查点：排期前检查每个执行需求都有任务承接，执行中检查任务与需求的对应关系未断，交付前检查需求层级完成情况与任务关闭情况一致。
核验方法可以直接抽查：
- 抽查若干父需求，确认其子需求覆盖完整、没有挂错层级。
- 抽查若干任务，确认都能回溯到具体需求，没有孤立任务。
- 抽查若干需求，确认进入执行的需求都有对应任务，没有只停留在层级图中的需求。
按这三项抽查，基本可以判断两张图是否各司其职又保持衔接。若抽查中发现需求图里出现大量任务节点，或任务图里只有需求标题，说明两张图的边界需要重新梳理。
常见问题
需求层级图里的父子关系和任务分解图的父子关系，判断标准有什么不同？
需求层级的父子关系看覆盖：子需求的交付内容应被父需求覆盖，父需求完成以子需求交付为前提，判断的是范围是否完整、归属是否正确。任务分解的父子关系看执行：父任务由子任务共同完成，子任务完成推动父任务推进，判断的是责任是否落实、依赖是否清楚。同一个父需求下的子需求，可能对应任务分解图里的多个任务，两张图的父子节点并不一一对应。
需求层级图一般画几层比较合适？
层级数量按需求复杂度确定，没有统一层数要求。简单需求可以只有需求层，复杂需求才向下展开子需求，必要时上接目标或主题层。判断标准是每一层是否承担了不同的管理作用：目标层说明为什么做，需求层说明做什么，子需求层说明复杂需求由哪些部分构成。如果某一层只是把上层标题换个说法，这一层就没有必要保留。
任务分解图里可以直接放需求节点吗？
不建议混放。任务分解图的节点应满足可分配、可估算、可验收三个条件，需求节点通常颗粒度较粗，无法直接分配和估算。把需求标题原样当任务，往往导致任务无法落到具体负责人，进度也无法判断。更稳妥的做法是保留需求与任务的关联关系，让每个任务能回溯到需求，同时让任务图只承载执行节点。
需求变更后，两张图应该按什么顺序更新？
先改需求层级，再改任务分解。需求变更首先影响的是范围和验收口径，需求负责人确认父需求与子需求的覆盖关系后，执行负责人再评估受影响的任务，调整负责人、工期和依赖。如果顺序反过来，先改任务再补需求，容易出现任务做了但需求范围没有确认的情况，交付评审时难以判断完成标准。
在 ONES 中如何承载需求与任务的关联？
ONES 的资料提到，复杂需求可利用「子工作项」拆解并关联研发和测试任务；迭代规划阶段，设计、研发、测试人员可在需求与验收标准达成一致后用子任务拆分需求，团队成员围绕迭代需求完成自己拆解的任务并通过看板管理状态。这些能力对应的是需求与任务之间的关联管理动作，具体关联字段和层级配置方式需按团队实际设置确定。
