项目收尾要按顺序完成六件事：确认交付与验收结论、结清合同与财务、移交成果与知识、释放资源并关闭工作项、复盘归档、正式宣布关闭。每一步都需要明确输入、负责人和可核对的产出。本文面向需要结束整个项目或阶段转换的项目经理与交付负责人，说明收尾的进入条件、六步主干流程、角色分工、遗留问题处置规则和关闭前检查清单。单次软件交付的验收细节不在本文展开。
要点总览（TL;DR）
- 收尾启动前先做进入条件核对并冻结范围：交付物状态、验收结论、合同义务、遗留问题登记和收尾资源五项逐项判断，未满足项转为遗留问题或新项目。
- 六步主干按依赖顺序推进：确认交付与验收结论、结清合同与财务、成果与知识移交、释放资源、复盘沉淀、关闭评审并宣布关闭，每步都有可核对的产出。
- 遗留问题分四类处置——必须关闭、转交运维、转入新项目、接受风险，每类有判定条件和审批人，缺少审批记录的接受风险项不能视为已处置。
- 关闭评审前按检查清单逐项核对，验收结论、遗留问题处置、结算状态、移交签收、归档完整、环境账号处理属于阻断项，未清零不得宣布关闭。
- 收尾任务与遗留问题作为工作项统一跟踪，移交记录、复盘报告和关闭确认记录集中归档，项目关闭状态与收尾进度对应。
收尾启动前先确认哪些条件
收尾处理的是项目整体结束或转入运维、转入下一阶段这类生命周期节点，与单次交付验收属于不同层级。一次交付验收通过，只说明某个批次成果被接收；项目能否进入收尾，还要看全部交付物、合同义务和未完成事项是否已有结论。把两者混在一起，容易出现“验收单签了、项目却关不掉”的情况。
启动收尾前，项目经理应组织一次进入条件核对，逐项给出“满足 / 未满足 / 不适用”的判断，并记录未满足项的处理安排。核对表可按以下条目组织：
| 核对项 | 判断标准 | 未满足时的处理 |
|---|---|---|
| 交付物状态 | 合同或项目章程列明的交付物均已完成，或有明确的遗留处理结论 | 列出缺口，转为遗留问题或新项目范围 |
| 验收结论 | 关键交付物已有客户或接收方的书面验收意见 | 约定验收时间，收尾计划相应顺延 |
| 合同义务 | 交付范围、服务期、质保条款的履行情况已梳理清楚 | 由商务确认剩余义务与结算条件 |
| 遗留问题登记 | 已知未完成事项、缺陷、待办均有记录和责任人 | 先补登记，再进入收尾 |
| 收尾资源 | 核心成员在收尾期的时间已预留 | 与职能经理协调排期 |
进入收尾的同时要冻结范围。冻结的含义是：不再接受新的需求变更和范围扩张，新提出的需求登记为变更请求，由项目发起人或变更评审决定转入新项目、转入运维还是拒绝。冻结不是停止一切工作，而是把工作限定在“完成既有交付、处理遗留问题、完成移交”之内。冻结决定应在收尾启动会上明确宣布，并通知客户与相关干系人。
收尾启动会的输入包括：项目章程与合同、交付物清单、验收记录、未完成事项清单、资源与预算使用情况。参与角色通常为项目经理、交付或技术负责人、商务与财务代表、质量与配置管理人员、客户或接收方代表，必要时请职能经理参加，确认人员释放时间。
项目收尾的六个步骤与每步产出
六个步骤按依赖关系排列：验收结论是结算与移交的前提，移交完成后才能释放资源，复盘与关闭评审在信息齐全后进行。下表给出每步的输入、动作、输出与完成标志，可作为收尾计划的骨架。
| 步骤 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、确认交付与验收结论 | 交付物清单、验收标准、测试与检查记录 | 逐项核对交付物；收集验收意见；登记未通过项 | 验收结论、遗留问题清单 | 全部交付物有“通过 / 遗留处理”结论并有人签字确认 |
| 二、结清合同、采购与财务 | 合同条款、采购订单、发票与付款记录 | 核对尾款条件；清理未结采购；确认应收应付 | 结算与付款状态记录 | 每笔款项有状态（已结 / 在途 / 争议），争议有处理方案 |
| 三、成果与知识移交 | 交付物、技术文档、操作手册、账号与权限清单 | 组织移交说明；接收方试用确认；整理归档目录 | 移交签收单、文档归档目录 | 接收方签收，归档目录与实际文档一致 |
| 四、释放人员、环境与外部资源 | 资源清单、环境与账号清单、外包与租赁合同 | 通知释放时间；回收权限；关停环境；退租退订 | 资源释放记录 | 人员已回到可用排期，环境与账号已关停或移交 |
| 五、复盘与经验沉淀 | 项目数据、问题记录、干系人反馈 | 组织复盘会；分析偏差原因；形成改进行动项 | 复盘报告、改进行动项 | 报告完成评审，行动项有责任人和期限 |
| 六、关闭评审与正式宣布关闭 | 前五步全部产出 | 逐项核对关闭条件；确认阻断项清零；发布关闭通知 | 关闭确认记录 | 评审结论为“同意关闭”，通知已送达干系人 |
每步都有常见卡点。验收环节常卡在客户迟迟不出具书面意见，处理办法是约定验收期限并在期限后按合同条款处理。结算环节常卡在尾款条件表述模糊，需要在收尾前由商务与客户对齐付款节点。移交环节常卡在文档与实际系统不一致，应在移交前做一次文档走查。资源释放常卡在成员已被新项目占用却未办交接，需要提前锁定交接窗口。复盘常流于形式，可用“偏差—原因—可复用做法”三栏结构约束讨论范围。关闭评审常因遗留问题无人认领而拖延，这正是下一节要解决的问题。
收尾阶段谁负责什么：角色与交付物分工
收尾出问题，多数不是没人干活，而是同一件事有两个负责人或没有负责人。按角色划分职责，并明确每项交付物的完成时点，可以减少推诿。项目经理对收尾整体负责，其他角色对各自交付物的内容质量负责。
| 角色 | 主要职责 | 负责的交付物 | 完成时点 |
|---|---|---|---|
| 项目经理 | 编制收尾计划、组织收尾启动会与关闭评审、跟踪遗留问题、对关闭结论负责 | 收尾计划、遗留问题清单、关闭确认记录 | 贯穿收尾全程，关闭评审时收口 |
| 交付 / 技术负责人 | 确认交付物完整性、编写或审核技术文档、执行知识移交 | 交付物核对结论、技术文档、移交说明材料 | 步骤一与步骤三 |
| 商务与财务 | 核对合同义务、办理结算与发票、确认尾款条件、清理采购 | 结算与付款状态记录 | 步骤二，关闭评审前完成 |
| 质量与配置管理 | 整理验收证据、维护文档版本基线、核对归档完整性 | 验收证据包、归档目录与基线记录 | 步骤一与步骤三 |
| 客户或接收方 | 出具验收意见、签收移交成果、确认遗留问题处理方式 | 验收意见、移交签收单、遗留问题确认 | 步骤一与步骤三 |
| 职能经理 | 确认人员释放时间、安排后续排期、接收成员交接 | 资源释放确认 | 步骤四 |
分工中有两处交接容易断档。一是技术负责人向接收方移交时，若接收方不是原客户团队，需要额外安排操作培训并留下培训记录。二是职能经理接收释放人员时，应确认成员手上的文档、账号和待办已交接完毕，而不是仅确认人员可以调走。项目经理在这两处交接中承担催办和确认的角色。
遗留问题与未完成事项怎么处理
收尾关不掉，通常卡在遗留问题。处理原则是先分类、再定审批人、最后落到清单字段，避免所有问题都堆在“待处理”状态。遗留问题可分为四类：
- 必须关闭：影响合同义务履行、存在安全或合规风险、阻断接收方正常使用的事项。判定条件是该事项不解决则验收结论不成立。审批人为项目经理与客户代表共同确认。
- 转交运维：已上线系统的日常维护、监控、小缺陷修复类事项。判定条件是接收方已具备运维能力并同意接收。审批人为运维负责人与客户代表。
- 转入新项目：超出原合同范围、需要独立立项的增强需求或二期建设内容。判定条件是需求已明确且不在原验收范围内。审批人为项目发起人。
- 接受风险：影响可控、修复成本高于收益、双方同意暂不处理的事项。判定条件是风险影响已评估且接收方书面认可。审批人为客户代表与项目发起人。
遗留问题清单建议包含以下字段：编号、问题描述、来源（验收 / 测试 / 客户反馈）、影响范围、责任人、处理方式（对应上述四类）、计划完成期限、当前状态、审批记录。其中“处理方式”和“审批记录”是关闭评审时的核对重点，缺少审批记录的“接受风险”项不能视为已处置。
风险接受需要留存记录，内容至少包括：风险描述、可能影响、接受理由、接受人、接受日期，以及后续跟踪方式。记录应由客户或接收方签字确认，归入项目档案。这样做的目的是在项目关闭后仍能追溯“当时为什么决定不处理”。
示例：一个系统上线项目的收尾过程
以下为演示情景，用于说明六步流程如何落地，不代表真实客户案例。某企业委托开发一套内部审批系统，合同约定上线试运行一个月后进入收尾。试运行期满，客户提出验收申请，项目进入收尾。
步骤一，确认交付与验收结论。交付负责人对照合同清单核对功能模块、接口文档和部署手册，质量人员整理测试报告与试运行记录。客户出具验收意见，同时提出三项未完成事项：两个报表格式待调整、一个历史数据导入脚本待优化。这三项登记为遗留问题，前两项定为“必须关闭”，第三项定为“转入新项目”。产出为验收结论和遗留问题清单。
步骤二，结清合同与财务。商务核对合同尾款条件，确认试运行验收通过即触发尾款支付；财务清理服务器采购的未结发票。产出为结算与付款状态记录，尾款标注“在途”，采购标注“已结”。
步骤三，成果与知识移交。技术负责人向客户信息部门做系统架构与运维培训，移交管理员账号、部署文档和接口说明。客户签收移交单。质量人员按模块整理归档目录，确认文档版本与上线版本一致。产出为移交签收单和归档目录。
步骤四，释放资源。项目经理通知职能经理，两名开发人员于两周后释放；回收测试环境访问权限，关停临时演示环境；退订试运行期间租用的云资源。产出为资源释放记录。
步骤五，复盘。项目组围绕进度偏差和数据导入问题组织复盘，形成两条改进行动项：需求阶段增加报表样例确认环节；数据迁移类工作提前安排样本验证。产出为复盘报告与行动项。
步骤六，关闭评审。项目经理组织客户代表、交付负责人和商务参加评审，逐项核对：两个报表问题已修复并复验通过，历史数据脚本已作为新项目需求登记，尾款在途有付款计划，移交单与归档目录齐全，资源已释放。评审结论为同意关闭，项目经理发布关闭通知并归档全部记录。
收尾完成检查清单
关闭评审前，按下表逐项核对。每项给出通过标准，未达到阻断标准的项目不得宣布关闭。
| 类别 | 检查项 | 通过标准 | 是否阻断 |
|---|---|---|---|
| 交付与验收 | 交付物核对完成 | 合同清单逐项有结论 | 是 |
| 交付与验收 | 验收意见已取得 | 客户或接收方书面确认 | 是 |
| 交付与验收 | 遗留问题全部有处理方式 | 四类处置均有审批记录 | 是 |
| 合同财务 | 结算状态清晰 | 每笔款项有状态与责任人 | 是 |
| 合同财务 | 未结采购已清理 | 无悬空订单 | 否，需有处理计划 |
| 移交与归档 | 移交签收单齐全 | 接收方已签字 | 是 |
| 移交与归档 | 文档归档完整 | 归档目录与实际文档一致，版本为最终版 | 是 |
| 资源释放 | 人员释放已确认 | 职能经理确认排期 | 否，需有释放日期 |
| 资源释放 | 环境与账号已处理 | 关停或移交有记录 | 是 |
| 复盘改进 | 复盘报告完成 | 报告已评审，行动项有责任人和期限 | 否，需有完成日期 |
阻断项集中在验收结论、遗留问题处置、结算状态、移交签收、归档完整和环境账号处理。这些事项未完成时宣布关闭，会把风险留给运维方或下一阶段团队。非阻断项允许带计划关闭，但计划本身要写入关闭确认记录，并指定跟踪人。所有检查结果由项目经理汇总，证据材料随关闭确认记录一并归档。
用工具承载收尾过程与归档
收尾阶段的事项分散在多个角色手中，靠邮件和表格传递容易丢失状态。把收尾任务和遗留问题作为工作项统一登记，可以让每项都有责任人、期限和关闭记录。ONES 支持项目制管理，针对需求明确、交付周期固定的场景严控里程碑和交付物，收尾清单可以作为项目末期的工作项集合纳入同一项目跟踪。遗留问题按“必须关闭、转交运维、转入新项目、接受风险”分类后，分别建立工作项或转入对应项目，关闭时留下处理记录，关闭评审时按状态筛选即可核对。
移交记录、复盘报告和关闭确认记录需要集中存放。ONES 提供知识库管理，可将收尾文档按项目归档，配合质量与配置管理维护的归档目录使用。评审结论和签收记录作为文档留存，便于项目关闭后追溯。复盘形成的改进行动项同样作为工作项登记，指定责任人和期限，避免复盘结束即失联。
项目关闭状态与收尾进度需要对应起来：收尾工作项全部关闭、阻断项清零后，才在项目中标记关闭并发布通知。ONES 的效能度量可从交付效率、交付质量、资源效率、完成情况等维度分析研发过程数据，收尾阶段的交付物完成情况和遗留问题处理情况可作为复盘的数据参考；预置的仪表盘模板可供项目经理直接使用，并按角色配置读写权限。具体使用哪些报表，应结合团队已有的数据记录情况决定。
常见问题
项目已经通过验收，为什么还不能直接宣布关闭？
验收通过只说明交付物被接收，项目关闭还涉及合同结算、成果移交、资源释放和文档归档。常见情况是验收单已签，但尾款条件未对齐、账号与环境未关停、遗留问题没有审批记录，这些都会让项目在关闭评审时被卡住。建议在验收通过后立即启动收尾进入条件核对，把未满足项登记为待办并指定责任人，再按六步流程逐项推进。
客户迟迟不出具书面验收意见，收尾怎么推进？
先确认合同或验收标准中是否约定了验收期限和逾期处理方式。有约定的，按约定在期限届满后推进后续步骤，并留存催办记录；没有约定的，由商务与客户补充确认验收节点和书面意见的出具时间，收尾计划相应顺延。在意见取得前，交付物状态可标注为“待确认”，但结算和正式关闭不宜提前完成，避免把未确认的风险留给后续团队。
收尾期间客户又提出新需求，应该接还是拒？
收尾启动时已冻结范围，新需求应作为变更请求登记，由项目发起人或变更评审决定去向：属于原合同范围内且影响验收的，纳入必须关闭项；超出原范围、需要独立投入的，转入新项目立项；属于上线后日常优化的，转交运维处理。关键是留下书面结论和审批记录，避免新需求以口头方式混入收尾工作，拖长关闭周期。
遗留问题中的“接受风险”需要哪些记录才算处置完成？
接受风险至少需要留存风险描述、可能影响、接受理由、接受人、接受日期和后续跟踪方式，并由客户或接收方签字确认后归入项目档案。关闭评审时核对的是审批记录是否齐全，仅有口头同意或清单上标注“暂不处理”都不足以证明风险已被正式接受。这样做的目的是项目关闭后仍能追溯当时为什么决定不处理。
复盘会容易走过场，怎么让结论真正落到后续项目？
用“偏差—原因—可复用做法”三栏结构约束讨论范围，每场复盘只围绕已发生的具体偏差展开，避免泛泛谈感受。复盘产出的改进行动项要作为工作项登记，指定责任人和完成期限，并在后续项目的启动或计划环节回看。复盘报告完成评审、行动项有人跟进，才算这一步收尾完成；否则报告归档后容易失联。
