研发阶段评审与决策机制要解决的核心问题，是每个阶段结束时“是否继续投入”。做法是把继续、有条件继续、暂停、终止变成固定时点、固定输入、固定决策人和固定记录的例行动作。本文按决策点划分、准入证据、角色与决策选项、记录跟踪、运行检查的顺序给出可套用的步骤与模板。机制只处理阶段级决策，单次发布许可归发布审批与质量门禁，单需求评审归需求评审与确认。决策点、证据与记录需要工作项和文档承载时，可放在ONES的项目与文档管理中统一管理。
要点总览（TL;DR）
- 先按研发阶段列出决策点清单，每个节点只回答项目是否继续投入下一阶段，把单次发布许可和单需求评审排除在外。
- 为每个决策点配置准入证据，写清提交人、提交时点和缺失处理规则，关键证据缺失不得进入决策会。
- 固定决策人、评审专家、材料准备人、记录人四类角色，并为继续、有条件继续、暂停、终止四种结论写明判定口径。
- 决策记录统一字段，有条件继续的条件当场转为待办并跟踪关闭，暂停与终止明确恢复条件或资源处置方式。
- 机制上线后按检查清单核对决策点召开、证据提交、结论明确性和边界遵守情况，前两个阶段周期逐项检查，之后转为季度抽查。
先划清阶段决策点的边界
建立机制的第一步是列出阶段决策点清单，明确哪些节点进入本机制。判断标准只有一条：这个节点要回答“项目是否继续投入下一阶段”。凡是回答“这次能不能发”“这个需求是否确认”的节点，都不列入。
决策点按研发阶段设置，常见划分是立项、方案、开发完成、验证、转产或上线前。阶段数量不同，决策点数量随之调整，不必凑齐五个。节点过密会让评审变成走流程，团队把同一批材料反复讲；节点过疏则问题积累到后期才暴露，返工成本高。一个可操作的密度是每个阶段结束时设一个决策点，阶段内部的关键技术选择由方案评审或技术评审处理，不单独设阶段决策。
每个决策点只回答四种结论之一：继续、有条件继续、暂停、终止。把结论选项提前写进清单，可以避免会上讨论发散到资源调配、人员安排等不属于阶段决策的话题。
三类评审的分工建议在清单中直接写明，减少执行时的混淆：
| 评审类型 | 回答的问题 | 典型时点 | 结论形式 |
|---|---|---|---|
| 阶段决策评审 | 项目是否继续投入下一阶段 | 各阶段结束时 | 继续、有条件继续、暂停、终止 |
| 发布审批与质量门禁 | 本次版本能否发布 | 每次发布前 | 放行、有条件放行、拦截 |
| 需求评审与确认 | 单个需求是否成立、范围是否确认 | 需求提出与变更时 | 通过、修改后通过、驳回 |
交付物是一张阶段决策点清单，至少包含四列：节点名称、所处阶段、该节点要回答的决策问题、边界说明（哪些事项不在本节点决策）。清单经研发负责人确认后发布，作为后续证据设计和会议安排的依据。
为每个决策点定义准入证据与评审材料
评审要有据可依，就要在决策点清单确定后，为每个节点列出准入证据。证据的作用是让决策人看到事实，而不是听汇报人的印象。证据项按节点差异配置，常见类型包括：需求与范围确认记录、方案与架构结论、测试与验证结果、风险与遗留问题清单。
每项证据要写清三件事：提交人、提交时点、缺失时的处理规则。提交时点建议设在决策会前一到两个工作日，给决策人留出阅读时间；材料在会前才发出，会议容易变成现场读材料。缺失处理规则要提前约定，常见做法是：关键证据缺失时不得进入决策会，由提交人补交后顺延；非关键证据缺失时可降级为有条件继续，把补齐证据作为条件写入结论；影响判断的核心证据无法补齐时，转为暂停。
材料版本与归档同样要写进规则。每次决策会使用的材料应标注版本号和日期，会后与决策记录一并归档，便于后续追溯当时依据的是哪一版测试报告或方案文档。材料分散在个人电脑或聊天工具里，会让复盘失去依据。
交付物是一张决策点证据清单表，可按以下结构填写：
| 决策点 | 证据项 | 提交人 | 提交时点 | 缺失处理 |
|---|---|---|---|---|
| 方案决策点 | 方案与架构结论、风险清单 | 技术负责人 | 会前2个工作日 | 架构结论缺失则顺延；风险清单缺失降级为有条件继续 |
| 开发完成决策点 | 需求范围确认记录、自测结果、遗留缺陷清单 | 项目经理、测试负责人 | 会前2个工作日 | 自测结果缺失不得开会；遗留缺陷清单缺失降级为有条件继续 |
| 验证决策点 | 测试与验证报告、问题关闭情况 | 测试负责人 | 会前2个工作日 | 验证报告缺失转为暂停 |
表格中的节点和证据项按实际阶段划分调整，关键是每个节点都有对应证据，且缺失规则事先写明，不在会上临时争论。
设定决策角色、决策方式与决策选项
评审会开成信息通报会，通常是因为没有明确谁拍板。角色分工建议固定为四类：决策人、评审专家、材料准备人、记录人。决策人对结论负责，一般由研发负责人或产品与技术共同指定的单一责任人担任，避免集体负责等于无人负责；评审专家提供专业判断，不承担拍板责任；材料准备人按证据清单提交材料并现场答疑；记录人负责形成决策记录并跟踪待办。
决策方式有两种，可按项目重要程度选择。会议评审适合跨职能、分歧较多的节点，能当场澄清问题；书面会签适合范围清晰、争议小的节点，节省会议时间。两者结合也常见：会前书面传阅材料并收集意见，会上只讨论分歧项并形成结论。选择哪种方式应写进机制，同一决策点不要每次临时决定。
决策选项需要判定口径，否则“有条件继续”会被滥用成“先继续再说”：
- 继续：准入证据齐全，无影响下一阶段的重大风险，按计划进入下一阶段。
- 有条件继续：存在可限期解决的问题，但不影响下一阶段启动；结论中必须写明条件内容、责任人和完成期限，到期复核。
- 暂停：存在影响判断的关键证据缺失或重大风险未澄清，暂停投入，明确恢复条件后重新评审。
- 终止：目标已不成立或投入产出明显失衡，停止项目并处理资源与范围。
分歧处理与升级路径也要提前约定。评审专家意见不一致时，由决策人综合判断并记录不同意见；决策人无法决断或分歧涉及跨部门资源时，升级到上一级研发管理会议，并明确升级后的答复时限。交付物是一份角色与决策规则说明，包含角色职责表和决策选项判定口径，随决策点清单一并发布。
把决策结论落到记录与后续跟踪
决策只有被记录和跟踪，机制才算闭环。决策记录建议包含以下字段：决策点名称、评审日期、参与人、证据材料版本、决策结论、附加条件与责任人、下次复核时间。字段固定后，记录可以按统一模板填写，避免每次自由发挥导致关键信息遗漏。
有条件继续是最需要跟踪的结论。会上的条件应当场转为待办事项，写明责任人和完成期限，纳入项目待办清单定期检查；到期未关闭的，触发复核，由决策人判断是延长条件、转为暂停还是升级处理。条件长期挂起不关闭，等于把风险带入下一阶段。
暂停与终止后的处理也要写进规则：暂停需明确恢复条件和重新评审的时间点，期间冻结新增投入；终止需明确范围收缩、资源释放和已交付成果的处置方式，避免项目名义上终止、人员仍在零星投入。
决策记录的查阅与归档方式应统一。记录与当次材料版本一并存放在项目文档中，项目成员可查，后续复盘和审计以此为准。交付物是决策记录模板字段表与跟踪规则，模板字段与上面的记录字段一致，跟踪规则写明待办生成、检查频率和到期处理方式。
示例：一个四阶段决策点的运行过程
以下为演示情景，用于说明规则如何串联，不代表特定企业的实际做法。
某研发项目按立项、方案、开发完成、验证四个阶段设置决策点。在开发完成决策点，材料准备人按证据清单在会前两个工作日提交需求范围确认记录、自测结果和遗留缺陷清单，测试负责人补充说明遗留缺陷的等级分布。决策人、两位评审专家和记录人参会，采用会议评审方式。
会上评审专家确认自测结果完整，但遗留缺陷清单中有两项中等级缺陷未关闭，影响验证阶段的测试覆盖。决策人形成结论：有条件继续，条件是在五个工作日内关闭这两项缺陷并补充回归结果，责任人为开发负责人，下次复核时间定在条件到期日。记录人当场把条件转为两条待办，附在项目待办清单中。
五个工作日后，开发负责人提交关闭证明，记录人核对后关闭待办，并在决策记录中补记复核结果，项目进入验证阶段。若条件到期未关闭，则按规则触发复核，由决策人决定延长条件或转为暂停。
这个示例可迁移的规律是：证据先于会议、结论落到选项、条件转为待办、复核回到记录。适用边界在于，它演示的是阶段级决策；同一项目中的单次发布仍需走发布审批与质量门禁，单个需求的变更仍需走需求评审与确认，三类流程各司其职。
机制上线后的完成检查
机制发布不等于在运行。建议在机制上线后的前两个阶段周期内，按下列清单逐项核对，之后转为季度抽查。检查项、通过标准、证据来源和负责人如下：
| 检查项 | 通过标准 | 证据来源 | 负责人 |
|---|---|---|---|
| 决策点是否按计划召开 | 计划内决策点全部召开，延期有说明 | 决策记录、项目计划 | 项目经理 |
| 证据是否在决策前提交且版本可查 | 关键证据在会前规定时点提交，标注版本 | 文档归档记录 | 材料准备人 |
| 结论是否包含明确选项与责任人 | 每条结论属于四种选项之一，附条件有责任人 | 决策记录 | 记录人 |
| 有条件继续的条件是否跟踪关闭 | 条件待办在期限内关闭或有复核记录 | 待办清单、复核记录 | 决策人 |
| 与发布审批、需求评审的边界是否被遵守 | 阶段决策会不处理单次发布许可和单需求确认 | 会议记录抽查 | 研发负责人 |
检查发现的问题按性质处理：决策点漏开属于执行问题，补开并记录原因；证据长期缺失属于规则问题，调整证据清单或提交时点；结论含糊属于口径问题，回到角色与决策规则说明中补充判定标准。检查结果在研发管理例会上通报，连续两个周期全部通过的检查项可降低抽查频率。
当决策点、证据材料和决策记录需要在同一处沉淀时，可以在ONES中为每个决策点建立工作项，把证据文档关联到对应工作项，决策结论和条件待办记录在文档与任务中，使阶段决策的输入、结论和跟踪保持可查。这样做的价值在于复盘时能直接看到某次决策依据的材料版本和后续关闭情况，而不必在多个工具间拼凑信息。
常见问题
阶段决策点设几个比较合适？阶段划分不同怎么办？
决策点数量跟随阶段划分，不必固定为五个。一个可操作的密度是每个阶段结束时设一个决策点，阶段内部的关键技术选择交给方案评审或技术评审处理，不单独设阶段决策。阶段少的项目决策点相应减少，阶段多的项目相应增加。判断节点是否过密，可以看团队是否在反复讲同一批材料；判断是否过疏，可以看问题是否总在后期才暴露。
关键证据在决策会前没有准备好，应该延期还是照常开会？
按事先约定的缺失处理规则执行，不在会上临时争论。常见做法是：关键证据缺失时不得进入决策会，由提交人补交后顺延；非关键证据缺失时可降级为有条件继续，把补齐证据写入结论并设期限；影响判断的核心证据无法补齐时，转为暂停。规则应在证据清单中提前写明，并明确哪些证据属于关键证据。
有条件继续和暂停的界限怎么把握？
看问题是否影响下一阶段启动。存在可限期解决的问题、但不影响下一阶段启动的，用有条件继续，结论中写明条件内容、责任人和完成期限，到期复核。存在影响判断的关键证据缺失或重大风险未澄清的，用暂停，明确恢复条件后重新评审。两者的共同点是都要有明确的后续动作和时间点，区别在于是否允许继续投入。
决策人无法当场拍板或评审专家意见分歧较大时怎么处理？
机制中应提前约定升级路径。评审专家意见不一致时，由决策人综合判断，并把不同意见记入决策记录；决策人无法决断，或分歧涉及跨部门资源时，升级到上一级研发管理会议，同时明确升级后的答复时限。升级期间该决策点按暂停处理，避免在结论未定时继续投入。
机制运行一段时间后，怎么判断它是否真的在起作用？
按检查清单核对可观察的证据：计划内决策点是否全部召开、关键证据是否在会前规定时点提交并标注版本、每条结论是否属于四种选项之一且附条件有责任人、有条件继续的条件是否在期限内关闭或有复核记录、阶段决策会是否处理了本应归发布审批或需求评审的事项。检查发现的问题按性质区分处理：漏开属于执行问题，证据长期缺失属于规则问题，结论含糊属于口径问题，分别对应补开、调整证据清单、补充判定标准。
