项目归档是把项目全生命周期的过程记录、交付物、决策依据和收尾结论整理成可检索、可追溯、可复用的档案，并在项目正式关闭或转入运维前完成一次完整移交。本文面向项目整体关闭或转换的场景，给出归档范围、六步流程、四类角色分工和一份可逐项勾选的完成检查表；单次软件交付的验收记录归入交付验收与追溯，不在本文展开。归档清单与文档留痕可以借助ONES等协作平台承载，具体方式在最后一节说明。
要点总览（TL;DR）
- 项目归档的范围从立项覆盖到项目关闭或移交运维，把候选内容分为必须归档、按需归档、不归档三类，再用一张含文件类别、责任人、来源系统、密级、保存期限的清单逐条跟踪。
- 归档按定范围与清单、收集与核对、整理与编目、评审与签署、移交与关闭、保存与复用六步推进，每步都定义输入、动作、输出和可判定的完成标志。
- 项目经理对完整性负责，文档管理员执行收集与编目，质量或PMO评审合规性，业务接收方签署移交确认；归档必须在项目关闭前完成，转换类项目在移交运维前完成。
- 关闭前用归档完成检查表逐项核对，关键交付物缺失、关键文件版本不一致、密级未标注、签署未完成、未确认接收都属于阻断项，整改通过后才能把项目状态置为关闭。
- 归档清单、文档版本、权限与签署记录可以放到协作平台上承载，ONES Wiki 的页面树、版本记录、角色权限与模板库可用于集中存放和留痕，具体配置需结合组织实际确认。
项目归档要归什么：范围与清单先定下来
归档范围的判断口径是“项目全生命周期中形成的、能够证明项目做了什么、为什么这样做、结果是否被接受的记录”。范围起点是立项，终点是项目关闭或移交运维，中间的计划、执行过程记录、变更、验收结论、收尾文件都应纳入视野。范围定得清楚，后续收集才有边界，也不会把日常草稿和正式记录混在一起。
实际操作中，建议把候选内容分成三类再决定去向：
- 必须归档：项目章程、合同与补充协议、经批准的计划基线、验收结论、变更审批记录、收尾报告、移交确认记录。这类文件是项目合法性与结果认定的依据，缺失即构成关闭阻断。
- 按需归档：周报月报、会议纪要、过程评审记录、测试与质量记录、培训材料。是否归档取决于项目类型、合同约定和后续复用价值，由项目经理与质量或PMO在定清单时逐项确认。
- 不归档：个人草稿、重复的中间版本、与项目无关的临时沟通记录、已被正式版本替代的废弃稿。这类内容保留在个人空间或临时目录，到期清理即可。
需要特别区分的是归档时点与验收时点。单次软件交付的验收记录在交付验收环节形成并归入交付验收与追溯；本文处理的是项目整体关闭或转换为运维时的那次归档，它要把包括验收结论在内的全部记录一次性收拢。两者对象不同，不要用一次交付验收替代项目归档。
清单是归档工作的主载体，建议至少包含以下字段，形成一张可逐条跟踪的表：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 文件类别 | 按立项、计划、执行、变更、验收、收尾归类 | 变更 |
| 文件名称 | 使用统一命名规则，含项目简称与版本 | XX项目_范围变更申请_V2.0 |
| 责任人 | 对该文件提交与准确性负责的人 | 项目经理或对应职能负责人 |
| 来源系统 | 文件原始产生位置，便于追溯 | 项目管理平台、邮件、合同系统 |
| 格式 | 正式记录优先用可长期读取的格式 | PDF、Office文档 |
| 密级 | 按组织密级规则标注 | 内部、秘密 |
| 保存期限 | 按合同、法规或组织制度确定 | 项目关闭后5年 |
清单在项目收尾启动时定稿，之后新增条目需经项目经理确认，避免收集阶段范围反复变动。
六步操作流程：从收集到关闭
归档按六个步骤推进，每一步都定义输入、动作、输出和完成标志，完成标志要可判定，便于交接和复核。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、定范围与清单 | 项目章程、合同、验收结论 | 按三类分级逐项确认归档内容，指定责任人与保存期限 | 项目归档清单 | 清单经项目经理与质量或PMO确认 |
| 二、收集与核对 | 归档清单 | 按清单向各责任人收取文件，核对是否齐全、版本是否为最终版 | 收集到位的文件集与差异记录 | 清单中每条均有文件或明确的缺失说明 |
| 三、整理与编目 | 收集到位的文件集 | 统一命名、建立目录结构、补充元数据、标注密级 | 编目完成的档案目录 | 目录结构与命名规则全部符合约定 |
| 四、评审与签署 | 档案目录与文件 | 质量或PMO评审完整性与合规性，项目经理与业务接收方签署 | 评审结论与签署记录 | 评审意见关闭，签署齐全 |
| 五、移交与关闭 | 签署后的档案 | 移交档案库或知识库，更新项目状态为关闭 | 移交记录与关闭状态 | 接收方确认接收，项目状态置为关闭 |
| 六、保存与复用 | 已入库档案 | 设定保存期限、访问权限与到期处置方式 | 保存策略与权限配置 | 权限与期限配置生效并可查 |
第二步最容易出问题。核对不只是数文件数量，还要比对版本：同一份变更申请如果存在多个版本，应以审批通过的最终版为准，其余版本标注为过程稿。发现缺失时，先判断是文件未提交还是确实未形成，前者补交，后者在清单中记录原因并由项目经理确认。
第三步的编目决定档案后续能否被检索到。命名规则、目录层级和元数据字段应在项目启动时就与组织档案制度对齐，收尾时只是执行，不必临时设计。密级标注在这一步完成，未标注密级的文件不进入移交环节。
第五步的移交与关闭是两个动作，顺序不能颠倒：先完成移交并由接收方确认，再把项目状态置为关闭。这样关闭状态本身就代表归档已完成，后续查询不会出现“已关闭但档案不全”的情况。
角色与交付物：谁在什么时点交什么
归档责任分散在四类角色上，任何一方缺位都会造成档案不完整。下表按角色列出职责边界、交付物和时点。
| 角色 | 职责边界 | 交付物 | 时点 |
|---|---|---|---|
| 项目经理 | 对归档完整性负总责，确认清单范围，处理缺失与争议 | 收尾报告、决策记录、经确认的归档清单 | 收尾启动时定清单，关闭前确认完整 |
| 文档管理员或项目助理 | 执行收集、命名、编目与目录维护，跟踪清单状态 | 编目完成的档案目录、收集差异记录 | 收集至编目阶段持续进行 |
| 质量或PMO | 评审归档完整性与合规性，出具评审结论 | 归档评审结论、整改意见 | 移交前完成评审 |
| 业务接收方或运维团队 | 确认可接手，签署移交记录 | 移交确认签署记录 | 移交环节，关闭之前 |
时点上有一条硬约束：项目关闭前必须完成归档，转换类项目在移交运维前完成归档。把归档放在关闭之后做，容易出现人员已解散、文件无人认领的局面。项目经理在收尾计划中应把归档列为关闭的前置条件，而不是关闭后的补充动作。
职责边界要写进收尾计划，避免“大家都以为别人在收”。文档管理员负责执行层面的收集与编目，但文件内容的准确性仍由各文件责任人负责；质量或PMO评审的是完整性与合规性，不替代项目经理对范围的决定权。
一个完整示例：从收尾会到档案入库
以下为一个方法演示情景，不对应真实客户项目，也不构成任何工具实测结论。
某项目已完成交付，进入关闭准备。收尾会上，项目经理拿出归档清单初稿，逐条与参会人确认责任人和提交时间：合同与补充协议由项目经理提供，计划基线由计划负责人提供，变更记录由变更提出人所在职能提供，验收结论由质量人员提供，收尾报告由项目经理撰写。会议结束时清单定稿，每条都有责任人和截止日期。
收集阶段，文档管理员发现范围变更申请存在两个版本，一份是提交稿，一份是审批后修订稿，两份内容在工期影响描述上不一致。处理方式是：以审批记录中确认的修订稿为最终版，提交稿标注为过程稿并移入过程目录；同时请变更提出人书面确认修订稿为有效版本，确认记录一并归档。这个问题的处置说明，版本一致性核对不能只看文件是否存在，还要看审批链是否闭合。
编目阶段，文档管理员按统一命名规则重命名全部文件，建立“立项—计划—执行—变更—验收—收尾”六级目录，为每份文件补充来源系统与密级字段。质量或PMO随后评审，抽查关键交付物的版本与签署情况，出具评审结论，提出两条整改：一份会议纪要缺少密级标注，一份培训材料未注明保存期限。整改完成后，项目经理与业务接收方在移交记录上签署。
最后，档案整体移交至档案库，接收方确认接收，项目状态更新为关闭。整个过程的关键产出是：定稿的归档清单、编目完成的目录、评审结论与整改记录、移交签署记录，四者共同构成归档完成的证据链。
归档完成检查表：逐项判断能否关闭
检查表是项目关闭前的最后关口，按六组检查项逐条判断，每项都要有通过标准和证据形式，不能只凭口头确认。
| 检查项 | 通过标准 | 证据形式 | 阻断标记 |
|---|---|---|---|
| 完整性 | 清单中必须归档条目全部到位，按需归档条目已逐项确认 | 清单状态截图或签字清单 | 关键交付物缺失即阻断 |
| 版本一致性 | 每份文件为审批通过的最终版，过程稿单独存放 | 版本核对记录 | 关键文件版本不一致即阻断 |
| 命名与编目 | 命名规则、目录结构、元数据字段符合约定 | 档案目录 | 不阻断，限期整改 |
| 密级与权限 | 全部文件已标注密级，访问权限按角色配置 | 密级标注记录与权限配置 | 密级未标注即阻断 |
| 签署记录 | 评审结论、项目经理与业务接收方签署齐全 | 签署文件或系统留痕 | 签署未完成即阻断 |
| 移交确认 | 接收方确认接收，项目状态可置为关闭 | 移交记录 | 未确认接收即阻断 |
填写要求上，每项检查由文档管理员填写实际状态并附证据，项目经理作为负责人复核签字，质量或PMO对阻断项做最终判定。检查表中出现任一阻断项时，项目不得置为关闭状态，整改完成后重新检查该项。全部检查项通过后，才允许把项目状态更新为关闭，并把检查表本身作为收尾文件一并归档。
用协作平台承载归档流程
归档的难点往往不在规则本身，而在清单状态分散在邮件和表格里、文档版本各存一处、签署记录难以追溯。把归档动作放到协作平台上，可以让清单、文档和状态在同一条流程里流转。
清单跟踪方面，可以把归档清单作为工作项或检查项管理，每条对应一个文件类别，责任人、截止时间、当前状态都在条目上体现。文档管理员按状态筛选待收集条目，项目经理查看整体完成比例，完成标志就是全部条目状态变为已归档。
文档集中存放方面，ONES Wiki支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，收尾报告、变更记录、评审结论可以按项目归入同一页面树，避免散落在个人目录。文档实时同步并记录所有页面版本，支持随时查看与回滚，版本一致性核对时可以直接对照历史版本。页面模板库可一键创建制式化文档模板，让收尾报告、移交记录按统一结构填写；附件支持存档和在线预览，接收方无需下载即可查阅。
权限与留痕方面，ONES Wiki支持为多种角色配置不同的读写权限，可按项目经理、文档管理员、质量或PMO、业务接收方分别设置访问范围；误删页面可从回收站恢复。归档评审与签署的记录随文档保留，项目状态关闭与归档完成在同一平台上衔接，查询时能同时看到关闭状态和归档证据。需要说明的是，密级字段、保存期限策略以及项目关闭状态与归档完成的联动方式，需结合组织实际配置确认，本文不对此作具体能力断言。
常见问题
项目已经关闭了，还能补做归档吗？
可以补，但成本和风险都会上升。项目关闭后团队往往已经解散，文件责任人难以联系，补做时容易只剩个人手里的零散版本，审批链也难以复原。更稳妥的做法是把归档列为关闭的前置条件：先完成移交并由接收方确认，再把项目状态置为关闭。若确实已经关闭，建议由原项目经理牵头，按归档清单逐条追溯来源系统与审批记录，缺失项在清单中记录原因并经质量或PMO确认，补做完成后更新归档状态。
归档清单在收尾阶段还能新增条目吗？
可以新增，但要控制变更。清单在收尾启动时定稿，之后新增条目需经项目经理确认，并说明新增理由和责任人。这样做的目的是避免收集阶段范围反复变动，导致文档管理员反复返工。如果新增的是必须归档类文件，应同步评估是否影响关闭时点；如果属于按需归档，可由项目经理与质量或PMO确认后列入，并在检查表中体现确认记录。
同一份文件存在多个版本，归档时以哪一版为准？
以审批通过的最终版为准，其余版本标注为过程稿单独存放。判断依据是审批链是否闭合，而不是文件修改时间或文件名里的版本号。实际操作中，先找到对应的审批记录，确认哪一版获得了批准，再请文件责任人书面确认有效版本，确认记录一并归档。如果审批记录本身缺失，应先补齐审批说明，再决定归档版本，避免把未获批准的稿件当作正式记录移交。
转换类项目（如移交运维）的归档时点和关闭类项目有什么不同？
两者都要在项目状态变更之前完成归档，差别在于接收方和移交内容。关闭类项目的接收方通常是档案库或档案管理部门，移交的是完整档案；转换类项目在移交运维前完成归档，接收方是运维团队，除档案外还需要确认运维可接手，例如运维手册、配置说明、遗留问题清单是否齐全。无论哪类，顺序都是先移交并取得接收方确认，再变更项目状态，避免出现状态已变更而档案不全的情况。
归档检查表由谁填写、谁复核？出现阻断项怎么处理？
通常由文档管理员填写每项的实际状态并附证据，项目经理作为负责人复核签字，质量或PMO对阻断项做最终判定。出现阻断项时，项目不得置为关闭状态，应针对该项限期整改，整改完成后重新检查该项，其余已通过项无需重复检查。检查表全部通过后，才允许更新项目状态，并把检查表本身作为收尾文件一并归档，形成可追溯的关闭证据。
