版本规划评审的分工，可以写成一张“谁准备、谁评审、谁定稿”的分工表。下面给出一份已填写的示例：产品负责人准备版本目标与范围清单，研发负责人评估技术可行性与工作量，测试负责人确认验收口径，业务代表判断价值与优先级，版本决策人拍板范围并记录不做清单。示例为假设情景，用于演示填写方式，读者可据此改造为自己团队的分工表。
要点总览（TL;DR）
- 分工表的核心结构是“谁准备、谁评审、谁定稿”：产品负责人出范围初稿，研发与测试在会前提交可行性与验收口径，业务代表判断优先级，版本决策人拍板并记录结论。
- 评审要同时产出三项结论：版本范围、优先级排序、不做清单；只写做什么而不写不做什么，后续容易被临时需求挤占资源。
- 可迁移的填写规则有四条：一人一责且结论有归属、输入材料先于评审会准备、范围与不做清单同时记录、结论与待办带责任人时限持续跟踪。
- 示例设定为单一产品、六周周期、五类角色的假设情景，团队规模、版本节奏或外部依赖变化时，按“有明确输入、有明确输出、有提交时限”的原则合并或补充角色。
- 发布执行、发布准入与回滚属于研发交付管理，在版本范围确定后另行组织，不放进规划评审的分工表。
示例目标：这份分工表要解决什么问题
这份分工表示例要交付的是一张可直接填写的表：每一行对应一个角色，列清楚该角色在评审前准备什么材料、评审会上关注什么、会后交出什么、什么时候交。填写完成后，团队拿到这张表就能知道一场版本规划评审该由谁发起、谁必须到场、谁的意见决定范围、结论记在哪里。
评审要产出的结论有三项。第一是版本范围，即这个版本做哪些需求、做到什么程度。第二是优先级排序，即在资源有限时先做哪些、后做哪些。第三是不做清单，即明确本版本不纳入的需求及原因。三项结论缺一不可，只写“做什么”而不写“不做什么”，后续很容易在执行中被临时插入的需求挤占资源。
需要划清的边界是：本文的分工表只覆盖“版本做什么”这一层决策。发布执行、发布准入标准与审批、版本回滚方案属于研发交付管理的范畴，由研发团队在版本范围确定后另行组织，不在本文的示例范围内。这样划分的原因是，规划评审回答的是“值不值得做、能不能做”，交付管理回答的是“怎么安全地发出去”，两者的参与角色和判断依据不同，混在一张表里会让评审会失焦。
示例的产出清单包括：一张填好的分工表、一份评审结论记录、一份范围调整记录、一份带责任人和时限的待办清单。这四样东西构成一次完整评审的最小交付物。
完整示例：一个版本规划评审的分工表
以下为假设情景示例，用于演示填写方式，不代表真实客户案例。情景设定：某产品团队准备规划下一个版本，版本周期为六周，参与评审的角色共五类。表中“时限”以评审会为参照点，会前为准备期，会中为评审期，会后为跟踪期。
| 角色 | 评审前输入材料 | 评审关注点 | 输出物 | 时限 |
|---|---|---|---|---|
| 产品负责人 | 版本目标说明、需求清单（含背景与预期价值）、初步优先级建议 | 目标是否清晰、需求之间是否重复或冲突 | 评审议程、范围初稿 | 会前3个工作日发出 |
| 研发负责人 | 技术可行性评估、工作量估算、外部依赖与风险清单 | 哪些需求存在技术不确定性、工作量是否超出周期容量 | 可行性结论、风险项与建议拆分 | 会前1个工作日提交 |
| 测试负责人 | 各需求的验收口径草案、测试资源与周期预估 | 验收标准是否可验证、测试时间是否被压缩 | 验收口径确认意见、测试排期约束 | 会前1个工作日提交 |
| 业务代表 | 业务侧价值判断、客户或用户反馈摘要、优先级诉求 | 需求的价值排序是否与业务目标一致 | 优先级调整建议 | 会中提出，会后1个工作日补充书面意见 |
| 版本决策人 | 汇总后的范围初稿、各方意见与分歧点 | 范围与资源是否匹配、分歧如何裁决 | 评审结论、不做清单、待办与责任人 | 会后1个工作日发布 |
配套的结论记录示例可以这样填：版本范围确定为需求清单中的A、B、C三项，D项因技术风险推迟到下个版本，E项因价值判断不足列入不做清单并注明原因；待办包括“研发负责人两周内给出D项的技术预研结论”“产品负责人补充E项的用户反馈依据”，均标注责任人与完成时间。范围调整记录则记下评审会上发生的每一次增减，包括提出人、调整理由和决策人确认。
逐项解释：每个角色为什么这样分工
产品负责人负责目标与范围初稿，是因为版本目标需要从业务价值和用户问题出发来定义，而产品负责人日常就在做需求收集与判断，掌握最完整的需求背景。由他先出初稿，评审会才有讨论的起点；如果让所有人从零开始讨论，会议时间会大量消耗在对齐背景上。初稿的作用是“可被修改的提案”，而非最终决定。
研发与测试在评审前提供材料，是把可行性判断前置。研发负责人的工作量估算和技术风险清单，决定了范围初稿中哪些需求在本周期内现实可做；测试负责人的验收口径草案，决定了每个需求“做到什么程度算完成”。这两类材料如果等到会上才口头给出，评审就容易变成拍脑袋定范围。放在会前提交，各方可以带着问题来，而不是带着空白来。
业务代表参与优先级判断，理由在于优先级本质上是价值排序，而价值判断需要业务侧的一线信息，比如客户反馈、销售诉求、运营节奏。产品负责人可以提供价值假设，业务代表提供价值证据，两者对照才能减少“谁声音大谁优先”的情况。示例中安排业务代表会中提出、会后补充书面意见，是考虑到业务侧时间碎片化，书面意见能保证判断留痕。
版本决策人拍板并记录结论，是整张表的关键一环。评审会上出现分歧是常态，分歧需要有明确的裁决人，否则结论会悬空。决策人的职责有两层：会上对范围与优先级做最终裁定，会后把结论、不做清单和待办整理发布。把“拍板”和“记录”放在同一角色身上，是为了保证结论的表述与决策意图一致，避免转述失真。
哪些事项留给研发交付管理？发布排期、发布准入检查、上线操作和回滚预案，都由研发团队在版本范围确定后按交付流程组织。规划评审的输出是“做什么”的结论，交付管理的输入正是这份结论。把两者分开，评审会不必讨论发布细节，交付团队也有清晰的起点。
当评审结论、范围调整和待办需要跨会议跟踪时，可以把它们放进统一的工作项与文档中留痕：结论作为版本工作项的说明，调整记录关联到对应需求，待办直接生成带责任人和截止时间的工作项。ONES 支持工作项与文档的关联管理，适合承载这类评审留痕；具体字段与流程配置可按团队实际需要设置。
可迁移规律：换团队、换版本也能套用的写法
从上面的示例可以提炼出几条填写规则，换团队、换版本时按规则改造即可，不必照抄角色名称。
- 一人一责，结论有归属。每个角色只对应一项主要职责，每项输出物都有明确的责任人。出现两个人共同负责同一输出物时，要指定其中一人为最终提交人。
- 输入材料先于评审会准备。把可行性、工作量、验收口径这类判断性材料放在会前提交，会上只处理分歧和裁决。可以给每类材料设一个提交截止时间，以评审会日期倒推。
- 范围与不做清单同时记录。结论记录里既写纳入的需求，也写排除的需求及原因。不做清单是后续拒绝临时插入需求的依据。
- 评审结论与后续跟踪衔接。每条待办都带责任人和时限，并在下一次版本例会上回顾完成情况。结论发布后，范围变更走同一套记录方式，保持可追溯。
改造时可以先保留“准备—评审—定稿”三段结构，再按团队实际替换角色。例如小团队中产品负责人与业务代表可能由一人兼任，此时应在表中注明兼任关系，避免职责遗漏；大团队中可能拆出多个业务代表，则需指定一人汇总意见后再提交。
适用边界：示例在什么情况下需要调整
示例设定的是单一产品、六周版本周期、五类角色的情景。团队规模不同，调整方向也不同：人数较少的团队可以合并研发与测试的输入材料，由同一人提交可行性与验收口径；版本节奏更快的团队（如两周一个版本）需要压缩会前准备时间，可把工作量估算改为在需求进入清单时就完成，评审会只做确认。
跨部门或外部依赖较多时，需要补充角色。例如版本依赖外部供应商交付接口，可增加接口对接人，负责在会前提供依赖就绪时间与风险；涉及多个业务线时，可增加各业务线的需求汇总人，避免业务代表一人无法覆盖全部诉求。补充角色的原则与示例一致：有明确输入、有明确输出、有提交时限。
再次说明，本文的分工表为演示情景，不是真实客户案例，表中团队设定、周期和角色数量均为假设，读者应按自己团队的实际组织结构调整。发布执行、发布准入与审批、版本回滚方案不在本文范围内，这些事项在版本范围确定后由研发交付管理另行组织。
常见问题
评审会上出现分歧、无法当场达成一致时，分工表该怎么处理？
分工表里已经指定了版本决策人，分歧的处置路径就是由决策人裁定。建议在会上把分歧点、各方意见和裁定结果一并记入范围调整记录，注明提出人和理由。如果分歧涉及技术不确定性，可以先列入待办，由研发负责人在约定时间内给出预研结论，再决定是否纳入本版本；如果涉及价值判断，则由业务代表补充书面依据后由决策人复核。关键是分歧不能悬空，必须落到“纳入、推迟、不做”三者之一。
团队规模很小，产品负责人同时承担业务代表职责，分工表怎么填才不遗漏？
可以在表中保留两个角色行，在角色名称后注明由同一人兼任，并分别填写两类输入材料和输出物。这样做的目的是让职责显性化：版本目标与范围初稿由产品视角产出，优先级诉求与价值证据由业务视角产出，即使由同一人完成，也需要分别准备、分别记录。评审时其他角色可以针对两类材料分别提问，避免因兼任而弱化价值判断这一环。
两周一个版本的快节奏团队，会前准备时间不够怎么办？
调整方向是把判断性材料前移到需求进入清单的环节。工作量估算和技术风险在需求提出时就由研发负责人给出初步结论，验收口径在需求描述中同步写明，评审会只做确认和裁决，不再从零评估。分工表的时限列相应改为“需求入池时提交”，评审会前只留半天用于汇总分歧点。这样做的代价是需求入池的门槛提高，需要产品负责人在提交前完成更充分的背景说明。
不做清单记录之后，后续有人要求临时插入需求，怎么衔接？
不做清单本身就是衔接依据。临时插入需求时，先对照不做清单看是否属于已排除项及排除原因是否仍然成立；如果原因已变化，走与评审相同的记录方式，写明提出人、调整理由和决策人确认，并同步更新版本范围与优先级。范围调整记录保持连续，下一次版本例会回顾时可以看到每次变更的来龙去脉。这样处理的作用是让变更可见、可追溯，而非一律拒绝。
评审结论和待办放在哪里跟踪比较合适？
常见做法是把结论作为版本工作项的说明，范围调整记录关联到对应需求，待办直接生成带责任人和截止时间的工作项，并在下一次版本例会上逐条回顾完成情况。ONES 支持工作项与文档的关联管理，可用于承载这类评审留痕，具体字段与流程配置按团队实际需要设置。选择承载方式时，重点看两点：结论能否被后续执行的人直接查到，待办是否有明确的关闭标准。
