需求复用的核心做法可以拆成三步：先识别哪些需求内容值得沉淀，再在需求评审通过后把可复用部分登记成条目，最后在新建需求时先检索比对，再决定直接引用、改写复用还是重新编写。要让这套做法稳定运转，团队需要统一条目字段和复用判定口径，并明确需求提出人、产品经理、需求负责人和评审人的分工。需求条目登记、检索与引用记录可以由ONES的工作项和文档承载，具体方式按团队现有流程配置。
要点总览（TL;DR）
- 需求复用按“识别—沉淀—调用”三步推进：先定复用单元与分类口径，评审通过后抽取登记条目，新建需求时先检索比对再决定引用、改写或新建。
- 条目登记用最小字段集控制判断成本：编号、名称、业务场景、适用范围、来源需求、版本、责任人和有效期，其中适用范围要写明不适用情形。
- 复用判定用三行表统一口径：适用范围完全覆盖且无实质差异时直接引用，核心逻辑可沿用但有差异时改写复用并记录变更点，差异影响核心逻辑时新建并注明检索结论。
- 分工上让检索和登记各有责任人：需求提出人检索比对，产品经理确认判定，需求负责人审核登记与清理，评审人检查复用来源与差异记录。
- 验证机制看记录而非条目数量：检查条目覆盖率、检索命中后的采用情况、引用链可追溯性和过期清理执行情况，把检索记录与判定结论纳入需求评审必查项。
需求复用先做哪三件事
需求复用从确定“复用单元”开始，而不是从建库开始。复用单元指一条可以被独立检索、判断和引用的需求内容片段，通常对应一个业务对象上的一个场景或一项能力要求。单元划得太粗，条目会变成整篇需求文档，检索时无法判断是否适用；划得太细，条目数量膨胀，维护成本超过复用收益。建议先按业务对象、使用场景、能力域三个维度确定分类口径，再开始抽取条目。
三步流程的顺序不能颠倒：先有分类口径，抽取的条目才能落到一致的位置；先有登记条目，新建需求时的检索才有内容可查。每一步都要有明确的输入、负责人、产出物和完成标志，否则流程容易停在“建了一个库，但没人用”。
| 步骤 | 输入 | 主要动作 | 负责人 | 产出物 | 完成标志 |
|---|---|---|---|---|---|
| 第一步：确定复用单元与分类口径 | 现有需求文档、业务对象清单、产品功能结构 | 按业务对象、场景、能力域划分分类层级；定义什么粒度的内容算一个复用单元；给出命名规则示例 | 需求负责人牵头，产品经理参与 | 分类口径说明与命名规则 | 团队能用同一口径说出某条需求属于哪个分类，且对粒度无争议 |
| 第二步：评审通过后抽取并登记条目 | 已通过评审的需求文档、评审结论 | 从需求中抽取可复用部分，按字段填写条目，标注适用范围与来源需求，提交登记 | 需求提出人或产品经理抽取，需求负责人审核登记 | 登记完成的复用条目 | 条目字段填写完整，来源需求可追溯，审核通过并进入可检索状态 |
| 第三步：新建需求时检索比对再决策 | 新需求描述、复用条目库 | 按业务对象和场景关键词检索；逐条比对适用范围与差异；判定直接引用、改写复用或新建，并记录判定结果 | 需求提出人执行，产品经理确认 | 复用判定记录与新需求内容 | 新需求文档中标注了复用来源或“无适用条目”的检索结论 |
三步中，第二步最容易被跳过。常见情况是需求评审通过后直接进入开发，没有人回头抽取条目，复用库长期为空。把“抽取条目”设为评审通过后的固定动作，并指定需求负责人跟踪，比事后补录更可靠。
复用条目的字段与判定规则怎么定
条目字段的作用是让后来的人在不打开原始需求文档的情况下，也能判断这条内容是否适用于自己的场景。字段不在多，而在每条都填得出来、看得懂。以下八项是建议的最小字段集。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 条目编号 | 按分类前缀加流水号，全局唯一 | 引用和追溯的锚点 |
| 条目名称 | 用“业务对象+场景+能力”描述，避免“通用逻辑”这类模糊命名 | 检索时第一眼判断相关性 |
| 业务场景 | 说明该条目在什么业务动作中产生作用 | 比对适用性 |
| 适用范围 | 写明适用的产品线、渠道、用户角色及明确的不适用情形 | 控制误用 |
| 来源需求 | 原始需求编号或文档链接 | 追溯背景与完整上下文 |
| 版本 | 条目内容每次实质修改递增版本号 | 区分引用的是哪一版 |
| 责任人 | 负责维护该条目的人 | 过期判断和内容更新有人负责 |
| 有效期 | 约定复核时间或失效条件 | 触发定期清理 |
复用判定用一张三行表控制，避免每次凭感觉决定。判定的依据是适用范围是否覆盖新场景、差异点是否影响核心逻辑。
| 判定结果 | 触发条件 | 处理方式 |
|---|---|---|
| 直接引用 | 新需求的业务场景、角色、约束条件均落在条目适用范围内，无实质差异 | 在新需求中引用条目编号，不复制内容；条目本身不修改 |
| 改写复用 | 核心逻辑可沿用，但存在场景、规则或约束上的差异 | 以原条目为基础改写，保留原条目链接，逐项记录变更点 |
| 不复用 | 适用范围不覆盖，或差异已影响核心逻辑，改写成本接近重写 | 新建需求内容，并在检索记录中注明“已检索、无适用条目”及原因 |
改写复用时，差异记录要写成可核对的形式：变更点、原条目内容、新内容、变更原因。保留原条目链接，使后续维护者能看到这条内容的演化路径。只写“根据实际情况调整”无法支撑追溯。
过期与失效条目按有效期处理：到期未复核的条目标记为待确认，检索时提示风险；确认不再适用的条目转为失效状态，保留编号和历史记录但不再出现在默认检索结果中。失效条目直接删除会切断已有需求的引用链，建议保留归档。
角色分工与各环节交付物
需求复用涉及四类角色。分工的关键是让“检索”和“登记”都有明确的责任人，避免所有人都认为别人会做。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求提出人 | 新建需求前执行检索，完成初步比对，提出复用判定建议 | 检索记录与判定建议 | 需求编写启动时 |
| 产品经理 | 确认复用判定，对改写复用的差异点把关，确保新需求逻辑完整 | 确认后的判定结论 | 需求评审前 |
| 需求负责人或资产管理员 | 维护分类口径，审核条目登记，跟踪有效期与清理 | 条目登记结果、清理记录 | 评审通过后登记时；每季度清理时 |
| 评审人 | 在需求评审中检查复用来源是否标注、差异记录是否充分、引用是否准确 | 评审意见 | 需求评审会上 |
交接上有两个关键时点。一是评审通过到条目登记之间，需求提出人或产品经理要把抽取结果交给需求负责人，登记完成才算这一步闭环。二是新需求评审前，产品经理要把复用判定结论交给评审人，评审人据此判断这条需求是站在已有资产上推进，还是重复建设。
在工具层面，复用条目可以作为独立的工作项类型登记，字段用自定义属性承载，来源需求通过关联关系挂接；检索时按业务对象和场景筛选，引用关系留在工作项关联中，差异说明写在需求文档里。这样条目状态、引用关系和变更记录都能在同一个协作空间里查到，减少在多个表格之间同步的成本。
一个完整示例：从旧需求到新需求复用
以下为演示情景，用于说明流程如何落地，不对应真实项目。
背景：某团队已有条目“订单退款-部分退款-按商品行计算退款金额”，来源是上一季度的电商退款需求，适用范围写明“自营渠道、按商品行计价、支持部分退款”。新需求来自线下门店渠道，同样需要部分退款，但计价按整单折扣后分摊，且退款审批需要店长确认。
检索与比对：需求提出人按“退款、部分退款”检索，命中该条目。逐项比对后发现，退款金额计算的核心规则可沿用，但计价方式和审批环节存在差异，差异影响计算输入但不改变退款主流程。判定为改写复用。
字段填写与差异记录：新需求引用原条目编号，保留原条目链接；差异记录写明三项变更——计价口径由商品行价格改为整单折扣分摊、新增店长审批节点、适用范围扩展至线下门店渠道。原条目本身不修改，避免影响已引用它的自营渠道需求。
评审确认：评审会上，评审人核对引用编号与差异记录，确认三项变更均有对应说明，且原条目适用范围未被错误扩大。评审通过后，需求负责人评估这次改写是否产生新的可复用内容，若门店渠道的计价规则具有通用性，则登记为新条目并关联原条目。
怎么判断复用做得好不好
验证复用机制是否运转，看的是记录和行为，而不是条目总数。条目多但无人引用，说明沉淀与调用脱节；引用多但差异记录缺失，说明判定流于形式。以下检查清单可按季度执行。
| 检查项 | 验证方式 | 合格表现 |
|---|---|---|
| 条目覆盖率 | 抽取一段时间内评审通过的需求，检查其中可复用内容是否已登记 | 高频业务场景有对应条目，抽取无明显遗漏 |
| 检索命中情况 | 查看新建需求的检索记录，统计命中条目并实际采用的比例 | 多数新需求有检索记录，命中后有明确判定结论 |
| 来源与差异可追溯 | 随机抽取改写复用的需求，沿引用链回溯到原条目 | 能查到原条目编号、变更点和变更原因 |
| 过期清理执行 | 核对有效期字段与清理记录 | 到期条目已复核，失效条目已归档且未出现在默认检索中 |
| 标签一致性 | 抽查条目分类是否落在既定口径内 | 同类内容归入同一分类，命名符合规则 |
常见失效情形有三类。条目描述过粗，写成整段业务背景，检索时无法判断适用性，应对办法是回到复用单元的粒度要求重新拆分。标签不一致，同一场景被归入不同分类，检索时互相找不到，应对办法是固定分类口径并定期抽查。只登记不调用，条目库持续增长但新需求仍从零编写，应对办法是把检索记录设为需求评审的必查项，让调用成为流程的一部分。
这三类问题的共同点是缺少可核验的记录。把检索记录、判定结论和差异说明作为需求文档的固定组成部分，复用是否发生、发生得是否规范，都能在评审和季度检查中被直接看到。
常见问题
需求复用应该从建条目库开始，还是先做别的？
建议先定复用单元和分类口径，再开始抽取条目。复用单元指能被独立检索、判断和引用的需求内容片段，通常对应一个业务对象上的一个场景或一项能力要求。粒度太粗，条目会变成整篇需求文档，检索时无法判断是否适用；粒度太细，条目数量膨胀，维护成本超过复用收益。
分类口径确定后，团队对“某条需求属于哪个分类、按什么粒度拆分”能形成一致说法，后续登记的条目才会落在可检索的位置上。
什么情况下可以直接引用已有条目，什么时候必须改写？
判断依据是适用范围是否覆盖新场景、差异点是否影响核心逻辑。新需求的业务场景、角色和约束条件都落在条目适用范围内且无实质差异时，可以直接引用条目编号，条目本身不修改。
核心逻辑可沿用但存在场景、规则或约束差异时，按改写复用处理：以原条目为基础改写，保留原条目链接，逐项记录变更点、原内容、新内容和变更原因。差异已经影响核心逻辑、改写成本接近重写时，新建需求内容，并在检索记录中注明已检索、无适用条目及原因。
条目到期后应该删除还是保留？
建议保留归档，不直接删除。到期未复核的条目先标记为待确认，检索时提示风险；确认不再适用后转为失效状态，保留编号和历史记录，但不再出现在默认检索结果中。
直接删除会切断已有需求的引用链，后续回溯改写复用的来源时找不到原条目。归档保留编号，既能控制误用，也能维持追溯关系完整。
团队规模不大，也需要设专门的资产管理员吗？
不一定设专职岗位，但需要有明确的人承担条目登记审核和有效期跟踪这两项职责。小团队可以由需求负责人兼任，关键是把职责写进流程，而不是默认大家都会做。
如果检索和登记都没有指定责任人，常见结果是评审通过后没人回头抽取条目，复用库长期为空。可以由产品经理抽取、需求负责人审核登记，交接时点定在评审通过之后。
复用条目应该登记在需求工具里还是文档里？
取决于团队希望条目承担什么作用。需要按业务对象和场景筛选、跟踪状态和引用关系时，把条目作为独立工作项类型登记更便于检索，字段用自定义属性承载，来源需求通过关联关系挂接，差异说明写在需求文档里。
如果条目以说明性内容为主、更新频率低，放在文档知识库中按分类组织也可以。ONES 的工作项和文档都能承载条目登记与检索，具体方式按团队现有流程配置。无论放在哪里，检索记录和判定结论都应作为需求文档的固定组成部分，便于评审时核对。
