项目暂停是项目生命周期中一种受控的中间状态：项目暂不推进，但保留恢复可能。要把它管好，需要先判断该不该停、由谁拍板，再冻结范围与基线、完成在途交接和资产留存，最后设定可验证的恢复条件与复核时点。本文按决策、执行、分工、恢复、示例、检查六个环节展开，并在交接记录与状态维护处说明ONES可承载的方式。
要点总览（TL;DR）
- 项目暂停先判断触发类型与决策权限：资源、需求、外部依赖、预算、合规风险各有不同的判断要点，决策结论要明确是暂停、终止还是缓期执行。
- 暂停执行按“冻结基线—处置在途事项—人员交接—资产留存—通知相关方”推进，每一步都有输入、动作、输出和完成标志。
- 暂停决策记录、暂停交接清单、恢复条件与复核计划是三份核心产物，分别由项目负责人起草，按权限由职能负责人、项目管理办公室和发起人确认。
- 恢复条件要写成可验证的判定语句，包含判定指标、数据来源、责任人和复核时点；复核结论分为批准恢复、有条件恢复、继续暂停、转入终止四类。
- 暂停流程是否到位可用决策记录、交接留存、恢复条件三组检查项核对，只发通知未冻结基线、交接依赖口头说明属于常见阻断项。
项目暂停前先判断：哪些情况该停、由谁决定
暂停不是项目负责人在压力下的临时选择，而是一项需要授权和留痕的管理决定。判断的起点是识别触发原因属于哪一类，再对照决策权限确认谁有权批准。原因不清、权限不明的“先停一停”，往往在恢复时变成范围争议和责任真空。
暂停的常见触发类型
| 触发类型 | 典型表现 | 判断要点 |
|---|---|---|
| 资源类 | 关键岗位人员长期缺位、核心团队被抽调至更高优先级事项 | 缺口持续时间是否超过项目可承受的等待窗口 |
| 需求类 | 需求方向发生重大调整、关键需求尚未确认 | 继续投入是否会产生大概率返工 |
| 外部依赖类 | 供应商交付延迟、合作方接口未就绪、审批未落地 | 依赖是否在项目可控范围之外，且短期无替代方案 |
| 预算类 | 预算冻结、付款节点未获批、成本超支需重新核定 | 资金缺口是否影响在途合同与人员安排 |
| 合规与风险类 | 出现安全、法务或合规问题需调查，或重大风险需重新评估 | 继续推进是否可能扩大风险敞口 |
同一项目可能同时命中多类触发条件，记录时应写明主因和次因，主因决定后续恢复条件的设定方向。
暂停、终止与缓期执行的区别
暂停保留项目恢复的可能，范围、基线和团队关系原则上延续；终止结束项目生命周期，进入清算与收尾；缓期执行通常指计划整体后移、项目仍在途，只是启动或推进时间推迟。三者的差别直接影响资源释放方式：暂停需要保留恢复所需的最小资产和信息，终止可以按收尾流程释放，缓期执行则更多是重排计划。决策记录中应明确写出本次属于哪一种，避免用“暂停”处理本应终止的事项，也避免把缓期执行写成暂停而造成不必要的冻结成本。
决策层级与审批要求
决策权限按影响范围划分：影响单个项目内部排期的，由项目负责人提出、职能负责人确认；涉及跨部门资源调配或预算调整的，由项目管理办公室复核、发起人或更高层级管理者批准；涉及合同、合规或客户承诺的，需客户方或法务、合规相关责任人共同确认。审批要求应事先在组织内约定，而不是每次临时找人签字。审批结论只有三种：批准暂停、不批准并继续推进、转入终止或缓期执行，每种结论都要有明确的责任人和生效时间。
暂停决策需要记录的关键信息
- 项目名称、当前阶段、暂停生效时间与预计暂停时长；
- 暂停原因分类、主因描述及支撑事实；
- 决策类型（暂停、终止、缓期执行）及决策人、审批人、决策日期；
- 暂停时的范围基线版本、进度基线版本与预算执行情况；
- 在途合同、外部依赖和人员安排的处置原则；
- 恢复条件的初步方向与下次复核时间。
暂停执行的核心步骤：从冻结到交接
决策批准后，暂停执行按“冻结—处置—交接—留存—通知”的顺序推进。每一步都要有明确输入、动作、输出和完成标志，避免出现“已经停了但没人说得清停在哪”的状态。
第一步：冻结范围、进度基线与在途变更
输入是当前批准的范围说明、进度计划和变更记录。动作是确认冻结时点的基线版本，把尚未审批的变更标记为挂起，停止新增需求进入当前范围。输出是带版本号的冻结基线说明。完成标志是所有干系人确认“以该版本为准”，后续讨论均以它为参照。
第二步：处置在途任务与外部依赖
输入是任务清单和依赖台账。动作是逐项标注每个在途任务的状态：完成待验收、做到一半需封存、可以取消、需移交他人。对外部依赖，逐一联系供应方或合作方，确认合同是否中止、暂停或继续履行，明确对方在暂停期间的义务。输出是在途任务处置表与外部依赖处置结论。完成标志是每项任务和依赖都有明确归属和下一步动作，没有“悬空”条目。
第三步：人员安排与交接
输入是团队名单和任务处置结果。动作是为每个成员确定暂停期间的安排：留在项目做维护、转至其他项目、待命或离场；对转出人员，指定接收人和交接内容。输出是人员安排表与交接确认记录。完成标志是接收人确认已理解交接内容，转出人员的工作不再依赖个人记忆。
第四步：资产、文档、环境与数据的留存
输入是项目资产清单。动作包括：归档关键文档并标注版本，保存代码、配置和数据的可用副本，记录环境地址、账号归属和访问方式，明确哪些环境继续运行、哪些关停。输出是资产留存清单。完成标志是他人按清单可在不询问原成员的情况下找到并理解这些资产。
第五步：通知相关方与发布暂停公告
输入是决策记录和上述各步产出。动作是向团队、客户、供应商和管理层分别发出通知，内容包含暂停原因（按披露范围）、生效时间、各方需配合的事项、联系人和下次信息更新时间。输出是暂停公告与通知记录。完成标志是关键相关方均确认收到，且知道在暂停期间找谁、何时能得到更新。
暂停执行步骤清单
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 冻结基线 | 范围说明、进度计划、变更记录 | 确认冻结版本，挂起未审批变更 | 冻结基线说明 | 干系人确认以该版本为准 |
| 处置在途事项 | 任务清单、依赖台账 | 逐项标注状态与归属，联系外部方 | 任务处置表、依赖处置结论 | 无悬空条目 |
| 人员交接 | 团队名单、处置结果 | 确定安排，指定接收人 | 人员安排表、交接确认 | 接收人确认理解 |
| 资产留存 | 资产清单 | 归档文档、保存副本、记录环境 | 资产留存清单 | 按清单可独立找到资产 |
| 通知相关方 | 决策记录与各步产出 | 分对象发出通知 | 暂停公告、通知记录 | 关键方确认收到 |
这些记录需要有稳定的存放位置，否则暂停几个月后很难还原。ONES Wiki 支持页面组关联项目、文档与任务互相对应，并提供页面版本记录与回滚，适合把冻结基线说明、交接清单和通知记录集中留存；权限可按角色配置读写范围，便于在暂停期间控制访问。具体配置以实际部署为准。
角色分工与交付物：谁负责什么
暂停流程失效，常见原因不是没人做事，而是同一件事被两个人默认对方负责。用职责矩阵把“提出、批准、执行、留存、复核”五类动作落到具体角色，可以显著减少交接遗漏。
角色职责矩阵
| 职责 | 项目负责人 | 职能负责人 | 项目管理办公室 | 客户或发起人 |
|---|---|---|---|---|
| 提出暂停建议并说明原因 | 主责 | 参与 | 知会 | 知会 |
| 批准暂停及决策类型 | 提出 | 确认资源影响 | 复核流程合规 | 按权限批准 |
| 冻结基线与在途处置 | 主责 | 配合人员安排 | 抽查完整性 | 确认范围影响 |
| 交接与资产留存 | 主责 | 指定接收人 | 提供模板与归档规范 | — |
| 恢复条件设定与复核 | 主责 | 参与判定 | 组织复核会议 | 确认恢复或转终止 |
矩阵中的“主责”指对该项产出负最终责任，不代表独自完成；跨部门事项由主责人协调，职能负责人对人员安排和资源释放承担确认责任。
三份核心交付物及负责人
- 暂停决策记录：由项目负责人起草，批准人签署。字段建议包括项目信息、暂停原因分类与描述、决策类型、决策人与审批人、生效时间、预计时长、影响范围、恢复条件初步方向。
- 暂停交接清单：由项目负责人组织编制，各任务责任人填写本人部分，接收人签字确认。字段建议包括任务或资产名称、当前状态、存放位置、接收人、交接日期、遗留问题。
- 恢复条件与复核计划：由项目负责人起草，项目管理办公室复核，发起人确认。字段建议包括恢复条件描述、判定指标、数据来源、责任人、复核时点、当前判定结果。
三份文件应在暂停生效后一个约定周期内完成签署，未完成的项列入待办并指定补交时间。使用统一模板可以减少字段遗漏，ONES Wiki 的页面模板库支持一键创建制式化文档，附件可在线预览，便于交接双方核对材料。
恢复条件与复核机制怎么设定
暂停期间最容易失控的环节是“等通知”。恢复条件写得含糊，复核就会变成凭感觉判断，项目要么长期悬置，要么在条件不成熟时仓促重启。可验证的恢复条件是保持项目可恢复的核心。
恢复条件的可验证写法
一条合格的恢复条件应包含判定指标、数据来源、责任人和判定标准，写成可以被第三方核对的语句。例如“关键岗位两名工程师到岗”比“人员到位后恢复”更可验证；“预算批复文件已下达且金额覆盖剩余工作量”比“预算问题解决”更可核对。条件数量不宜过多，聚焦决定能否推进的关键前提，通常三到五条即可，并区分必须满足和可以并行处理两类。
恢复条件表
| 恢复条件 | 判定指标 | 数据来源 | 责任人 | 复核时点 |
|---|---|---|---|---|
| 关键人员到位 | 指定岗位人员到岗并完成交接确认 | 人员安排表、交接记录 | 职能负责人 | 每月复核 |
| 预算落实 | 批复文件下达，金额覆盖剩余工作量 | 财务批复文件 | 项目发起人 | 每月复核 |
| 外部依赖就绪 | 供应方交付确认或接口联调通过 | 依赖台账、验收记录 | 项目负责人 | 每两周复核 |
| 需求方向明确 | 范围说明经批准并形成新基线 | 变更记录 | 项目负责人 | 触发式复核 |
复核周期与责任人
复核周期按暂停原因的不确定性设定：外部依赖类可每两周一次，资源与预算类可每月一次，出现明确信号时随时触发。每次复核由项目管理办公室组织，项目负责人汇报条件达成情况，职能负责人和发起人参与判定。复核要有简短记录，写明本次判定结果和下次复核时间，避免复核流于形式。
暂停期间的状态维护与信息更新
暂停期间项目仍需保持“可被找到、可被理解”的状态：工作项状态统一标记为暂停或挂起，冻结基线版本保持可查，交接清单和恢复条件表随复核结果更新。相关方按公告约定的节奏收到进展说明，即使没有变化也应有“本期无变化、下次复核时间”的简短更新。在ONES中，项目工作项状态与文档可以保持关联，复核结论作为文档版本留存，便于恢复评审时追溯每次判定的依据。
恢复评审的输入与结论类型
恢复评审的输入包括恢复条件表的当前判定结果、冻结基线说明、交接清单完成情况、资源与预算的确认材料。结论分为四类：满足条件、批准恢复并重排计划；部分满足、批准有条件恢复并限定范围；不满足、继续暂停并更新复核计划；条件已不可能满足、建议转入终止。结论需由原批准层级或授权人确认，并同步更新项目状态。
示例：一个研发项目暂停与恢复的完整过程
以下为演示情景，用于说明流程衔接，不代表真实客户案例。
情景设定与暂停原因
某研发项目处于开发中期，核心模块依赖外部供应商提供的数据接口。供应商因自身排期调整，接口交付推迟约三个月，同时项目两名关键开发人员被抽调至紧急事项。项目负责人评估后认为继续开发将产生大量返工，提出暂停建议，主因为外部依赖，次因为资源缺口。
决策记录与交接执行
项目负责人提交暂停决策记录，写明原因分类、当前基线版本、在途任务清单和初步恢复方向。职能负责人确认人员抽调安排，项目管理办公室复核流程完整性，项目发起人批准暂停，生效时间为当月末。随后执行冻结：范围基线锁定为当前批准版本，两项未审批变更挂起；在途任务逐项标注为完成待验收、封存或取消；两名转出人员完成交接，接收人签字；代码、配置和测试数据保存副本，环境地址与账号归属记入资产留存清单；向客户和供应商发出暂停公告，说明联系人和每月更新安排。
暂停期间的复核
恢复条件设定为三条：供应商接口交付确认、关键岗位人员到岗、剩余预算确认。复核周期为每月一次，由项目管理办公室组织。第一个月复核，三项条件均未满足，记录“继续暂停”；第二个月，预算确认完成，其余两项未达成；第三个月，供应商交付接口并通过联调，一名关键人员到岗，另一名仍在协调中。
恢复评审与重新启动
第四个月复核时，三项条件全部满足。恢复评审输入包括条件判定结果、冻结基线说明和交接清单完成情况。评审结论为批准恢复，并要求重排进度计划、将挂起的变更重新提交审批。项目负责人更新工作项状态，重新确认团队分工，向相关方发布恢复通知，项目进入新一轮执行。整个过程的关键记录均保留在项目文档中，后续复盘可直接调取。
完成检查：暂停流程是否做到位
暂停流程是否合规、是否真正可恢复，可以用下面的清单逐项核对。任一项未通过，都应视为阻断项，在恢复评审前补齐。
决策与记录完整性检查
- 暂停原因已分类，主因有事实支撑；
- 决策类型明确为暂停、终止或缓期执行；
- 决策人、审批人、生效时间齐全，审批层级符合组织约定；
- 暂停决策记录已归档，相关方可查。
交接与资产留存检查
- 范围与进度基线已冻结并标注版本；
- 在途任务和外部依赖均有处置结论，无悬空条目；
- 转出人员完成交接，接收人已确认；
- 文档、代码、配置、数据有可用副本，环境访问方式有记录；
- 暂停公告已发出，关键相关方确认收到。
恢复条件与复核计划检查
- 每条恢复条件包含判定指标、数据来源、责任人和判定标准；
- 复核周期已确定并有责任人；
- 暂停期间有按约定节奏的信息更新记录；
- 恢复评审的结论类型和批准人已事先约定。
常见遗漏与阻断项
实践中高频出现的问题包括：只发通知未冻结基线，恢复时无法判断哪些变更属于暂停前；交接依赖口头说明，原成员离场后无人能接手；恢复条件写成“情况好转”，复核无法判定；暂停期间无人更新状态，相关方以为项目仍在推进。这些情况应作为阻断项处理，在恢复评审前完成整改，否则恢复后的项目将带着未解决的范围和责任问题重新启动。
常见问题
项目暂停期间，团队成员已经转到其他项目，恢复时人员无法全部回来怎么办？
这种情况应在暂停决策阶段就预判。交接时除记录任务状态，还要标注每项工作的可替代性和最低人员配置要求，把“关键岗位到岗”写成恢复条件之一，并明确岗位名称和人数，而不是笼统写“人员到位”。复核时如果人员无法全部回归，恢复评审可以给出有条件恢复的结论：先按现有人员重排范围，把依赖缺失人力的部分继续挂起，待人员补齐后再纳入。若长期无法满足，则按条件已不可能满足处理，转入终止或重新立项。
暂停时间较长时，冻结的基线还需要维护吗？
需要，但维护的重点是保持可读和可追溯，而非继续更新进度。冻结基线应保留版本号和冻结时点说明，暂停期间发生的任何范围讨论、外部依赖变化和复核结论，都作为新记录追加，不改动原基线内容。这样恢复评审时能清楚区分“暂停前的批准范围”和“暂停期间的新情况”，避免把两者混在一起导致范围争议。版本记录和回滚能力可以帮助保留这一过程。
客户不同意暂停，但内部资源确实无法支撑，怎么处理？
先区分决策类型：如果客户承诺和合同义务仍然有效，单方面暂停会带来履约风险，此时更适合走“有条件缓期执行”或缩减范围的路径，由项目负责人提出方案，职能负责人确认资源约束，项目管理办公室评估影响，客户或发起人批准。若确实需要暂停，应把客户确认作为决策生效的前提之一，并在暂停公告中写明对交付节点的影响和后续沟通安排。决策记录中保留不同意见和最终批准人，便于后续追溯。
暂停期间没有任何变化，还需要按周期复核吗？
需要保留复核动作，但可以简化。每次复核至少记录三项内容：本次判定结果、依据的数据来源、下次复核时间。即使结论是“继续暂停”，这条记录也能证明项目处于受控状态，而不是被遗忘。复核节奏可按暂停原因的不确定性调整，外部依赖类可以每两周一次，资源和预算类可以每月一次；连续多次无变化时，可经批准人同意后延长周期，但不宜取消复核时点。
暂停和终止在收尾动作上有什么不同，容易混在哪里？
暂停保留恢复可能，因此要保留最小可恢复资产：冻结基线、交接清单、环境与数据副本、恢复条件表，团队关系原则上延续；终止结束项目生命周期，进入清算与收尾，资源按收尾流程释放，合同和资产按约定处理。最容易混的地方是资源释放：用暂停的方式处理本应终止的项目，会长期占用人员和环境；用终止的方式处理本可恢复的项目，则会造成资产和知识流失。决策记录中明确写出类型，是避免混淆的关键动作。
