面对多个来源的需求冲突，先要判断哪一件该先处理。本文给出一套可复算的方法：用严重程度衡量冲突对目标、交付和质量的破坏力，用影响范围衡量被波及的需求、角色、系统和时间窗，两组指标按统一口径打分后合成优先级。评分结果用于排序和沟通，最终取舍仍由需求负责人确认。
要点总览（TL;DR）
- 评估需求冲突要同时看两组指标：严重程度衡量对目标、交付、质量的破坏力，影响范围衡量波及的需求、角色、系统和时间窗，两组分开打分再合成。
- 严重程度取目标偏离、交付阻断、质量风险、返工成本四项均分；影响范围取需求数、角色数、系统或模块数、时间窗四项均分，每项按1–5分档位打分并附证据。
- 优先级分可用严重程度分×影响范围分（1–25分），也可用加权求和，本轮内统一一种方法；已造成交付延期、质量事故或合规风险的冲突走一票优先，不参与分数比较。
- 排序按一票优先、优先级分高低、并列时先看交付阻断再看角色数的顺序执行，评分依据与处理状态随冲突记录留存以便复核。
- 分数只反映相对紧迫度，不替代需求价值判断；数据缺失或待确认项较多时结果不可比，需求变化后需重新打分。
评估目标：先回答冲突该不该优先处理
需求冲突评估的对象是冲突本身，而非单个需求的价值。两个需求都很重要，也可能因为指向同一资源、同一交付节点而互相挤压，这时要评估的是“这组冲突如果不处理，会造成多大破坏、波及多宽”，而不是“哪个需求更值得做”。把这两件事混在一起，排序就会变成部门之间争资源，难以形成可复核的结论。
评估的输出是一份处理顺序建议：哪些冲突先处理、哪些可以排队、哪些需要升级到更高层级决策。它支撑的是排期和沟通，不直接给出需求取舍结论。冲突往往牵涉目标优先级、预算或客户承诺，这些判断超出评分能覆盖的范围，需要由需求负责人结合业务意图确认。评估的价值在于把“先处理哪个”从印象之争变成有依据的讨论：每个冲突的分数、证据和判断理由都记录在案，评审时可以逐项核对，而不是各说各话。
使用边界还包括时间边界。评估针对一个明确的时间窗，例如本迭代、本月或某个版本发布前。超出时间窗的冲突可以记录，但不纳入本轮排序，避免清单无限膨胀导致评估失焦。
指标与范围：严重程度和影响范围各看什么
严重程度回答“破坏力多大”，影响范围回答“波及多宽”。两组指标分开打分，再合成优先级，可以避免一种常见偏差：影响面很广但破坏力有限的冲突，被误排到造成交付阻断的冲突之前。
严重程度建议看四个指标，每个按1–5分打分：
| 指标 | 1分 | 3分 | 5分 | 判断依据 |
|---|---|---|---|---|
| 目标偏离 | 不影响既定目标 | 使某个目标的部分指标需要调整 | 使核心目标无法达成或方向改变 | 目标文档、OKR或版本目标说明 |
| 交付阻断 | 不影响任何交付节点 | 使某个节点需要顺延或缩减范围 | 使关键节点无法交付 | 排期表、里程碑计划 |
| 质量风险 | 无可见质量影响 | 可能引入需修复的缺陷 | 可能造成线上事故或数据错误 | 缺陷记录、技术评估意见 |
| 返工成本 | 无需返工 | 局部返工，工作量可控 | 大范围返工或推翻已交付内容 | 变更记录、工作量估算 |
影响范围同样看四个指标：涉及需求数按去重后的需求条目计；角色数按实际承担职责的角色计，同一人兼任多个角色时分别计入；系统或模块数按受影响的边界计；时间窗指冲突从出现到必须解决之间的可用时间，时间越短、越接近交付节点，分数越高。四个指标各按1–5分打分，5分对应波及范围最大或时间窗最紧的情形。
评估前要先确定纳入清单的冲突和时间范围。建议只纳入已记录、有明确来源的冲突，例如来自客户反馈、内部评审、线上问题或合规要求；口头提出、尚未形成记录的事项先登记再评估。时间范围与S1确定的时间窗一致，清单之外的冲突不参与本轮排序。
数据口径与证据：分数从哪里来
评分要可复算，每个分数都应能追溯到具体证据。证据来源包括需求文档、评审记录、排期表、缺陷或变更记录。打分时在评分表里附上证据位置和一句判断理由，例如“交付阻断4分：影响版本V2.3的联调节点，见排期表第3行”。
统计口径要事先写清。涉及需求数按去重后的需求条目计，同一需求被多个来源重复提出只算一条；角色数按实际承担职责计，产品、研发、测试、运营分别计数，兼任者分别计入；系统或模块数按架构边界计，不按代码文件或页面数量计。时间窗以天或迭代为单位，写明起止日期。口径一旦确定，本轮评估内不再调整，否则分数之间不可比。
缺失值处理规则：某项指标没有记录支撑时，标记为“待确认”，不默认给中间分。待确认项超过两项的冲突，先补证据再参与排序；确实无法补齐的，在结果中标注“数据不完整”，由需求负责人决定是否按现有信息处理。
评分人建议由需求负责人、对应研发负责人和测试负责人共同参与，各自对自己掌握的证据打分，分歧超过两分的指标当场核对证据。交叉确认的作用是减少单人凭印象打分，也让后续排期更容易被各方接受。
计算与排序步骤：从打分到处理顺序
先分别合成两个总分。严重程度分取四个指标的平均值，影响范围分取四个指标的平均值，两者都落在1–5分区间。如果业务上认为某个指标更关键，可以改用加权求和，权重需在评估前写明来源，例如由需求负责人和研发负责人共同确定并记录在评估说明中，不能事后按结果调整权重。
优先级公式示例：优先级分 = 严重程度分 × 影响范围分，取值范围1–25分。乘法的作用是让“破坏力大且波及广”的冲突显著靠前，同时避免单项高分直接决定顺序。也可以采用加权求和，例如严重程度占60%、影响范围占40%，适合希望两个维度都参与但差距不被放大的场景。两种方法选一种，本轮内统一使用。
排序规则按以下顺序执行：
- 先应用一票优先条件：已经造成交付延期、线上质量事故或合规风险的冲突，直接排到最前，不参与分数比较。
- 其余冲突按优先级分从高到低排序。
- 分数并列时，先看是否阻断交付，阻断者优先；仍并列时看影响角色数，角色多者优先。
- 排序结果连同各指标分数、证据位置和判断理由一起记录，便于复核和后续更新。
排序完成后，把结果同步到冲突记录中，标明处理状态和负责人。冲突记录、评分依据和处理状态如果分散在文档、表格和聊天记录里，复核成本会很高。ONES 的需求管理可以把冲突作为工作项登记，关联相关需求、评分字段和处理状态，让评分依据与需求条目在同一处流转，评审时直接查看记录而不必重新收集材料。
例子：三个冲突如何排出先后
以下为演示情景。某版本发布前记录了三组冲突：
- 冲突A：客户要求增加导出字段，与已排期的报表改版争用同一名后端开发。证据：客户邮件、排期表。
- 冲突B：测试提出登录流程的安全校验与现有快捷登录方案冲突，可能影响上线。证据：评审记录、缺陷单。
- 冲突C：运营希望调整首页文案，与设计规范中的用语要求不一致。证据：需求文档、设计规范。
逐项打分（1–5分）：
| 冲突 | 目标偏离 | 交付阻断 | 质量风险 | 返工成本 | 严重程度均分 |
|---|---|---|---|---|---|
| A | 3 | 3 | 2 | 3 | 2.75 |
| B | 4 | 5 | 5 | 4 | 4.5 |
| C | 1 | 1 | 1 | 2 | 1.25 |
| 冲突 | 需求数 | 角色数 | 系统/模块数 | 时间窗 | 影响范围均分 |
|---|---|---|---|---|---|
| A | 2 | 3 | 1 | 4 | 2.5 |
| B | 3 | 4 | 2 | 5 | 3.5 |
| C | 1 | 2 | 1 | 2 | 1.5 |
代入公式计算：A为2.75×2.5≈6.9分，B为4.5×3.5=15.75分，C为1.25×1.5≈1.9分。冲突B同时满足一票优先条件——已影响上线节点且存在质量风险，直接排第一；A排第二，C排第三。若A与C分数接近，按并列规则先看交付阻断，A的阻断分更高，顺序不变。
边界情况：如果冲突B的安全校验最终确认不影响上线，一票条件不再成立，此时B仍以15.75分居首，但需要在记录中更新判断理由，避免后续复核时依据过期。
解读与限制：分数能说明什么、不能说明什么
分数反映的是相对紧迫度，用于回答“先处理哪个”，不回答“哪个需求更有价值”。一个分数较低的冲突，可能对应重要的长期客户关系，这类判断需要需求负责人结合业务意图处理，评分表只提供参考。
数据不完整时结果不可比。待确认项较多的冲突，其分数带有较大不确定性，应在结果中标注，不宜与证据完整的冲突直接比较名次。分母为零的情形也要注意：如果某个时间窗内没有可统计的需求条目，影响范围分失去意义，此时应改用定性判断并说明理由。
单指标高分不能直接决定全部顺序。质量风险5分但影响范围很小的冲突，与各项均衡偏高的冲突相比，谁先处理要看合成结果和阻断条件，不能因为某一项突出就跳过排序规则。评估结论也需要随需求变化更新：需求范围调整、排期变化或新证据出现后，重新打分并记录变更，避免一次打分长期沿用导致排序失真。
常见问题
冲突清单里既有正式记录的需求，也有会上口头提出的意见，要不要一起打分？
建议先登记再评估。口头提出、尚未形成记录的事项，先补上来源、提出人和涉及的需求条目，再纳入本轮清单。没有记录支撑的冲突在打分时容易出现证据缺失，导致待确认项过多、分数不可比。如果时间紧，可以先把口头事项列为“待登记”，本轮只对已记录冲突排序，下一轮再纳入。
两个冲突的优先级分完全一样，按并列规则还是分不出来，怎么办？
并列规则用尽后仍无法区分，说明现有指标没有捕捉到差异。此时可以回到证据层面核对：检查两项冲突的交付阻断分和角色数是否有打分偏差，分歧超过两分的指标当场核对证据。如果核对后仍然并列，把两项冲突一并提交需求负责人，由其结合业务意图决定顺序，并在记录中写明“分数并列、人工裁定”及理由，便于后续复核。
某个指标确实找不到记录，能直接给3分吗？
不建议默认给中间分。中间分会让缺失数据看起来像正常评估结果，掩盖不确定性。正确做法是标记“待确认”，并注明缺什么证据、由谁补充。待确认项超过两项的冲突，先补证据再参与排序；确实补不齐的，在结果中标注“数据不完整”，由需求负责人决定是否按现有信息处理。这样排序结论的不确定性是可见的，而不是被平均分掩盖。
权重可以每次评估都调整吗？
权重应在评估开始前确定并写明来源，例如由需求负责人和研发负责人共同商定后记录在评估说明中。同一轮评估内权重保持不变，否则不同冲突的分数之间失去可比性。如果业务重点发生变化，可以在新一轮评估中调整权重，但要同步说明调整原因，并避免按已有结果反向调权重。采用乘法公式时不存在显式权重，同样需要本轮内统一使用一种合成方法。
评估做完、顺序排好之后，冲突处理到一半需求又变了，要重新打分吗？
需要更新。需求范围调整、排期变化或新证据出现，都会改变原有指标的取值。建议在冲突记录中保留历次评分和变更理由，重新打分后对比新旧结果，说明顺序是否变化及原因。对于已经处理完的冲突，保留原评分作为记录即可；对于仍在排队的冲突，按最新分数重新排序，避免用过期结论指导排期。
