需求冲突分析的依据由四类材料构成：需求来源与原始记录、需求条目及其属性、冲突双方的关联事实、裁决规则与决策记录。操作上先把模糊的“有冲突”写成可核对的问题陈述，再逐条挂接依据，最后按统一规则给出裁决并留痕。本文按这一主线展开，适用于需求理解与澄清阶段的冲突分析，不涉及需求建模和正式评审流程。
要点总览（TL;DR）
- 需求冲突分析的依据分四类：来源依据（业务目标、用户反馈、合同与合规条款的原始记录）、条目依据（需求描述、优先级、验收标准、约束与假设）、关联事实（角色、场景、时间窗口、资源与依赖）、规则依据（优先级规则、决策权限、历史裁决与变更记录）。
- 分析前先把模糊的“有冲突”写成可核对的问题陈述，区分目标、范围、资源、优先级四类冲突，取证才有针对性。
- 取证按四步推进：登记冲突并锁定需求版本、逐类取证并标注缺失、统一口径比对识别真实冲突、引用规则给出裁决建议；缺失依据列为待决事项，不能默认某一方成立。
- 依据是否充分看四点：四类依据均有材料或明确标注缺失、冲突陈述可被第三方复核、裁决引用规则而非个人偏好、结论与变更已留痕可追溯。
- 冲突分析是评审前的准备工作，产出问题陈述、依据清单和裁决建议，裁决权仍在产品负责人或决策者手中。
先明确：需求冲突分析要回答什么问题
冲突分析要回答的是一个具体问题：两条或多条需求之间，在给定目标和约束下，是否存在不能同时成立的关系，如果存在，应当依据什么做出取舍。把这个问题答清楚，分析才算完成；答不清楚，收集再多材料也只是堆信息。
判定冲突时先分类，不同类型的冲突取证方向不同。目标冲突指两条需求服务于相互矛盾的业务目标，例如一个要求缩短交付周期、另一个要求增加审批环节。范围冲突指对同一功能边界理解不一致，一方认为包含批量导入、另一方认为只做单条录入。资源冲突指需求本身不矛盾，但争抢同一批人力、预算或时间窗口。优先级冲突指目标、范围、资源都清楚，但两条需求都要求先进同一迭代。分类之后，取证才有针对性。
分析的输出应包含三件东西。第一是冲突陈述，用一段话写清涉及哪几条需求、冲突类型、影响范围和当前状态。第二是依据清单，逐条列出支撑判断的材料及其来源。第三是裁决建议，说明建议采纳哪一方、依据哪条规则、还有哪些事项待决。这三件东西合起来，才构成一份可以交给决策者使用的分析结果。
需要区分的是，冲突分析不等同于需求建模，后者关注需求如何结构化表达；也不等同于正式评审，后者是多方确认与签署的会议机制。冲突分析是评审之前的准备工作，产出的是问题陈述和建议，裁决权仍在决策者手中。
下面是一份可直接填写的问题陈述模板：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 冲突编号 | 唯一标识，便于追溯 | CF-2024-017 |
| 冲突类型 | 目标／范围／资源／优先级，可多选 | 资源冲突、优先级冲突 |
| 涉及需求 | 需求编号与一句话描述 | REQ-102 订单批量导出；REQ-118 报表定时推送 |
| 影响范围 | 受影响的迭代、模块、角色 | 本迭代后端两人力，影响运营与财务两个角色 |
| 问题陈述 | 一句话写清不能同时成立的点 | 两条需求均要求本迭代由同一后端小组完成，人力不足以同时交付 |
| 当前状态 | 待取证／分析中／待裁决／已裁决 | 待取证 |
四类核心依据及取数方式
四类依据分别回答不同层面的问题：来源依据回答“这条需求为什么存在”，条目依据回答“这条需求具体要求什么”，关联事实回答“冲突发生在什么条件下”，规则依据回答“按什么标准取舍”。四类齐全，裁决才有支撑；某一类缺失，应在清单中明确标注，作为待决事项处理。
来源依据：需求的出处与原始记录
来源依据包括业务目标文件、用户反馈原始记录、合同条款、合规与监管要求。取数动作是找到需求提出时的原始材料，而不是转述版本。例如用户反馈应保留原始工单或访谈记录，合同条款应定位到具体条款编号。责任人是需求提出方，由其提供出处并确认材料完整。
条目依据：需求本身的描述与属性
条目依据包括需求描述、优先级标记、验收标准、约束条件与假设。取数动作是从需求管理工具或文档中导出当前版本，并确认版本号与最后修改时间。优先级字段尤其关键，它是优先级冲突的直接证据。责任人是需求分析人员，负责核对条目内容与实际表述一致。
关联事实：冲突发生的具体条件
关联事实包括涉及的角色、使用场景、时间窗口、资源占用与依赖关系。取数动作是确认每条需求由谁使用、在什么场景下使用、要求在什么时间前交付、占用哪些人力或系统资源、依赖哪些上游工作。责任人是需求分析人员会同技术负责人，必要时向相关角色确认。
规则依据：裁决所依据的标准与先例
规则依据包括团队既定的优先级规则、决策权限划分、历史裁决记录与变更历史。取数动作是找到现行规则文本和最近的相关裁决案例，确认规则是否仍然有效。责任人是产品负责人或指定的规则维护者。
四类依据可整理为一张清单表，逐项标注取得状态：
| 依据类别 | 具体材料 | 来源系统或文档 | 责任人 | 是否已取得 |
|---|---|---|---|---|
| 来源依据 | 业务目标说明、用户反馈原始记录、合同条款 | 目标文档库、反馈工单系统、合同档案 | 需求提出方 | 是／否／部分 |
| 条目依据 | 需求描述、优先级、验收标准、约束与假设 | 需求管理工具或需求文档 | 需求分析人员 | 是／否／部分 |
| 关联事实 | 角色、场景、时间窗口、资源与依赖 | 排期表、资源计划、依赖关系记录 | 需求分析人员、技术负责人 | 是／否／部分 |
| 规则依据 | 优先级规则、决策权限、历史裁决、变更记录 | 团队规则文档、评审记录、变更日志 | 产品负责人 | 是／否／部分 |
当依据分散在需求条目、Wiki 页面和历史评审记录中时，取证本身会消耗不少时间。ONES 可承载需求条目与工作项管理，并通过 ONES Assistant 理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题，减少反复补充背景的环节；在需求澄清阶段，它还能围绕用户反馈洞察和 PRD 质量检查提炼要点与待澄清问题，帮助分析人员更快定位依据所在。具体可用范围以实际产品配置为准。
操作步骤：从收集依据到形成裁决建议
把依据收集组织成固定步骤，可以避免分析做到一半才发现关键材料缺失。以下四步各有明确的输入、动作、输出和完成标志。
步骤一：登记冲突并锁定涉及需求条目
输入是提出冲突的线索，可能来自评审会上的分歧、开发过程中的疑问或用户反馈。动作是按前述模板登记冲突编号、类型、涉及需求和影响范围，并锁定每条需求的当前版本号。输出是填写完成的冲突问题陈述。完成标志是涉及需求条目已明确到编号和版本，第三方可以据此找到对应内容。
步骤二：按四类依据逐项取证，标注缺失项
输入是冲突问题陈述。动作是依照依据清单表逐类收集材料，每取得一项即记录来源与责任人；无法取得的项目标注为缺失，并写明缺失原因和可能的补齐途径。输出是带取得状态的依据清单。完成标志是四类依据均有明确状态，不存在“未检查”的空白项。
步骤三：用统一口径比对，识别真实冲突与表述差异
输入是依据清单中的材料。动作是把涉及需求放在同一组条件下比对：同一时间窗口、同一资源池、同一验收口径。比对时重点区分真实冲突与表述差异，例如两条需求文字不同但指向同一功能，属于表述差异，应合并描述而非裁决取舍。输出是比对结论，逐条说明哪些构成真实冲突、哪些已澄清。完成标志是每条涉及需求都有明确的比对结论。
步骤四：依据规则给出裁决建议并标注待决事项
输入是比对结论和规则依据。动作是引用现行优先级规则或决策权限，给出建议采纳的方案，并列出因依据缺失而无法判断的事项。输出是裁决建议与待决事项清单。完成标志是每条建议都能指向具体规则条款或历史裁决，待决事项已明确由谁在何时决定。
整个流程可记录在一张冲突分析工作单上，包含步骤状态、依据取得情况和缺失标记，便于交接与复核。
角色分工与交付物
依据收集无人负责是冲突分析最常见的失败原因。把每类依据的提供责任落到具体角色，分析才能按时推进。
| 角色 | 负责事项（R／A／C／I） | 交付物 |
|---|---|---|
| 需求提出方 | 负责提供来源依据（R）；确认业务目标与场景事实 | 业务目标说明、反馈原始记录、合同条款定位 |
| 需求分析人员 | 负责组织取证与形成结论（R）；协调各方补齐材料 | 冲突问题陈述、依据清单、比对结论、裁决建议 |
| 产品负责人或决策者 | 负责裁决（A）；确认规则适用性 | 裁决结论、待决事项的处理决定 |
| 记录与留痕责任人 | 负责归档（R）；维护变更历史 | 冲突分析工作单归档、变更记录更新 |
| 技术负责人 | 被咨询（C）；提供资源与依赖事实 | 资源占用与依赖关系说明 |
裁决结论与变更需要可追溯。ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合把冲突分析结论、评审意见和需求变更记录放在同一工作上下文中管理，便于后续回溯当时依据了哪些材料。
示例：一次优先级冲突的依据挂接
以下为演示情景，用于说明依据如何支撑结论。
背景：某迭代周期内，后端小组只有两名工程师可用。REQ-102 要求实现订单批量导出，REQ-118 要求实现报表定时推送，两条需求都被标记为高优先级，且都计划进入本迭代。开发负责人提出无法同时交付，形成优先级冲突。
逐类挂接依据。来源依据方面，REQ-102 来自运营部门提出的月度对账需求，附有原始反馈工单；REQ-118 来自财务部门的季度报表要求，附有合同条款中关于报表交付时间的约定。条目依据方面，两条需求的描述、验收标准均已确认，优先级字段均为“高”，但 REQ-118 的约束条件中写明“季度末前上线”。关联事实方面，两条需求均依赖同一订单数据服务，后端两名工程师本迭代无其他可调配人力，REQ-118 的时间窗口早于 REQ-102 的对账周期。规则依据方面，团队现行规则规定合同约定时间优先于内部运营需求，且历史上有过一次同类裁决。
缺失项处理：REQ-102 的运营方未能提供对账周期的准确起止时间，该事实标注为缺失。处理方式是不据此推断 REQ-102 可以延后，而是将其列为待决事项，由运营负责人在裁决会上补充。
裁决建议：依据合同时间优先规则，建议本迭代优先交付 REQ-118，REQ-102 顺延至下一迭代，并在工作单中记录规则条款编号与历史裁决参考。待决事项为 REQ-102 的实际对账时间要求，需运营方确认后决定是否调整顺延方案。
可迁移的规律是：当资源冲突与优先级冲突叠加时，时间窗口和合同约束往往是最硬的依据；缺失的事实应显式标注，不能用作支持任何一方的理由。适用边界在于，该结论依赖团队已存在明确的优先级规则，若规则本身缺失，应先补规则再裁决。
完成检查：依据是否足以支撑裁决
分析是否可以交付，用以下清单逐项核对。任一项不通过，应视为阻断项，补齐后再提交裁决。
- 四类依据是否均有材料，或已明确标注缺失并写明补齐途径。存在未检查的空白项即为阻断。
- 冲突陈述是否包含类型、涉及需求编号与版本、影响范围，第三方能否仅凭陈述找到对应材料。无法复核即为阻断。
- 裁决建议是否引用了具体规则条款或历史裁决，而非仅表达个人倾向。仅凭偏好给出的建议不得提交。
- 结论与需求变更是否已记录归档，变更历史能否追溯到本次分析。无留痕即为阻断。
- 待决事项是否已明确责任人与决定时间，避免分析结束后无人跟进。
四项核心检查全部通过，说明依据足以支撑裁决建议；若仅存在非关键缺失且已列为待决事项，可提交裁决但需在结论中注明依据边界。
常见问题
团队还没有成文的优先级规则，冲突分析还能做吗？
可以先做取证和比对，但裁决环节会缺少依据。此时建议把分析范围收缩到事实层面：完成冲突陈述、依据清单和比对结论，明确哪些是真实冲突、哪些只是表述差异，并把“缺少优先级规则”本身作为待决事项提交给产品负责人。规则补齐后再进入裁决，避免用个人偏好替代规则。
如果冲突反复出现，可以借这次分析梳理出团队实际在用的取舍口径，经决策者确认后形成书面规则，供后续同类冲突引用。
关键依据一时拿不到，分析要不要停下来等？
不必整体停摆。做法是把缺失项显式标注在依据清单上，写明缺失原因和补齐途径，其余依据照常收集和比对。缺失的事实不能用来支持任何一方的结论，相关判断转为待决事项，注明由谁在什么时间补齐。
如果缺失的是规则依据或涉及合同、合规的硬约束，则属于阻断项，应补齐后再提交裁决；如果只是某一方的场景细节，可以先提交带依据边界的裁决建议，由决策者判断是否接受。
两条需求文字表述不同，算不算冲突？
先比对再定性。把两条需求放在同一时间窗口、同一资源池、同一验收口径下比较，如果指向同一功能或同一目标，属于表述差异，应合并描述、统一措辞，不进入裁决环节。只有在给定目标和约束下确实不能同时成立，才构成真实冲突。
比对结论要逐条写明，说明哪些构成真实冲突、哪些已澄清，这样第三方复核时能看清判断过程。
冲突分析结论做出后，怎么保证后续能追溯？
把冲突分析工作单、依据清单、比对结论和裁决建议一并归档，并在需求条目上同步更新状态与变更记录，注明本次分析引用了哪些材料和规则条款。这样后续回溯时，能还原当时依据了哪些事实、按什么规则做的取舍。
使用 ONES 时，需求条目、评审意见和变更记录可以放在同一工作上下文中管理，ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，便于把分析结论与需求变更关联起来。具体可用范围以实际产品配置为准。
资源冲突和优先级冲突同时出现时，先处理哪一个？
建议先固定资源事实，再处理优先级。资源冲突回答的是“能不能同时做”，优先级冲突回答的是“先做哪一个”，前者不清楚，后者无从谈起。先把可用人力、时间窗口和依赖关系确认下来，再引用优先级规则在候选需求之间排序。
当时间窗口与合同约定叠加时，这类硬约束通常优先于内部运营需求；但这一判断依赖团队已有明确的优先级规则，规则缺失时应先补规则再裁决。
