暂停管理指南：项目成员如何做好任务执行，实操方法全流程

引言

项目暂停落到一个执行者头上时，往往只有一句话的通知，却意味着接下来两周到两个月的所有动作都要重新设计。我做过七年交付和研发项目，经历过至少十一次不同类型的暂停：客户预算冻结、合规审查、组织架构调整、关键人离职、上游供应商断供，还有一次是全公司范围的数据安全排查。

这些暂停里真正让团队付出代价的，从来不是"停"这个动作本身，而是暂停期间任务上下文丢失、责任边界模糊、恢复时大面积返工。我见过一个做了四个月的定制开发项目，暂停六周后重启，光是核对"哪些改动已经提交、哪些还在本地、哪些客户口头答应过"就花了十一个人天。

所以这篇指南不站在项目经理或 PMO 的视角谈"如何管理暂停"，而是站在项目成员的视角，回答一个更具体的问题：当暂停指令落到你头上，从接到通知到恢复交付，你具体该做哪些动作、按什么顺序做、做到什么程度算合格。

一、核心结论：暂停是状态切换，不是任务终止

先说结论。暂停管理的本质，是把任务从"推进态"切换到"可恢复态"。这两个状态的差别不在于做不做，而在于任务是否还能被别人读懂、被自己接续、被组织追责。

一个任务在推进态时，上下文大量存在于人的脑子里：我记得这个接口为什么要这么写、我记得客户当时说"先这样吧"、我记得这个字段是临时加的。暂停期一旦超过两周，这些脑子里的上下文会衰减到不足以支撑恢复。项目成员唯一能对抗衰减的手段，就是在暂停生效的那一刻把上下文外化成别人能读的形态。

1. 项目成员在暂停期的四个目标

目标要少，否则执行时会失焦。我一般只要求自己盯住四件事，按优先级排序：

• 不失控：暂停期间任务的真实状态是可查的，不依赖任何一个人的记忆。
• 不返工：恢复后不需要重新做已经做过的事，也不需要推翻已经确认过的结论。
• 不背锅：哪些动作是暂停期内我做的、哪些是别人做的、哪些是被禁止做的，有记录可查。
• 不空转：暂停期我的时间没有被浪费，但也没有因为"想干活"而产生新的对外承诺。

这四条里，最容易被忽略的是"不背锅"。很多人以为暂停期不做事就安全，实际上恰恰相反：暂停期你如果私下推动了某个改动，恢复后出了问题，责任归属会变得极其难说清。

2. 暂停管理有四层粒度，别混为一谈

"项目暂停了"这句话本身是模糊的。我在实际项目里会把它拆成四层，因为每一层的决策权、成员可做的动作、禁止动作都完全不同。

把这四层分清楚，能解决暂停期最多的一类冲突：上层说"项目停了"，而你还在一层一层地问"那我手上这个能不能继续"。答案不在"项目停了"这句话里，而在你手上这个任务的粒度归属里。

3. 一句话主线

如果整篇只记住一句话，就记这句：项目成员做暂停管理，不是等通知、不是瞎忙，而是先确认边界，再冻结上下文，暂停中低耗维护，恢复时按清单重启，让任务始终处于可恢复、可交付、可追溯的状态。

接下来的所有内容，都是这句话的展开。

二、背景与真实场景：暂停为什么总变成一团乱麻

暂停之所以难，不是因为它复杂，而是因为它发生的时刻通常没人负责。项目正常推进时有明确的角色分工，一旦暂停，原来的分工链条会瞬间失效，变成所有人都等别人先动。

1. 我踩过的三次坑

（1）坑一：只停了会议，没停承诺

有一次客户项目暂停，团队停止了所有例会，大家默认"停就是全停"。结果我的一位同事在暂停前已经口头答应客户"下周给一版原型"，暂停通知下来后他没说，客户也没问，三周后客户重启项目时第一句话就是"原型呢"。这个坑的根源是：会议是内部动作，承诺是外部动作，停掉前者不会自动停掉后者。

（2）坑二：只停了代码，没停数据

另一个项目暂停期间，一位开发为了让环境"保持可演示"，继续往测试库里手工改数据。两个月后项目恢复，测试同学按用例跑回归，发现十几条缺陷全是脏数据造成的假阳性，排查花了整整两天。没有记录的手工改动，等价于给未来埋雷。

（3）坑三：只停了进度，没停工时口径

第三次更隐蔽。项目暂停了，但团队的工时系统还在按原口径要求填报，成员只能凭印象填。三个月后做成本复盘，发现暂停期的工时数据完全不可用，导致这根成本线在整个项目核算里成了黑箱。暂停如果没有同步改变度量口径，数据就会自动变成噪声。

2. 暂停的六类触发源，处理方式完全不同

我统计过自己经手的十一次暂停，触发源大致分六类。分类的意义在于：不同触发源决定了暂停的预期时长和恢复的不确定性，你要准备的深度完全不同。

从这张图能看出一个反常识的结论：短暂停往往比长暂停更危险。因为短暂停时大家心理上认为"很快就好"，所以懒得写暂停卡、懒得同步依赖方；而长暂停反而会触发正式流程。我遇到过的返工最严重的一次，恰恰是只停了九天的需求确认暂停。

3. 为什么"成员视角"的暂停管理长期缺位

我翻过不少团队的项目管理制度，涉及暂停的部分通常只有两句话：一句是"暂停需经发起人审批"，另一句是"暂停期间工作另行安排"。这两句话都是给管理者用的，对执行者没有可操作性。

缺位的原因很现实：管理制度是为决策者写的，而暂停期真正的风险发生在执行层。决策者关心的是"要不要停"，执行者关心的是"停了之后我手上这些东西怎么处理"。这两个问题的答案不在同一份文档里。

所以我建议每个项目成员自己准备一套动作清单。它不需要审批，不需要工具，一张纸就能写完，但它决定了暂停的代价由谁承担。

三、拆解五个常见误区

下面这五个误区我都亲眼见过，其中三个我自己踩过。它们的共同特征是：在暂停发生的那一刻看起来很合理，在恢复的那一刻全部变成成本。

1. 误区一：把暂停当放假

现象是暂停通知一下来，成员立刻进入低功耗模式，不回消息、不看工单、不理会上下游。表面看没有损失，实际上损失在恢复时才出现：恢复那天你需要重新建立全部上下文，而重建成本通常高于维护成本的三到五倍。

正确做法是区分"停止推进"和"停止关注"。推进可以停，关注不能停：每周花十五分钟扫一遍自己的任务列表和依赖方动态，成本极低，但能让恢复时间从三天压缩到半天。

2. 误区二：私下继续推进

这是我最想强调的一条。很多技术同学觉得"反正闲着，我把这个功能写完"，看似是主动性，实际上制造了三个问题：第一，改动没有经过评审，恢复后可能直接推翻；第二，暂停期内的工作量不在任何计划里，工时和绩效口径对不上；第三，一旦这个改动引入了缺陷，责任归属会变得极其难界定。

判断标准很简单：如果这个改动会影响对外交付内容、会产生新承诺、会改动共享资源（代码主干、测试环境、生产数据、文档权限），那它就不属于"可以自己决定"的范围。

3. 误区三：只口头同步

暂停期的沟通有一种特殊惯性：因为事情不多，大家倾向于用口头或即时消息说一句就完事。"我跟 PM 说过了""我在群里发过"，这类表述在暂停期特别常见，也特别危险。

原因在于暂停期的信息衰减速度极快。暂停两周，参与者的记忆准确率会掉到不足以支撑决策的水平。凡是涉及范围、时间、责任人、恢复条件的结论，都必须留成可检索的文字，哪怕只有三行。

4. 误区四：恢复时直接开工不校验

暂停结束的信号通常很模糊："可以继续了"。很多人听到这句话就立刻切换到推进态，直接接着上次的进度往下做。问题在于，暂停期间世界变了：上游接口可能改了版本、需求可能被重新解读、优先级可能已经被别的项目占用。

正确顺序是：先校验，再排序，最后执行。校验的是版本、数据、接口、文档和承诺五件事，缺一件都可能让你白做。

5. 误区五：把暂停卡写成流水账

另一种极端是写得太细。我见过有人暂停期写了三千字的交接文档，把每个函数都解释一遍，结果恢复时没人看完，关键结论反而被淹没。

暂停卡的正确长度是一页以内，字段固定，用来看而不是用来读。它回答的是"现在到哪了、卡在哪、谁能接、什么条件下能继续"，不是"我这两个月都干了什么"。

四、专业判断逻辑：可恢复性是唯一验收标准

暂停期做得好不好，不需要复杂的评估。我只有一个验收标准：假设明天换一个人接手、或者三个月后我自己回来，能不能在半天内说清这个任务的真实状态并继续推进。能，就是合格；不能，暂停管理就是失败的，不管你在暂停期做了多少事。

1. 三个判断维度

把可恢复性拆开，实际是三个维度在支撑。我通常用它们来给自己的暂停动作做体检：

• 边界清晰度：暂停范围、暂停时长、恢复条件、责任人是否都有明确结论，且能被第三方读懂。
• 上下文完整度：任务当前进度、未完成项、关键决策及理由、依赖方状态是否都已外化成文字。
• 责任可追溯性：暂停期发生的每一次变更、每一次沟通结论、每一次例外授权，是否都有记录人和时间点。

这三个维度里，最容易做不完整的是第二个。因为决策和进度是显性的，而"为什么这么决定"是隐性的，往往只存在于讨论现场。

2. 任务四分类：不是所有任务都该停

"项目暂停"不等于"所有动作归零"。我在暂停期会把手上任务分成四类，分类依据是是否影响正式交付、是否产生对外承诺、是否消耗关键共享资源。

这里有一个必须提前说清的边界："可预研"这一类的判定权不能只在成员自己手里。我的做法是，把预研清单一次性报给项目经理确认，确认之后再动手，避免恢复时被质疑"暂停期你为什么要做这个"。

3. 暂停期"允许推进"的三道门槛

判断一个任务能不能在暂停期继续，我用三道门槛，必须同时满足：

1. 不影响正式交付：即使这个成果被完全丢弃，也不会拖慢恢复后的交付节奏。
2. 不产生对外承诺：不会让客户、合作方或上下游产生任何新的时间或功能预期。
3. 不消耗关键共享资源：不占用主干分支、不占用测试环境、不改动生产数据、不影响其他人正在使用的东西。

三道门槛有一道不满足，就归入"必须停"。这个规则的粗暴之处正是它的价值：在暂停期，判断成本越低越好，因为没有人有精力做复杂的权衡。

4. 暂停时长与上下文衰减

很多人问"暂停多久才需要正式写暂停卡"。我的经验是不要按时间设阈值，因为衰减速度取决于任务复杂度而不是天数。但有一个粗略的参考关系值得知道：

这张图解释了一个常见困惑：为什么有些暂停明明只有一周，恢复起来却像重新开始。原因不是时间长，而是任务的复杂度高，记忆的衰减曲线更陡。

5. 恢复就绪度：一个可以直接打分的自评表

我在恢复前会给自己打一次分，五项各 20 分，低于 60 分就不开工，先去补齐。

• 任务状态字段完整（进度、未完成项、阻塞原因），20 分
• 关键决策及理由有记录，20 分
• 依赖方状态与联系方式明确，20 分
• 恢复条件有书面确认，20 分
• 版本与数据基线可复现，20 分

这个自评表的价值不在于分数本身，而在于它把"我准备好了吗"这个模糊问题变成了五个可验证的检查点。

五、真实案例与数据观察：把上下文保全做成机制

前面讲的是方法，这一段讲一个具体案例，说明当暂停管理从"个人自觉"变成"机制保障"时，差距有多大。

1. 案例背景

我参与过的一家研发组织大约 300 人，做的是面向中大型企业的私有化交付产品，同时并行推进十几个客户项目。2024 年他们遇到一次典型的批量暂停：两个主要客户的预算审批延后，涉及三个项目、约 40 人，暂停周期从三周拉长到九周。

第一次暂停（三周）时他们没有做任何冻结动作，恢复后光是理清"哪些需求已确认、哪些缺陷已修复、哪些测试用例已执行"就花了约 60 人时。第二次暂停（六周）之前，他们把暂停期动作固化成了流程，恢复时的对齐成本降到了约 12 人时。

2. 冻结链：需求，任务，缺陷，测试用例要一起冻

这个案例最有价值的发现是：暂停时只冻任务是不够的，必须沿着工作项的关联关系整条链一起冻。他们后来的做法是四层同时处理：

1. 需求层：标记需求状态为暂停，同时冻结验收标准版本，避免恢复时口径漂移。
2. 任务层：每个任务填写阻塞原因字段，明确是"外部暂停"而不是"无人认领"。
3. 缺陷层：区分暂停前已修复待验证、暂停中暂停修复、暂停前未处理三类，避免恢复时误判缺陷量。
4. 测试用例层：记录已执行到的用例编号，恢复后从这个编号继续，而不是全量重跑。

这四层里，最容易被忽略的是测试用例层。但实测下来，它恰恰是恢复时最省时间的一层，因为回归测试通常是恢复后第一个大块动作，有断点记录就能省掉一半工作量。

3. 工具能力带来的差异：以 PingCode 为例

这个团队在第二次暂停前，把工作项管理迁到了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，在暂停管理这类场景里，它的几个特性直接决定了执行成本。

第一是私有化部署。这个团队做的是私有化交付产品，客户对数据驻留有硬要求。暂停期间涉及客户环境的数据基线留档，必须留在自己的环境里，私有化部署让"冻结现场"这件事可以直接在内部系统完成，不需要绕道外部工具。

第二是Jira 平滑迁移。他们原本用的是 Jira，历史项目里有大量工作项和状态配置。迁移过程中，原有的任务层级、状态流转和字段映射都保留了下来，这意味着暂停期新增的"阻塞原因""暂停确认人""恢复条件"这类字段，可以直接挂到既有工作项上，而不是另建一套台账。对中大型组织来说，这一点很关键：暂停管理最怕的就是"正文在系统里、暂停信息在表格里"，两套数据一旦分叉，恢复时必然对不上。

第三是需求，任务，缺陷，测试用例的关联链。前面说的四层冻结，如果依赖人工维护关联关系，暂停一次就要重做一遍。放在有原生关联的工作项体系里，冻结动作就变成了对一条已有链路做状态标记。

4. 数据观察

下面这组数据来自这次批量暂停的复盘，属于团队内部统计口径，我把它整理出来用于说明差异量级。

5. 从这次案例里我提炼出的三条判断

第一，暂停成本的大头不在暂停期间，而在恢复前两周。如果只能做一个动作，就做冻结，其他都可以省。

第二，冻结的收益随暂停时长非线性增长。暂停三周时，有冻结和没冻结的差距大约是 30 人时；暂停九周时，差距拉大到 60 人时以上。

第三，暂停信息必须和正文信息在同一个系统里。只要出现"正文在工具里、暂停台账在表格里"的分叉，恢复时的一致性成本就会重新出现。

六、不同情况下的行动建议

下面按五种最常见场景给出动作清单。每条建议我都标注了"最小动作"，也就是时间紧张时至少要完成的那一件。

1. 场景一：项目级暂停，你只是执行成员

这种情况你的决策权最小，但记录责任最大。建议按顺序做四件事：

1. 确认边界：向项目经理确认四件事，暂停范围、预计时长、恢复条件、恢复决策人。不要接受"等通知"这种模糊答复，至少要拿到"如果 X 发生就算恢复"。
2. 冻结现场：把当前版本的代码分支、文档版本、测试数据基线做好标记。最小动作是给当前分支打一个带日期和暂停标记的 tag。
3. 写暂停卡：一页以内，字段固定，重点是未完成项和阻塞原因。
4. 同步依赖方：主动告知你可能影响的上下游，尤其是你以为"对方知道"的那些人。

这里要特别提醒：不要替项目经理向客户做任何解释。暂停期对外沟通的口径必须统一，成员擅自解释会直接制造承诺风险。

2. 场景二：任务级暂停，上游依赖没就绪

这种暂停通常最短，也最容易被轻忽。我的建议是：

• 把阻塞原因写清楚，写到"下一次看到这句话就知道当时卡在哪"的程度。
• 把任务拆成"依赖外部"和"不依赖外部"两部分，后者可以有限推进，但需报备。
• 给依赖方设定一个主动询问的时间点，比如每周固定一天确认一次，而不是被动等消息。

最小动作是第一条。因为依赖型暂停最容易出现"责任漂移"，时间一长，没人记得最初是谁在等谁。

3. 场景三：你个人被临时抽调或休假

这种暂停和项目无关，但对上下文完整度的要求反而最高，因为接手的人不是你。建议：

1. 写一份交接清单，按"正在做的、卡住的、待确认的、别碰的"四类组织。
2. 明确临时联系人和他们能决定什么、不能决定什么。
3. 把共享资源（权限、环境、密钥、文档）的归属明确移交，不要保留"之后再处理"的模糊地带。

这里有个容易被忽略的点：要明确写出"哪些事不要动"。很多返工不是因为接手的人做错了，而是因为没人告诉他什么不该做。

4. 场景四：客户预算冻结，长期停摆

这类暂停通常在 45 天以上，风险从"返工"转为"人流失"。行动重点要换：

• 按周而非按天维护，成本控制在每人每周 15 分钟以内。
• 建立知识留档，把核心设计决策和技术选型理由写下来，防止关键人离开后无法追溯。
• 每两周做一次依赖方状态扫描，因为长期停摆期外部变化最大。
• 工时与绩效口径要提前书面确认，避免停摆结束后出现核算争议。

最小动作是第三条。长期停摆最怕的是恢复时发现上游已经变了而你完全不知道。

5. 场景五：恢复启动

这一步最容易被"直接开工"取代，所以我把恢复动作单独列成清单，建议按顺序执行：

1. 确认恢复指令：谁宣布的、范围是否完整、是否有新增约束。
2. 校验五件事：版本、数据、接口、文档、对外承诺。
3. 重排优先级：暂停期的变化可能让部分任务失去意义，先删再加。
4. 校准里程碑：不要沿用暂停前的排期，宁可重新估一次。
5. 做一次返工检查：重点查版本冲突、数据一致性、文档与实现是否脱节。
6. 复盘：把这次暂停暴露的脆弱点写下来，作为下一次的输入。

这六步做完大概需要半天到一天，但它通常能省掉两到三天的返工。从投入产出比看，这是整篇指南里最划算的一段动作。

七、不同情况下的取舍

暂停管理里没有"全都做到最好"的选项，每一条动作都有成本。下面五组取舍是我在实际项目里反复做过的判断。

1. 冻结粒度 vs 维护成本

冻得越细，恢复越准，但记录成本越高。我的经验是冻到"任务级"就够了，不要再往下拆到字段级或函数级。

举个具体例子：一个包含 20 个任务模块的需求，如果每个模块都写暂停说明，成本大约 3 小时；如果只在任务级别写，成本不到 1 小时，而恢复时的精度损失通常不超过半天。冻到任务级，是投入产出比最高的一档。

2. 同步频率 vs 信息过载

暂停期同步太频繁会制造噪音，太少会让信息断层。我倾向于按"是否有状态变化"来决定是否同步，而不是按固定周期。

具体做法：没有变化就不发消息；有变化就发一条包含"现状，影响，待确认，建议，下次同步"五段式的短消息。这样同步次数可能一周只有一次，但每一条都有信息量。暂停期最浪费的沟通是"本周无进展"。

3. 低耗维护 vs 完全停手

完全停手最省事，但恢复成本最高。我的判断依据是暂停预期时长：两周以内可以接近完全停手，只做记录；两周以上建议保持每周一次的低耗维护。

低耗维护的具体内容是：扫一遍我负责的工作项状态、看一遍依赖方有没有变化、确认恢复条件有没有更新。三件事加起来不超过十五分钟，但它把恢复的启动成本压到了最低。

4. 工具化 vs 手工台账

小规模、短周期的暂停，一张表格完全够用，不需要为了暂停管理专门上工具。但如果同时存在多个暂停项目、涉及跨团队依赖，手工台账会很快失效。

失效的临界点通常出现在两个地方：一是依赖方信息需要跨项目查询时；二是暂停信息与任务正文开始分叉时。一旦出现这两点，就应该把暂停状态字段放进工作项体系里，而不是继续维护外部表格。

这也是我在上一个案例里强调工作项关联链的原因。对中大型组织来说，把暂停状态作为工作项的原生字段，比新增一套暂停台账更可持续。PingCode 这类主要服务中大型企业和 100 人以上组织的平台，支持私有化部署和从 Jira 平滑迁移，本质上解决的就是"暂停信息必须和正文同源"这个问题。国产替代的语境下，迁移成本是否可控，往往比功能清单更影响选型决策。

5. 短期交付 vs 长期可恢复性

这是最根本的一组取舍。暂停期花时间写暂停卡，短期看是减少了产出；但它换来的是恢复时的确定性。我的判断是：暂停超过两周时，可恢复性的优先级应该高于任何短期的推进产出。

因为暂停期的"推进产出"有很高概率被推翻，而上下文一旦丢失，是很难补回来的，补不回来的不是内容，是当时的判断理由。

八、可直接使用的模板：一页纸暂停管理台账

下面是我自己在用的模板，字段精简到能在一页内填完。它的设计原则是：每个字段都对应一个恢复时的具体决策，不填就没法做恢复判断。

1. 暂停卡字段

字段一共十二个，建议固定不动，避免每次暂停都要重新设计格式。

pause_card:
task_id: PRJ-1284 # 工作项编号，必须可追溯到系统

task_name: 客户对账模块接口联调

pause_level: 任务级 # 项目级 / 任务级 / 依赖级 / 个人级

pause_reason: 上游结算系统接口版本待确认

pause_start: 2026-03-04

expected_duration: 2周（不确定，取决于上游）

current_progress: 接口联调完成70%，异常分支未覆盖

unfinished_items:

对账差异处理逻辑未联调

异常码映射表未确认

blocker: 上游接口v2.3文档未发布

restore_condition: 上游发布v2.3文档并通过连通性测试

dependencies:

团队: 结算平台组 联系人: 张工 状态: 等待上游

团队: 客户交付组 联系人: 李工 状态: 已知悉暂停

forbidden_actions:

不修改主干分支

不向客户承诺联调时间

next_sync: 2026-03-11

owner: 我 / 备份人: 王工

这张卡里我认为最关键的两个字段是 restore_condition 和 forbidden_actions。

前者把"等通知"变成可判断的条件，后者把"不背锅"变成可执行的约束。缺少这两个字段的暂停卡，恢复时依然需要重新开会确认。

2. 看板状态设计

暂停不能只做标记，要成为看板上的独立状态，否则在视图中会和普通任务混在一起。我的建议是三个状态：

• 暂停-待恢复：已冻结，恢复条件未满足。
• 暂停-可维护：允许低耗维护，需每周更新一次状态。
• 恢复中：恢复条件已满足，正在做校验和重排优先级。

这三个状态的价值在于：让"暂停中"的任务在统计口径里是可见的，而不是消失在"进行中"里。我见过太多项目，暂停任务被留在进行中状态，导致进度报表长期失真。

3. 恢复检查表

恢复当天按顺序勾选，任何一项不通过就不要进入开发。

4. 沟通模板

暂停期同步用五段式，控制在两百字以内。我给的示例是任务级暂停的同步：

【现状】对账模块接口联调暂停，整体完成70%，异常分支未覆盖。
【影响】恢复后预计需额外2天覆盖异常分支，不影响其他模块。

【待确认】上游v2.3接口文档发布时间是否已确定。

【建议】暂停期保持每周一次状态同步，不做主干改动。

【下次同步】2026-03-11，如无变化将不再单独发消息。

这个模板的关键是最后一句。明确写出"无变化不打扰"的规则，能显著降低暂停期的沟通噪音，也不会让人觉得你不主动。

九、结语：成为让项目"可恢复"的人

写到这里，我想把整篇的核心观点再收一次。暂停管理的价值不在于暂停期间做了多少事，而在于你让任务变得多"可恢复"。一个可恢复的任务，具备三个特征：状态可读、上下文可查、责任可追溯。做到这三件事，你在暂停期什么都不做也是合格的；做不到，你在暂停期做再多也只是把风险往后推。

我也想说一个可能不太常见的判断：在暂停期保持克制，比在暂停期保持忙碌更难，也更有价值。很多人用"我在推进"来对抗暂停带来的不确定感，但这种推进往往既没经过授权，也没留下记录，最后变成恢复时的负债。

下一步你可以做三件事，按投入从低到高排列：

1. 把本文第八节的暂停卡字段复制到你自己的笔记里，下次接到暂停通知时直接用，不用现设计格式。
2. 把五项恢复就绪度自评表放到团队里讨论一次，确认哪些字段是你们团队真正需要的，删掉多余的。
3. 在下一次项目复盘时，把"暂停期上下文保全"作为固定议题，看看恢复工时里有多少是可避免的。

最后一句。项目暂停不会越来越少，组织越复杂、外部依赖越多，暂停就会越频繁。但每一次暂停都在筛选一件事：谁能把自己手上的工作维持在别人能接、自己也能接的状态。这样的人在项目恢复时不需要重新开始，因为他们的工作从来就没有真正中断过。