瀑布项目计划模板的正文说明“计划是什么”，配套附件则证明“计划依据什么、执行到哪、如何验收”。一套完整的配套附件通常分为基准类、跟踪类和确认类：基准类锁定范围、进度与成本，跟踪类记录执行偏差与变更，确认类支撑阶段评审与最终验收。下面给出可直接复制的计划正文骨架表和附件登记表，并说明字段填写、必填判断、填写示例与变更后的维护方法。
要点总览（TL;DR）
- 瀑布项目计划模板的配套附件按用途分为基准类、跟踪类、确认类：基准类锁定范围、进度与成本，跟踪类记录执行偏差与变更，确认类支撑阶段评审与验收。
- 计划正文骨架表与附件登记表通过“条款编号”互相引用，先定正文条款，再登记附件，避免附件与正文脱节。
- 必填附件包括范围说明书、WBS词典、进度基准、里程碑清单和验收单；成本基准与质量检查表在合同、预算审批或质量条款出现时转为必填。
- 附件登记表需统一编号、类别、对应条款、责任人、审批人、版本、生效日期与状态口径，失效附件保留记录用于追溯。
- 计划变更时先判断是否触及附件内容，再决定升版或标记失效，并在阶段评审时逐项核对正文条款与登记表是否一一对应。
可复制空白模板：计划正文与配套附件清单
先拿到两张表：一张是计划正文骨架，用来组织计划本身的章节与审批；另一张是配套附件登记表，用来管理所有附件的归属、版本与状态。两张表通过“条款编号”互相引用，填写时先定正文条款，再登记附件。
表一：计划正文骨架表
| 条款编号 | 章节名称 | 主要内容 | 填写人 | 版本 | 审批状态 |
|---|---|---|---|---|---|
| 1 | 项目概述 | 背景、目标、交付物总览 | |||
| 2 | 范围与WBS | 范围边界、WBS分解层级、工作包说明 | |||
| 3 | 进度计划 | 阶段划分、任务依赖、里程碑 | |||
| 4 | 成本与资源 | 预算构成、人力投入、采购安排 | |||
| 5 | 质量与验收 | 质量标准、检查方式、验收条件 | |||
| 6 | 风险与变更 | 风险识别、变更控制流程 | |||
| 7 | 沟通与干系人 | 汇报机制、评审节点、干系人清单 | |||
| 8 | 配套附件索引 | 引用附件登记表中的附件编号 |
填写提示：条款编号一经确定，后续附件登记与变更记录都沿用该编号；版本按“V1.0、V1.1”递增，审批状态填“草稿、待审批、已审批、已失效”。
表二：配套附件登记表
| 附件编号 | 附件名称 | 所属类别 | 对应正文条款 | 责任人 | 审批人 | 版本 | 生效日期 | 状态 |
|---|---|---|---|---|---|---|---|---|
| ATT-01 | 基准类/跟踪类/确认类 | 草稿/已审批/已失效 | ||||||
| ATT-02 | ||||||||
| ATT-03 | ||||||||
| ATT-04 | ||||||||
| ATT-05 |
填写提示：附件编号按登记顺序编排，不复用已失效编号；一个附件对应多个正文条款时，在“对应正文条款”列写全，如“2、3”；状态为“已失效”的附件保留在表中，用于追溯历史版本。
配套附件分几类、每类放什么
附件分类的依据是它回答的问题，而不是文件格式。基准类回答“计划依据什么成立”，跟踪类回答“执行到哪、偏了多少”，确认类回答“是否达到验收条件”。按这三类归档，附件数量可控，查找时也能直接定位到正文条款。
| 类别 | 典型附件 | 回答的问题 | 对应正文条款 |
|---|---|---|---|
| 基准类 | 范围说明书、WBS词典、进度基准、成本基准 | 计划的范围、时间、成本依据是什么，经谁批准 | 2 范围与WBS、3 进度计划、4 成本与资源 |
| 跟踪类 | 里程碑清单、风险登记册、变更记录、问题日志 | 执行与基准的偏差在哪，变更和风险如何处理 | 3 进度计划、6 风险与变更 |
| 确认类 | 质量检查表、验收单、阶段评审记录 | 交付物是否满足质量条款，阶段能否通过评审 | 5 质量与验收、7 沟通与干系人 |
范围说明书界定做什么与不做什么，WBS词典为每个工作包补充验收标准、责任人和估算依据，两者共同支撑正文第2章。进度基准与成本基准是经审批的计划版本，后续偏差对比都以它们为参照。里程碑清单把正文中的关键时间点单独列出，便于在阶段评审时逐项核对。风险登记册、变更记录和问题日志属于动态附件，随项目推进持续更新，登记表中记录其最新版本即可。
字段说明：附件登记表每一列怎么填
登记表的字段口径需要统一，否则同一份附件在不同人手里会出现不同编号和状态。下表逐列说明含义与常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 附件编号 | 附件的唯一标识 | “ATT-”加两位序号，按登记顺序递增 | 复用已失效编号，导致追溯混乱 |
| 附件名称 | 附件的正式名称 | 与文件标题一致，包含项目名或阶段名 | 使用“最终版”“新版”等无法区分的名称 |
| 所属类别 | 基准类、跟踪类、确认类 | 按附件回答的问题归类，只选一类 | 把变更记录归入基准类 |
| 对应正文条款 | 附件支撑的计划章节 | 填写正文骨架表中的条款编号，多个用顿号分隔 | 只写章节名不写编号，正文改版后无法对应 |
| 责任人 | 负责编写与维护附件的人 | 填写具体角色或姓名，一人负责 | 与审批人填成同一人且无复核 |
| 审批人 | 对附件内容做批准的人 | 按项目授权填写，通常为项目经理或质量负责人 | 空缺或填写“待定”长期不更新 |
| 版本 | 附件自身的版本号 | 从V1.0起，内容实质变化时升版 | 与计划正文版本混用同一编号 |
| 生效日期 | 该版本开始被引用的日期 | 审批通过之日，格式统一为年-月-日 | 填写编写日期而非审批日期 |
| 状态 | 附件当前所处阶段 | 草稿、已审批、已失效三选一 | 用“完成”“OK”等非标准表述 |
责任人与审批人分开填写，是为了让编写和批准形成两次独立动作；小项目中可以由同一人承担两个角色，但登记表仍分列记录。版本号与计划正文分开编号，附件内容变化时只升附件版本，正文条款不变则无需改版。
必填与选填：哪些附件不能省
附件是否必填，取决于项目是否需要据此做范围确认、进度对比和验收。以下三档清单给出判断条件，项目可按规模在必填项内做简化，但不跳过必填类别。
| 档位 | 附件 | 判断条件 |
|---|---|---|
| 必填 | 范围说明书、WBS词典、进度基准、里程碑清单、验收单 | 所有单项目计划均需具备，用于界定范围、对比进度和完成验收 |
| 条件必填 | 成本基准 | 存在外部合同、预算审批或需要按阶段核算成本时必填 |
| 条件必填 | 质量检查表 | 合同或项目章程中有明确质量条款、检查标准时必填 |
| 选填 | 问题日志、经验教训记录 | 项目周期较长、跨阶段协作较多时建议保留，短周期小项目可简化 |
小规模项目的简化规则：WBS词典可与WBS表合并为一张表，但每个工作包仍需有验收标准和责任人；里程碑清单可并入进度基准的里程碑行，登记表中注明合并关系；问题日志在问题数量少时可并入风险登记册，但需保留问题与风险的区分标记。合同要求高于上述规则时，以合同约定的附件为准。
填写示例：一个交付阶段的完整附件组合
以下为演示情景：某单项目进入“系统开发与交付”阶段，计划正文已审批至V1.1，需登记该阶段配套附件。示例仅示范填写深度，不代表真实项目数据。
正文片段：第3章进度计划写明“开发阶段6周，第4周末为联调里程碑”；第5章质量与验收写明“交付前完成功能检查与性能检查，客户签署验收单后阶段关闭”。
| 附件编号 | 附件名称 | 所属类别 | 对应正文条款 | 责任人 | 审批人 | 版本 | 生效日期 | 状态 |
|---|---|---|---|---|---|---|---|---|
| ATT-01 | 系统开发阶段范围说明书 | 基准类 | 2 | 需求负责人 | 项目经理 | V1.0 | 2025-03-03 | 已审批 |
| ATT-02 | 开发阶段WBS词典 | 基准类 | 2、3 | 计划负责人 | 项目经理 | V1.0 | 2025-03-03 | 已审批 |
| ATT-03 | 开发阶段进度基准 | 基准类 | 3 | 计划负责人 | 项目经理 | V1.1 | 2025-03-10 | 已审批 |
| ATT-04 | 开发阶段里程碑清单 | 跟踪类 | 3 | 计划负责人 | 项目经理 | V1.0 | 2025-03-03 | 已审批 |
| ATT-05 | 开发阶段风险登记册 | 跟踪类 | 6 | 风险负责人 | 项目经理 | V1.2 | 2025-03-17 | 已审批 |
| ATT-06 | 功能与性能质量检查表 | 确认类 | 5 | 质量负责人 | 质量经理 | V1.0 | 2025-03-03 | 已审批 |
| ATT-07 | 阶段交付验收单 | 确认类 | 5、7 | 项目经理 | 客户代表 | V0.9 | — | 草稿 |
示例中进度基准因联调里程碑调整升版至V1.1，旧版V1.0标记为已失效并保留在登记表中；验收单在阶段结束前保持草稿状态，客户签署后升为V1.0并填写生效日期。正文第8章“配套附件索引”直接引用ATT-01至ATT-07，读者从正文即可定位到对应附件。
调整与维护：附件随计划变更怎么更新
附件与正文脱节，通常发生在计划变更和阶段切换时。维护的核心动作是：先判断变更是否触及附件内容，再决定升版或失效，最后在阶段评审时逐项核对。
| 触发条件 | 更新动作 | 责任人 | 检查时点 |
|---|---|---|---|
| 范围增减或工作包调整 | 更新范围说明书与WBS词典，升版并重新审批 | 需求负责人 | 变更批准后3个工作日内 |
| 里程碑日期调整 | 进度基准与里程碑清单同步升版，旧版标记失效 | 计划负责人 | 变更批准当日 |
| 成本或预算调整 | 成本基准升版，登记表更新生效日期 | 项目经理 | 预算审批通过后 |
| 阶段结束进入下一阶段 | 确认类附件归档，新阶段附件重新登记编号 | 项目经理 | 阶段评审会上 |
| 附件内容失效但需追溯 | 状态改为已失效，保留编号与版本，不删除记录 | 附件责任人 | 每次升版时 |
阶段评审时按清单核对：正文条款编号与登记表是否一一对应；已审批附件是否都有生效日期；失效附件是否保留记录；验收单等确认类附件是否在阶段关闭前完成签署。项目收尾时，计划正文与全部附件按编号顺序归档，交接给运维或下一阶段负责人，登记表作为归档索引一并移交。
附件登记与版本维护如果放在文档工具里手工同步，容易出现正文改了、登记表没改的情况。ONES 的项目计划功能支持按交付物或阶段分解WBS、设置任务依赖并用里程碑标记关键节点，计划和里程碑可建立基线，用于对比执行偏差并追溯变更；ONES Wiki 的文档可以关联任务，也能插入工作项列表，适合把计划正文、附件登记表与对应工作项放在同一处维护。团队可以把每个附件登记为一条工作项或一篇关联文档，在变更时同步更新状态与版本，让附件与计划正文保持一致。
常见问题
小项目人手有限，附件登记表能不能简化？
可以简化形式，但不宜跳过必填类别。常见做法是把WBS词典与WBS表合并为一张表，每个工作包仍保留验收标准和责任人；里程碑清单并入进度基准的里程碑行，并在登记表中注明合并关系；问题数量少时把问题日志并入风险登记册，用标记区分问题与风险。范围说明书、进度基准和验收单建议保留独立文件，它们是范围确认和阶段关闭的直接依据。
附件版本和计划正文版本要不要用同一套编号？
建议分开编号。计划正文按自身版本递增，附件各自维护版本号，附件内容变化时只升附件版本，正文条款不变则无需改版。登记表中的“对应正文条款”记录的是条款编号，与版本号无关，这样正文改版后仍能定位附件支撑的是哪一章。若正文条款本身调整，则需同步更新登记表的对应关系。
合同对交付文档有额外要求时，以哪份清单为准？
以合同约定为准。本文给出的必填、条件必填与选填三档清单用于常规单项目计划编制，合同或项目章程提出更高要求时，按合同列明的附件种类、格式和提交时点执行，并在附件登记表中补充相应条目。合同要求与内部简化规则冲突时，不因项目规模小而省略合同约定的附件。
阶段评审时重点检查附件的哪些状态？
可以按四项核对：正文条款编号与登记表是否一一对应；已审批附件是否都填写了生效日期；失效附件是否保留编号与版本记录；验收单等确认类附件是否在阶段关闭前完成签署。发现附件缺失或状态未更新时，先补齐再进入下一阶段，避免带着未确认的附件推进后续工作。
用文档工具维护附件登记表，怎样减少正文与附件不同步？
关键是让附件登记与计划正文处在同一处维护，并在变更时同步更新状态。ONES 的项目计划功能支持按交付物或阶段分解WBS、设置任务依赖并用里程碑标记关键节点，计划和里程碑可建立基线，用于对比执行偏差并追溯变更；ONES Wiki 的文档可以关联任务，也能插入工作项列表，适合把计划正文、附件登记表与对应工作项放在一起维护。团队可以把每个附件登记为一条工作项或一篇关联文档，变更时同步更新版本与状态。
