需求层级规范模板：层级定义表与父子挂接检查表

需求层级规范模板用于解决两个常见问题：同一类需求在不同团队被拆到不同层级，以及父子关系挂接随意、子项无人认领。模板由两张可复制表格组成：层级定义表先统一各层级的名称、编号、粒度与责任角色，父子挂接检查表再逐条核对父项与子项的类型、跨度、覆盖、归属和状态。按“先定义、后挂接”的顺序填写，可以让需求分解在同一套口径下进行。

要点总览（TL;DR）

• 模板由两张表组成：层级定义表统一各层级的名称、编号、定义、粒度标准、责任角色和进入下一层的条件；父子挂接检查表逐条核对类型匹配、层级跨度、覆盖关系、唯一归属和状态一致性。
• 填写顺序是先定层级定义表并评审，再抽取存量需求按新口径归位，最后用挂接检查表逐组核对，待修正项闭环后才算完成。
• 层级定义表的定义、粒度标准、责任角色、进入条件，以及挂接检查表的父项子项编号、覆盖关系、唯一归属、检查结果为必填；缺失时先补齐再判定通过。
• 粒度标准和进入下一层的条件最容易写虚，应落到可观察事实，如验收周期、涉及模块数、验收标准是否评审通过。
• 层级增减或字段变更时同步更新编号与边界，保留版本号和变更记录，并按季度或触发条件复核待修正项是否闭环。

可复制空白模板：层级定义表与父子挂接检查表

两张表承担不同任务。层级定义表回答“我们的需求分几层、每层是什么”，父子挂接检查表回答“这一组父子关系挂得对不对”。建议先完成层级定义表并经过评审，再开始填写挂接检查表，避免检查时反复修改层级口径。

表一：层级定义表（空白）

将下表复制到文档或表格工具中，按团队实际层级数量增删行。每一行对应一个层级，从顶层向下排列。

层级编号	层级名称	定义	粒度标准	典型示例	责任角色	进入下一层的条件	备注

表二：父子挂接检查表（空白）

每一行对应一组父子关系。检查结果填写“通过”“待修正”或“不适用”，待修正项需写明问题与修正动作。

检查项编号	父项编号	父项层级	子项编号	子项层级	类型匹配	层级跨度	覆盖关系	唯一归属	状态一致性	检查结果	问题描述与修正动作	检查人	检查日期

填写顺序

1. 由需求管理负责人牵头填写层级定义表，逐层写清定义与粒度标准，组织产品、研发、测试角色评审并确认。
2. 层级定义表定稿后，选取一批已有需求，按定义表重新归位，形成挂接检查的样本。
3. 用父子挂接检查表逐组核对父子关系，记录检查结果与待修正项。
4. 修正完成后复检，将两张表作为团队需求管理的基线资料存档。

字段说明：每一列填什么、怎么判断填对了

字段说明与上表表头逐列对应。填写时以“另一位同事能否只凭这一列做出相同判断”为检验标准，能则说明写法合格。

层级定义表字段

字段	填什么	判断填对的标准
层级编号	层级的固定标识，如 L1、L2、L3，从顶层向下递增	编号唯一、连续，全文引用层级时统一使用编号
层级名称	该层的业务叫法，如“业务需求”“产品需求”“子需求”	名称在团队内无歧义，不与相邻层级混用同一叫法
定义	用一两句话说明这一层描述的是什么对象、解决什么问题	定义能区分本层与上下层，不含“视情况而定”一类模糊表述
粒度标准	该层需求的合适大小，可用验收周期、涉及模块数、可独立交付与否等可观察口径描述	拿到一条需求能据此判断“是否属于这一层”，而不是凭感觉
典型示例	一到两个符合本层粒度的真实或脱敏示例	示例本身符合粒度标准，不把跨层内容混入同一示例
责任角色	对该层需求内容负责的角色，如业务负责人、产品经理、研发负责人	角色可对应到具体岗位，职责是“对内容负责”而非仅“参与评审”
进入下一层的条件	本层需求满足什么条件才允许拆出下一层，如验收标准明确、范围已确认	条件可核验，未满足时拆层应被退回
备注	补充说明，如与其他层级的边界提示	不承载必填信息，缺失不影响层级判断

父子挂接检查表字段

字段	填什么	判断填对的标准
检查项编号	本次检查的序号，如 C-001	与父项、子项编号组合后能唯一定位一组关系
父项编号 / 父项层级	父需求的编号及其在定义表中的层级	编号可回溯到需求条目，层级与定义表一致
子项编号 / 子项层级	子需求的编号及其层级	同上；子项层级应恰为父项的下一层
类型匹配	父项与子项是否属于定义表允许的相邻层级组合	填写“通过”或“待修正”，待修正需说明跨了几层或类型不符
层级跨度	父子之间相隔的层级数	正常应为相邻一层；出现跨层时标记待修正
覆盖关系	子项集合是否完整覆盖父项范围，有无遗漏或超出	能指出遗漏点或超出部分；无法判断时先补范围说明再检查
唯一归属	子项是否只挂在一个父项下	一个子项对应多个父项时标记待修正，并确定主归属
状态一致性	父项与子项的状态是否矛盾，如父项已关闭而子项仍在进行	状态组合符合团队流转规则；矛盾时记录具体状态对
检查结果	通过、待修正或不适用	待修正项必须同时填写问题描述与修正动作
检查人 / 检查日期	执行本次核对的人与日期	可追溯到具体人员，便于复检时对照

粒度标准与进入下一层的条件是最容易写虚的两列。写法上尽量落到可观察的事实：例如粒度标准写成“可在一次迭代内完成验收、涉及不超过两个模块”，进入下一层的条件写成“验收标准已评审通过且范围无待定项”。责任角色写岗位而非人名，人员变动时无需改表；检查人字段则写具体执行人，用于复检追溯。

必填与选填：哪些字段缺失会导致模板失效

两张表的字段并非同等重要。必填字段缺失会让判断无法进行，选填字段缺失只影响信息完整度。下表给出对照与处理方式。

表	必填字段	选填字段	必填缺失的后果与处理
层级定义表	层级编号、层级名称、定义、粒度标准、责任角色、进入下一层的条件	典型示例、备注	缺少定义或粒度标准时，不同角色会给出不同归层判断，模板失去统一口径的作用；应先补齐再评审，未补齐不进入挂接检查
父子挂接检查表	父项编号、父项层级、子项编号、子项层级、类型匹配、覆盖关系、唯一归属、检查结果	层级跨度、状态一致性、问题描述与修正动作、检查人、检查日期	缺少父项或子项编号时无法定位关系；缺少覆盖关系或唯一归属时检查流于形式；应补齐后再判定通过

必填字段缺失时的处理原则是“先补后判”：补齐字段前，该行检查结果不得填“通过”。若因信息尚未明确暂时无法填写，可标记为待修正并写明缺什么、由谁补、何时补，避免以空白行混过检查。

选填字段按场景使用。典型示例在培训新成员、解释层级边界时价值较高，层级稳定后可精简；层级跨度在层级数量较多时建议填写，便于发现跨层挂接；状态一致性在需求流转规则较严格时纳入常规检查；检查人与检查日期在需要复检或审计时填写。选填字段的取舍由团队在模板说明中写明，避免同一团队内有的填有的不填。

填写示例：一个需求从顶层到子项的完整挂接

以下为演示情景，用于说明两张表如何配合，数据不代表真实项目。假设团队采用三层需求结构：业务需求、产品需求、子需求。

层级定义表示例行

层级编号	层级名称	定义	粒度标准	典型示例	责任角色	进入下一层的条件	备注
L1	业务需求	描述业务方希望达成的目标与价值	一个业务目标，可在季度内评估效果	提升新用户首次下单转化	业务负责人	目标与衡量口径确认后	不直接进入开发
L2	产品需求	为实现业务目标而定义的产品能力	可在一次迭代内完成验收，涉及不超过两个模块	新增首单优惠券自动发放	产品经理	验收标准评审通过且范围无待定项	—
L3	子需求	产品需求下可独立交付的组成部分	可由一名研发在数日内完成并单独验证	优惠券发放规则配置	研发负责人	—	最底层，不再拆分

父子挂接检查表示例行

检查项编号	父项编号	父项层级	子项编号	子项层级	类型匹配	层级跨度	覆盖关系	唯一归属	状态一致性	检查结果	问题描述与修正动作
C-001	BR-012	L1	PR-045	L2	通过	相邻一层	覆盖业务目标中的转化环节	仅挂 BR-012	一致	通过	—
C-002	PR-045	L2	SR-101	L3	通过	相邻一层	覆盖发放规则部分	仅挂 PR-045	一致	通过	—
C-003	PR-045	L2	SR-102	L3	待修正	跨一层	子项内容超出父项范围	同时挂 PR-046	一致	待修正	SR-102 实为另一产品需求的组成部分，改挂 PR-046 并补充 PR-045 的覆盖说明

示例中 C-003 暴露了两类常见问题：子项内容超出父项范围，以及一个子项同时挂在两个父项下。修正动作是先确定主归属，再补齐父项的覆盖说明，复检通过后该行才改为“通过”。这说明挂接检查表的价值在于把“看起来挂上了”变成“逐项核对过”。

当层级与父子关系在工具中管理时，规范需要落到具体的工作项结构上。ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务，将需求、研发、测试等环节串联起来；团队也可以根据实际场景自定义工作流，规范需求状态的流转。层级定义表确定的层级与进入条件，可以对应到工作项类型与状态规则；挂接检查表中的类型匹配、唯一归属和状态一致性，则可以在需求评审或迭代规划时按同一口径核对。

调整与维护方法：层级增减、字段变更与定期复核

层级规范不是一次定稿就长期不变。团队规模扩大、业务线拆分或研发流程调整时，模板需要同步更新，否则会出现“表上三层、实际拆四层”的脱节。

层级数量增减的调整步骤

1. 明确调整原因与影响范围，例如新增一层是因为产品需求粒度过粗，还是因为业务与产品职责分离。
2. 在层级定义表中插入或删除行，同步更新层级编号，保持编号连续、引用一致。
3. 修订相邻层级的定义、粒度标准与进入下一层的条件，确保新旧层级之间边界清晰。
4. 抽取一批存量需求按新层级重新归位，用父子挂接检查表核对，记录需要迁移的关系。
5. 发布新版本并通知相关角色，设定过渡期，过渡期内新旧口径并行核对。

字段新增或废弃的处理方式

新增字段应先说明它解决什么判断问题，再决定放在哪张表、是否必填。新增必填字段意味着所有存量行都需要补填，应评估补填成本并安排时间窗口；新增选填字段可先在部分团队试用，稳定后再推广。废弃字段时保留历史记录，在变更说明中注明废弃原因与替代字段，避免旧文档中的字段被继续引用。

定期复核的触发条件与检查范围

复核可分为定期与触发两类。定期复核建议按季度或按版本节奏执行，检查层级定义是否仍与实际拆解一致、必填字段是否普遍填写、挂接检查的待修正项是否闭环。触发式复核在以下情况发生时启动：团队规模明显变化、新增业务线、需求流转规则调整、连续出现同类挂接错误。复核范围至少覆盖层级定义表全表、近期新增需求的父子关系，以及上一轮待修正项的关闭情况。

模板版本与变更记录

模板应保留版本号与变更记录，记录内容包括变更日期、变更人、变更字段或层级、变更原因和生效范围。版本号可采用“主版本.次版本”形式：层级结构或必填规则变化记为主版本，措辞澄清或选填字段调整记为次版本。变更记录与模板放在同一文档中，评审时一并确认，确保使用模板的人能查到当前版本与历史差异。

常见问题

团队只有两三层需求，还需要用这套模板吗？

需要，但可以精简。层级数量少时，层级定义表保留层级编号、名称、定义、粒度标准和责任角色即可，进入下一层的条件可以合并到粒度标准中描述。父子挂接检查表可先保留类型匹配、覆盖关系、唯一归属和检查结果四项，层级跨度在只有两层时意义不大，可列为选填。模板的价值在于让不同角色对“什么算一层”有共同判断，与层级多少无关。

存量需求已经挂错层级，是全部重挂还是分批处理？

建议分批处理，优先处理仍在进行中的需求。先按层级定义表把在办需求重新归位，用挂接检查表核对并记录待修正项；已关闭的历史需求保留原状，在变更记录中说明新旧口径差异即可。全部重挂成本高，且历史数据对当前判断影响有限。若历史需求需要用于追溯或审计，再单独安排一轮核对。

一个子项确实同时服务两个父项，检查表要求唯一归属怎么处理？

先确定主归属，即该子项的主要交付目标属于哪个父项，将其挂在主父项下；另一个父项通过关联或说明的方式引用，并在覆盖关系中注明依赖。若两个父项确实各占一半，说明该子项粒度偏粗，应考虑拆成两个子项分别挂接。检查表中遇到多父项时标记待修正，写明主归属判断和拆分或关联的处理动作，复检通过后再改为通过。

层级定义表评审通过后，新项目可以直接套用吗？

可以套用，但要确认新项目的业务对象和交付节奏是否与定义表一致。若新项目涉及不同业务线或采用不同的迭代周期，粒度标准可能需要调整。建议套用时先做一次小范围试填，用挂接检查表核对几条真实父子关系，确认口径可用后再全面推行。调整部分记入变更记录，避免同一团队出现多个版本并行。

在工具中管理需求层级时，模板里的字段怎么落地？

层级定义表的层级编号与名称可对应到工具中的工作项类型，进入下一层的条件可对应到状态流转规则。ONES 支持对功能复杂的需求使用「子工作项」进行拆解，并关联研发和测试任务；团队也可以根据实际场景自定义工作流，规范需求状态的流转。挂接检查表中的类型匹配、唯一归属和状态一致性，可以在需求评审或迭代规划时按同一口径核对，检查结果记录在评审文档中。