阶段决策跟踪要解决的问题是：阶段关口上作出的继续、调整或终止决定，在会后是否有人落实、能否被复核。它跟踪的对象是一次具体决策，而非一个阶段的全部工作。本文给出一套可直接运转的做法，包括跟踪范围、决策台账字段、会前会中会后三段流程、角色分工、完整示例和完成检查清单，适合负责研发阶段管理、评审组织或项目治理的人员参照建立机制。
要点总览（TL;DR）
- 阶段决策跟踪的对象是阶段关口上的继续、调整、终止三类决策，每条决策单独成行，发布审批与单需求评审留在各自流程内。
- 决策台账至少覆盖决策标识、阶段与关口、决策事项、依据与证据、结论、决策人、后续动作、责任人、截止时间、复核时点和状态。
- 运转靠会前材料齐套与议题清单、会中逐项形成结论并当场确认责任人与时限、会后录入分发提醒复核四步衔接。
- 记录、落实、复核三项职责分给不同角色，未关闭项在下一阶段入口处交接，避免决策在会后断链。
- 用决策落实率与超期未处置项数量判断机制是否有效，在阶段入口评审前逐项核对。
阶段决策跟踪要管住哪些决策
阶段决策跟踪的范围应当收窄到阶段关口上的方向性决策。典型场景是阶段评审、里程碑评审、关口评审结束时，评审参与者对“这个阶段是否通过、项目是否继续投入”作出的判断。这类判断影响资源投入和后续计划，一旦作出就需要留下记录并跟踪落实，因此纳入跟踪范围。
关口决策通常分为三类，跟踪时的处理方式不同：
- 继续：阶段目标基本达成，进入下一阶段。跟踪重点是准入条件是否满足、遗留事项是否带入下一阶段。
- 调整：方向可行但范围、计划、资源或技术方案需要修改。跟踪重点是调整项是否形成明确的动作、责任人和时限。
- 终止：不再继续投入或暂停。跟踪重点是收尾动作，包括资源释放、资料归档、相关方通知。
需要与两类相邻流程划清边界。发布审批与质量门禁针对的是某次发布是否放行，判断对象是版本或交付物，结论是放行或不放行，属于发布管理流程；单需求评审针对的是一个需求的方案与确认，属于需求管理流程。这两类流程也会产生决策，但它们的记录和跟踪在自己的流程内完成。阶段决策跟踪只在关口决策涉及跨阶段资源与方向时介入，避免把所有评审结论都塞进同一张台账。
跟踪的最小对象是一次决策，而非一个阶段的全部工作。一个阶段关口可能同时产生多条决策，例如“本阶段通过”“某技术方案下阶段重新验证”“某供应商合作终止”，每条决策单独成行、单独指定责任人和复核时点。这样做的原因是不同决策的落实周期和复核方式差异很大，合并记录会导致部分事项被整体进度掩盖。
一张决策台账需要哪些字段
决策台账是整套机制的承载物。字段设计的原则是：任何人在不看会议纪要的情况下，仅凭一行记录就能知道决策了什么、依据是什么、谁在什么时候要完成什么、何时复核。下表给出可直接建表的字段清单。
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 决策标识 | 唯一编号，建议包含阶段代号与序号，如 D2-003 | 跨文档、跨会议引用同一条决策 |
| 所属阶段与关口 | 写明阶段名称与关口名称，如“设计阶段出口评审” | 按阶段汇总与检索 |
| 决策日期 | 决策形成的会议日期 | 计算落实周期与超期 |
| 决策事项 | 一句话描述要决定的问题，避免写成工作项 | 明确决策对象 |
| 备选方案 | 列出会上讨论过的主要选项及各自利弊 | 支撑复核时理解决策背景 |
| 决策依据与关键证据 | 写明支撑结论的数据、测试结果、评估结论或文档名称 | 可追溯，防止事后争议 |
| 决策结论 | 继续、调整或终止，调整类需写明调整内容 | 核心结论字段 |
| 决策人与参与角色 | 记录最终决策人及参与评审的角色 | 明确权责来源 |
| 后续动作 | 逐条列出决策生效后必须完成的事项 | 把结论转为可执行动作 |
| 责任人 | 每个后续动作对应一名责任人，写到人 | 避免集体负责 |
| 截止时间 | 具体日期，与下一阶段启动时点对齐 | 判断是否按期 |
| 复核时点 | 计划复核的日期或触发条件，如“下一阶段入口评审前” | 安排复核 |
| 状态 | 待落实、落实中、待复核、已关闭、已超期 | 日常跟踪与统计 |
填写上有两点要求值得强调。决策依据字段要写到可核查的程度，例如引用某份测试报告的名称与结论，而非只写“评估通过”。后续动作字段要与决策结论区分开：结论回答“决定什么”，后续动作回答“因此要做什么”，两者混写会让跟踪失去抓手。
会前、会中、会后怎么运转
台账是静态结构，机制能否运转取决于三段流程的衔接。每一步都应有明确的输入、动作、输出和完成标志，缺一项就容易出现“会开完了、事没人跟”的情况。
会前：材料齐套与议题清单
输入是阶段进展报告、关键指标数据、风险与问题清单、待决策事项提案。动作由评审召集人完成：核对材料是否覆盖每个待决策事项，把议题整理成清单，标明每项议题需要形成的结论类型和决策人。输出是议题清单与齐套的材料包。完成标志是所有议题都有对应材料，且决策人已确认参会。
会中：逐项形成结论并当场确认
输入是议题清单。动作是按议题逐项讨论，每项结束时当场确认三件事：结论是继续、调整还是终止；后续动作有哪些；每项动作的责任人和截止时间。输出是逐项确认的会议结论。完成标志是每个议题都有明确结论，没有“再议”“待定”这类悬置项；确实无法当场决策的，要指定决策时限和决策人，作为一条待决记录进入台账。
会后：录入、分发、提醒与复核关闭
输入是会议结论。动作分四步：跟踪管理员在会后一个工作日内将结论录入台账；将台账中与本角色相关的条目分发给各责任人；在截止时间前设置到期提醒；到达复核时点后组织复核，确认动作完成情况并更新状态。输出是更新后的台账与复核记录。完成标志是所有决策条目状态为已关闭，或超期项已进入处置流程。
角色分工与各自交付物
跟踪链条上通常涉及五类角色。分工的关键是记录、落实、复核三项职责分开，避免同一人既执行又验收。
| 角色 | 会前 | 会中 | 会后 | 主要交付物 |
|---|---|---|---|---|
| 阶段负责人 | 提交阶段进展与待决策事项 | 陈述阶段情况，回应质询 | 承接本阶段相关后续动作 | 阶段报告、待决策事项提案 |
| 评审召集人 | 核对材料齐套，编制议题清单 | 主持议程，控制逐项形成结论 | 确认会议结论文本 | 议题清单、会议结论 |
| 决策人 | 确认参会与议题 | 作出继续、调整或终止结论 | 对重大调整项参与复核 | 决策结论 |
| 跟踪管理员 | 准备台账模板与历史未关闭项 | 现场记录结论与责任人 | 录入台账、分发、提醒、组织复核 | 决策台账、复核记录 |
| 执行责任人 | — | 确认承接的动作与时限 | 按期完成动作并提交完成证据 | 动作完成说明与证据 |
交接时点有两个关键节点。会议结束到台账录入之间，由评审召集人向跟踪管理员移交会议结论，移交完成的标志是结论文本经召集人确认。复核完成后，由跟踪管理员向下一阶段的阶段负责人移交未关闭项，移交完成的标志是下一阶段入口处能看到上一阶段的遗留清单。
当决策台账与后续动作分散在会议纪要、邮件和表格中时，跟踪容易断链。ONES 可以用工作项承载每条决策及其后续动作，把责任人、截止时间和状态放在同一处，决策依据以文档形式关联到对应工作项，复核时直接查看状态与证据，减少在多处记录之间核对的工作量。是否引入工具取决于决策数量和跨团队程度，决策条目少、参与方集中的团队用共享表格也能运转。
一个完整示例：某阶段关口决策如何被跟踪到关闭
以下为演示情景，用于说明字段与流程如何衔接，不代表任何具体项目。
背景与决策事项。某产品研发项目进入设计阶段出口评审。阶段负责人提交的报告显示核心功能设计已完成，但关键性能指标在测试环境中仅达到目标的八成。待决策事项为：是否按原计划进入开发阶段。
依据与结论。会上讨论了两个备选方案：一是按原计划进入开发，性能问题在开发阶段并行优化；二是推迟两周进入开发，先完成性能方案验证。决策依据记录为测试报告编号及结论、性能优化方案的可行性评估。决策人最终选择方案二，结论填写为“调整：推迟进入开发阶段，完成性能方案验证并通过复测后进入”。
后续动作与复核设置。台账中登记三条动作：完成性能优化方案设计，责任人为主设计人员，截止时间为决策后第五个工作日；完成方案复测，责任人为测试负责人，截止时间为决策后第十个工作日；更新开发阶段计划，责任人为项目经理，截止时间为复测通过后两个工作日。复核时点设为“开发阶段入口评审前”，状态为待落实。
复核与关闭。复测到期后，跟踪管理员组织复核，确认复测结果达到目标，方案设计与计划更新均已完成并附有证据。台账状态更新为已关闭，复核记录中写明复测结论与关闭日期。未关闭项为零，该条决策跟踪结束，下一阶段入口处不再出现遗留项。
怎么判断跟踪做到位了
机制是否有效，可以用一份检查清单逐项核对。检查频率建议与关口节奏一致，在每个阶段入口评审前执行一次。
- 记录完整性：本阶段所有关口决策均有台账记录，决策事项、依据、结论、决策人四项无空缺；抽查两条记录，能在不查会议纪要的情况下说清决策背景。
- 可追溯性：每条决策的依据能指向具体文档或数据，后续动作与结论一一对应，没有只有结论没有动作的条目。
- 按期落实：统计本阶段决策的后续动作按期完成比例，逐条核对超期项是否有说明。
- 超期处置：超期项是否已升级到阶段负责人或决策人，是否重新设定了时限；连续两次超期的动作是否调整了责任人或方案。
- 复核回写：复核结论是否记录在台账中，未关闭项是否已带入下一阶段入口清单，下一阶段计划是否体现了这些约束。
判断标准可以简化为两个指标：决策落实率，即已关闭决策占全部决策的比例；超期未处置项数量。前者反映机制覆盖程度，后者反映执行力度。两个指标在阶段入口评审时作为输入材料提交，跟踪机制就形成了从决策到复核再到下一阶段的闭环。
常见问题
阶段决策跟踪和发布审批、需求评审怎么区分，会不会重复记录？
三者的判断对象不同。阶段决策跟踪针对阶段关口上的方向性决策，结论是继续、调整或终止，影响资源投入和后续计划；发布审批与质量门禁判断的是某次发布是否放行，结论是放行或不放行；单需求评审针对一个需求的方案与确认。后两类流程的结论在自己的流程内记录和跟踪。
实际操作中，只有当关口决策涉及跨阶段资源与方向调整时才进入决策台账。如果一次评审既确认了阶段通过，又顺带批准了某个需求的方案，可以只把阶段通过这一条记入台账，需求结论留在需求流程里，避免同一件事在两处重复维护。
决策会上无法当场定论的事项，怎么进入跟踪？
无法当场决策的事项同样要形成一条记录，写明待决问题、已讨论的备选方案、尚缺的信息、指定的决策人和决策时限，状态标为待落实。这样它不会因为会议结束而消失。
到决策时限后，由跟踪管理员提醒决策人给出结论，再把结论补入台账并转入后续动作跟踪。需要留意的是，待决记录不宜长期挂起，若同一事项连续两次到期仍未决策，应升级到更高一层决策人或重新评估该事项是否还必要。
决策条目不多的小团队，也需要建台账和分这么多角色吗？
机制可以按规模裁剪。决策条目少、参与方集中的团队，用一张共享表格承载台账字段即可运转，角色也可以合并，例如由评审召集人兼任跟踪管理员。
需要保留的底线是记录与复核分开：作出决策的人不独自验收自己的决策是否落实，未关闭项在进入下一阶段前有人确认。角色合并时把这条底线写进流程说明，规模扩大后再拆分为独立角色。
复核时发现后续动作没完成，应该怎么处理？
先判断未完成的原因属于执行延误还是决策前提变化。执行延误的，更新截止时间并明确新的责任人或补救措施，状态保持落实中；连续两次超期的动作，应调整责任人或方案，而不是继续顺延。
决策前提变化的，例如外部条件或技术路线发生改变，需要把该条决策退回决策人重新判断，形成新的决策记录并关联原记录，原记录标注为已被替代。无论哪种情况，复核结论都要回写到台账，未关闭项带入下一阶段入口清单。
决策依据要记录到什么程度才算可追溯？
标准是复核时不需要再翻会议纪要就能理解决策背景。依据字段应指向可核查的具体材料，例如测试报告的名称与关键结论、评估文档的版本、数据指标的统计口径与时间范围。
只写“评估通过”“数据良好”这类概括判断，事后无法判断结论是否仍然成立。对于依赖口头信息作出的决策，也应把信息来源和获取时间记录下来，便于复核时确认前提是否变化。
