FS管理方法大全：实施团队任务依赖落地方案落地清单

我带过一支 80 人的实施交付团队，印象最深的一次延期，根因不在代码，而在文档与计划之间那条缝：功能规格说明书（FS）里白纸黑字写着“单点登录需对接客户方既有 IAM 平台”，项目计划里却只有一个笼统的“集成开发”节点。没人把它翻译成“等客户 IAM 接口开放后才能开工”。UAT 前一周，客户 IT 说排期要等到下个月，整条链路停摆 11 天。复盘时我们发现，规格没漏、评审也过了，漏的是把规格变成依赖这一个动作。

所以这篇《FS管理方法大全：实施团队任务依赖落地方案落地清单》，我不打算再给你一份“五种方法、十大原则”的清单式作文。我打算把 FS 管理拆到能直接动手的粒度：哪些依赖必须登记、谁来登记、什么频率扫、什么阶段可以省、什么阶段绝对不能省，以及工具在其中到底能承担多少、不能承担多少。

一、核心结论：FS 管理的成败，不在文档写得多好，而在依赖挂得够不够准

先给判断，再讲理由。FS 管理真正难的不是把功能规格写完整，而是把功能规格里的每一条约束，翻译成任务计划里可追踪、可预警、可追责的依赖关系。前一件事是文档能力，后一件事才是管理能力。我见过太多团队文档质量不差，评审通过率 90% 以上，但计划里的依赖关系几乎是空的。

这里必须先把“FS”说清楚，因为它在交付一线至少有两个高频含义。第一个是 Functional Specification，功能规格说明书，也就是需求方与实施方之间那份“系统到底要做成什么样”的约定。第二个是 Finish-to-Start，完成-开始依赖，是项目计划四种任务依赖关系里使用频率最高的一种前置约束。

而这两件事在实施团队里恰好是同一件事的两端：功能规格（FS）是依赖（FS）的来源，完成-开始依赖（FS）是功能规格落地的最小单位。规格里写“订单审核通过后才能触发发货”，翻译成计划就是一条 FS 依赖。规格里写“需与客户财务系统对账”，翻译成计划还是一条 FS 依赖，只不过上游在客户那边。整篇方法论的逻辑，就建立在这个双关之上。

基于这个判断，我给出四条可以直接拿去用的结论。

1. 结论一：依赖不是计划的附属品，而是 FS 文档的落地形态。一份写完就归档的功能规格，等于没写；一份能自动长出依赖条目的功能规格，才算真正被消费了。
2. 结论二：依赖失控的主因是“识别缺失”，不是“跟踪不力”。多数团队的看板跟踪做得挺勤，但登记进看板的依赖本来就只有真实依赖的一半。
3. 结论三：清单比方法重要。团队缺的从来不是“知道什么叫依赖管理”，而是“每周三下午十五分钟该干哪六件事”。
4. 结论四：工具只能放大流程，不能替代流程。流程没定清楚就上工具，只会把混乱从 Excel 搬到系统里，并且更难改回来。

这四条结论背后，是我对 37 个实施项目的延期复盘数据。我把“导致里程碑顺延的根因”做了归类，结果比预想的更集中：依赖类问题占了将近六成。注意，这里统计的是根因，不是表面现象，表面现象永远是“开发没做完”。

二、背景与真实场景：三个我亲历的依赖翻车现场

抽象地讲依赖管理，谁都会点头。所以我更愿意把三个真实场景摊开讲，你可以对照自己的项目看有没有中招。

1. 场景 A：规格里有、计划里没有

这是出现频率最高的一类。功能规格评审时，业务顾问写得很到位：“发票开具需在订单状态流转为‘已发货’之后触发。”评审会上所有人点头。但到了计划环节，任务被拆成“发票模块开发”“订单状态机改造”两条并行任务，谁也没建依赖。

结果是订单状态机改造晚了三天，发票模块的联调测试全部作废重跑。问题不在于谁不负责，而在于规格评审和计划拆解是两个不同角色、不同时间、不同交付物的动作，中间没有任何强制衔接机制。

2. 场景 B：依赖识别对了，但对错了人

某次跨团队集成，实施组成员在台账里登记了一条依赖：上游是“平台组提供鉴权 SDK”，责任人写的是“平台组”。看起来很清晰，实际上平台组有四个小组，真正负责 SDK 的是其中一个，而他们并不知道自己被挂成了上游。

这条依赖在台账里躺了九天，状态一直是“进行中”。依赖的责任人必须精确到人，不能精确到部门。“平台组”不是责任人，是责任池。

3. 场景 C：外部依赖没有留提前量

客户方的接口开放、第三方厂商的硬件到货、客户 IT 的安全评审，这三类外部依赖的共同特征是：你无法推动，只能等待，而且它们的排期通常以后者自己的节奏为准。我见过最可惜的一次，内部全部按计划完成，只差客户安全评审一周的窗口，整个上线窗口从财年末挪到了下一季度。

把这三个场景的代价量化一下会更直观。我统计过同一个根因（一条接口依赖未登记）在不同环节被发现的成本差异，结论是：越早发现越便宜，而且便宜得不是线性关系。

三、常见误区：五个把 FS 管理做成形式主义的坑

依赖治理做不下去的团队，通常不是没开始，而是开始的方式错了。我总结出五个反复出现的误区，每一个都能在三个月内把治理热情消耗干净。

1. 误区一：把 FS 当成“写完即完成”的交付物

很多团队的 FS 文档有完整的版本号、评审记录、签收单，然后就进了知识库，此后再也没被打开过。判断标准很简单：如果一份功能规格从评审通过到项目结束都没有产生过任何任务或依赖条目，它就是一份合规但无效的文档。

2. 误区二：只做依赖识别，不做依赖排序

把依赖登记齐了，然后呢？我见过一份 200 多条的依赖台账，密密麻麻，但没有任何优先级标记。项目经理每周看一遍，看了一个月，最后放弃了。原因是：无法排序的清单等于没有清单。依赖必须按“影响里程碑的程度”和“阻塞时长”两个维度排出高低。

3. 误区三：把所有依赖都当成硬依赖

这是另一个极端。有些团队为了安全，把所有相关性都标成强依赖，结果整个计划变成一条串行长链，任何一环延误都会整体顺延，反而失去了并行压缩工期的空间。依赖分级不是为了严谨，是为了保留并行度。

4. 误区四：用周会替代依赖台账

“我们每周都过进度，有依赖当场就说了。”这句话我在至少二十个项目里听过。问题是：口头同步的依赖没有状态、没有责任人、没有关闭条件，下一次会议时所有人的记忆都已经刷新过了。周会是依赖的发现机制，不是依赖的存储机制。

5. 误区五：指望工具自动解决依赖

工具能做的是可视化、提醒和留痕，它做不了的是判断“这条算不算真依赖”“这个责任人对不对”。我见过团队把工具里的依赖关系图画得非常漂亮，但四十条依赖里有十一条的上游其实已经完成了，只是没人更新状态。工具放大流程，也放大流程的漏洞。

这五个误区的共同点，是它们都能带来短期观感上的改善。这正是它们难以被察觉的原因，代价是延后三个月才出现的。

四、专业判断逻辑：依赖分型、强度分级与三对齐原则

讲完误区，接下来是我实际在用的判断框架。它分三层：先分清类型，再评估强度，最后用三个对齐把依赖钉死在计划里。

1. 第一层判断：四种依赖类型，决定排期方式

既然本文的 FS 有两个含义，这里就先把 Finish-to-Start 这一层讲透。项目计划中的任务依赖一共有四种，实施团队用得最多的是前两种，但后两种一旦出现就极容易误判。

这张表我建议直接贴到项目启动会的投屏上。实施团队的依赖登记里，FS 应该占七成左右；如果 FS 占比超过九成，通常说明团队没有认真区分 SS 和 FF，把可并行的任务串行化了。

除了类型，依赖的来源也必须分开标注，因为它决定了推进手段完全不同。内部任务依赖靠排期解决，跨团队依赖靠协商解决，外部供应商依赖靠合同和提前量解决，客户方依赖靠干系人管理和书面确认解决。把这四类混在一张表里，用同一种方式推进，是很多台账失效的真实原因。

2. 第二层判断：依赖强度分级，决定管控成本

不是所有依赖都值得进台账。我的做法是分三档：

• 硬依赖：不满足就无法开工或无法交付，且无法用加班、返工、替代方案绕过。必须进台账，必须有提前量，必须每周扫描。
• 软依赖：顺序上建议遵守，但可以通过调整方案绕过（例如先用桩数据顶替）。登记但不必每周扫描，按里程碑节点检查即可。
• 资源依赖：不卡顺序，卡的是同一个人或同一套环境。这类依赖最容易在台账里被忽略，却经常是实际阻塞的来源。

分级的价值在于让团队的注意力集中在真正会卡住的依赖上。我做过一次统计，一个 40 人规模的项目，登记进台账的依赖里真正的硬依赖通常只占三到四成。如果全部按硬依赖管控，等于给团队增加了两倍无效会议成本。

3. 第三层判断：三对齐原则，把依赖钉死在计划里

一条依赖被登记但没落地，通常是三个对齐里缺了至少一个：

• 里程碑对齐：这条依赖影响哪个里程碑？如果影响不了任何里程碑，它的优先级就该往下调。
• 交付物对齐：上游到底交付什么？是“接口文档”还是“可调用的接口环境”？这两个东西相差一周甚至一个月。
• 责任人对齐：上游责任人是谁、下游责任人是谁，必须是两个具体的名字，不能是部门名或角色名。

我在一个 120 人的实施团队做过前后对比：三对齐执行之前，依赖的平均闭环率是 61%；执行之后的第三个月，闭环率稳定在 94%。差距不在于团队更努力了，在于每条依赖都有了明确的关闭条件。

五、案例与数据观察：一个 120 人实施团队的 90 天依赖治理

接下来讲一个我实际参与的改造。团队规模 120 人，主要做行业软件的驻场实施，年交付项目 40 多个，改造前的平均里程碑延期率是 19%，也就是说每五个里程碑就有一个顺延。

1. 改造前的诊断：问题是断链，不是态度

我们花了两周做诊断，方法很土：随机抽 10 份已完成的功能规格，把里面所有隐含的依赖关系人工标出来，再对照当时的项目计划看登记了几条。结果是：规格里平均隐含 23 条依赖，计划里平均登记 9 条，覆盖率不到四成。

更值得注意的是，登记的那 9 条里，有 3 条的负责人写的是部门名。也就是说，覆盖率 39%，责任人明确率 67%，两者叠加后真正可管控的依赖不到三成。这个数字比任何人的主观感受都更有说服力。

2. 改造三步：打标、台账、扫描

第一步是给功能规格“打标”。我们不重写规格模板，只在每条功能描述后面加一个必填的依赖字段，格式是固定的，写不出依赖就写“无依赖”，但必须显式填写。这个动作的妙处在于：把“想不起来”变成“必须做决定”。第一个月就暴露出大量原本会被漏掉的依赖。

第二步是台账化。我们在 PingCode 里建立依赖登记工作项类型，把上游任务、下游任务、依赖类型、强度、责任人、提前量、影响里程碑这些字段固定下来。选它的直接原因是它能和已有的需求、任务、缺陷数据打通，依赖不用手工维护两份；另外它支持私有化部署，这一点对服务金融、能源类客户的项目很关键，客户现场不允许数据出内网。团队当时还有两百多个在跑的 Jira 项目，也是靠 PingCode 的平滑迁移能力一次性搬过来的，没有出现历史数据断档。

第三步是每周十五分钟的依赖扫描会。规则很硬：只讲状态为“阻塞”和“即将到期”的硬依赖，每条不超过一分钟，讲完必须给出下一步动作和责任人。三条硬规则：不讨论技术方案、不解释历史原因、不评价他人。这三条把会议时长从原来的平均 52 分钟压到了 15 分钟以内。

# 依赖台账最小结构（YAML 示例，字段即工作项自定义字段）
dependency:

id: DEP-2026-0317

type: FS # FS 完成-开始 / SS 开始-开始 / FF 完成-完成 / SF 开始-完成

strength: hard # hard 硬依赖 / soft 软依赖 / resource 资源依赖

source: customer # internal 内部 / cross-team 跨团队 / external 外部厂商 / customer 客户方

upstream:

task: "客户 IAM 平台开放测试接口"

owner: "客户 IT 张工" # 必须到人，禁止填写部门名

due: 2026-04-08

downstream:

task: "单点登录联调与回归测试"

owner: "实施组 李工"

milestone: "M3-集成测试通过"

lead_time_days: 5 # 提前量：下游开工前必须完成的天数缓冲

status: blocked # open / blocked / closed

close_condition: "联调用例全部通过且客户签字确认"

注意最后那个 close_condition 字段。它是我在这套改造里加的最有用的一个字段，没有关闭条件的依赖，永远不会被关闭。它会一直挂在“进行中”，占据团队注意力，直到所有人对它免疫。

3. 90 天后的数据

三个月后，几个核心指标的变化是可以被量化的。需要说明的是，这些数据来自该团队内部的项目管理数据统计口径，属于单一组织样本，不一定适用于所有团队，但趋势值得参考。

• 功能规格依赖覆盖率：从 39% 提升到 88%
• 依赖责任明确到人的比例：从 67% 提升到 100%
• 依赖平均闭环时长：从 6.5 天缩短到 1.4 天
• 里程碑平均延期天数：从 23 天降到 7 天
• 跨团队阻塞人均耗时：从每周 4.2 小时降到 1.1 小时

也要说失败的部分。前 30 天基本是失败的，我们犯的错是只做了工具映射，没有做流程约定，把依赖关系画进了系统，但没人规定谁在什么时间更新状态。结果第一周的依赖台账在第二周就出现了四分之一的陈旧数据。后来补上“每周扫描会前必须刷新状态”这条硬规定，数据才活过来。先定流程，再上工具，这个顺序反了就要付两次成本。

六、分阶段落地清单：从启动到复盘的四组可勾选动作

下面这份清单是我在多个项目里反复删改后的版本。它的设计原则是：每一项都能被判定完成或未完成，不写“加强”“优化”这类无法验证的动作。你可以直接复制到文档里用，也可以按后文的裁剪建议做减法。

1. 启动阶段：依赖识别清单（8 项）

• □ 功能规格中每条功能描述后附依赖字段，无依赖需显式填写“无依赖”
• □ 规格评审会的输出物中明确包含一份依赖初稿，而非只有评审意见
• □ 已按内部、跨团队、外部厂商、客户方四类来源对依赖做来源标注
• □ 已按 FS / SS / FF / SF 四类对依赖做类型标注
• □ 已识别所有 FF 和 SF 类型依赖（这两类必须强制扫描，不能靠经验）
• □ 每条依赖的上游交付物已明确到可验证的粒度（如“可调用的测试环境”而非“接口支持”）
• □ 每条依赖的影响里程碑已填写，且能对应到具体的验收节点
• □ 外部依赖和客户方依赖已单独拉出，列入干系人沟通计划

2. 规划阶段：排序与提前量清单（7 项）

• □ 已按“影响里程碑程度 × 阻塞时长”对硬依赖排序，并标出前 20% 的关键依赖
• □ 每条硬依赖已设定提前量（建议不少于 3 个工作日，外部依赖不少于 10 个工作日）
• □ 已检查是否存在可并行的 SS 依赖被误判为 FS，导致串行链过长
• □ 已评估每条硬依赖是否存在替代方案（桩数据、降级方案、临时接口）
• □ 资源依赖（同一人或同一环境的争用）已单独列出并与任务排期交叉核对
• □ 关键依赖的上游责任人已逐一确认，且对方已知晓自己被挂为上游
• □ 已确定依赖台账的更新频率与更新责任人（通常为项目计划负责人）

3. 执行阶段：跟踪与预警清单（8 项）

• □ 每周固定时间进行依赖扫描，时长控制在 15 分钟以内
• □ 扫描会只讨论状态为“阻塞”和“未来 7 天内到期”的硬依赖
• □ 每条依赖的状态在扫描会前已由责任人自行刷新，陈旧数据比例低于 10%
• □ 阻塞超过 3 个工作日的依赖已升级至项目经理或项目指导委员会
• □ 依赖状态变更后，下游任务的排期已同步刷新（不是只改状态）
• □ 上游任务的变更已触发依赖关系的重新评估，而非仅通知下游
• □ 客户方和外部厂商依赖已按周与对方确认一次，并留存书面记录
• □ 新产生的依赖在产生当日即登记入台账，不积压到周会

4. 复盘阶段：沉淀清单（6 项）

• □ 已统计本期依赖覆盖率（规格隐含依赖 vs 台账登记依赖）
• □ 已统计依赖平均闭环时长与陈旧数据比例，并与上期对比
• □ 已归因为“依赖未识别”导致的延期，并定位到具体环节（评审、拆解还是登记）
• □ 已把本期高频的依赖类型沉淀为规格模板中的预设提示项
• □ 已将本期出现的 FF、SF 类依赖整理为检查清单，供下个项目强制扫描
• □ 已将依赖相关的失败案例写入项目复盘文档，并指定下期改进责任人

四组清单合计 29 项。我建议第一次落地时不要全上，因为一次性推到 29 项的团队，三个月后能坚持的通常不到 8 项。后面第七节会给出按规模裁剪的建议。

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

同一套清单不可能适配所有团队。下面是我按三种维度给出的具体建议，你可以直接对号入座。

1. 按团队规模：三种落地路径

20 人以下的小团队，不要上工具，也不要建台账系统。用一份共享表格即可，字段只保留四列：依赖内容、上游责任人、下游责任人、影响里程碑。每周站会顺手过一遍，控制在 5 分钟内。这个阶段的核心目标不是治理精细度，是养成“有依赖就说出来”的习惯。

20 到 100 人的团队，需要流程加轻量工具。关键动作是把依赖变成一个有状态的对象，而不是一段文字。这个阶段最容易出问题的地方是跨组依赖，组内靠沟通能解决，跨组就必须有台账，因为跨组的信任成本远高于组内。

100 人以上的组织，就需要平台化支撑了。原因有三：依赖数量级上升导致人工维护失效；跨部门的权限和数据隔离必须由系统保证；管理层需要看到组织级的依赖风险视图而非项目级明细。这个规模段的团队，通常会选择像 PingCode 这类面向中大型企业、支持组织级权限与私有化部署的项目管理平台。私有化部署这一项在金融、能源、政企类实施项目里往往是硬门槛，客户的现场环境不允许数据出内网。

另外这类组织普遍存在历史工具迁移问题，团队如果原来用 Jira 管理需求，迁移过程能否保持需求与任务的关联链路不断档，会直接影响依赖数据的完整性，这也是选择平台时容易被忽略但很关键的评估点。

2. 按项目类型：三种侧重点

标准产品实施类项目，依赖主要集中在客户方环境准备、数据迁移和历史数据清洗上。这三类依赖的共同特点是外部性强、可控性低。建议把清单重点放在启动阶段的来源标注和规划阶段的提前量设定上，执行阶段的扫描频率可以适当降低，改为按关键节点检查。

定制开发类项目，依赖主要集中在内部模块之间和技术方案确认上，可控性高，但数量多。建议把重心放在规划阶段的类型标注和内部依赖排序上，特别是要小心把 SS 误判为 FS 造成的串行化。

多供应商集成类项目，依赖的复杂度最高，因为没有一方能完全推动另一方。这类项目的核心动作是：把所有跨供应商依赖写成书面确认件，明确交付物、时间和验收标准，并设定明确的违约触发条件。台账在这里的作用已经从管理工具变成了协调依据。

3. 按交付模式：驻场与远程的差异

驻场交付的团队有一个天然优势：依赖的发现成本极低，当面问一句就知道。但优势也带来隐患，口头同步的依赖最容易被漏登记，因为大家默认“都说过了”。建议驻场团队把登记动作绑定到每日站会的固定环节里。

远程交付的团队正好相反，依赖的发现成本高，但登记习惯通常更好。这类团队要重点防的是另外一件事：状态陈旧。因为看不到对方在做什么，依赖状态更新一滞后，下游的排期判断就会失真。建议远程团队把状态刷新设为每日动作，而不是每周。

八、不同情况下的取舍

清单给完之后，还有一些无法回避的取舍。这些取舍没有标准答案，但有判断依据。

1. 文档粒度 vs 维护成本

依赖字段填得越细，管控能力越强，但维护成本也越高。我的经验阈值是：当一条依赖的维护时间超过它平均能节省的阻塞时间的十分之一时，这个字段就该砍掉。按这个标准，绝大多数团队其实只需要八个字段：编号、类型、强度、来源、上游任务与责任人、下游任务与责任人、影响里程碑、关闭条件。

2. 工具先行 vs 流程先行

前面那个 120 人团队的教训已经说明了：流程先行，工具跟上。但还有一层更细的取舍，如果组织已经有一个在用的项目管理平台，不要为了依赖治理引入第二套系统。双系统带来的第一代价不是成本，是数据不一致，而依赖数据一旦不一致，整个台账的可信度就归零了。这也是为什么我倾向于在现有平台上扩字段，而不是新建工具。

3. 全量登记 vs 只登记关键依赖

理论上全量登记更严谨，实践上通常更难维持。我的建议是按阶段区分：启动阶段全量识别，规划阶段开始分级筛选，执行阶段只跟踪硬依赖和资源依赖。登记全量、跟踪关键，这两件事可以同时成立。反过来，登记少量、跟踪全部，是不成立的。

4. 强管控 vs 自组织

强管控的典型特征是：依赖升级机制明确、超期自动上报、管理层可见。它的适用条件是项目对交付时间高度敏感，且团队对依赖的敏感度尚未形成。自组织的典型特征是：依赖靠团队自觉维护，只在必要时升级。它适用于成熟团队和长周期项目。多数实施团队的现实选择是分阶段：项目前期强管控，稳定运行后逐步放开。

5. 自建 vs 采购（含国产替代场景）

在服务金融、能源、大型制造类客户的实施项目中，工具选型往往不是纯效率决策。客户对数据不出内网的要求，会把可选范围直接压缩到支持私有化部署的产品上。同时，如果组织正在做工具链的国产化替换，还需要评估迁移成本，特别是需求、任务、缺陷之间的历史关联链路能否完整保留，因为依赖治理恰恰建立在这些关联之上。这个维度上，面向中大型企业的 PingCode 支持私有化部署并且提供 Jira 平滑迁移路径，是这类场景里被较多组织纳入评估范围的选项之一。

但需要明确的是：工具选型解决的是承载能力问题，解决不了流程缺失问题。流程没定，换哪个平台都是一样的结果。

6. 谁来当依赖的 Owner

最后一个取舍，也是最难的一个：依赖到底谁负责。常见做法是让项目经理统管全部依赖，但这在实践中会迅速失控，因为项目经理无法对四十条技术依赖逐条判断真实进展。

我的建议是采用双责任人制：上游责任人负责“按约定交付”，下游责任人负责“验证并关闭”，项目经理只负责升级裁决和节奏把控。这样依赖的日常推进不依赖项目经理的个人精力，团队规模扩大时也不会成为瓶颈。

九、总结：一份清单解决不了所有问题，但能解决从 0 到 1

回到开头那个问题：FS 管理到底管的是什么。我的结论很明确，管的是功能规格到任务依赖之间那段没人负责的路。这段路不长，但它是实施团队延期的高发地带，因为规格评审的人不管计划，排计划的人不读规格，两边都以为对方会处理。

这也解释了为什么市面上那么多“方法大全”读起来都对、用起来无效：它们讲的是方法，而真正缺失的是一个把方法钉进每周节奏的机制。方法的边际收益是递减的，节奏的边际收益是持续的。

还有三个我在实践中形成的、可能和主流说法不太一致的判断，作为这篇的收尾。

• 第一，依赖覆盖率比依赖闭环率更重要。闭环率低只是效率问题，覆盖率低是盲区问题。盲区不会出现在报表里，只会在里程碑当天出现。
• 第二，台账应该越做越薄，而不是越做越厚。如果一个团队的依赖条目三个月内从 100 条涨到 300 条，通常不是治理见效了，而是分级筛选失效了。
• 第三，工具的价值上限由流程决定，不是你付了多少钱决定的。同一个平台，流程清晰的团队用它把延期率从 19% 降到 7%，流程缺失的团队用它把混乱从表格搬进了系统，仅此而已。

如果你打算从明天开始动手，我建议的路径是这样的：第一周，抽三份已完成的功能规格，人工标出所有隐含依赖，对比当时的计划登记数量，算出你团队的真实覆盖率；第二周，把依赖字段加入规格模板，设为必填，同时确定台账的八个最小字段；第三周，开始每周十五分钟的依赖扫描会，规则从第一天就定死；第四周，统计陈旧数据比例，如果高于 15%，不要急着加字段，先去解决更新责任落实的问题。

三十天之后，你会拿到一组属于自己团队的数字。那组数字比任何一篇方法大全都更有说服力，因为它说明的是你团队真实存在的问题，而不是别人团队可能的做法。