项目集决策记录用一张表把决策事项、背景依据、备选方案、决策结论、影响范围、责任人和复核节点固定下来，形成可追溯的治理凭证。本文提供可直接复制的空白表格、逐字段说明、必填与选填划分、一份完整填写示例，以及模板随项目集阶段调整的维护方法，适用于需要跨项目协调决策的项目集管理场景。
要点总览（TL;DR）
- 模板按“表头—事项—方案与依据—结论—执行—变更与关闭”六个区块组织，共18个字段，可直接复制填写。
- 必填与选填按决策影响程度划分：日常授权类可简化备选方案与评估依据，重大决策需追加关联项目集与数据来源。
- 填写示例用一次范围调整决策演示字段之间的对应关系，结论必须能追溯到备选方案和评估依据。
- 模板维护包括版本递增、新增字段先评审后生效、历史记录按版本归档和季度抽查记录质量。
可复制空白模板：项目集决策记录表
下表按“表头—事项—方案与依据—结论—执行—变更与关闭”六个区块组织，可直接复制到文档或表格工具中填写。每个区块承担不同的记录任务，填写时按顺序推进，避免结论先行、依据后补。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 项目集名称 | |
| 记录编号 | ||
| 记录日期 | ||
| 记录人 | ||
| 决策事项 | 事项标题 | |
| 决策类型 | ||
| 触发原因 | ||
| 方案与依据 | 备选方案 | |
| 评估依据 | ||
| 相关材料 | ||
| 结论 | 决策结论 | |
| 生效条件 | ||
| 影响范围 | ||
| 执行 | 责任人 | |
| 完成时限 | ||
| 复核节点 | ||
| 变更与关闭 | 变更记录 | |
| 关闭状态 |
表格结构保持稳定，字段值随决策内容变化。复制后建议保留区块标题行，便于多人协作时快速定位填写位置。
字段说明：每个字段填什么、为什么要有
同一张表由不同记录人填写时，口径不一致会让记录失去横向比较的价值。以下逐字段说明含义与填写口径，并列出常见错误，供记录人对照使用。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 项目集名称 | 决策所属的项目集 | 使用组织内正式名称，与立项文件一致 | 写简称或项目名，导致归属不清 |
| 记录编号 | 唯一标识，用于检索与引用 | 按“项目集缩写-年份-序号”编制，如 PJ-A-2025-007 | 重号、跳号，或事后补编 |
| 记录日期 | 决策形成或记录归档的日期 | 填写决策会议或审批完成的日期 | 填记录整理日期，与决策时点脱节 |
| 记录人 | 对记录完整性负责的人 | 填实际整理人，可附所属角色 | 只写部门，无法追溯 |
| 事项标题 | 一句话概括决策对象 | 动词开头，包含对象与范围，如“调整A子系统交付范围” | 标题过泛，如“讨论一下” |
| 决策类型 | 决策的性质分类 | 从约定取值中选择：范围调整、资源调配、里程碑变更、风险处置、日常授权等 | 自造类型，导致统计口径混乱 |
| 触发原因 | 为什么此时需要决策 | 写具体事件或条件，如“供应商交付延期两周” | 写“项目需要”，缺少事实依据 |
| 备选方案 | 考虑过的可选路径 | 逐条列出，至少两个；每条写清做法与代价 | 只写最终方案，无法体现权衡 |
| 评估依据 | 比较方案所用的标准与数据 | 写清维度（成本、进度、风险）及数据来源 | 写“综合评估”，无可核验内容 |
| 相关材料 | 支撑决策的文档或数据 | 列名称与位置，便于后续查阅 | 留空或只写“见附件” |
| 决策结论 | 最终选择及关键理由 | 明确选择哪个方案，并用一句话说明理由 | 只写“同意”，未指向具体方案 |
| 生效条件 | 结论开始起作用的前提 | 写时间、审批或前置动作，如“自指导委员会批准次日起” | 默认立即生效，忽略审批环节 |
| 影响范围 | 受决策影响的组织与工作 | 列关联项目、团队、合同或交付物 | 只写本项目，遗漏关联项目集 |
| 责任人 | 推动决策落地的人 | 填具体姓名与角色，一人为主责 | 写团队名，无人真正负责 |
| 完成时限 | 执行动作的截止时间 | 填具体日期，与里程碑对齐 | 写“尽快”“近期” |
| 复核节点 | 检查执行效果的时间点或事件 | 写日期或触发事件，如“下次项目集评审会” | 只设时限不设复核，执行结果无人验证 |
| 变更记录 | 记录本身的修订历史 | 写日期、修订内容、修订人 | 直接覆盖原文，丢失历史 |
| 关闭状态 | 决策是否已执行完毕 | 从“待执行、执行中、已关闭、已撤销”中选择 | 长期停留在“执行中” |
填写时把握两条口径：结论必须能追溯到备选方案和评估依据；执行字段必须能对应到具体的人和时点。这两条决定了记录能否在事后被复核。
必填与选填：按决策类型区分填写要求
所有决策都按同一深度记录，会让日常授权类事项负担过重，也会让重大决策记录偏轻。建议按决策影响程度划分填写要求：基础字段全部必填，重大决策追加字段，日常授权类可简化部分字段。
| 字段 | 日常授权类 | 一般管理决策 | 重大决策 |
|---|---|---|---|
| 表头四项 | 必填 | 必填 | 必填 |
| 事项标题、决策类型、触发原因 | 必填 | 必填 | 必填 |
| 备选方案 | 可简化为一句话说明 | 必填，至少两个 | 必填，逐条写代价 |
| 评估依据 | 选填 | 必填 | 必填，附数据来源 |
| 相关材料 | 选填 | 必填 | 必填 |
| 决策结论、生效条件 | 必填 | 必填 | 必填 |
| 影响范围 | 选填 | 必填 | 必填，列关联项目集 |
| 责任人、完成时限 | 必填 | 必填 | 必填 |
| 复核节点 | 选填 | 必填 | 必填，可设多个 |
| 变更记录、关闭状态 | 必填 | 必填 | 必填 |
判定规则可以归纳为三条：涉及范围、预算、里程碑或跨项目资源的决策按重大决策填写；影响限于单个团队内部排期的按日常授权类简化；介于两者之间的按一般管理决策处理。选填字段的启用条件是：该字段缺失会导致后续无法复核决策合理性时，即转为必填。
缺失必填项时，不建议先归档再补。处理方式有两种：记录人当场标注缺失项并说明原因，由决策责任人在复核节点前补齐；或将该记录状态标为“待完善”，在下次评审会上作为议题处理。两种方式都要求缺失项可见，避免记录表面完整、实际无法追溯。
填写示例：一次范围调整决策的完整记录
以下为演示情景，用于说明字段之间如何互相支撑，不代表真实客户案例。设定：某项目集下辖三个子项目，其中数据平台子项目因上游接口延期，需要调整本期交付范围。
| 字段 | 填写内容 |
|---|---|
| 项目集名称 | 客户运营平台项目集 |
| 记录编号 | COP-2025-012 |
| 记录日期 | 2025-03-18 |
| 记录人 | 李敏（项目集管理办公室） |
| 事项标题 | 调整数据平台子项目本期交付范围 |
| 决策类型 | 范围调整 |
| 触发原因 | 上游计费系统接口交付延期两周，原定本期上线的实时对账模块缺少依赖 |
| 备选方案 | 方案一：整体延期两周，三个子项目同步顺延；方案二：本期先交付批量对账，实时对账移至下期；方案三：临时开发模拟接口，维持原范围 |
| 评估依据 | 按进度、成本、风险三个维度比较：方案一影响两个下游子项目的验收节点；方案二保住本期主要验收里程碑，下期增加约三周工作量；方案三需额外投入两名开发约四周，且模拟接口存在上线后返工风险 |
| 相关材料 | 《上游接口延期说明》《本期验收里程碑清单》，存放于项目集文档库 |
| 决策结论 | 采用方案二：本期交付批量对账，实时对账纳入下期范围，理由是保住本期验收节点且不引入返工风险 |
| 生效条件 | 经项目集指导委员会确认后生效，确认前按原计划执行 |
| 影响范围 | 数据平台子项目交付清单；报表子项目的对账报表依赖需同步调整；客户侧验收范围说明需更新 |
| 责任人 | 王强（数据平台子项目负责人） |
| 完成时限 | 2025-03-31 前完成交付清单与验收范围说明的修订 |
| 复核节点 | 2025-04-10 项目集月度评审会核对修订结果与客户确认情况 |
| 变更记录 | 2025-03-20 补充客户侧沟通结论，记录人李敏 |
| 关闭状态 | 执行中 |
这份示例中，触发原因提供了事实依据，备选方案覆盖了延期、缩范围和临时补救三种路径，评估依据用同一组维度比较，结论直接指向方案二并给出理由。执行字段把责任落到具体的人、日期和复核会议，变更记录保留了后续补充的痕迹。填写自己的记录时，可对照检查：结论能否在备选方案中找到对应项，复核节点是否有人真正核对。
当决策记录需要在多个子项目之间流转、与项目进度和文档保持对应时，可以把记录作为项目集下的文档承载。ONES Wiki 支持页面组关联项目，需求与文档互相对应，文档可嵌入任务进度和报表，便于在记录中直接引用执行进展；其版本记录支持查看与回滚，适合保留决策记录的修订历史。ONES Plan 则可从项目集层面总览多项目信息，帮助在复核节点核对决策落地情况。是否采用工具承载，取决于项目集规模与协作人数，记录表本身的结构不因工具而改变。
调整与维护：让模板跟着项目集治理走
模板落地后，字段会随项目集阶段、规模和治理要求变化。维护的目标是让新记录适应新要求，同时保证历史记录仍可读、可检索。
模板版本与编号规则同步维护。每次调整模板结构时递增版本号，并在模板首页注明版本与生效日期；记录编号规则保持稳定，已归档记录的编号不因模板升级而重编。新增字段需经过评审：由项目集管理办公室提出字段草案，说明新增原因和填写口径，在评审会上确认后随下一版本生效，生效前的记录不强制回填。
历史记录按项目集和年份归档，保留原模板版本标识，检索时以记录编号和事项标题为主要入口。定期抽查可以每季度抽取若干条记录，核对必填项完整性、结论与依据的对应关系、复核节点是否落实，抽查结果反馈给记录人用于改进填写质量。
模板与治理流程的衔接体现在两个动作：评审会议议程中固定设置决策记录回顾环节，检查上次决策的执行与复核情况；变更流程中要求范围、里程碑类变更必须引用对应的决策记录编号，使变更与决策形成闭环。维护清单可归纳为：版本递增并注明生效日期、新增字段先评审后生效、历史记录按版本归档、季度抽查记录质量、评审与变更流程引用记录编号。按此执行，模板会随治理实践逐步细化，而不会因频繁改动失去可比性。
常见问题
项目集决策记录和会议纪要有什么区别，能不能合并成一份？
会议纪要记录讨论过程，决策记录聚焦结论及其执行约束。两者可以放在同一份文档里，但决策记录需要独立成段并带编号，否则后续变更流程引用时找不到明确对象。建议会议纪要中涉及决策的部分，单独生成或链接一条决策记录，纪要保留讨论脉络，记录承担追溯职责。
决策记录由记录人写还是由决策责任人写？
常见做法是记录人整理、决策责任人确认。记录人负责字段完整和表述清晰，决策责任人负责确认结论、生效条件和执行责任与实际一致。如果由决策责任人独自填写，容易省略备选方案和评估依据；如果记录人写完无人确认，结论可能与会上共识有偏差。确认动作可以在复核节点前完成，不必当场签字。
决策执行到一半发现前提变了，原记录怎么处理？
不建议直接修改原结论。可以在变更记录中写明变化原因，并新开一条决策记录处理调整后的事项，两条记录通过编号互相引用。这样原决策的生效条件和当时的判断依据都保留下来，后续复盘时能看清决策是在什么信息条件下做出的。若原决策整体失效，将关闭状态标为“已撤销”并注明依据。
项目集规模较小，是否也需要完整的六区块模板？
可以按需裁剪，但表头、事项、结论、执行四类字段建议保留，它们决定了记录能否被检索和复核。方案与依据区块在决策影响限于单个团队时可以简化为一句话说明；变更与关闭区块即使项目集小，也建议保留关闭状态，避免记录长期停留在执行中。裁剪后的模板应注明版本，便于与后续扩展的版本区分。
决策记录放在文档工具里，如何与项目进度对应起来？
一种做法是把记录作为项目集下的文档页面，在记录中引用对应的工作项或里程碑，复核时从记录直接跳到执行进展。ONES Wiki 支持页面组关联项目，需求与文档互相对应，文档可嵌入任务进度和报表，版本记录支持查看与回滚；ONES Plan 可从项目集层面总览多项目信息。工具承载方式取决于项目集规模与协作人数，记录表结构本身保持不变。
