需求优先级冲突决策记录表要解决的是“当时为什么这样排”的问题：让未参与讨论的人能还原冲突、依据和结论，并在优先级再次被挑战时快速追溯。设计时可按“冲突事实—评估依据—决策结论—执行与回看”四段组织字段，明确每段由谁在什么时点填写，再用检查清单验收记录质量。
要点总览（TL;DR）
- 决策记录表按“冲突事实—评估依据—决策结论—执行与回看”四段组织，每段对应明确的填写时点，避免全部内容在会后补写。
- 必填字段覆盖需求编号、冲突对象与类型、影响范围、价值维度、成本与依赖、证据来源、决策人、结论、生效范围、失效条件、执行状态与复查日期。
- 填写责任按“谁掌握信息谁填写”分配：提出方填事实段，研发评估角色填成本与依赖，业务决策人填结论段，执行负责人更新状态。
- 结论要写明附带条件与失效条件，并设定复查日期和承接人，条件变化时由需求管理角色登记变更记录。
- 验收时重点检查三处缺口：只写结论不写依据、只写结论不写条件、缺复查节点，发现后应退回对应角色补充。
决策记录表先定四段结构
决策记录表的价值在于把一次优先级判断从会议口头结论变成可查阅的记录。四段结构分别回答四个问题：冲突是什么、依据是什么、谁定了什么、后来怎么执行。每段有对应的填写时点，避免所有内容都在会后一次性补写。
| 段落 | 回答的问题 | 填写时点 | 主要填写人 |
|---|---|---|---|
| 冲突事实 | 哪两个需求在争什么资源，冲突点在哪里 | 冲突提出时 | 需求提出方或需求管理角色 |
| 评估依据 | 按什么口径比较，证据来自哪里 | 评估过程中 | 需求管理角色、研发评估角色 |
| 决策结论 | 谁做的决定，结论和生效条件是什么 | 决策会上 | 业务决策人 |
| 执行与回看 | 结论是否落地，何时复查，有无变更 | 决策后持续更新 | 需求管理角色、执行负责人 |
行粒度需要提前约定。一条冲突一行适合追溯单次决策，每次优先级争议都有独立记录；按需求对象一行适合查看同一需求被反复调整的历史。实践中可以组合使用：主表按冲突事件一行，另设变更记录子表挂在需求对象下，记录每次优先级变化的时间、原因和决策编号。团队冲突频率低时，单表按冲突一行即可；需求变更频繁、同一需求多次被挑战时，子表能减少主表重复。
必填字段清单与填写口径
字段设计的目标是让记录具备自解释能力。下表给出可直接复制使用的字段清单，“必填”指缺少该字段记录即不完整，“选填”可按团队规模取舍。
| 段落 | 字段 | 填写内容 | 填写人 | 必填/选填 | 示例 |
|---|---|---|---|---|---|
| 冲突事实 | 需求编号与名称 | 冲突涉及的需求标识与简短名称 | 需求提出方 | 必填 | REQ-231 订单导出批量下载 |
| 冲突事实 | 提出方 | 提出该需求的角色或部门 | 需求提出方 | 必填 | 华东区销售运营 |
| 冲突事实 | 冲突对象 | 与之争夺同一资源的另一需求或事项 | 需求管理角色 | 必填 | REQ-245 对账异常提醒 |
| 冲突事实 | 冲突类型 | 资源争抢、交付时间冲突、价值判断分歧等 | 需求管理角色 | 必填 | 同一迭代研发资源争抢 |
| 冲突事实 | 影响范围 | 受影响客户、业务线、交付节点 | 需求提出方 | 必填 | 影响3个大客户季度结算，涉及月底上线节点 |
| 评估依据 | 价值维度 | 按团队既定口径填收入影响、客户覆盖、合规要求等 | 需求管理角色 | 必填 | 收入影响高，覆盖2个重点客户 |
| 评估依据 | 成本与依赖 | 研发工作量、外部依赖、前置条件 | 研发评估角色 | 必填 | 约15人日，依赖财务系统接口排期 |
| 评估依据 | 证据来源 | 支撑判断的具体材料及位置 | 需求提出方、需求管理角色 | 必填 | 客户访谈纪要2024-05-12、近三月工单统计 |
| 评估依据 | 评估口径与假设 | 本次比较采用的评分方法及关键假设 | 需求管理角色 | 必填 | 按价值/成本比排序，假设接口可在两周内就绪 |
| 决策结论 | 决策人 | 对结论负责的单一角色 | 业务决策人 | 必填 | 产品负责人 |
| 决策结论 | 参与人 | 参与讨论与评估的角色 | 会议记录人 | 必填 | 销售运营代表、研发负责人、需求管理 |
| 决策结论 | 结论 | 明确哪个需求先做、排入哪个迭代 | 业务决策人 | 必填 | 本迭代先做REQ-231，REQ-245顺延至下迭代 |
| 决策结论 | 生效范围 | 结论适用的迭代、版本或业务线 | 业务决策人 | 必填 | 仅适用于Q3第2迭代 |
| 决策结论 | 附带条件与失效条件 | 结论成立的前提，以及何种情况需重新评估 | 业务决策人 | 必填 | 条件：接口两周内就绪；失效：大客户结算提前至本迭代 |
| 执行与回看 | 执行状态 | 未开始、进行中、已完成、已变更 | 执行负责人 | 必填 | 进行中 |
| 执行与回看 | 复查日期 | 下次检查结论是否仍成立的时间 | 需求管理角色 | 必填 | 迭代中期评审日 |
| 执行与回看 | 变更记录 | 结论调整的时间、原因与新结论 | 需求管理角色 | 选填，发生变更时必填 | 接口延期，REQ-245提前插入 |
| 执行与回看 | 关联需求 | 相关需求编号或评审记录链接 | 需求管理角色 | 选填 | REQ-245、迭代评审纪要 |
评估依据段最容易写空。填写时要求每条判断都能指向具体材料，例如客户反馈记录、工单数量统计或合同条款，避免只写“价值高”“客户很急”。决策结论段的失效条件同样关键，它把结论从一次性拍板变成有边界的判断，后续条件变化时团队知道何时需要重新讨论。
记录表需要承载在需求条目和团队知识库中，才能与需求本身保持关联。ONES 提供项目管理与知识库等模块组合，需求条目可在项目中管理，决策记录可沉淀为 Wiki 页面，并通过关联需求字段回指具体条目；ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面等上下文回答问题，并将结果保存为工作项或 Wiki 页面，便于在记录过程中减少重复录入。具体字段配置与关联方式以实际环境为准。
角色分工与决策流转
记录表变成会后补写的空壳，通常是因为填写责任没有落到具体角色。按“谁掌握信息谁填写”的原则分配，可以让记录在流程中自然形成。
| 角色 | 负责字段 | 填写时点 | 交接对象 |
|---|---|---|---|
| 需求提出方 | 需求编号与名称、提出方、影响范围、证据来源 | 冲突提出时 | 需求管理角色 |
| 需求管理角色 | 冲突对象、冲突类型、价值维度、评估口径、复查日期、变更记录 | 评估中及决策后 | 业务决策人、执行负责人 |
| 研发评估角色 | 成本与依赖 | 评估中 | 需求管理角色 |
| 业务决策人 | 决策人、结论、生效范围、附带条件与失效条件 | 决策会上 | 执行负责人 |
| 执行负责人 | 执行状态 | 决策后持续更新 | 需求管理角色 |
流转顺序为：冲突提出方提交事实段，需求管理角色补齐冲突对象与类型并组织评估，研发评估角色给出成本与依赖，业务决策人在决策会上填写结论段，执行负责人接手执行状态，需求管理角色在复查日期核对结论是否仍成立。每个交接点以字段填写完整为标志，事实段不完整不进入评估，评估依据缺失不进入决策会。
决策人缺席时，记录表应写明“决策人未到场，结论待确认”，并指定确认时限，避免用参会人的推测代替决策。意见不一致时，记录少数意见及其理由，并注明最终结论由谁拍板，这样复盘时能看到分歧点而非只有一致结论。记录表通过需求编号与需求条目关联，通过评审纪要链接与会议记录关联，保证结论能回到具体对象和讨论现场。
填写示例：一次优先级冲突的完整记录
以下为演示情景，用于说明字段如何组合，不代表真实项目数据。
冲突事实：需求REQ-231“订单导出批量下载”由华东区销售运营提出，与REQ-245“对账异常提醒”争夺同一迭代的研发资源，冲突类型为同一迭代资源争抢。影响范围为3个大客户季度结算，涉及月底上线节点；REQ-245影响财务对账效率，无硬性时间要求。
评估依据：价值维度上，REQ-231收入影响高、覆盖2个重点客户，REQ-245主要提升内部效率；成本与依赖上，REQ-231约15人日、依赖财务系统接口排期，REQ-245约8人日、无外部依赖；证据来源为客户访谈纪要2024-05-12和近三月工单统计；评估口径为按价值与成本比排序，假设财务接口可在两周内就绪。
决策结论：决策人为产品负责人，参与人包括销售运营代表、研发负责人和需求管理角色。结论为本迭代先做REQ-231，REQ-245顺延至下迭代，生效范围仅限Q3第2迭代。附带条件为财务接口两周内就绪；失效条件为大客户结算提前至本迭代，届时需重新评估。
执行与回看：执行状态为进行中，复查日期定在迭代中期评审日，变更记录暂空，关联需求为REQ-245及迭代评审纪要。若接口延期，需求管理角色在变更记录中登记新结论，并同步调整REQ-245的排期。
完成检查：这张表能否支撑复盘与追溯
记录填写完成后，用以下清单逐项核对，判断是否达到留痕、复盘和追溯要求。
- 未参会者仅凭记录能否说清冲突双方、冲突点和影响范围。
- 每条评估判断是否指向具体证据，证据位置是否可查。
- 结论是否写明决策人、生效范围和失效条件。
- 附带条件是否具体到可判断成立与否，而非笼统描述。
- 复查日期是否明确，复查是否有承接人。
- 发生变更时，变更记录是否写明时间、原因和新结论。
- 记录是否通过需求编号与需求条目、评审纪要建立关联。
常见缺口集中在三处：只写结论不写依据，导致复盘时无法判断当时的信息是否充分；只写结论不写条件，导致条件变化后仍沿用旧结论；缺复查节点，导致决策落地后无人回看。检查时发现任一缺口，应退回对应角色补充，而不是在记录末尾加一句“已确认”。
常见问题
冲突双方各执一词、会上没有形成一致意见时，记录表该怎么写？
记录表仍按四段填写，结论段如实写明“未达成一致”及当前处理方式，例如暂缓排期或由上级决策人裁定。同时记录少数意见及其理由，并注明最终由谁拍板、确认时限是什么。这样复盘时能看到分歧点和判断依据，而不是只留下一个看似一致的结论。
同一需求在多个迭代里反复被调整优先级，记录表要每次新建一行吗？
可以组合使用主表与变更记录子表。主表按冲突事件一行，记录每次争议的完整判断过程；子表挂在需求对象下，登记每次优先级变化的时间、原因和对应决策编号。冲突频率低时单表按冲突一行即可；同一需求多次被挑战时，子表能避免主表重复堆叠，也便于查看该需求的完整调整历史。
评估依据写到什么程度才算可追溯？
判断标准是每条依据都能指向具体材料并说明位置，例如客户访谈纪要的日期、工单统计的时间范围、合同条款的编号。只写“价值高”“客户很急”这类描述，复盘时无法判断当时的信息是否充分。评估口径与关键假设也要一并写明，条件变化时才能判断原结论是否仍然成立。
决策记录表放在哪里，才能和需求条目保持关联？
记录表需要与需求条目、评审记录建立可回查的关联，常见做法是通过需求编号互相引用，并在记录中附上评审纪要的位置。ONES 提供项目管理与知识库等模块组合，需求条目可在项目中管理，决策记录可沉淀为 Wiki 页面并通过关联需求字段回指具体条目；ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面等上下文回答问题，并将结果保存为工作项或 Wiki 页面，减少记录过程中的重复录入。具体字段配置与关联方式以实际环境为准。
团队规模小、冲突不频繁，字段可以精简到哪些？
可以保留支撑追溯的最小集合：需求编号与名称、冲突对象、冲突类型、价值维度、成本与依赖、证据来源、决策人、结论、生效范围、失效条件、执行状态和复查日期。参与人、关联需求、变更记录等字段在冲突少时可先设为选填，发生变更时再补。精简的前提是未参会者仍能凭记录还原判断过程，不能为了少填而删掉依据和条件。
