挂起管理方法大全：研发团队任务执行入门指南落地清单

去年冬天，我帮一家 140 人规模的研发中心做交付复盘。看板上处于「挂起」状态的任务有 312 条，占全部未关闭工作项的 23%。挂得最久的一条叫「接入某银行二代征信接口」，最后一条评论停在 2023 年 11 月，只有五个字：等对方文档。它的原负责人已经离职 8 个月，需求方换了三任产品经理，而这条任务至今仍被算进「在办工作」里，每个月出现在交付报表的分子上。

这不是个例。我复盘过的十几个研发团队里，几乎每个看板底部都压着这样一层「沉积物」：没人做、没人关、没人认领，但它在系统里是活的。

这篇文章想解决的问题很具体：挂起不是把任务挪到一边，而是一套带触发条件的调度机制。下面我会先给结论，再讲我见过的真实场景、七个反复出现的坑、可以复制的判断逻辑和落地清单，最后给出不同规模团队的取舍建议。

一、先给结论：挂起管理管的是「唤醒条件」，不是「暂停动作」

在展开之前，我把最核心的五条结论放在前面。如果你只想记五句话，记这五句就够了。

1. 结论一：挂起率不是越低越好

很多团队把「挂起任务占比」当成一个越少越健康的指标，我在评审会上听过不止一次「我们要把挂起率压到 5% 以下」。这个目标本身就是错的。

一个健康的研发团队，挂起率通常稳定在 10%-18% 之间。低于这个区间，往往说明两件事：要么团队不敢承认自己排不下，把所有事都硬塞进迭代，用「延期」掩盖「做不了」；要么团队成员习惯了口头搁置，任务根本不进系统，看板反而更干净、也更失真。

挂起率高不一定是坏事，关键要看两个配套指标：挂起任务的平均停留时长，以及挂起任务在 30 天内的复活率。前者高、后者低，才是真正需要治理的信号。

2. 结论二：没有唤醒条件的挂起，本质是一次软删除

我在做数据回溯时最常用的一个切分维度是：这条挂起任务有没有写清楚「什么条件下可以重新开始」。有唤醒条件和没有唤醒条件，后续命运几乎完全不同。

没有唤醒条件的挂起任务，本质上和关闭没有区别，唯一的差别是它还在占用看板位置、拉高在制品数量、稀释报表口径。它给团队制造了一种「这件事我还没放弃」的错觉，但决策其实早就做完了，只是没人敢按关闭键。

我跟踪的 2400 条挂起任务里（6 个团队、12 个月的看板导出数据，属于样本推演而非正式统计），有明确唤醒条件的只占 34%，而这两组任务的结局差距极大。

3. 结论三：挂起必须携带「原因 + 责任人 + 复核时间」三件套

这三样东西缺任何一样，挂起就会失控。原因决定后续分类统计和复盘方向，责任人决定有没有人真的盯着，复核时间决定这件事会不会被重新想起。

我在推动落地时会把这三项设成必填字段，不填就流转不到挂起状态。刚开始阻力很大，工程师会说「我就是临时放一下」。三个月之后，同一个团队的产品经理告诉我，这是他最喜欢的一个约束，因为终于知道哪些事是「真的在等」。

4. 结论四：阻塞和挂起必须分开建模

这是我在几乎所有团队都会纠正的第一个概念混淆。阻塞（Blocked）是「现在要做但做不了」，挂起（On Hold）是「现在不做，等条件成熟再做」。前者是被动的，后者是主动的决策。

混在一起建模的后果非常直接：你无法回答「我们有多少产能被外部依赖卡住了」这个问题，也无法把「我们主动放弃了多少事」和「我们被卡住了多少事」分开看。这两种情况的管理动作完全不同。

5. 结论五：挂起额度要像在制品一样被限制

既然挂起任务仍然占用团队的注意力资源，它就应该消耗额度。我的经验值是：挂起任务数量不超过当前在制品（WIP）的 15%，超过就要触发治理动作，而不是继续往挂起池里丢东西。

额度机制的作用不是卡死，而是逼团队在「挂起」和「关闭」之间做一次真实的取舍。额度满了，就必须有人站出来说：这条我决定关掉。

二、背景与真实场景：挂起是怎么变成研发「黑洞」的

要治理一件事，得先看清它长什么样。我先把三种经常被混为一谈的「停」拆开，再讲四个我反复遇到的具体场景。

1. 被混为一谈的三种「停」：阻塞、挂起、搁置

研发任务停下来，其实有三种完全不同的性质，但绝大多数团队在系统里只有一个状态或一个标签来表示它们。

• 阻塞：任务仍在当前迭代的承诺范围内，只是暂时无法推进。典型表现是等一个接口、等一次代码评审、等环境就绪。它有明确的责任人，且通常有外部的解锁方。
• 挂起：主动决定本轮不做。它已经从承诺中退出，但仍保留在未来某个时点重新进入的可能性，且这个可能性有明确的触发条件。
• 搁置：事实上已经不打算做了，只是没有正式关闭。搁置是一种管理上的失职，不是一种状态。

三者的关键差异在于「谁承诺了下一步」。阻塞是外部承诺，挂起是内部承诺，搁置是没有人承诺。系统里只用一个状态承载这三种含义，度量就必然失真。

2. 场景一：需求方一句「先放放」

这是最常见的挂起来源。产品经理在会上说「这个先放放，下个版本再说」，任务就进了挂起池。「下个版本」不是一个可观测的条件，它只是一个礼貌的说法。

我做过的分类统计里，这类「等需求确认或决策」的挂起任务，最终有接近一半在 90 天内被直接关闭，且没有留下任何结论。这不是坏结果，坏的是这一半的决定被推迟了三个月才做出。

3. 场景二：外部依赖永远差一周

等第三方接口、等合作方数据、等供应商排期。这类任务的特点是有明确的责任人，但责任人没有控制权。它会在挂起池里以「下周就能好」的姿态反复出现，每次复核都往后挪一周。

我对这类任务的建议是：把「等」这件事本身拆成独立任务，并为等待设置一个硬性截止日。超过截止日就触发技术方案的备选路径评审，而不是继续等。等待本身也是需要被管理的工程活动。

4. 场景三：技术预研失败后没人敢关

技术方案验证到一半发现走不通，但已经投入了两周人力。这时候团队通常不会关闭任务，而是挂起来「保留成果」。我完全理解这种心态，但从数据看，这类任务的复活率不到 9%。

更有效的做法是：先把预研结论写成文档，再关闭任务并链接文档。保留的是结论，不是任务。任务留在系统里不会让成果更安全，只会让看板更脏。

5. 场景四：季度末的冻结与预算切换

合规评审窗口期、预算年度切换、组织架构调整，都会批量产生挂起。这类挂起是合理的、外部驱动的，问题出在它们往往批量产生、批量遗忘。

我的建议是把这类挂起打上独立的来源标签，并为它们设置统一的复核日期，比如「下一财年 Q1 首周」。批量挂起就应该批量复核，一个一个盯是浪费管理成本。

三、拆解常见误区：我在多个团队反复看到的七个坑

下面这七个坑，我在不同公司、不同规模的团队里都见过至少一遍。它们的共同点是：当时没人觉得有问题，三个月后全部变成噪音。

1. 误区一：把挂起当「稍后做」，不设有效期

「稍后」是一个没有边界的时间概念。没有有效期的挂起任务，在心理上等同于已经完成，因为大脑不再为它分配注意力了。挂起必须带 TTL（最长存活时间），到期自动回到复核队列。这不是不信任人，而是承认人的记忆不可靠。

2. 误区二：只有状态，没有原因字段

只有一个「挂起」状态，你最多能算出挂起率，算不出任何可行动的结论。加上原因字段之后，你才能回答「我们有多少产能被外部依赖吃掉」，这类结论才能推动跨部门动作。

3. 误区三：挂起任务不占在制品额度

这是最隐蔽的一个坑。挂起任务不进入迭代，因此不计入在制品数量。结果是团队一边挂着 40 条任务，一边继续接新需求，报表上看起来产能健康，实际上每个月的复核都在消耗大量管理时间。

4. 误区四：挂起不需要责任人

很多团队认为「既然不做了，就不用指派人」。但挂起需要的是「唤醒责任人」而不是「执行责任人」。这个人在任务复活时要负责重新评估、重新排期、重新对齐需求方。

没有唤醒责任人的挂起任务，就是一条无人认领的孤儿任务。

5. 误区五：用「延期」代替「挂起」

我见过一个团队，任务的截止日期被连续修改了 11 次，每次改完状态都是「进行中」。这种做法的危害在于：它污染了交付周期数据，让所有关于「我们平均多久能交付一件事」的度量全部失效。

不断延期的任务，本质上是已经挂起但不敢承认。承认挂起，比维护一个虚假的进行中状态健康得多。

6. 误区六：挂起时不通知需求方

挂起是一个决策，决策需要被同步。我参与过一次事故复盘，起因是一个被挂起 5 周的任务，需求方一直以为它在正常开发，直到上线前一天才发现没做。

挂起动作应该自动触发一条通知：谁、为什么、什么时候复核。这不是流程繁琐，这是把一次隐性决策变成显性记录。

7. 误区七：用挂起掩盖决策缺失

这是所有误区的根因。挂起池膨胀，99% 的情况下不是因为任务太多，而是因为该做决定的人没有做决定。挂起是给决策者留的缓冲带，不是给决策者留的逃避通道。

我判断一个团队挂起管理是否健康，会问一个问题：最近一次挂起例会上，有几条任务被真的关闭了？如果答案是零，那这个例会只是走流程。

四、专业判断逻辑：该不该挂起、挂多久、谁来唤醒

前面讲的是「不该怎么做」，接下来讲「应该怎么判断」。这套逻辑我在多个团队里跑过，可以直接作为评审时的判断依据。

1. 五问决策树：决定一条任务该不该挂起

当有人提出要挂起一条任务时，我会依次问五个问题。任何一问回答不上来，就不该流转到挂起状态。

1. 这条任务在未来 90 天内有没有可能重新开始？不会，直接关闭，别挂起。
2. 重新开始的前置条件是什么？必须落成一个可观测的事实，例如「对方接口联调环境可用」「合规评审结论出具」。
3. 这个条件由谁负责推进？没有明确的人，就是没有人负责。
4. 谁负责在条件满足时把这条任务拉回来？这是唤醒责任人，通常不是原执行人。
5. 如果条件永远不满足，这条任务的兜底动作是什么？写清楚兜底动作，能避免无限期挂起。

五问全部通过，才允许挂起。我在一个 80 人团队推行这套问法后，第一个月挂起任务数量下降了 60%，其中大部分直接变成了关闭。这才是真实的数据清洗。

2. 挂起额度的计算方法

额度不是拍脑袋定的。我通常用这个公式起算，然后观察两个迭代再调整：

挂起额度上限 ≈ 当前在制品数量 × 15%。以 6 个并行小组、每组在制 8 条计算，在制品总量约 48 条，挂起额度上限就是 7 条左右。

额度满了之后的发生的事情才是关键：团队必须坐下来做一次取舍，而不是简单地忽略额度。额度机制的价值在于它强制产生一次对话。

3. 按 TTL 分层的复核节奏

不同原因的挂起，合理的复核周期完全不同。统一用 30 天复核，对短周期任务太慢，对长周期任务又太频繁。

4. 唤醒条件必须可观测、可自动判定

这是我最强调的一条。唤醒条件如果只能靠人去判断，那它就不是条件，而是一种愿望。对比下面这两句话，你立刻能看出差别。

• 不可观测：「等对方技术方案成熟」，什么时候算成熟？没人知道。
• 可观测：「对方提供 v2 接口文档且沙箱环境可访问」，这是一个可以打勾的事实。

我要求所有挂起任务的唤醒条件写成「当 X 事实成立时」，且 X 必须能被外部验证，最好还能被系统字段表达。这样才有可能做自动化提醒。

5. 责任人的定义：不是执行人，是「盯的人」

挂起任务的负责人字段，填的应该是「唤醒责任人」。这个人通常具备三个特征：有推进外部依赖的能力、了解业务上下文、在复核时有决策权。

我的经验是：唤醒责任人应该是项目经理或技术负责人，而不是原执行工程师。原执行人已经切换上下文去做别的事了，让他去盯一件自己不做的事，效率极低。

五、落地方法：状态机、字段与自动化规则

判断逻辑讲清楚之后，剩下的就是把它们固化到工具里。这一节我给出可以直接抄的建模方式、字段清单和自动化规则示例。

1. 状态建模：把阻塞和挂起拆成两个状态

我的标准建议是在工作任务类型下设置这样一组状态：待处理 → 进行中 → 阻塞 → 挂起 → 已完成 / 已取消。阻塞和挂起平级，但语义不同。

如果工具的状态数量有限制，退一步的做法是：用状态表达「阻塞」，用独立字段 + 视图表达「挂起」。最差的做法是只用一个「暂停」状态同时承载两种含义，这会让后面所有度量都失去意义。

2. 必备字段清单

下面这六个字段是我认为的最小可用集。少于六个，挂起就会失控；多于八个，填写成本会让团队抵触。

3. TTL 自动化规则示例

规则不复杂，关键是有人真的去配置。下面是一段示意配置，你可以照着改写到自己团队的工具里。

# 挂起任务自动复核规则（YAML 伪配置，仅示意结构）
rules:

name: hold-ttl-7d-decision

when:

status: "挂起"

hold_reason: ["等需求确认或决策"]

actions:

at_day: 3

do: "提醒唤醒责任人更新结论，并 @ 产品负责人"

at_day: 7

do: "自动流转到『待决策评审』泳道，标记 needs-decision"

at_day: 10

do: "升级至项目集负责人，进入周会议题"

name: hold-ttl-14d-external

when:

status: "挂起"

hold_reason: ["等外部依赖"]

actions:

at_day: 7

do: "要求更新依赖方状态与预计可用时间"

at_day: 14

do: "触发备选方案评审任务，指派给技术负责人"

name: hold-ttl-90d-zombie

when:

status: "挂起"

last_updated_days_ago: 90

actions:

do: "自动标记 zombie-hold，进入月度挂起治理会强制判定"

这段配置里最值得注意的是最后一条。僵尸任务的判定不应该靠人去翻看板，而应该由系统在 90 天这个阈值上自动打标。人在没有提醒的情况下，是不会主动去清理挂起池的。

4. 看板与视图设计

挂起任务不应该混在主看板上，否则会持续干扰团队对「当前在做什么」的判断。我通常建议建两个独立视图。

• 阻塞视图：按阻塞天数排序，只显示责任人，每天站会看一眼。目标是缩短阻塞时长。
• 挂起治理视图：按复核日期排序，显示原因、唤醒条件、唤醒责任人、是否僵尸。每周或每两周看一次。目标是做取舍。

两个视图对应两种完全不同的管理动作，这就是为什么状态必须分开建模的直接原因。

5. 挂起例会怎么开才不浪费时间

挂起例会最容易开成「念清单」，我见过开着开着就没人来了。我的建议是把它压缩成一个 30 分钟的「三选一」会议。

每条任务只有三个选项：复活并排期、继续挂起并更新唤醒条件、关闭。要求当场给结论，不允许「再看看」。一个团队如果能在 30 分钟内处理完 15 条挂起任务，说明决策链路是通的。

六、数据观察与案例：以 PingCode 为例的 90 天治理

前面讲的是方法，这一节讲一个我实际参与过的落地案例，以及为什么这类治理必须依托工具才能长期跑下去。

1. 为什么挂起治理必须用工具固化

我试过用文档和表格做挂起管理，坚持不过两个迭代。原因是三个动作必须自动化，而人工做不可持续：提醒、升级、僵尸标记。

只要提醒依赖人去记，它就一定会忘；只要升级依赖人去提，它就一定会拖；只要僵尸标记依赖人去翻看板，它就一定会漏。挂起治理的核心不是流程设计能力，而是规则的自动化执行能力。

2. PingCode 上的落地配置

在最近这个项目里，客户是一家 300 人规模的研发组织，分 9 个小组，年内还有信创合规要求。我们最终选择在 PingCode 上落地这套挂起管理机制，主要考虑三个点。

第一是字段与工作流的自由度。PingCode 允许我们为工作任务类型单独配置「挂起」状态与六个自定义字段，并设置必填校验，这直接对应前面讲的落地清单。

第二是部署与合规。这家客户有数据不出域的要求，PingCode 支持私有化部署，这一点在信创和金融类客户里往往是硬门槛。

第三是迁移成本。客户原本用 Jira，历史项目有 4 年数据、约 18 万个工作项。PingCode 支持从 Jira 平滑迁移，状态映射、字段映射和附件历史都做了对应处理，这也是我们最终没有选择自研工具的原因。对中大型企业来说，PingCode 是国产替代时一个风险较低的选项，它主要服务的也正是 100 人以上、组织层级较多的研发组织。

3. 90 天治理的具体数据

治理前我们做了一次基线采集：挂起任务占比 23%，平均挂起时长 58 天，僵尸任务（90 天无更新）占比 41%，平均交付周期 46 天。

治理动作很简单，就是前面讲的三件事：补齐六字段、配置 TTL 自动提醒、每两周开一次 30 分钟的三选一会议。90 天后再采集一次数据。

有一个数据值得单独说：平均交付周期缩短了 28%，但团队人数和执行方法没有任何变化。原因不在于做得更快，而在于看板更干净之后，团队对「现在该做什么」的判断成本下降了。

七、不同情况下的行动建议：按团队规模给方案

同样一套方法，在 20 人团队和 300 人组织里的落地方式完全不同。下面按三个规模区间给出我的具体建议。

1. 10-30 人团队：先做一件事，把唤醒条件写下来

这个规模不需要复杂的字段和工作流，一个「挂起原因」加一个「唤醒条件」就够了。团队小，信息传递靠口头就能完成，过度设计反而是负担。

我建议的最小动作是：每周五花 15 分钟过一遍挂起池，逐条问「这件事的唤醒条件变了吗」。变了就复活或者关闭，没变就继续挂着。这个动作坚持三个月，效果比任何工具配置都明显。

2. 30-100 人团队：补字段，加提醒，建独立视图

到了这个规模，跨组协作开始出现，口头同步开始失效。这时候必须补齐六字段，并配置至少两条自动化规则：7 天提醒和 30 天升级。

同时建议把挂起任务从主看板移出，建立独立的挂起治理视图，按复核日期排序。让站会专注在阻塞上，让治理会专注在做取舍上。

3. 100 人以上组织：分层治理，工具固化，指标入报表

100 人以上的组织，挂起治理必须变成一项有 owner 的常规工作，而不是一次运动式清理。PingCode 这类面向中大型企业的平台在这个阶段优势更明显，因为跨项目集的字段一致性、权限分层和报表能力，是小工具很难覆盖的。

我建议的做法是：小组级每周自查，产品线级双周治理会，组织级每月看一次挂起总额度和平均挂起时长趋势。三个层级的关注点不同，小组关注「这条要不要复活」，产品线关注「挂起额度是否超标」，组织关注「趋势是否恶化」。

八、不同情况下的取舍：挂起的收益、代价与禁用场景

任何管理动作都有代价。挂起最大的问题不是它没用，而是它太容易被滥用。这一节讲清楚什么时候该用，什么时候不该用。

1. 什么时候必须挂起

• 外部依赖明确、但解锁时间不由团队控制，且任务本身仍然有价值。
• 合规窗口期未到，提前开工会产生返工风险。
• 技术方案正确但资源被更高优先级的线上问题占用，且预期两周内可恢复。
• 需求方向已确认要做，但上游产品方案尚未定稿。

这四种情况的共同点是：不确定性来自外部，且存在一个可观测的解锁时点。满足这两条，挂起就是合理的管理动作。

2. 什么时候直接关闭比挂起更好

反过来，如果一条任务满足下面任意一条，我会建议直接关闭，不要挂起。

• 预研结论是「此路不通」，成果应该沉淀为文档而不是保留任务。
• 需求方已经不再追问，且连续三次复核都没有实质进展。
• 挂起时长已经超过 90 天，技术方案大概率已过时。
• 责任人和需求方都已离职或转岗，上下文已经断裂。

关闭不是失败，挂着不管才是。关闭会留下一条清晰的记录，告诉未来的团队「我们当时评估过、决定不做」。挂起只会留下一条没人能解释的噪音。

3. 什么时候应该拆任务而不是挂起

有一种情况常常被误判为挂起：任务太大，导致无法在当期完成。这时候正确的动作是拆分，而不是挂起整条。

我常用的判断方法是：如果这条任务的预估工作量超过两周，且已经挂起过一次，那就应该拆成「可以独立交付的最小单元」，把其中能做的部分留在迭代里，把暂时做不了的部分单独挂起。这样至少有一部分价值能当期交付。

4. 挂起的隐性成本：上下文重建代价是非线性的

很多人以为挂起的成本就是「晚点做」。实际不是。加州大学欧文分校的 Gloria Mark 在关于工作打断的研究中指出，人在被打断之后平均需要约 23 分钟才能回到原任务的专注状态。任务挂起是同一类打断，只是时间尺度更大。

我做过一次小的复盘估算（4 个团队的复盘访谈，属示意推演）：一条挂起 7 天的任务，重新接手时重建上下文的成本大约是 0.4 人天；30 天时上升到 1.6 人天；90 天时接近 4.8 人天，几乎等于重做。

九、落地清单：12 项可以直接抄的检查项

下面这份清单我通常会直接给到团队负责人，按顺序执行即可，不要跳步。

1. 确认工具中「阻塞」和「挂起」是两个独立状态，不是同一个标签。
2. 为挂起状态配置至少四个必填字段：原因、唤醒条件、唤醒责任人、复核日期。
3. 把挂起原因收敛为不超过 6 个选项，选项必须是互斥的。
4. 为每一类挂起原因设定 TTL：决策类 7 天、依赖类 14 天、资源类 30 天、合规类 90 天。
5. 配置至少一条自动化提醒规则，在 TTL 的 50% 处触发。
6. 配置一条僵尸标记规则，在 90 天无更新时自动打标。
7. 建立独立的挂起治理视图，按复核日期排序，不与主看板混用。
8. 设定挂起额度上限，初始值为在制品数量的 15%。
9. 把挂起例会固定在日历上，每两周一次，时长不超过 30 分钟。
10. 例会只允许三种结论：复活排期、继续挂起并更新条件、关闭。
11. 每月向管理层输出三个数字：挂起占比、平均挂起时长、僵尸任务占比。
12. 每季度做一次挂起池清洗，把 90 天以上的任务批量判定。

这份清单里，第 4 条和第 12 条是最容易被跳过、也是最影响长期效果的。前者决定了规则能不能自动化，后者决定了历史包袱会不会反复堆积。

1. 常见问题速答

问：挂起任务要不要计入产能规划？不直接计入当期产能，但要计入注意力预算。我的做法是把挂起任务的复核与治理工作量按每月 1.5-3 人天预留出来，这部分不体现在迭代计划里，但它是真实存在的管理成本。

问：小团队没有工具支持，能不能做挂起管理？能，但要做减法。至少保留「唤醒条件」和「复核日期」两个字段，用最简单的看板列或者表格维护，每周固定 15 分钟过一遍。工具不是前提，规则才是。

问：挂起任务被复活后，应该重新估算工时吗？必须重新估算。我见过太多团队直接沿用三个月前的估算，结果计划全部失准。复活时应该做一次轻量评估，确认技术方案是否仍然适用，这是唤醒责任人最核心的职责。

问：怎么说服团队接受必填字段带来的填写成本？用数据说话。先花两周记录「因为挂起信息不全导致的时间浪费」，比如一次跨部门误判、一次重复沟通。把这两周的损失摆出来，比讲十遍流程规范都有效。

问：挂起率应该设成 KPI 吗？不建议。挂起率是诊断指标，不是考核指标。一旦变成 KPI，团队会学会直接关闭任务来美化数字，挂起池会变干净，但真实问题会被藏得更深。要考核的是平均挂起时长和僵尸任务占比。

十、总结与下一步

回到开头那家 140 人的研发中心。我们做的第一件事不是清理那 312 条挂起任务，而是把「挂起」这一个状态拆成了三个动作：阻塞要盯、挂起要写条件、搁置要关闭。

三个月后，挂起任务降到 127 条，其中真正需要保留的只有 60 多条。剩下的不是被「处理」掉的，而是被「决定」掉的。

我对挂起管理的核心判断只有一句话：挂起是一种延迟决策，而不是取消决策。延迟决策必须有到期日，否则它就变成了取消决策的伪装。绝大多数团队的挂起池之所以失控，不是因为任务太多，而是因为没有人愿意在正确的时间做出那个决定。

如果你准备动手，我建议的下一步只有三步，按顺序做，不要并行。

1. 今天：导出你们当前所有处于挂起或暂停状态的任务，统计总数和超过 90 天未更新的数量。这两个数字就是你的基线。
2. 本周：挑出超过 90 天的那一批，开一次 30 分钟会议，只允许三个结论，复活排期、继续挂起并写明唤醒条件、关闭。不要讨论，只做决定。
3. 本月：把四个必填字段和两条自动化规则配置到你们使用的工具里，可以是 PingCode，也可以是任何支持自定义状态与字段的平台。配置完成之前，不允许新增挂起任务。

做完这三步，你会发现挂起池的规模至少下降三分之一。剩下的部分，交给时间和固定节奏的治理会去解决。