版本规划评审分工要解决的是决策责任分配：版本做什么由谁判断、材料由谁准备、冲突由谁裁决、结论由谁跟踪。本文按“范围划定—角色分工—会前材料—会议推进—结论跟踪—示例—自查”的顺序，给出一套可直接套用的分工表、材料清单和记录模板。评审只对版本内容做决策，发布执行、上线准入与回滚预案归研发交付管理，不纳入本次会议议题。
要点总览（TL;DR）
- 版本规划评审分工按决策问题分配角色：产品负责人提案版本目标与范围取舍，研发负责人判断技术可行性与工作量，交付负责人确认依赖与节奏，质量与运营代表提出验收口径与上线风险意见。
- 评审前由产品经理汇总版本目标、需求清单与优先级依据、工作量与依赖清单、风险与待决问题清单，提前分发并确认预读，让分歧在会前暴露。
- 会议按目标、范围、优先级、依赖、风险的顺序逐项推进，范围与优先级冲突由拍板人当场裁决并说明理由，记录人与拍板人分开设置。
- 结论统一为通过、有条件通过、退回补充三类，待办写明责任人、截止时间与可核验的验证方式；发布执行、上线准入与回滚预案作为移交项归研发交付管理。
- 评审后可用角色覆盖、材料时限、结论可执行、待办完整、移交清晰、再评审有据六项自查，判断分工是否真正落地。
评审要定什么：先划清版本规划评审的决策边界
版本规划评审的对象是“这个版本做什么、先做什么、依赖谁、有什么风险”，输出的是决策结论，而非任务排期表。把边界先写进会议通知，能避免会议被发布细节拖长，也能让每个参会角色清楚自己要在哪一类问题上表态。
建议在评审材料首页放一张范围清单，把纳入项与移交项分开列：
| 类别 | 具体事项 | 处理方式 |
|---|---|---|
| 纳入评审 | 版本目标与成功衡量口径 | 会上确认，形成结论 |
| 纳入评审 | 需求范围与本期不做清单 | 会上确认取舍 |
| 纳入评审 | 需求优先级及排序依据 | 会上裁决冲突 |
| 纳入评审 | 跨团队依赖与外部接口 | 会上确认责任方与时间窗 |
| 纳入评审 | 已知风险与待决问题 | 会上定处理方式或升级 |
| 移交研发交付管理 | 发布执行计划、上线准入检查 | 记录为移交项，另行安排 |
| 移交研发交付管理 | 回滚预案与故障处理流程 | 记录为移交项，另行安排 |
| 移交研发交付管理 | 版本排期与资源调度细节 | 评审后由交付侧细化 |
边界清晰后，评审会上的争议会集中在“做不做、先做哪个”上。遇到发布节奏类问题，记录人当场记为移交项并注明承接方，会议继续按议程推进，不在现场展开讨论。
角色分工表：谁提问、谁判断、谁记录、谁拍板
分工的原则是按决策问题找人，而非按部门排座次。每个角色对应一类可判定的问题，并明确其输出物，这样会上不会出现“大家都关心、没人负责”的场面。
| 角色 | 核心职责 | 负责判断的事项 | 输出 |
|---|---|---|---|
| 产品负责人 | 提案并解释版本目标与范围取舍 | 版本目标是否成立、范围取舍是否合理、优先级依据是否充分 | 版本目标陈述、范围与优先级提案 |
| 研发负责人 | 评估技术可行性与投入 | 技术方案是否可行、工作量估算是否可信、架构影响是否可接受 | 可行性结论、工作量区间、技术风险提示 |
| 交付/项目负责人 | 确认跨团队依赖与节奏 | 依赖方是否承诺、时间窗是否冲突、交付节奏是否可衔接 | 依赖清单确认结果、节奏建议 |
| 质量代表 | 提出验收口径意见 | 验收标准是否可验证、测试范围是否覆盖关键场景 | 验收口径意见、测试关注点 |
| 运营代表 | 提出上线风险意见 | 用户影响、上线时机、配套准备是否到位 | 上线风险意见、配套需求 |
| 记录人 | 如实记录结论与待办 | 不参与裁决，负责结论措辞准确、待办可执行 | 评审记录、待办清单 |
| 拍板人 | 对范围与优先级冲突做最终裁决 | 冲突事项的最终结论 | 裁决结论及理由 |
记录人与拍板人应分开设置。拍板人通常是产品负责人或其上级，记录人由产品经理或项目管理人员担任。两者分离的好处是：拍板人可以专注判断，记录人对结论的完整性和可执行性负责，会后不会出现“当时说定了但没人写清楚”的情况。拍板人不在场时，会议应改为收集意见，不形成最终结论。
评审前材料准备：让每个角色带着判断入场
会前材料的目标是让每个角色在到场前已完成本角色的判断准备。材料由产品经理汇总，至少提前两个工作日分发，并要求各角色回复预读确认；未确认的角色，会议开始前由记录人提醒补齐。
| 材料 | 内容要点 | 准备人 | 预读角色 |
|---|---|---|---|
| 版本目标说明 | 版本要达成的业务结果、成功衡量口径 | 产品负责人 | 全体 |
| 需求清单 | 本期候选需求、本期不做清单 | 产品经理 | 全体 |
| 优先级依据 | 排序方法、关键假设、数据或反馈来源 | 产品经理 | 产品、研发、运营 |
| 工作量与依赖清单 | 初步估算区间、跨团队依赖项及对接人 | 研发负责人、交付负责人 | 产品、交付 |
| 风险与待决问题清单 | 已知风险、影响面、需要会上决定的问题 | 产品经理汇总 | 全体 |
分发检查项可以简化为四条：材料是否齐全、版本目标是否有衡量口径、待决问题是否写成问句、分发时间是否满足预读时限。预读确认方式建议用简短回复，例如“已读，研发侧对第 3 项工作量有异议”，让分歧在会前就浮出水面，会上直接进入判断环节。
评审会怎么开：按目标、范围、优先级、依赖、风险逐项过
会议按固定顺序推进，每个议题都走“输入—提问—判断—结论”四步，完成标志是记录人写下该议题的结论措辞。顺序建议如下：
| 顺序 | 议题 | 输入材料 | 主要提问人 | 判断人 | 结论形式 |
|---|---|---|---|---|---|
| 1 | 版本目标 | 版本目标说明 | 拍板人 | 产品负责人 | 目标确认或修改后确认 |
| 2 | 范围取舍 | 需求清单、不做清单 | 研发、交付 | 产品负责人提案，拍板人裁决 | 纳入/移出清单 |
| 3 | 优先级 | 优先级依据 | 运营、质量 | 拍板人 | 排序结果及理由 |
| 4 | 依赖 | 依赖清单 | 交付负责人 | 交付负责人确认，冲突升级 | 依赖确认或待协调 |
| 5 | 风险 | 风险与待决问题清单 | 质量、运营 | 对应角色判断，拍板人定处理方式 | 接受/缓解/升级 |
范围与优先级出现冲突时，由拍板人当场裁决并说明理由，记录人同步写入结论。裁决依据应回到版本目标：与目标关联弱的需求优先移出，而非按提出方级别排序。未决问题当场记录为待办，写明升级对象和答复时限，例如“依赖方接口时间窗未定，由交付负责人两日内与对方确认并回复”。
会议时长控制靠议题顺序而非压缩讨论：目标议题控制在十分钟内完成，范围与优先级占主要时间，依赖与风险各留固定时段。某议题超时且无结论时，记录人标记为待决，进入下一议题，避免整场会议被单个问题占满。
评审结论与待办：记录、确认与跟踪
会议结束当天，记录人发出评审记录，结论字段统一为三类：通过、有条件通过、退回补充。有条件通过必须写明条件内容和满足时限；退回补充必须写明缺什么材料、由谁补、何时再评审。
| 记录字段 | 填写要求 |
|---|---|
| 评审结论 | 通过 / 有条件通过 / 退回补充，附一句理由 |
| 范围结论 | 本期纳入清单与移出清单 |
| 优先级结论 | 排序结果及裁决说明 |
| 待办 | 事项、责任人、截止时间、验证方式 |
| 移交项 | 范围外事项、承接方、移交时间 |
| 再评审触发条件 | 例如范围变更超过约定比例、关键依赖失效 |
待办的验证方式要可核验，例如“补充接口联调时间窗确认邮件”“提交修订后的工作量估算表”，而非“继续跟进”。结论同步范围包括参会角色、版本相关研发与交付人员；同步后如发生范围或优先级变更，按记录中约定的触发条件发起再评审，而非在群聊中口头调整。
评审记录与待办需要在同一处持续跟踪，避免结论散落在文档和聊天记录里。ONES 可将评审材料、结论记录与待办工作项放在同一项目空间中，待办直接指派责任人与截止时间，状态变化对参会角色可见，下次评审前可直接调取上期待办的完成情况作为输入。
示例：一次中等规模版本规划评审的分工落地
以下为演示情景，不对应真实团队或行业。某产品团队计划评审下一个版本规划，参与角色包括产品负责人、研发负责人、交付负责人、质量代表、运营代表，记录人由产品经理担任，拍板人为产品负责人。
会前：产品经理提前三个工作日发出材料包，包含版本目标说明（目标为提升某核心流程的完成率，衡量口径为上线后四周的流程完成率）、十二项候选需求及本期不做清单、优先级依据、研发给出的工作量区间、三项跨团队依赖、五项待决问题。预读确认中，研发负责人对其中两项需求的工作量提出异议，交付负责人标注一项依赖的对接人尚未确认。
会上：目标议题十分钟内确认。范围议题中，研发负责人指出两项需求技术方案未定，建议移出本期；运营代表希望保留其中一项以配合活动节奏。拍板人依据版本目标裁决：技术方案未定的需求移出，运营诉求转为下期候选并记录理由。优先级议题按目标关联度排序，质量代表提出验收口径需覆盖两个关键异常场景，纳入验收标准。依赖议题中，交付负责人确认两项依赖，第三项标记为待协调，形成待办。风险议题中，运营代表提出上线时机与活动窗口冲突，记录为移交项，交研发交付管理另行安排。
会后：记录人当天发出记录，结论为“有条件通过”，条件为第三项依赖在五个工作日内确认。待办共四条，分别写明责任人、截止时间和验证方式。移交项一条，注明承接方为交付负责人。两周后待办全部关闭，版本按调整后的范围进入排期。
完成检查：评审分工是否真正落地
每次评审后可用以下清单自查，全部满足说明分工已落地；存在未满足项时，在下次评审前修正对应环节。
- 角色覆盖：版本目标、范围、优先级、依赖、风险五类问题均有明确判断人，且同一问题不出现两个最终判断人。
- 记录与裁决分离：记录人未兼任拍板人，结论措辞由记录人统一整理。
- 材料时限：材料包在会前约定时限内分发，各角色完成预读确认，分歧在会前已暴露。
- 结论可执行：结论为通过、有条件通过或退回补充之一，有条件通过写明条件与时限。
- 待办完整：每条待办有责任人、截止时间和可核验的验证方式。
- 移交清晰：范围外事项已记录承接方与移交时间，未在会上展开讨论。
- 再评审有据：记录中写明再评审触发条件，变更发生后按条件发起而非临时召集。
若连续两次评审出现同类待办逾期，应检查对应角色的判断事项是否与其职责匹配，必要时调整分工表，而非单纯催促执行。
常见问题
版本规划评审和发布评审可以合并开吗？
可以放在同一天连续开，但建议分成两场，各自有独立的议程和结论记录。版本规划评审回答“做什么、先做什么”，参与角色以产品、研发、交付、质量、运营为主；发布评审回答“怎么发、何时发、出问题怎么回滚”，由研发交付管理主导。合并成一场时，发布细节容易挤占范围与优先级的讨论时间，结论也容易混在一起难以跟踪。若团队规模较小、人员高度重叠，可连续召开并在记录中分栏写明两类结论。
拍板人缺席时，评审还能形成结论吗？
涉及范围取舍和优先级冲突的议题，拍板人不在场时建议只收集意见、不形成最终结论，由记录人整理分歧点和各角色意见，另行安排裁决。目标确认、依赖确认这类不需要最终裁决的议题可以照常推进并记录。若确实无法等到拍板人到场，可事先书面授权一名代理人，并在会议通知和记录中写明授权范围，避免事后对结论有效性产生争议。
评审材料提前多久分发比较合适？
常见做法是至少提前两个工作日，材料量大或依赖方较多时提前三个工作日。判断标准是各角色是否有足够时间完成本角色的判断准备：研发需要时间核对工作量，交付需要时间与依赖方确认时间窗，质量与运营需要时间梳理验收口径和上线风险。分发后要求简短预读确认，把异议在会前提出来，会上直接进入判断环节，而不是现场首次阅读材料。
评审通过后需求又发生变化，怎么处理？
在评审记录中预先约定再评审触发条件，例如范围变更超过约定比例、关键依赖失效、版本目标调整。触发条件满足时按约定发起再评审，沿用同一套材料与议程，只针对变化部分讨论，并在记录中注明与上期结论的差异。未达到触发条件的小幅调整，可由产品负责人在记录中登记变更并同步参会角色，不必每次重新召集全员评审。关键是把变更路径写清楚，避免在群聊中口头调整后无人知晓。
小团队角色重叠时，分工表怎么简化？
角色可以合并，判断事项不宜合并。例如产品负责人同时承担拍板职责时，记录人应由另一名成员担任，保证结论有人独立整理；研发负责人同时对接外部依赖时，依赖确认与可行性判断仍要分别留下结论。简化后的分工表至少保留四类判断：目标与范围、技术可行性与工作量、依赖与节奏、验收与上线风险，并明确每类问题的最终判断人。团队扩大后再按需拆分角色。
