项目暂停是项目生命周期中的一次状态转换，需要先判断是否该暂停，再完成范围冻结、交付物清点、合同与成本处理、文档交接，最后设定恢复或终止的评审时点。本文按决策、执行、角色文档、示例和出口检查五个环节展开，适用于项目整体层面的暂停安排；单次软件交付的验收流程不在讨论范围内。
要点总览（TL;DR）
- 暂停前先比较暂停、终止、缩减范围、延期四个选项：目标仍有效且恢复条件可验证时选暂停，恢复无时间窗口或成本超过重新立项时选终止。
- 执行按冻结范围、清点工作项、处理合同付款、归档资料环境、通知确认五步推进，每步都要有输出和完成标志。
- 暂停记录至少写清原因、范围快照、资源状态、已发生成本、恢复条件和评审日期，让数月后的接手人能还原判断。
- 恢复条件写成可验证的信号，并同时设置固定复核日期和触发信号，避免项目长期悬置、无人跟进。
- 暂停期间保留人员控制在维持合同义务、环境可用和客户沟通的最小范围，并明确工作内容与汇报节奏。
先判断：项目该暂停、继续还是终止
暂停的实质是把项目从“推进”切换到“保留”，资源投入大幅收缩，但项目目标和交付义务仍然存在。因此，判断的核心不是“当前有多难”，而是“外部条件是否可能在可预期的时间内恢复”。如果恢复没有时间窗口，或者恢复成本已经超过重新立项的成本，更合适的动作是终止；如果目标不变、只是节奏需要调整，延期或缩减范围往往比暂停更轻。
暂停的典型触发条件
- 预算冻结：客户或公司层面的资金审批暂停，短期内无法继续支付人力与采购费用，但预算周期结束后可能恢复。
- 关键依赖缺失：上游系统、第三方接口、供应商交付或关键岗位人员缺失，且缺失原因在项目控制范围之外。
- 需求方向待定：业务方正在重新评估产品方向或优先级，尚未形成可执行的需求结论。
- 外部合规或客户决策未落地：合同审批、监管许可、客户内部立项流程尚未完成，继续投入会产生无法回收的成本。
与终止、缩减范围、延期的区分标准
| 选项 | 适用情形 | 资源处理 | 需要回答的问题 |
|---|---|---|---|
| 暂停 | 目标仍然有效，恢复条件明确但时间不确定 | 保留少量人员维持，其余释放 | 恢复信号是什么？谁在什么时点复核？ |
| 终止 | 目标失效、恢复成本过高或合同已无履行基础 | 全部释放，进入收尾与结算 | 已发生成本如何结算？交付物如何移交？ |
| 缩减范围 | 预算或时间受限，但核心目标仍可交付 | 按新范围重新配置 | 哪些需求移出？合同是否需变更？ |
| 延期 | 资源或依赖短期可恢复，节奏调整即可 | 资源基本不变，调整排期 | 新时间点是否可靠？里程碑如何重排？ |
决策输入与决策人
做出暂停决定前，项目负责人应准备四类信息：当前范围与里程碑完成情况、已发生成本与剩余预算、在途合同与采购义务、关键依赖的恢复预期。决策人通常是项目发起人或业务负责人，涉及合同金额、客户关系和人员编制时，需要财务、法务与客户方对接人共同确认。项目负责人负责提供判断依据和执行决定，不宜单独决定涉及合同义务的暂停。
暂停决定的记录要素
决定一旦形成，应当场留下书面记录，至少包含：暂停原因、生效日期、范围快照、资源处理方式、已发生成本口径、恢复条件、评审日期和决策人。这份记录是后续交接、复核和追责的共同依据，缺少任何一项，几个月后接手的人都难以还原当时的判断。
暂停执行步骤：从冻结范围到完成交接
暂停决定生效后，执行动作应按“先冻结、再清点、后交接”的顺序推进。每一步都要有明确输出和完成标志，避免出现“已经通知了但没人确认”的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 冻结范围 | 当前需求列表、变更记录 | 关闭变更入口，停止新增需求受理与排期 | 范围快照与冻结说明 | 变更入口已关闭，相关方已知悉不再受理新需求 |
| 2. 清点工作项 | 任务看板、迭代计划 | 按已完成、进行中、未开始分类，标注负责人与所处状态 | 工作项清点表 | 每项都有状态与责任人，无归属不明的任务 |
| 3. 处理合同与付款 | 合同台账、采购订单、付款计划 | 确认在途合同的中止或延续方式，核对已发生费用与待付款节点 | 合同与成本处理说明 | 财务与法务确认无遗漏的付款义务 |
| 4. 归档资料与环境 | 文档库、代码仓库、测试与生产环境、账号清单 | 整理文档目录，提交代码与配置，记录环境状态，回收或移交账号权限 | 归档清单与访问说明 | 接手人可按清单独立找到全部资料 |
| 5. 通知与确认 | 相关方名单 | 书面通知客户、供应商、内部协作团队，明确对接人与联系方式 | 通知记录与接收确认 | 关键相关方均书面确认收到 |
冻结范围时，容易遗漏的是口头需求和正在讨论中的变更。执行时应把最近一次评审通过的范围作为基线，把未决需求单独列出并标注“暂停期间不处理”，而不是直接删除，以便恢复时重新评估。清点工作项时，进行中的任务要写清停在哪一步、下一步动作是什么，这比只标一个“暂停”状态更有交接价值。
合同与付款是暂停执行中最容易被技术团队忽略的部分。外包、采购和订阅服务可能按月计费，暂停项目不等于自动停止付款。执行时应逐项确认哪些合同可以中止、哪些需要继续履行最低采购量、哪些存在违约风险，并把结论同步给财务。归档环节则要保证代码、配置、数据和账号的可恢复性，尤其是只有个别人掌握的部署脚本和第三方账号。
角色分工与暂停期间要交付的文档
暂停涉及决策、执行、保留和恢复准备四类工作，角色边界不清时最容易出现“决定做了但没人收尾”的情况。下表给出常见分工，实际组织中可由同一人兼任，但职责要写清楚。
| 角色 | 主要职责 | 关键产出 |
|---|---|---|
| 项目发起人/业务负责人 | 批准暂停决定，确认恢复条件与评审时点 | 暂停决定与恢复条件 |
| 项目负责人 | 组织冻结与清点，编写暂停记录，指定保留人员 | 暂停记录、工作项清点表 |
| 职能经理 | 安排人员释放与保留，处理绩效与排班衔接 | 人员安排表 |
| 财务/法务 | 核对合同义务、已发生成本与付款节点 | 成本与合同处理说明 |
| 客户方对接人 | 确认暂停范围、交付物接收方式与恢复沟通渠道 | 书面确认记录 |
暂停记录应包含的字段
- 暂停原因与决策依据
- 生效日期与预计复核日期
- 范围快照：已交付、进行中、未开始三类清单
- 资源状态：保留人员、释放人员、外部供应商状态
- 成本已发生额与待付款项
- 恢复条件与触发信号
- 资料归档位置与访问方式
- 决策人与各相关方确认记录
暂停期间仍需维持的事项通常包括：合同最低义务的履行、关键账号与环境的可用性、客户关系的定期沟通、以及恢复所需的前置准备。保留人员宜控制在能维持这些事项的最小范围，并明确其工作内容和汇报节奏，避免保留变成事实上的半停工。
这些记录和归档资料需要有稳定的存放位置。ONES Wiki 支持文档关联项目任务，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚；同时可为不同角色配置读写权限。把暂停记录、范围快照和归档说明放在与项目关联的文档空间中，恢复评审时接手人可以直接沿项目找到对应资料，减少因人员变动造成的信息断档。
示例：一个研发项目暂停三个月的处理过程
以下为演示情景，用于说明各环节的实际产出，不代表特定企业案例。
触发场景。某研发项目进入第二个迭代，客户方因内部预算审批延迟，通知暂停新增投入。项目已完成需求梳理和基础架构搭建，两个模块处于开发中，一个外包测试合同按月计费。项目负责人判断：客户预算周期为三个月，目标未变，属于可恢复的暂停，而非终止。
决策过程。项目负责人整理当前范围完成度、已发生人力成本、外包合同剩余付款节点和客户预算恢复的预期时间，提交项目发起人。发起人与客户方对接人确认暂停期限与恢复条件后，签署暂停决定，约定三个月后首个工作日进行恢复评审，触发信号为客户预算批复文件。
冻结与交接。项目关闭需求变更入口，把两个开发中模块的任务标注为暂停并写明停点；外包合同与供应商协商中止后续排期，已完成的测试报告归档；代码提交至主仓库并打标签，测试环境保留但停止定时任务；客户方账号权限回收，内部账号按最小范围保留。全部资料整理进与项目关联的文档页面，暂停记录中列明归档位置。
暂停期间的成本与人员处理。开发人员释放回职能团队，保留一名技术负责人每周投入少量时间维护环境与对接客户；外包费用按已完成工作量结算，后续不再计费；已发生成本与待付款项由财务确认后写入暂停记录。
恢复评审。三个月后评审时，客户预算已批复，但需求方向有调整。评审结论为恢复项目并缩减原范围中的一个模块，重新排期。技术负责人依据暂停记录和归档资料，在一周内完成环境恢复和任务重新分派。
恢复、转终止与完成检查
暂停项目最常见的风险是长期悬置：没有人再提起，资源名义上保留，成本持续发生，恢复时发现资料缺失或人员已离职。避免这种情况的关键是把出口写进暂停决定，并设置定期复核。
恢复条件与评审时点的设置
恢复条件应写成可验证的信号，例如“客户预算批复文件下达”“上游接口通过验收”“关键岗位人员到岗”，而不是“情况好转”这类无法判断的表述。评审时点可以设为固定日期，也可以设为触发信号出现后的若干工作日内，两者结合更稳妥：固定日期保证定期回看，触发信号保证不错过恢复窗口。
转为终止时的收尾动作
评审结论为终止时，需要完成：通知全部相关方并取得确认、结算合同与付款、移交或销毁交付物与数据、释放保留人员、关闭项目账号与环境、归档最终记录。终止不是暂停的简单延长，已发生的成本口径和合同义务要在关闭前结清。
暂停状态的定期复核机制
建议在暂停记录中指定复核责任人和复核频率，例如每月由项目负责人核对一次恢复条件是否出现，每季度由发起人做一次去留判断。复核结果要写入记录，即使结论是“继续暂停”，也留下判断痕迹。复核内容至少包括：恢复条件进展、保留人员工作是否仍有必要、成本是否仍在发生。
暂停项目完成检查清单
- 暂停决定有书面记录，决策人明确
- 范围快照完整，变更入口已关闭
- 工作项均有状态与责任人，进行中任务写明停点
- 在途合同、采购与付款节点已核对并处理
- 文档、代码、环境与账号已归档，接手人可独立访问
- 相关方已书面确认，对接人明确
- 已发生成本与待付款项口径清晰
- 恢复条件可验证，评审日期与复核责任人已确定
- 保留人员的工作内容与汇报节奏已安排
这份清单可以在暂停执行结束时逐项核对，也可以作为定期复核的检查依据。清单全部通过，项目才算完成从推进到暂停的转换，后续的恢复或终止才有可靠的基础。
常见问题
项目暂停期间，外包和订阅类合同会自动停止计费吗？
通常不会。外包、采购和订阅服务可能按月计费或设有最低采购量，暂停项目并不自动中止付款义务。执行暂停时应逐项核对合同：哪些可以协商中止、哪些需要继续履行最低义务、哪些存在违约风险，并把结论同步给财务，写入暂停记录的成本部分。合同条款的具体处理方式以合同约定和法务意见为准。
暂停决定由项目负责人单独做出可以吗？
涉及合同义务、客户关系和人员编制的暂停，不宜由项目负责人单独决定。项目负责人负责准备判断依据并执行决定，批准通常由项目发起人或业务负责人做出；涉及金额、合同和人员安排时，需要财务、法务与客户方对接人共同确认。把决策人和各方的确认记录写进暂停记录，后续复核时才有依据。
暂停期满后恢复条件仍未出现，应该怎么处理？
在评审时点重新做一次去留判断，而不是默认继续暂停。可以比较三种走向：恢复推进、继续暂停并更新评审日期、转为终止。继续暂停需要说明保留人员和成本是否仍有必要，并重新设定复核时点；如果恢复条件长期无法验证或恢复成本已超过重新立项，转为终止更合适。无论哪种结论，都要写入记录，留下判断痕迹。
暂停期间保留人员的工作怎么安排才不至于变成半停工？
保留人员宜控制在能维持必要事项的最小范围，并把工作内容写具体，例如合同最低义务的履行、关键环境与账号的可用性维护、客户定期沟通、恢复所需的前置准备。同时明确汇报节奏和投入比例，让保留有实际产出可检查。人员释放与保留的安排由职能经理落实，并与绩效和排班衔接。
暂停记录和归档资料放在哪里，才能保证几个月后接手人找得到？
关键是让资料与项目保持关联，而不是散落在个人电脑或聊天记录里。可以把暂停记录、范围快照和归档说明放在与项目关联的文档空间中，并在记录里写明归档位置和访问方式。ONES Wiki 支持文档关联项目任务，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚；同时可为不同角色配置读写权限。这样恢复评审时，接手人可以直接沿项目找到对应资料。
