暂停管理指南：研发团队如何做好任务执行，风险控制全流程

去年第三季度，我受邀去一家 320 人的 B 端 SaaS 公司做发布流程复盘。研发负责人在会议室白板上写了一行数字：412。这是他们需求管理系统里当时挂在"暂停"状态的工作项总数，平均搁置 76 天，最久的一条挂了 517 天，标题是"重构计费网关的重试策略"。

真正让在场所有人沉默的不是 412 这个数字，而是接下来那句话，没人能说清这里面有多少还应该做、多少已经作废、多少恢复时要推翻重来。那次复盘后，我们花了六周做一件事：把"暂停"从一个垃圾桶式的兜底状态，改造成一套有输入条件、有责任归属、有复核节奏、有退出判据的管理流程。

这篇文章讲的就是这件事。我不打算写成又一份"状态机最佳实践"，因为暂停管理的难点从来不在工具配置，而在于团队对"停下来的任务"这件事的认知偏差。暂停不是任务的中断，而是一笔需要计息的负债。下面我把核心结论、真实场景、常见误区、判断逻辑、实际数据和不同规模团队的取舍完整讲一遍。

一、核心结论：暂停是负债，不是垃圾桶

先把判断放在最前面。研发团队交付失控的根源，通常不是任务做不完，而是暂停的任务只被记账、没有被计息。一个暂停的任务同时占用两种稀缺资源：一种是"我已经对业务方做出的交付预期"，另一种是"未来恢复它所需的上下文重建成本"。前者是负债本金，后者是利息。

只登记状态、不管理利息，负债就会在某个发布节点集中到期。这时候团队看到的表象是"最后冲刺阶段总有莫名其妙的延期"，真实原因却是三个月前随手暂停的那批任务同时复活了。

1. 暂停是一个显式状态，必须带四个要素

我在所有推行成功的团队里都坚持同一条规则：一个任务要进入暂停状态，必须同时填满四个字段，缺一个就不允许流转。

• 暂停原因：不是"暂时不做"这种废话，而是可归类的枚举值，比如"等待外部接口联调""优先级让路给线上故障""技术方案未经压测验证"。
• 恢复条件：一个可被客观判断真假的命题。"三方支付网关给出沙箱环境"是可判断的，"等业务方想清楚"不是。
• 责任人：暂停期间仍然有 owner，负责盯恢复条件，而不是"暂停了就不关我事"。
• 复核日期：一个具体的日期，到期必须有人做一次"继续暂停还是关闭"的决策。

这四个要素里，最容易被跳过的是"恢复条件"。它难写，但它的价值最高，因为它把暂停从情绪化决定变成了可验证的等待。

2. 暂停管理真正管的是恢复成本

很多团队把暂停管理的目标定为"减少暂停数量"，我认为方向错了。有些暂停是健康的：一个需求等外部合规审批，硬做只会返工；一个技术方案等压测数据，先写代码就是浪费。

真正要管理的是恢复成本随搁置时间的增长速度。一个搁置 3 天的任务，恢复时只需要看一眼代码和当天的讨论记录；搁置 90 天的任务，恢复时你面对的是一个已经改过三轮的代码库、一批离职或转岗的协作者、以及一份没人记得为什么这么写的技术方案。

3. 暂停总量需要预算，就像在制品上限一样

既然任务是负债，那就应该有授信额度。我的建议是给每个研发团队设一个"暂停预算"：同时处于暂停状态的工作项不超过该团队当前迭代容量的 20%。超出时，团队必须先关闭或升级一批暂停任务，才能新增暂停。

这个数字不是拍脑袋来的。在我参与过的团队里，暂停占比低于 15% 时，暂停基本是真实的客观阻塞；超过 25% 之后，暂停就开始变成"我们不想做但不好意思拒绝"的委婉表达。

4. 暂停必须分类，不同类别走完全不同的流程

把所有暂停塞进一个状态，是失败的开始。至少拆成三类：等待型暂停（外部依赖未就绪，恢复条件在别人手里）、让路型暂停（资源被更高优先级抢占，恢复条件在自己手里）、验证型暂停（方案不确定性高，需要先做验证再决定是否继续）。

三类的最大差异在于谁是瓶颈：等待型要盯外部、让路型要盯排期、验证型要盯时间盒。用同一套流程管这三类，等于用同一把钥匙开三种锁。

二、暂停为什么在研发团队里最容易失控

需求、缺陷、任务这三种工作项里，任务是最容易在暂停状态里腐烂的。原因很直接：需求有业务方追着问，缺陷有线上表现压着改，而任务只有研发团队自己知道。

没有外部压力，就没有自然回流。团队会不自觉地用"暂停"作为缓解排期焦虑的手段，把它从视野里挪走，焦虑感立刻下降，代价被推迟到未来某个不确定的时间点支付。

1. 三类暂停的来源完全不同

第一类是外部依赖型。等第三方接口、等安全评审、等硬件到货、等合规口径。这类暂停的特点是恢复条件不由团队控制，所以最容易变成无限期等待，团队会逐渐忘记自己还在等什么。

第二类是优先级让路型。线上出了 P0 故障，两个人被抽走三天；季度目标调整，中优先级需求整体后移。这类暂停的特点是恢复条件其实掌握在自己手里，但没人主动把它捡回来。

第三类是方案不确定型。技术选型没定、性能瓶颈没定位、数据迁移方案没验证。这类暂停最危险，因为它的上下文衰减最快，三天前讨论的技术权衡，一周后就会变成"这个方案为什么被否了"。

2. 暂停是如何在一个迭代里悄悄累积的

我观察过一个团队的迭代日志。两周迭代，第一天在途暂停 6 个，第三天变成 9 个，第七天变成 14 个，迭代结束时是 21 个。整个过程没有任何一次"我们要暂停一批任务"的决策，全是单点行为：某人在早会上说"这个先放一放"，然后拖到看板最下面。

这就是失控的本质：暂停是分布式决策，但后果是集中式爆发。每个人做的每一次暂停看起来都合理，叠加起来就超过了团队的处理能力，而且没有任何一个环节会报警。

3. 一条被忽略的曲线：恢复成本随搁置时间非线性上升

我们在一家 320 人的研发组织里做过一个小规模实验：随机抽取 40 个从暂停状态恢复的工作项，记录搁置天数和实际恢复耗时，同时对照"假设当初一次做完"的估算工时。

结果是，搁置 14 天以内的任务，恢复平均耗时 0.8 人时；15 到 45 天之间是 2.6 人时；46 到 90 天是 5.9 人时；超过 90 天是 11.4 人时。换算下来，超过 90 天恢复一个任务的平均开销，等于重新做一遍的四成左右。

这条曲线的形状比绝对值更重要：恢复成本不是线性增长，而是在 30 天左右开始加速。这意味着暂停管理的复核周期如果超过一个月，实际上已经放弃了成本控制。

三、拆解六个常见误区

暂停管理做不好，几乎都不是工具问题。我复盘过十几个失败案例，问题反复出现在同样的六个认知偏差上，而且每一个都听起来很有道理。

1. 误区一：暂停等于优先级调低

这是最普遍的误解。优先级调低意味着任务仍在队列里排队，它会参与排期、占用容量估算、出现在看板上。暂停是完全不同的一件事，它意味着任务退出了队列，不再占用容量，但欠下的交付承诺依然存在。

把两者混同的后果是，团队的容量估算永远偏乐观。因为排期时只统计了"进行中"的任务，暂停任务被视为不存在，等到它们复活时，计划就被彻底打乱了。

2. 误区二：暂停不需要写原因

我见过一个团队，暂停状态的必填字段只有一个"备注"，实际情况是 78% 的备注为空，剩下 22% 写的是"先这样""等通知""后面再说"。六个月后复盘时，没有人能解释这些任务为什么停下来。

更隐蔽的代价是：没有原因的暂停，等于把决策责任从系统转移到了个人记忆里。而个人记忆恰恰是研发团队最不可靠的存储介质，一次转岗、一次离职，这些任务的上下文就永久丢失了。

3. 误区三：暂停任务暂时没有负责人

暂停任务的 owner 和进行中任务的 owner 承担的责任不同。进行中的 owner 负责推进，暂停的 owner 负责盯条件、定期复核、在条件满足时把任务拉回来。

"暂时没有负责人"在实践中等于"永久没有负责人"。我建议的做法是：暂停任务必须保留原 owner，如果原 owner 离开项目，必须在流转时指定新的接管人。这条规则看起来死板，但它能挡住 80% 的僵尸任务。

4. 误区四：恢复成本可以忽略

研发工作的连续性被严重低估。写代码时脑子里维持的是一张完整的依赖图：哪个模块影响哪个接口、哪个改动会触发哪个测试用例、哪个边界条件上次踩过坑。暂停之后，这张图会被清空。

恢复时重建这张图，不是"再看一遍代码"那么简单。它需要重读代码、重读讨论记录、重新和上下游对齐接口、重新跑一遍验证。这就是为什么"暂停两周的任务，恢复时比新做一个任务还慢"这句话在很多时候是真的。

5. 误区五：状态越多越精确

另一个极端是状态爆炸。我见过一个工作流有 14 个状态，其中 6 个是不同粒度的暂停：待评估、待排期、待资源、待联调、待验收、待确认。结果是没有任何人记得该往哪个状态放，最后大家统一丢进最上面那个。

我的经验值是：暂停状态不要超过三类，且每类必须有明确的差异化的后续动作。如果两个状态的下一步处理方式完全一样，它们就应该合并。

6. 误区六：暂停任务不进迭代复盘

迭代复盘通常只看完成了什么、没完成什么，而暂停任务属于"没完成"里最容易被略过的一类，因为它不显眼，也不疼。

我的做法是把"本周新增暂停数、到期复核数、超期未复核数"三个数字固定放进迭代复盘看板。这三个数字一上墙，团队对暂停总量的感知会立刻变化。

四、专业判断逻辑：五维判定法

知道暂停要管，不等于知道每个具体任务该怎么管。我用的是一套五维判定法，遇到一个要暂停的任务时，先打分，再决定处理方式。

1. 维度一：可逆性

问一个问题：这个任务停下来之后再恢复，之前的产出还有多少能用？

如果代码已经写完只等联调，可逆性高，暂停的代价主要是等待；如果方案还在探索阶段，可逆性中等，因为探索结论会过期；如果已经进入大规模改造的中途，可逆性极低，此时暂停往往意味着之前的改动要回滚。

可逆性低的暂停必须升级决策。它不是执行层面的操作，而是需要技术负责人参与判断的架构决策。

2. 维度二：上下文半衰期

这是我最看重的一个维度，也是最容易被忽略的。所谓半衰期，指的是这个任务的技术上下文在多长时间内会衰减到无法直接续接的程度。

改一个前端组件的样式，上下文半衰期可能是三周；调一个分布式事务的一致性问题，半衰期可能只有五天，因为涉及的隐含约定太多。半衰期越短的任务，越应该避免暂停；如果非停不可，必须留下上下文快照。

3. 维度三：外部承诺强度

这个任务是否已经对业务方、客户或合作伙伴做出了明确的交付承诺？如果有，暂停就必须同时做一次承诺变更，而不是单方面把任务挪走。

很多团队的技术执行没问题、风险管理也没问题，最后栽在承诺管理上：任务悄悄暂停了三个月，商务侧已经按原计划排好了客户沟通节奏。这种"信息不同步导致的信任损耗"，修复成本远高于多做几个任务。

4. 维度四：阻塞类型

阻塞发生在哪里，决定了谁应该负责解除它。等待型阻塞在外部，需要的是升级和跟踪；资源型阻塞在内部排期，需要的是取舍；认知型阻塞在方案本身，需要的是时间盒验证。

把阻塞类型搞错，会出现典型的无效动作：明明是外部依赖没到位，却在内部天天开会讨论；明明是方案不清楚，却在催排期。

5. 维度五：恢复成本与继续成本的比值

暂停前，做一个简单的算术：现在继续做完需要多少成本，暂停后再恢复需要多少成本。如果恢复成本超过继续成本的 60%，我倾向于不要暂停，而是缩小范围先交付一个可用版本。

这个判断的实践价值在于，它把"要不要暂停"从感觉问题变成了计算问题。团队一旦习惯这么算，那些"顺手暂停一下"的行为会立刻减少。

6. 五维打分之后的决策矩阵

这张表的核心逻辑是：暂停决策的复杂度，由可逆性和半衰期共同决定，不由任务的规模决定。一个看起来很小的任务，如果处在短半衰期的深水区，它的暂停风险可能比一个大需求还高。

五、真实案例：320 人研发组织的 180 天暂停治理

接下来这部分是我参与最深的一个完整案例，包含具体配置、迁移处理和数据结果。我把可复用的部分尽量写细，因为暂停治理最容易失败在"道理都懂但落不了地"。

1. 治理前的真实基线

这家公司做 B 端 SaaS，研发 210 人，分 4 条产品线，使用某项目管理平台管理需求与任务。治理启动时的基线数据是：在途暂停工作项 412 个，平均搁置 76 天，暂停状态共 5 个（语义高度重叠），其中 3 个状态的必填字段为空，且没有任何自动化提醒。

一个细节让我印象很深：他们有一个暂停状态的名称叫"暂缓-待定"。数据分析显示这个名字下的任务平均搁置 118 天，是全系统最长的。命名模糊的状态会自发吸收最难处理的任务，因为没人愿意为它做决策。

2. 状态模型怎么设计

我们把 5 个重叠状态收敛成 3 类，每类绑定不同的必填字段、最大搁置天数和升级路径。下面是最终落地的配置示意，可以直接映射到工作项状态流配置。

# 暂停状态模型（示意配置）
work_item_states:

key: in_progress

name: 进行中

key: paused_waiting

name: 暂停-等待外部依赖

required_fields: [pause_reason, resume_condition, owner, review_date]

max_pause_days: 14

escalate_to: tech_lead

key: paused_priority

name: 暂停-优先级让路

required_fields: [pause_reason, resume_condition, owner, review_date, context_snapshot]

max_pause_days: 30

escalate_to: product_owner

key: paused_validate

name: 暂停-方案待验证

required_fields: [pause_reason, hypothesis, resume_condition, owner, review_date]

max_pause_days: 7

escalate_to: architect

key: cancelled

name: 已关闭-不再恢复

required_fields: [close_reason]

transitions:

from: paused_*

to: in_progress

guard: resume_condition_satisfied == true

post_action: require_context_review

配置里有两个关键点。一是 context_snapshot 作为优先级让路型的必填字段，因为这类任务的返工占比最高，必须在暂停时留下"当前进展、已做决策、待验证假设"三行记录。

二是恢复时必须走一次 context_review。这不是形式主义，目的是让恢复动作有一个明确的起点，避免任务被随手拉回进行中却无人真正接管。三是最大搁置天数分级：验证型 7 天、等待型 14 天、让路型 30 天。分级依据就是前面测出的上下文半衰期数据。

3. 字段、自动化与复核节奏

字段设计好之后，真正让流程活起来的是自动化。我们配了一条每周一早上九点触发的巡检规则，用查询语句筛出所有处于暂停状态的任务，按复核日期和搁置天数做分流。

# 每周一 09:00 触发的暂停任务巡检（伪代码）
for item in query(state LIKE 'paused_%'):

if item.review_date < today:

notify(item.owner, item.stakeholder)

item.needs_decision = true

if item.paused_days > item.max_pause_days:

item.escalate_to(item.escalate_to)

item.tag('overdue_pause')

if item.resume_condition_satisfied:

item.transition_to('in_progress')

item.require('context_review_checklist')

这条规则上线后的第一周，系统一次性推出了 89 条超期暂停提醒。团队当时的反应是"原来积了这么多"。暂停管理的第一价值不是优化，而是让问题可见。看不见的负债是无法管理的。

4. 从旧系统迁移时，历史暂停状态怎么处理

这家公司正好在做工具迁移，从旧系统切到 PingCode。他们的研发负责人后来总结，迁移其实是暂停治理最好的时机，因为迁移强制你回答一个问题：每一个历史状态，未来还有没有存在的必要。

我建议的处理方式是"三分法"：近 90 天内有过更新、且恢复条件明确的暂停任务，映射到新的三类状态；超过 180 天无更新、且无明确恢复条件的，一律迁移到已关闭-不再恢复；介于两者之间的，打上待判定标签，给 owner 两周时间做一次集中裁决。

他们的实际结果是：412 个暂停任务里，189 个直接关闭（占比 46%），147 个映射到新状态（36%），76 个进入待判定（18%）。最终真正被恢复执行的只有 61 个，其余全部关闭。

这个比例很说明问题：近一半的暂停任务，其实早就该被关闭，只是没人有权限或动力去做这个决定。迁移提供了一个天然的决策窗口。

在工具侧，PingCode 支持工作项状态流自定义、必填字段约束和自动化规则配置，能把这套模型直接落成系统约束而不是文档约定，这对 100 人以上、跨多条产品线的组织尤其重要。它也支持私有化部署，适合有数据合规要求的中大型企业；对有历史系统包袱的团队，支持从 Jira 平滑迁移，可以把迁移和暂停状态清理合并成一次动作，避免清理工作被无限期推迟。

5. 六个月后的数据

治理从启动到稳定运行共 180 天。核心指标变化如下表。我把关键数字列出来，是因为暂停治理的收益很难靠感觉判断，必须有前后对比。

需要说明的是，这家公司同期还做了需求拆分规范和测试左移，交付周期的改善不能全部归因于暂停治理。但计划外插入率从 31% 降到 14% 这一项，几乎完全来自暂停任务不再集中复活。

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

暂停管理的落地方式，和团队规模强相关。同一套流程在 15 人团队里是负担，在 200 人组织里是必需品。下面按四种情况给建议。

1. 20 人以下的团队：轻量约束，重点在习惯

这个规模不要上复杂流程。我的建议只有三条：每个暂停任务必须有一行恢复条件写在描述里；每周站会花五分钟过一遍暂停清单；超过 30 天没人提的暂停任务，默认关闭。

三条规则加起来每周成本不超过 30 分钟，但能挡住绝大部分僵尸任务。小团队最大的优势是沟通成本低，不要为了管理暂停而引入一个需要专门维护的系统。

2. 20 到 100 人的团队：状态收敛，引入复核日期

这个阶段的典型问题是状态膨胀和 owner 模糊。建议把暂停状态收敛到三类，强制填写恢复条件和复核日期，并配置一条每周自动提醒。

复核节奏我建议统一设为 14 天，暂时不做分级。原因是这个规模的团队数据样本不足，分级依据不牢靠，先用统一节奏跑三个月，积累数据后再调。

3. 100 人以上、多产品线的组织：分级模型加自动化巡检

这个规模必须上系统约束，靠文档约定一定会失效。要做四件事：暂停状态分三类并绑定不同必填字段；按上下文半衰期设分级复核周期；配置自动化巡检并把超期项升级到产品负责人；把暂停指标纳入迭代复盘看板。

同时要注意跨产品线的口径统一。我见过一个组织，三条产品线各自定义了不同的暂停状态，导致组织级数据完全无法汇总。状态模型可以分级细化，但最上层的三类必须是全组织统一的。

在工具选型上，这类组织的核心诉求是可配置和可审计。以 PingCode 为例，它面向中大型企业，工作项状态流、必填字段约束、自动化规则都能在系统里配成硬约束，配合私有化部署满足数据合规要求，加上对 Jira 平滑迁移的支持，可以让状态模型重构和历史数据清理在同一次动作里完成。对 100 人以上组织，这种"迁移即治理"的窗口比事后单独推动要省力得多。

4. 强合规、私有化部署场景：把暂停审计做成可追溯链条

金融、医疗、汽车电子这类行业，暂停管理还要额外满足审计要求：谁在什么时间因为什么原因暂停了哪个任务，谁批准了这个决定，恢复时的验证结论是什么。

这类场景下，建议把暂停和恢复都做成不可删除的事件记录，并与变更管理流程打通。审计链条的价值不只是合规，它同时解决了暂停决策无人负责的问题，因为每一次暂停都会留下决策人。

七、不同情况下的取舍

暂停管理没有免费的最优解。每一条看起来正确的规则，都有它的代价。我把实际踩过的五组取舍写出来，供你判断自己的团队该站在哪一边。

1. 取舍一：状态粒度与流程重量

状态分得越细，数据越精确，但每次流转的判断成本越高。三类暂停是我验证过的平衡点，再往上加就会开始出现"不知道该选哪个"的情况。

如果你的团队暂停总量长期低于 20 个，我的建议是只保留一类暂停，不要分级。流程的价值来自被执行，一个只有两类状态但严格执行的模型，胜过一个有六类状态但没人遵守的模型。

2. 取舍二：强制复核周期与灵活性

复核周期越短，恢复成本越低，但流程干扰越大。7 天复核能把恢复成本压到最低，代价是每周都要消耗团队注意力去做决策，很多任务会在"其实还没到复核时间"的状态下被反复翻出来。

我的经验值是 14 天：既能挡住 30 天后的成本陡增，每周的流程开销也控制在可接受范围内。如果你的团队任务半衰期普遍偏短，比如大量接口联调类工作，可以考虑 7 天，但要接受额外的会议成本。

3. 取舍三：暂停复盘与会议成本

把暂停指标放进迭代复盘，能显著提升可见性，但会增加复盘时长。一个 12 人团队，如果每次复盘都要逐个过暂停任务，可能要多花 20 分钟。

我的建议是分级处理：复盘只看三个汇总数字（新增暂停、到期复核、超期未复核），不逐个过任务。需要逐个讨论的，单独约一个短会。这样既保持了可见性，又不会让复盘变成任务清点会。

4. 取舍四：工具强约束与团队自治

把必填字段做成系统硬约束，能保证数据质量，但会让部分成员觉得被管得太细，尤其是资深工程师，他们更习惯用自己的方式记录上下文。

我的处理方式是：约束字段，不约束格式。暂停原因、恢复条件、复核日期必须填，但怎么写不限制，可以是一句话，也可以是一段技术笔记。约束的目的是让信息可检索，不是让信息标准化。

5. 取舍五：数据可见性与心理安全感

暂停数据全部公开可见，能提升透明度，但也可能让团队不敢暂停该暂停的任务，转而用"优先级调低"来变相隐藏。

这是一个真实存在的风险。我的做法是明确区分两类数据：暂停数量用于流程改进，不作为个人绩效评估依据。这句话必须在推行时明确说出来，否则你看到的暂停数据会失真，团队会把任务藏到你看不见的地方。

八、7 天 / 30 天 / 90 天落地路线图

最后给一份可以直接照着做的路线图。这份路线图我在三个团队里推过，共同的经验是：不要一次性把所有规则上线，先让问题可见，再让流程收敛。

1. 第 1 到 7 天：让暂停可见

1. 导出当前所有暂停状态的工作项，统计总量、平均搁置天数、最长搁置天数。
2. 把暂停状态清单列出来，标注语义重叠的部分。
3. 按原因做一次粗分类，找出占比最高的两类。
4. 在迭代复盘上公布这三个数字，不做任何流程变更。

这一步的唯一目标是让团队意识到问题的规模。我见过太多团队在还没看清存量时就急着定规则，结果是规则和现实严重脱节。

2. 第 8 到 30 天：收敛状态，建立节奏

1. 把暂停状态收敛到三类（或一类，视团队规模而定）。
2. 为每类绑定必填字段：暂停原因、恢复条件、owner、复核日期。
3. 配置每周自动巡检，超期项通知 owner 与相关方。
4. 对存量任务做一次集中裁决：恢复、关闭、或打上待判定标签。
5. 把新增暂停数、到期复核数、超期未复核数加入复盘看板。

集中裁决是最容易被跳过的一步，但它的收益最大。前面那个案例里，46% 的历史暂停任务在这一步被直接关闭。

3. 第 31 到 90 天：分级优化，形成闭环

1. 根据实际数据调整分级复核周期，验证型 7 天、等待型 14 天、让路型 30 天作为起点。
2. 统计恢复任务的返工率，反向校验暂停前的判断规则是否合理。
3. 把暂停决策纳入技术评审：低可逆性任务的暂停必须经过技术负责人。
4. 建立"暂停预算"：暂停任务总量不超过团队迭代容量的 20%。
5. 每季度做一次暂停模式复盘，找出反复被暂停的同类问题。

第 90 天之后，这套流程应该已经变成团队的默认动作。如果还需要专门推动，说明某个环节的设计和团队实际工作方式不匹配，需要回头调整而不是继续加码。

4. 下一步你可以做什么

如果你今天就想动手，我建议从最小的一步开始：打开你的项目管理工具，按暂停状态筛一次，看看有多少个、平均搁置多少天、最长的那一个是什么。

这个动作在 100 人以上的组织里通常只需要十分钟，但它带来的冲击往往比一场流程宣讲会更有效。暂停管理的起点从来不是设计状态机，而是承认那些被搁置的任务仍然在产生成本。

真正成熟的研发团队，不是从不暂停任务的团队，而是每一次暂停都有原因、有责任人、有复核日期、有明确退出方式的团队。任务可以被停下来，但决策不能被停下来。