确定需求重复建设的识别口径，核心是把“重复”拆成可判定的条件：同一业务对象、同一用户任务、同一能力范围，在给定时间窗内被两条及以上需求分别提出或分别建设。完整口径由判定字段、相似度阈值、统计范围、时间窗和严重程度分级五部分组成。先抽取小样本人工标注并校准阈值，再全量统计，最后通过抽样复核确认误判率，结果才能用于合并需求、复用已有能力和调整排期。
要点总览（TL;DR）
- 识别口径由五部分组成：判定字段、相似度阈值、统计范围、时间窗和严重程度分级；缺任何一项，结果都难以复算。
- 判定字段建议固定为业务对象、用户任务、功能点、验收标准、目标用户五类，字段加权与文本相似度组合使用，权重来源写入口径文档。
- 核心公式：重复率=重复需求对数÷需求总对数；重复投入工时占比=重复需求工时÷总需求工时，分母与单位在指标卡上固定标注。
- 阈值先人工标注样本再校准，全量计算后抽样复核；误判率超出预设范围时回到阈值校准环节。
- 重复率是描述性指标，跨团队比较须同口径同时间窗，不宜单独作为团队绩效指标。
评估目标：重复建设要回答投入浪费在哪里
识别重复建设的直接目的，是给研发投入的调整提供依据。度量结果通常服务于三类决策：把内容重合的需求合并为一条、优先复用已有能力而不是重新开发、在排期阶段协调相近需求的交付顺序。口径设计要先对齐这些决策，再决定统计什么、统计到多细。
重复建设对研发投入的影响，可以从三个可观察的方面量化：
- 重复开发工时：两条需求分别投入设计、开发、测试的工时之和，减去合并后本应需要的工时，差额即重复投入。
- 重复维护成本：功能相近但实现分散，后续每次变更需要在多处修改，维护工时随实现数量增加。
- 能力碎片化：同一能力由多个模块分别承载，用户入口、权限、数据口径不一致，带来额外的对齐和治理工作。
口径设计遵循三条原则。可判定，指任意两条需求能否判为重复，依据明确的字段和阈值，不同人按同一规则得出相同结论。可复算，指统计范围、分母、时间窗固定，换人换时间重算结果一致。可复核，指每条判定保留记录、复核人和结论，出现争议时可以回溯到具体证据。
指标与范围：重复率、重复投入占比与分级
核心指标建议设三个，分别回答“有多少对重复”“占比多高”“浪费多少工时”。三个指标共用同一套判定结果，避免各自定义造成口径分裂。
| 指标 | 定义 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 重复需求对数 | 判定为重复的需求对数量 | 重复需求对计数 | 无 | 对 |
| 重复率 | 重复需求对占全部可比需求对的比例 | 重复需求对数 | 需求总对数 | 百分比 |
| 重复投入工时占比 | 重复需求所耗工时占总需求工时的比例 | 重复需求工时 | 总需求工时 | 百分比 |
统计范围需要事先写死。纳入哪些需求状态，例如已评审通过、已进入开发或已上线的需求；纳入哪些产品线或业务域；时间窗按需求创建时间还是按上线时间切分。建议以需求创建时间划定时间窗，因为它对应“提出时是否已知已有能力”这一判断场景；若关注交付浪费，则改用上线时间。两种口径不能混用，跨期比较时必须保持一致。
排除项要单独说明：待处理需求集合的日常管理属于需求池管理范畴，不在本口径内统计；产品线能力布局规划属于产品线管理范畴，也不纳入重复识别。这两类工作有自己的评估方式，混入重复率会稀释指标含义。
严重程度分三档，对应不同处置动作：
| 分级 | 判定特征 | 建议处置 |
|---|---|---|
| 完全重复 | 同一业务对象、同一用户任务，功能点与验收标准基本一致 | 合并为一条需求，保留信息更完整的一条 |
| 高度相似 | 功能点与验收标准大部分重合，目标用户或场景存在差异 | 复用已有能力并做参数化或配置扩展 |
| 部分重叠 | 能力范围交叉，但业务对象或交付形态不同 | 排期协调，明确边界与共用组件 |
数据口径与证据：判定字段和相似度阈值
判定字段决定两条需求“像不像”，建议固定五类字段，并在需求条目上保证可读可查：
| 字段 | 作用 | 判定要点 |
|---|---|---|
| 业务对象 | 区分是否作用于同一实体 | 订单、客户、工单等对象名称与范围一致 |
| 用户任务 | 区分用户要完成的目标 | 任务描述指向同一结果，而非同一界面 |
| 功能点 | 比较实现范围 | 核心操作、输入输出、规则基本重合 |
| 验收标准 | 比较交付要求 | 关键验收条件可互相覆盖 |
| 目标用户 | 比较使用人群 | 角色、权限、使用场景一致或高度接近 |
相似度计算可采用字段匹配加权与文本相似度组合的方式。字段匹配按五类字段逐项打分，权重来源要在口径文档中写明，例如业务对象和用户任务权重最高，因为它们决定是否属于同一件事；功能点和验收标准次之；目标用户作为辅助。文本相似度用于处理描述措辞不同的情况，作为补充信号，不单独决定结论。
阈值不能凭经验直接定。做法是先抽取一批需求对，由两人以上独立人工标注“重复/不重复”，形成标注集；再在若干候选阈值上分别计算误判（标为重复实际不重复）与漏判（标为不重复实际重复），选择误判与漏判都在可接受范围内的阈值。校准记录要写明样本量、标注人、候选阈值和最终选择理由。
证据留存包括判定记录、复核人和判定结论。每条被判为重复的需求对，保留触发判定的字段对比、相似度得分和人工确认意见。这样在需求方提出异议时，可以回到具体证据讨论，而不是争论“感觉像不像”。
在需求条目和字段管理环节，ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯（F2）。判定字段可以作为需求条目的固定属性维护，判定记录随需求一起留痕，便于后续复核。需要说明的是，现有资料未说明 ONES 提供需求之间相似度或重复度的自动计算能力，识别规则和阈值仍需团队自行定义并在流程中执行。
计算与评估步骤：从抽样校准到全量统计
执行分六步，每步都有明确产物，保证结果可复算：
- 圈定范围：确定产品线、需求状态和时间窗，导出需求清单及判定字段，形成统计底表。
- 抽取样本：从底表中随机抽取需求对，样本量以能覆盖主要业务对象为准，记录抽样方法。
- 人工标注：两人以上独立标注重复与否，分歧项讨论后定论，形成标注集。
- 校准阈值：在候选阈值上计算误判与漏判，选定阈值并记录校准日期与样本量。
- 全量计算：按选定阈值对全部需求对打分判定，汇总重复需求对数与重复需求工时。
- 抽样复核：从全量判定结果中再抽一批，人工核对，计算误判率，超出预设范围则回到第4步。
两个核心公式：
- 重复率 = 重复需求对数 ÷ 需求总对数 × 100%。分母是统计范围内所有可比需求对的数量，单位是“对”，结果以百分比表示。
- 重复投入工时占比 = 重复需求工时 ÷ 总需求工时 × 100%。分子为被判为重复的需求所投入的工时，分母为统计范围内全部需求的工时，单位为人时或人天，需在指标卡上固定标注。
分母为零和数据缺失要单独处理。统计范围内需求少于两条时，需求总对数为零，重复率标记为“不可计算”，不用零值填充。工时数据缺失的需求，在重复投入占比中单列为“工时缺失”，不参与分母计算，同时记录缺失条数，避免缺失数据拉低整体比例。复核抽样比例建议不低于判定结果的一定份额，通过标准为误判率低于校准阶段设定的上限；具体比例和上限由团队在口径文档中约定，不设通用达标线。
例子：一个季度需求集合的重复率试算
以下为演示情景，数据为假设值，用于说明口径如何落地。
某产品线一个季度内创建并进入评审的需求共 60 条，按创建时间划定时间窗，统计范围为该产品线全部已评审需求。60 条需求两两组合共 1770 对，作为重复率的分母。
先从 1770 对中抽取 120 对做人工标注，两人独立判定后确认重复 18 对、不重复 102 对。在候选阈值 0.7、0.75、0.8 上分别试算：阈值 0.7 时误判 5 对、漏判 2 对；阈值 0.75 时误判 3 对、漏判 3 对；阈值 0.8 时误判 1 对、漏判 6 对。团队选择 0.75，兼顾误判与漏判。
按 0.75 全量计算，1770 对中判定为重复的共 96 对，重复率 = 96 ÷ 1770 × 100% ≈ 5.4%。这 96 对涉及的需求去重后为 71 条，其累计工时 1240 人时；统计范围内全部需求工时 8600 人时，重复投入工时占比 = 1240 ÷ 8600 × 100% ≈ 14.4%。
分级结果：完全重复 22 对，建议合并；高度相似 41 对，建议复用已有能力并做配置扩展；部分重叠 33 对，建议排期协调并明确共用组件。复核阶段再抽 100 对，误判 4 对，误判率 4%，低于校准阶段约定的上限，结果可用。
在这个流程中，需求条目、判定字段和判定记录需要稳定留存。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布（F1），标准流程、评审节点、交付物模板和研发过程数据可以沉淀为可复用资产（F3），适合把重复判定规则固化为评审环节的一项检查。若团队希望从历史文档和协作数据中查找已有能力描述，ONES 支持在 Wiki 页面、附件等知识上下文中进行全局知识检索（F4），可作为人工判定时的辅助证据来源；它不替代相似度计算和阈值判定。
解读与限制：指标能说明什么、不能说明什么
重复率高不等于管理失控。需求来源分散、业务处于快速试错阶段、多个团队并行探索同一市场时，重复提出本身可能是正常现象。解读时要结合需求来源结构、业务阶段和产品线成熟度，判断重复是信息不对称造成的，还是探索策略的有意选择。前者适合通过复用机制改善，后者需要的是排期协调而非简单合并。
相似度阈值直接改变结果。阈值调低，重复对增多，重复率上升，误判风险增加；阈值调高，漏判增多，重复率被低估。因此跨团队、跨季度比较必须使用同一阈值、同一字段权重和同一时间窗口径，否则数字不可比。阈值调整后应重算历史数据或明确标注口径变更点。
重复率是描述性指标，不宜单独作为团队绩效指标。把它与个人或团队考核挂钩，容易诱发需求描述刻意差异化、拆分需求规避判定等行为，反而破坏数据质量。它更适合作为需求评审和排期会议的输入，配合具体需求对清单使用。
口径需要定期复校。业务范围扩展、需求粒度变化、团队调整后，原有字段权重和阈值可能不再适用，应重新抽样标注并校准，记录校准日期。每次复校后保留新旧口径的对照，避免历史数据被误读。
常见问题
统计范围按需求创建时间还是上线时间划定时间窗，两者结果差异大吗？
两种口径回答的问题不同。按创建时间划定，对应“需求提出时是否已知已有能力”，适合评估信息不对称造成的重复；按上线时间划定，对应“交付阶段实际发生了多少重复投入”，适合评估浪费。同一批需求在两种口径下的重复率通常不一致，差异大小取决于需求从创建到上线的周期长短和期间的能力变化。
选定一种后，跨期比较和跨团队比较都要沿用同一种，并在口径文档中写明。需要同时看两个视角时，分别出两份结果，不要混算成一个数字。
工时数据不完整时，重复投入工时占比还能算吗？
可以算，但要先处理缺失。把工时缺失的需求单列为“工时缺失”，不纳入分母，同时记录缺失条数；如果缺失比例较高，应在结果旁标注覆盖率，说明该比例的适用范围。分母为零时（统计范围内需求少于两条），重复率标记为“不可计算”，不用零值填充。
缺失处理规则要写进口径文档并保持稳定，否则不同季度之间无法比较。
两条需求被判为重复后，应该合并还是保留？
按分级结果处置。完全重复，即同一业务对象、同一用户任务且功能点与验收标准基本一致，建议合并为一条，保留信息更完整的一条；高度相似，即功能点与验收标准大部分重合但目标用户或场景有差异，建议复用已有能力并做参数化或配置扩展；部分重叠，即能力范围交叉但业务对象或交付形态不同，建议排期协调并明确边界与共用组件。
合并前要确认两条需求背后的业务方是否知情，避免合并后遗漏真实诉求。
阈值调整后，历史数据要不要重算？
建议重算，或在结果上明确标注口径变更点。阈值调低会抬高重复率并增加误判，调高会低估重复率并增加漏判，新旧数字直接放在一起比较会误导判断。重算成本高时，至少保留新旧口径的对照表和校准日期，让读者知道数字背后的规则已经变化。
业务范围扩展、需求粒度变化或团队调整后，也应重新抽样标注并校准阈值。
判定记录需要保留到什么程度，才经得起需求方质疑？
每条被判为重复的需求对，保留触发判定的字段对比、相似度得分、人工确认意见、复核人和判定结论。需求方提出异议时，回到具体字段和得分讨论，而不是争论主观印象。判定记录随需求条目一起留存，便于后续追溯和口径复校时复用。
在 ONES 中，需求、基线、版本和变更作为统一管理对象，判定字段可作为需求条目的固定属性维护，判定记录随需求留痕（F2）。现有资料未说明 ONES 提供需求之间相似度或重复度的自动计算能力，识别规则和阈值仍需团队自行定义并在流程中执行。
