项目集决策记录要能回答五个问题：谁在什么授权范围内、依据哪些信息、对什么事项、做出了什么决定、后续由谁在何时验证结果。围绕这五点建立字段，记录就能支撑追溯、复查和交接。下面给出字段清单、四步建法、角色分工、填写示例和合格检查，可按组织实际裁剪。
要点总览（TL;DR）
- 决策记录围绕五个问题设计字段：谁在什么授权范围内、依据哪些信息、对什么事项、做出什么决定、由谁在何时验证结果。
- 字段按“识别—评估—决定—执行—复查”分组，必填字段保证可追溯，涉及预算、范围基线或跨组件资源的决策可把约束假设、变更替代关系也设为必填。
- 建立流程分四步：触发与登记、评估材料准备、决策会议与签署、归档分发与复查，每步都有明确的输入、输出和完成标志。
- 记录人、批准人、知悉人三类身份分开，复查由项目集经理发起，关闭权限归批准该决策的治理机构或其书面授权角色。
- 合格检查按可追溯性、授权合规、执行闭环、依据完整性、知悉覆盖五类进行，前四类为阻断项，不通过不进入已批准或已关闭状态。
一份可用的项目集决策记录包含哪些字段
字段设计的目标是让一份记录在半年后由未参会的人打开，也能还原当时的判断过程。建议按“识别—评估—决定—执行—复查”五个环节分组，每组字段回答一个明确的管理问题。必填字段保证可追溯，选填字段按决策影响面增补。
| 字段名 | 所属分组 | 必填/选填 | 填写要点与回答的管理问题 |
|---|---|---|---|
| 决策编号 | 识别 | 必填 | 唯一且稳定，便于引用和检索；回答“这是哪一条决策” |
| 决策标题 | 识别 | 必填 | 一句话说明决策对象，如“XX组件二期预算追加” |
| 决策层级与授权依据 | 识别 | 必填 | 写明由哪一级治理机构决策、依据哪份授权文件或章程；回答“谁有权做这个决定” |
| 触发原因与背景 | 识别 | 必填 | 说明为什么现在必须决策，附关键事实；回答“为什么会有这条决策” |
| 备选方案 | 评估 | 必填 | 列出至少两个可行方案，包括“维持现状” |
| 评估依据 | 评估 | 必填 | 数据、测算、专家意见、约束条件；回答“凭什么这样选” |
| 影响范围 | 评估 | 必填 | 涉及的项目集组件、里程碑、预算、资源、风险 |
| 约束与假设 | 评估 | 选填 | 决策成立所依赖的前提，前提变化时触发复查 |
| 最终决定 | 决定 | 必填 | 明确、可执行的结论，避免模糊表述 |
| 决定理由 | 决定 | 必填 | 说明为何选此方案而非其他方案 |
| 决策日期与生效时间 | 决定 | 必填 | 区分做出决定的日期与开始执行的日期 |
| 评审与批准人 | 决定 | 必填 | 记录实际批准人及签署方式 |
| 行动项、责任人与截止时间 | 执行 | 必填 | 每项行动可指派、可验收 |
| 关联风险与依赖 | 执行 | 必填 | 指向风险登记项或其他决策、组件依赖 |
| 分发范围与知悉确认 | 执行 | 必填 | 谁需要知道、是否已确认收到 |
| 复查时点 | 复查 | 必填 | 约定何时验证结果，可用日期或触发事件 |
| 关闭状态与验证结论 | 复查 | 必填 | 记录复查结果：达成、部分达成或需调整 |
| 变更与替代关系 | 复查 | 选填 | 本条决策替代或修订了哪条旧决策 |
必填与选填的划分可按决策影响面调整：涉及预算、范围基线或跨组件资源的决策，建议把“约束与假设”“变更与替代关系”也设为必填。字段数量以能支撑追溯为限，过多字段会让填写者省略关键内容。
按四步建立决策记录：从触发到归档
决策记录的价值在于形成稳定流程，而非事后补写。以下四步说明每步的输入、动作、输出与完成标志，项目集可按治理节奏裁剪频率。
第一步：决策触发与登记
输入是触发事件，如预算偏差超阈值、组件里程碑延期、风险升级或治理会议议题。项目集经理或议题提出人判断事项是否超出组件负责人权限，超出则登记为决策事项。动作是分配决策编号、填写标题、触发原因和拟决策层级。输出是一条处于“待评估”状态的记录。完成标志是编号唯一、背景事实清楚、拟决策机构明确。
第二步：评估材料准备
输入是登记后的记录和支撑数据。责任人整理备选方案、影响分析、风险与依赖，必要时请财务、资源或技术角色提供测算。动作是把方案和评估依据写入记录，标注约束与假设。输出是可供治理机构审议的材料包。完成标志是每个备选方案都有影响说明，关键数据有出处，风险与依赖已关联到对应登记项。
第三步：决策会议与签署
输入是评估材料包和会议议程。授权人按议事规则表决或拍板，记录人现场记录最终决定、理由、行动项和复查时点。会后由批准人确认记录内容并签署。输出是“已批准”状态的决策记录。完成标志是决定表述明确、批准人可识别、行动项均有责任人和截止时间。
第四步：归档、分发与复查
输入是已批准的记录。动作包括存入项目集决策台账、按分发范围通知相关角色并收集知悉确认、在复查时点核对行动项完成情况和决策效果。输出是带验证结论的关闭记录或调整后的新决策。完成标志是知悉确认齐全、复查结论已填写、状态更新为关闭或转入后续决策。
在工具承载上，决策记录通常以文档形式留存，行动项和风险以工作项跟踪。ONES Plan 可借助项目集管理总览多项目信息，支持查看多项目数据集合、多维度掌控项目进度，并可自定义项目属性管理不同类型项目；与 ONES Project 配合时，还能查看相关项目和迭代的工作量与工时数据。这些数据可作为评估依据和复查时的对照来源。决策记录专用模板或登记功能未在现有资料中提及，实际配置时需核验。
谁负责填写、批准与复查决策记录
记录无人维护，通常源于角色边界不清。建议把“记录人、批准人、知悉人”三类身份分开，并明确复查与关闭权限。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目集经理 | 识别需上报的决策事项，组织评估材料，维护决策台账，跟踪行动项 | 决策登记、材料包、行动项跟踪表 |
| 决策机构/治理委员会 | 在授权范围内审议并拍板，确认记录内容 | 批准签署、会议决议 |
| PMO 支持角色 | 维护模板与编号规则，检查记录完整性，组织复查提醒 | 模板、台账、完整性检查结果 |
| 组件负责人 | 提供组件层面事实与影响分析，执行分配的行动项 | 影响说明、执行反馈 |
| 记录人 | 现场记录决定、理由与行动项，会后整理成文 | 决策记录初稿 |
| 知悉人 | 接收分发并确认知悉，按需在组件内传达 | 知悉确认 |
复查责任人一般由项目集经理担任，负责在约定时点发起验证；关闭权限归批准该决策的治理机构，或由其书面授权的角色。涉及预算和范围基线的决策，关闭前应有财务或对应职能的确认意见。
示例：一条预算调整决策记录怎么填
以下为演示情景，用于说明字段写法，不代表真实案例。
背景与触发：某项目集下属组件A在第二季度出现预算偏差，累计支出达到批准预算的112%，组件负责人申请追加预算。该事项超出组件负责人权限，登记为决策事项，编号PG-2024-017。
备选方案与评估依据：方案一为追加预算并维持原范围；方案二为压缩非关键功能范围、预算不变；方案三为延期一个季度以分摊成本。评估依据包括近三个月实际支出明细、剩余工作量估算、延期对下游组件的影响分析。约束条件是年度预算总额不可突破，假设是供应商报价在三个月内有效。
决定与理由：治理委员会选择方案二，理由是压缩范围可在不突破年度总额的前提下保住关键里程碑，延期方案会连带影响两个下游组件的交付窗口。
行动项与复查：组件负责人两周内提交范围调整清单，项目集经理更新里程碑计划，财务角色核对调整后预算。复查时点设为范围调整上线后一个月，验证支出是否回到预算区间。
这条示例的可迁移规律是：备选方案要包含“不追加资源”的选项，评估依据要指向可核对的数据，决定理由要说明放弃其他方案的原因，复查时点要绑定可观察的结果。
完成检查：决策记录是否合格
检查按三类进行，任一项阻断项不通过，记录不应进入“已批准”或“已关闭”状态。
| 检查类别 | 检查项 | 通过标准 | 是否阻断 |
|---|---|---|---|
| 可追溯性 | 编号唯一，关联事项与替代关系完整 | 能通过编号找到关联的风险、行动项或旧决策 | 阻断 |
| 授权与合规 | 批准人、授权依据齐全 | 批准人处于授权范围内，签署可识别 | 阻断 |
| 执行闭环 | 行动项有责任人、截止时间和复查时点 | 每项行动可验收，复查时点明确 | 阻断 |
| 依据完整性 | 备选方案与评估依据已填写 | 至少两个方案，关键数据有出处 | 阻断 |
| 知悉覆盖 | 分发范围与知悉确认 | 受影响角色均已确认 | 非阻断，可限期补齐 |
常见缺口包括：只写结论不写依据，导致后续无法解释为何放弃其他方案；缺复查时点，行动项完成后无人验证效果；无变更关联，新旧决策并存造成执行冲突。维护上建议每月抽查台账完整性，复查到期前由 PMO 提醒责任人，决策被替代时在原记录中标注替代关系并保留历史版本。
常见问题
决策记录和会议纪要有什么区别，能不能直接用会议纪要代替？
会议纪要记录一次会议讨论了什么、谁参加了，决策记录聚焦一条决策的完整生命周期。一次治理会议可能产生多条决策，每条都应有独立编号、授权依据、备选方案、行动项和复查时点。会议纪要可以作为决策记录的附件或来源材料，但替代不了决策记录本身，因为纪要通常不跟踪决策执行结果和关闭状态。
实际操作中可以让会议纪要承担“触发与登记”的部分作用：会上形成的决策事项当场分配编号，会后由记录人按模板补齐评估依据和行动项，再进入批准流程。
决策事项的影响面很小，也要走完整的四步流程吗？
可以裁剪，但裁剪的是审批层级和材料厚度，不是可追溯性。影响面小的决策，评估材料可以简化为一页说明，备选方案写两个即可，复查时点可以设为固定周期抽查而非单独验证。编号、决定表述、责任人、截止时间和复查时点这几项建议保留，否则后续无法回答“这件事当时怎么定的”。
判断是否裁剪的依据是决策是否改变预算、范围基线、跨组件资源或对外承诺。触及其中任何一项，建议按完整流程执行。
决策执行到一半前提条件变了，原记录怎么处理？
在原记录中标注状态变化，并新建一条决策记录说明调整内容，用“变更与替代关系”字段把新旧两条关联起来。原记录保留历史版本，不删除、不覆盖，这样复查时能看清决策演变的路径。
如果前提变化属于记录中已写明的“约束与假设”，可以直接触发复查，由复查责任人评估是否需要重新决策；如果前提变化超出原假设范围，建议按新事项重新登记，避免在原记录上反复修改导致版本混乱。
跨多个组件的决策，行动项应该拆到什么粒度？
按可验收的最小交付物拆分，每项行动对应一个责任人和一个截止时间。跨组件决策常见的做法是先拆到组件级，再由组件负责人拆到团队级，决策记录中保留组件级行动项即可，避免台账被过细的任务淹没。
需要特别注意的是依赖关系：如果组件B的行动要以组件A的产出为前提，应在行动项中写明前置条件，并在“关联风险与依赖”字段中指向对应事项。复查时先核对前置条件是否满足，再判断行动是否延期。
用文档工具管理决策记录时，怎样保证台账不散落？
关键是固定存放位置和编号规则：所有决策记录集中在一个项目集知识库或文档空间中，按编号或年份组织页面，模板统一。行动项和风险如果放在项目管理工具里跟踪，建议在决策记录中保留指向对应工作项的引用，形成文档与工作项的双向关联。
ONES Plan 可借助项目集管理总览多项目信息，支持查看多项目数据集合、多维度掌控项目进度，并可自定义项目属性管理不同类型项目；与 ONES Project 配合时还能查看相关项目和迭代的工作量与工时数据，这些数据可作为评估依据和复查时的对照来源。决策记录专用模板或登记功能未在现有资料中提及，实际配置时需核验。
