FF管理指南：跨部门团队如何做好任务依赖，风险控制全流程

去年 Q3，我参与的一个跨部门版本交付出了个典型的"隐形翻车"：上线前三天，研发负责人说"代码功能已经全部完成，进度 100%"；文档负责人说"文档也写到最后一章了，进度 90%"。两个团队在周报里都是绿色。结果上线前 36 小时，文档团队发现接口描述必须等代码冻结后才能定稿，而研发坚持代码冻结要等文档确认接口语义，两边互相等对方先"完成"，形成了一个死锁。最后是凌晨两点拉了场临时会，靠人工拍板把接口字段砍掉两个才解开。

这就是 FF 依赖的经典形态：不是谁没干活，而是两端都以为自己快完成了，却没人定义"完成"到底以谁的完成时点为锚。

这篇文章我想从"依赖即风险"这个角度，把跨部门团队做任务依赖管理的全流程讲透。FF（Finish-to-Finish，完成到完成）依赖是所有依赖类型里最容易被排期表掩盖、最容易被周报"漂绿"、也最难在事后追责的一种。我会给出我自己在多个中大型组织里验证过的建模方法、风险评分模型、升级机制，以及在工具选型上的真实取舍判断。

一、先给结论：FF 依赖不是排期技巧，而是风险控制对象

如果你的团队把 FF 依赖当成甘特图上的一条连线来处理，那它一定会在某个深夜变成一场救火。我给出的核心结论是：FF 依赖的本质不是"时间约束"，而是"双边完成条件的耦合"。时间约束可以靠加人、加班、压缩范围来解，而完成条件耦合只能靠明确定义和结构性设计来解。

1. FF 依赖和 FS 依赖的根本差异在哪

FS（Finish-to-Start）是大家最熟悉的：A 完成，B 才能开始。它的最大优点是延迟暴露得早。A 只要没完成，B 就动不了，甘特图上立刻出现一条悬挂的空档，项目经理一眼就能看见。

FF 恰恰相反。FF 的定义是：B 的完成不能早于 A 的完成，但 B 可以在 A 完成之前就开始。于是就有了一个危险的中间态，B 的进度条一直在往前走，看起来非常健康，但它的"完成"被牢牢绑在 A 身上。A 一旦延迟，B 已完成的部分可能全部作废，需要返工。

（1）双边收尾型

最典型的就是我开头说的那个场景：代码冻结与文档定稿互相等待。两端都在收尾阶段，都接近 100%，但谁都不能先落锤。

（2）内容互校型

市场部的对外宣传物料和技术团队的技术白皮书，需要互相校验口径。两边都写了 80%，但任何一方改动核心表述，另一方就要跟着改。这种 FF 依赖的特点是变更不是单向传播，而是来回震荡。

（3）窗口绑定型

合规审计报告和业务数据汇总，必须在同一个监管窗口内同时提交。业务数据晚上线一天，审计报告就得整体重做。这种 FF 依赖的特点是外部时点锁死，内部没有协商空间。

2. 我的核心判断：FF 依赖的失控，九成不是排期问题，是"完成定义"问题

我复盘过自己参与的十余个跨部门项目，FF 依赖真正出问题的场景里，只有不到两成是纯粹的工期估算错误。剩下八成以上，根因都指向同一件事：两端团队对"完成"这个词的定义不一致。

研发说的"完成"是"功能代码合并进主干"，文档说的"完成"是"终稿通过评审"，市场说的"完成"是"物料印刷文件交付"。这三个"完成"在语义上根本无法对齐，但在周报里都会被简化成同一个 100%。

所以我给出的第一条行动原则是：凡是标了 FF 的依赖，必须额外定义"完成锚点"，即两端的完成以哪一个可验证的产出物为准。没有完成锚点的 FF 依赖，等同于没有依赖管理。

3. 三条可以直接拿去用的结论

• 结论一：FF 依赖必须比 FS 依赖更早锁定完成锚点。FS 可以在 A 完成后再谈 B 的细节，FF 不行，因为 B 已经开始做了。
• 结论二：FF 依赖必须设置"冻结点"而非"完成点"。真正需要被管理的是"从哪一刻起允许自由变更"，这个时点通常比完成点早 3 到 5 天。
• 结论三：FF 依赖必须绑定一个责任人，而不是两个团队各管一半。双边耦合的事项，如果责任也对半分，等于无人负责。

在展开具体方法之前，先看一组我用来向团队解释"为什么 FF 最危险"的对比。这组数据来自我参与过的 9 个跨部门项目的复盘记录（已脱敏，属于样本推演，不是行业统计），用五个维度对比四类依赖的管理难度。

二、真实场景：三个 FF 依赖失控的现场还原

抽象的方法论讲多了容易飘。我把三个我亲身处理过的 FF 失控现场按时间线还原出来，每个案例的失控机制都不一样，但都能用同一套逻辑解释。

1. 案例一：上线窗口的双边收尾（研发 × 技术文档）

这是个 120 人规模的研发组织，产品线有 4 个功能模块由不同团队负责，文档由一个独立的技术写作团队支撑。上线流程要求：代码冻结后才能最终确认接口文档，接口文档确认后才能冻结代码。

听上去荒谬，但在实际流程里这很常见，因为代码冻结意味着"不再改接口"，而接口文档确认意味着"接口定义已经稳定"。两边其实在等同一个信号，但都把它定义成对方先给出的动作。

项目最终延期 4 天。真正的问题不是延期本身，而是这 4 天里：文档团队有 3 人在空转等待，研发团队有 6 人在反复确认字段命名。粗算下来大约是 30 人天的无效消耗，而这只影响了一个版本。

2. 案例二：内容互校的来回震荡（市场 × 技术）

技术团队要发一篇架构演进的白皮书，市场团队要同步做一套对外宣传物料。两份内容必须口径一致，于是自然而然地形成了 FF 依赖。

问题出在"来回震荡"上。第一轮，市场改了对外表述，技术跟着改了白皮书；第二轮，技术调整了性能数据，市场又得改物料；第三轮，市场觉得某个术语用户看不懂，改了措辞，技术又得跟着改。三轮下来，文档版本号从 v2.3 一路打到 v7.1，双方都疲惫不堪。

这个案例的关键教训是：内容互校型 FF 依赖必须设置"变更冻结轮次"。我们后来改成"最多两轮互校，第三轮由产品负责人拍板，任何一方不得再提变更"，效率立刻回来了。

3. 案例三：外部窗口锁死的合规交付（合规 × 业务数据）

这个案例最刚性。监管要求季度数据报表和合规说明文档必须在同一天提交。业务数据团队要等各业务线汇总，合规团队要基于最终数据撰写说明。

数据团队的汇总延迟了两天，合规团队被迫在 8 小时内完成了原本计划 2 天的撰写工作。最终提交是赶上了，但说明文档里有两处数据引用错误，后续被要求补充说明材料，隐性成本比延期更高。

这个案例说明：窗口绑定型 FF 依赖几乎没有缓冲可用，必须靠前置阻断来管理，即提前设定"数据必须在第 N 天前锁定，逾期不候，按最坏情况先出一版说明"。我给这个团队的设计是提前 5 天做一次"最坏情况版本预演"，让合规团队提前准备好模板和话术框架。

4. 三个案例抽出来的共性

把三个案例放在一起看，会发现它们共享三条相同的失控路径：

1. 依赖没有被显式声明。三个案例里，没有任何一个团队在项目启动时明确说过"这里有一个 FF 依赖"，都是在执行过程中自然形成的。
2. 完成定义没有对齐。三个案例里，两端对"完成"的理解都不一致，但都没人主动去澄清。
3. 没有任何风险缓冲设计。三个案例都是走一步看一步，没有预设兜底方案。

下面这张图把三个案例的失控成本拆开，用来支撑"FF 依赖的隐性成本远大于显性延期"这个判断。所有数据来自项目复盘记录，属于样本推演。

三、把依赖"可视化"：从模糊的相互等待到可管理的对象

我在上一节反复强调"依赖没被显式声明"是根源。这一节讲怎么把它显式化。我用的方法叫依赖地图（Dependency Map），核心思路是把每个 FF 依赖变成一个三元组：上游交付物 + 下游交付物 + 完成锚点。

1. 依赖识别四步法

很多人做依赖识别的方式是"开会让大家想"，这个方法的问题在于，人会本能地忽略自己不确定的依赖。我用的四步法是从交付物倒推，而不是从任务正推。

（1）第一步：列出所有对外交付物

让每个团队列出"我要交给别人什么"。注意是交付物，不是任务。比如"接口文档终稿"是交付物，"写接口文档"是任务。这一步的目的是建立清单，通常一个中等规模版本会列出 20 到 40 个交付物。

（2）第二步：标注每个交付物的输入来源

对每个交付物问一句："为了交付它，我必须先拿到什么？"来源如果是本团队内部，跳过；如果是外部团队，标记为一个候选依赖。

（3）第三步：判断依赖类型

关键的一步。判断标准很简单：如果下游可以在上游完成之前就开工，且两端必须同时收尾，那就是 FF。很多人会把这种情况误判成 FS，因为潜意识里觉得"要等"，但实际上下游早就开始了。

（4）第四步：为每个 FF 依赖填写完成锚点

完成锚点必须是可验证的客观事实，不能是主观判断。下面是我在团队里推行的一份 YAML 声明格式，可以直接放进代码仓库或项目管理工具的依赖描述字段里。

dependency:
id: DEP-2024-Q3-017

type: FF

upstream:

team: 研发-交易域

deliverable: 支付接口定义冻结

completion_anchor: "接口字段清单签字确认 + Swagger 版本号锁定为 v3.2"

frozen_at: "上线前 5 个工作日"

downstream:

team: 技术写作

deliverable: 支付模块对外文档终稿

completion_anchor: "终稿通过双人评审 + 无 P0/P1 修改意见"

frozen_at: "上线前 2 个工作日"

risk:

probability: 0.4

impact: 8

detectability: 0.3

owner: 张（研发侧 PM）

fallback:

plan_a: "接口定义提前 3 天冻结，文档同步预写"

plan_b: "文档降级为在线更新模式，上线后 24 小时内补齐"

trigger: "上线前 3 天接口仍未冻结"

这份声明的关键点在于 completion_anchor 和 frozen_at 两个字段。完成锚点解决了"完成定义不一致"，冻结点解决"什么时候不能再改"。这两件事在绝大多数团队的依赖管理里是完全缺失的。

2. 从声明的依赖到被管理的依赖，会衰减多少

我要给出一个可能不太好听但很真实的观察：团队声明出来的依赖，最终真正被持续管理的通常只剩三成左右。这不是态度问题，是流程设计的必然衰减。下面这张漏斗图是我在一个 200 人规模组织里做依赖盘点时的记录（样本推演数据）。

3. RACI 与依赖矩阵的组合用法

RACI 矩阵被讲烂了，用户真正的痛点也不是不会做，而是"矩阵做完没人执行"。我自己踩过的坑是：把 RACI 当成一张静态文档交付，结果它在立项会后就没再被打开过。

我后来的做法是把 RACI 的 C（Consulted，被咨询）和 I（Informed，被告知）直接挂到依赖上。具体来说，每一个 FF 依赖都必须明确：

• A（Accountable）：只有一个，是 FF 依赖的责任人，负责最终拍板。这个人通常不是两个团队中任何一方的直属领导，而是项目层面的角色。
• R（Responsible）：两端各有一个，负责实际执行。
• C（Consulted）：变更冻结前必须征求意见的人，通常是接口的下游使用方。
• I（Informed）：冻结决策做出后需要同步的人，包括测试、运维、客服。

关键判断是：FF 依赖的 A 不能由两端任何一方担任。我见过太多团队让研发负责人当 A，结果在冲突时他天然偏向自己团队的方案。A 必须是项目级角色，拥有跨团队的裁决权。

4. 单一事实来源看板怎么搭

依赖管理的最后一个基础设施是"单一事实来源"（Single Source of Truth）。这个概念被说得多，但真正落地的少。我的判断是：做成看板的不是任务列表，而是依赖列表。

具体结构上，我用的是一个"依赖清单 + 状态流转"的双层视图。依赖清单是主视图，每行一个依赖，包含上下游团队、类型、完成锚点、冻结点、风险评分、责任人、当前状态。状态流转只有五个值：已识别、已确认、执行中、已冻结、已关闭。

这里面最容易被忽略的是"已冻结"这个状态。缺少冻结态，是绝大多数依赖看板失效的技术原因，因为无法区分"还在改"和"不能再改"，看板就退化成了一张任务列表。

四、把依赖"风险化"：FF 依赖的风险控制全流程

到这一步，依赖已经被可视化、被结构化。接下来的问题是我在开头提出的核心命题：怎么把每个依赖当成一个风险源来管。这一节讲完整流程。

1. 风险登记册怎么落到依赖上

传统的风险登记册和依赖管理通常是两张皮：风险登记册里写的是"人员流失""供应商延期"这类泛化风险，依赖看板里写的是任务关系。我把它们合并成一张表，每个 FF 依赖自动成为一条风险条目。

合并后的登记册字段设计如下，这是我目前认为最实用的六列结构：

2. 风险评分：为什么我加了"可探测性"这一维

传统的风险评分是概率乘以影响。我在实践中加上了第三维，可探测性。原因是我发现，FF 依赖最致命的特征恰恰是"发现晚"，而不是"发生率高"。

我用的评分公式是：风险值 = 概率 × 影响 × (1.5 – 可探测性)。可探测性越低，(1.5 – 可探测性) 越大，风险值被放大。这个系数上限是 1.5，意味着最不可探测的风险权重是最可探测风险的 1.5 倍。

举例说明：一个 FF 依赖，概率 0.3、影响 6、可探测性 0.8（很容易提前发现），风险值 = 0.3 × 6 × 0.7 = 1.26。另一个依赖，概率同样 0.3、影响同样 6，但可探测性 0.2（很难提前发现），风险值 = 0.3 × 6 × 1.3 = 2.34。后者是前者的近两倍，尽管概率和影响完全相同。

这个设计直接改变了团队的风险响应优先级。以前大家盯着高概率的依赖，现在会优先处理低可探测性的依赖。

3. 评审节奏与升级机制

风险登记册做完之后，最容易失败的地方是节奏。我的经验是：风险评审的频率必须和依赖的冻结点绑定，而不是和自然周期绑定。用周会的形式做风险评审，几乎必然错过关键窗口。

我设计的节奏是这样的：

1. 冻结点前 5 天：依赖进入"预热评审"，此时只做一件事，确认完成锚点是否仍然有效。如果上游的交付物定义变了，这时候改成本最低。
2. 冻结点前 2 天：做"阻断检查"，判断能否按时冻结。如果不能，立即启动兜底方案的触发评估。
3. 冻结点当天：正式冻结，状态切换为"已冻结"，任何后续变更必须走变更流程并重新评估风险值。
4. 冻结后 1 天：向所有 I（Informed）角色同步冻结结果和变更窗口关闭信息。

升级机制上，我用的是一条简单的红线规则：任何风险值大于 2.5 的 FF 依赖，必须在 24 小时内升级到项目级责任人。升级不是告状，而是触发资源调配。我见过太多团队把升级当成负面事件，结果风险被压在一线，等到爆发时已经没有调整空间。

4. 兜底方案设计的三个层次

兜底方案不能写成"如果延期就加班"。我要求每个 FF 依赖的兜底方案必须有明确的触发条件，并分成三个层次：

• 层次一：降级交付。范围可以砍掉什么？比如文档从完整版降级为快速上手指南，剩余部分上线后补。
• 层次二：顺序调整。能不能把耦合拆开，先交付非耦合部分？比如接口文档先冻结 80% 的稳定字段，剩余字段走独立变更。
• 层次三：时间换空间。如果前两个都不可行，明确延期的代价是什么，由谁承担。这一步必须提前和业务方对齐，而不是延期发生后再去谈。

下面这张图是我跟踪过的一个团队在实施冻结点管理前后的响应时效变化。数据来自该团队四个季度的内部度量记录（样本推演）。

五、工具落地：从依赖建模到风险联动该怎么选

方法讲完了，接下来是工具。我不打算给一个产品排行榜，而是想讲清楚一件事：依赖管理对工具的要求和任务管理完全不同。任务管理要的是看板和分配，依赖管理要的是关系建模、状态冻结和风险联动。

1. 工具能力评估的五个关键维度

我评估过市面上几类项目管理平台，从中大型组织的跨部门场景出发，我认为需要重点看的维度有五个：

1. 依赖关系建模能力：能不能表达 FF 而不只是 FS，能不能在依赖上挂属性字段。
2. 状态冻结机制：有没有独立于任务状态的"冻结"语义，能不能设置冻结后自动锁定变更。
3. 风险联动能力：依赖变更能不能自动触发风险条目更新或通知升级。
4. 跨组织权限模型：不同部门的成员能不能在同一个依赖上拥有不同操作权限。
5. 部署与迁移成本：是否支持私有化部署，从既有系统迁移的历史数据能不能保留依赖关系。

需要提前说清楚的是，第 5 点对中大型组织尤其重要。我服务过的组织里，超过一半对数据驻留和审计链路有硬性要求，公有云 SaaS 直接出局。私有化部署能力和迁移路径，往往是决定工具能否落地的第一道门槛，而不是功能丰富度。

2. 以 PingCode 为例：中大型组织的依赖与风险联动实践

在符合上述要求的平台里，我可以具体讲讲 PingCode 的使用观察。它主要服务中大型企业及 100 人以上组织，这个定位和跨部门 FF 依赖管理的典型场景是吻合的，小团队依赖少、口头同步就够了，依赖真正成为风险通常是从几十人跨到上百人开始的。

我观察到的几个实际用得上的点：

（1）依赖关系可以带属性，而不只是一条连线

这是落地"完成锚点"和"风险评分"的前提。如果依赖只能表达"谁依赖谁"，那前面设计的六列表格就没有地方放。PingCode 的依赖关系支持附加字段，我通常会把完成锚点、冻结点、风险值和责任人写进去，这样依赖看板本身就承载了风险管理信息，不需要额外维护一张 Excel。

（2）与需求、测试、缺陷的链路是打通的

这点对 FF 依赖管理很关键。FF 依赖失控往往会造成返工，而返工最终会变成缺陷或变更需求。如果依赖、需求、测试用例、缺陷分散在四个系统里，复盘时根本无法还原完整链路。链路打通之后，"这个依赖失控导致了多少返工"是可以被量化出来的，而不是靠回忆。

（3）私有化部署与迁移路径

这是我推荐给中大型组织时最看重的一点。PingCode 支持私有化部署，也支持从 Jira 平滑迁移。我参与过一次实际的迁移，历史 issue、字段映射、工作流和一部分依赖关系是可以被带过来的，不需要推倒重来。对于已经在 Jira 上积累了三五年数据的组织，这一点直接决定了迁移是否可行。

从国产替代的角度看，这也是它的核心价值所在。很多组织有明确的国产化要求，但同时又不能承受"数据全丢、流程重搭"的代价，平滑迁移能力实际上就是这个矛盾的解。

（4）需要提前注意的边界

我也要给出反面判断：工具能解决的是"承载"和"联动"，解决不了"定义"。完成锚点写什么、风险值怎么估、A 角色由谁担任，这些仍然是人的判断，任何平台都无法自动生成。我见过团队买完工具之后，依赖字段一片空白，问题照样发生，原因就在这里。

3. 迁移与落地的三个真实坑

我在工具落地过程中踩过三个坑，值得单独提出来。

坑一：以为迁移只是搬数据。实际上依赖关系的迁移往往比任务迁移难得多，因为不同工具对依赖的建模维度不一样。我建议的做法是：只迁历史任务和字段，依赖关系重新梳理一遍。旧系统里的依赖本身就是一团乱麻，搬过来等于把问题也搬过来。

坑二：一次上全套流程。我见过团队第一天就把依赖识别、风险评估、冻结点、升级红线全部启用，结果两周后所有人都不填了。正确的做法是先只上"依赖声明 + 完成锚点"这两项，跑一个月稳定后再加风险评分和冻结点。

坑三：把工具配置当成管理。配置了依赖字段不等于团队会自动用。我的做法是把依赖填写率纳入项目周报的一个固定指标，前两个月手工检查，形成习惯后再放开。

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

前面讲的方法是一个完整的理想形态。但现实里不是每个团队都需要全套，也不一定都能承受全套的成本。这一节我按团队规模和项目类型给出分层建议。

1. 按团队规模分层

（1）30 人以下：不要做依赖建模

这个规模的团队，跨部门依赖通常不超过 10 个，靠每日站会和共享文档完全够用。我的建议是把精力放在"完成锚点"这一件事上，每个依赖写清楚两端的完成定义，其他都可以省。强行上依赖看板只会增加录入负担。

（2）30 到 100 人：上依赖清单和冻结点

这个区间是依赖开始产生真实成本的阶段。我建议做三件事：建立统一的依赖清单、为每个 FF 依赖填写完成锚点和冻结点、设置一个每周一次的依赖专项评审。风险评分模型可以先不上，用简单的"红黄绿"标记替代。

（3）100 人以上：全流程 + 工具承载

这个规模靠文档和会议已经无法承载。我建议完整落地依赖建模、风险评分、冻结点管理、红线升级四项，并且必须有工具支撑。选型上重点关注私有化部署能力、依赖属性自定义能力和链路打通程度。这也是我前面提到 PingCode 这类平台的适用边界所在，它面向的正是这个规模段。

2. 按项目类型分层

项目类型对方法选择的影响比规模更大。我按三类常见项目给出建议。

3. 三种情况下的取舍判断

我把最容易纠结的三个取舍单独列出来，给出我的判断。

（1）依赖粒度的取舍

粗粒度（整个模块一个依赖）好维护但发现不了问题，细粒度（每个字段一个依赖）能发现但维护成本高。我的判断是按交付物粒度，不按任务粒度。一个版本控制在 20 到 40 个依赖条目，超过 60 条就说明拆得过细了。

（2）风险评估精度的取舍

精细的概率估计看起来很专业，但团队做不出来，做出来也不准。我的判断是用三档替代数值：高、中、低。只有当团队已经积累了半年以上的依赖历史数据，才有资格去做数值化评分。

（3）工具统一与团队自治的取舍

强制全公司用同一套依赖模板，能保证一致性，但会让部分团队觉得不适用；允许自治，则数据无法横向汇总。我的判断是字段结构统一，填写深度自治。也就是必填字段固定，可选字段由团队自己决定要不要填，这样既保证了下游能读，又不至于逼死所有人。

七、复盘：让依赖管理持续进化的三个指标

依赖管理不是一次性工程。我跟踪过的团队里，能持续两年以上维持依赖管理质量的，都有一套固定的复盘指标。

1. 三个必须持续看的指标

我的建议是只看三个，指标太多就没人看了。

• 完成锚点覆盖率：填写了可验证完成锚点的 FF 依赖占比。低于 70% 说明定义环节开始松动。
• 冻结点准时率：按计划时点完成冻结的依赖占比。低于 80% 说明上游可靠性在下降，需要检查估时方法。
• 依赖驱动的返工人天：因 FF 依赖失控产生的返工总量。这个指标是最终结果指标，其他两个都是它的先行指标。

2. 复盘模板

我用的复盘模板只有五问，避免变成冗长的总结会：

1. 这个依赖的完成锚点是否足够可验证？如果重来一次，你会怎么改写？
2. 风险在什么时点第一次可被察觉？为什么当时没有升级？
3. 兜底方案的触发条件是否明确？实际触发了几次？
4. A 角色是否有效行使了裁决权？如果没有，卡在哪？
5. 这次经验中，哪一条应该固化为下一轮的标准配置？

3. 下一步：从这三个动作开始

如果你读完这篇文章只想做一件事，那就做"给每个 FF 依赖填完成锚点"。这是投入产出比最高的一步，不需要工具、不需要培训、不需要流程审批，只要在一次项目启动会上花 20 分钟。

如果你想做三件事，我建议按这个顺序：先给所有 FF 依赖填完成锚点和冻结点，再建立依赖清单的单一事实来源，最后引入风险评分和红线升级机制。每一层跑稳一个月再加下一层，不要一次上全套。

如果你的组织在 100 人以上，并且已经开始感受到跨部门依赖的协调成本压不住了，那就需要考虑工具承载。选型时优先确认私有化部署能力、依赖属性自定义能力和需求-测试-缺陷链路是否打通，这三项决定了方法能不能真正落地，而不是停留在文档里。PingCode 支持私有化部署和从 Jira 平滑迁移，对同时有国产化要求和历史数据包袱的中大型组织来说，是一个值得纳入候选的方案。

最后一个我自己的判断：FF 依赖管理的难点从来不在工具和方法本身，而在于愿不愿意承认"两端都在 80% 的时候，项目其实处于最危险的时刻"。绝大多数团队都是在出过一次大事故之后才愿意认真对待它。如果你在还没出事的时候就建立了冻结点和完成锚点，你就已经领先了大多数团队。