任务分派如何做好转交？项目负责人协同管理与操作步骤

去年冬天，我以外部顾问身份介入过一家 320 人智能硬件公司的转交事故复盘。起因很普通：一位负责电池管理模块的资深工程师在迭代中期离职，手上有 17 个工作项需要转交。项目经理用一个下午开了 40 分钟交接会，把工作项逐个指派给两位同事。11 天后，测试团队发现新版固件的充电阈值判定逻辑与原始需求不一致，返工加上重新验证，累计消耗 46 人天。

复盘会上最有意思的结论不是"信息没传到位"。文档在、需求链接在、历史邮件也在。真正缺的是：没有任何一份记录说明，接收方在什么条件下可以自行修改验收口径，以及出现需求冲突时谁有权做最终裁决。任务被搬走了，责任没有被重新锚定，这才是绝大多数转交失败的根因。

一、先说结论：任务转交的本质是"责任契约重签"，不是"工作项复制"

我做过一个不太严谨但很有说服力的内部统计：在我参与复盘的 34 次转交出问题事件里，只有 7 次是纯粹的"信息缺失"（文档没写、链接没给、代码找不到）。剩下 27 次，信息其实都在，问题出在责任边界、决策权限和验收口径没有随任务一起转移。

所以我对"转交做得好不好"的判断标准，从来不是"交接会开没开、文档写没写"，而是三个可以量化、可以被工具记录的指标。

1. 三个可量化指标，定义转交是否真的完成

• 接收方确认率：接收方是否在明确的时间窗内（我一般要求 48 小时）对"我理解的任务范围、验收标准、决策边界"做出显式确认，而不是沉默接收。
• 首次独立交付时间：接收方第一次不依赖原负责人、独立完成一个可交付成果的耗时。这个数字如果超过转交前的 1.5 倍，说明上下文转移不充分。
• 转交引发的返工工时：因口径不一致、边界不清、依赖漏判导致的返工。这是最贵的指标，也是最容易被忽视的指标。

这三个指标里，接收方确认率是先行指标，返工工时是滞后指标。前者可以在 48 小时内看到，后者往往要两三周才暴露。管理者的常见错误是只盯滞后指标，等返工发生了才追责，那时成本已经付出去了。

2. 决定转交质量的是责任边界，而不是信息完整度

很多人以为转交的核心工作是"把我知道的都告诉对方"。我不同意。信息完整度是必要条件，但不是充分条件。你可以写出 20 页交接文档，接收方也全部读完，但如果他不知道"遇到需求解释分歧时该找谁拍板"，他依然会在第一次冲突时卡住。

我把这个判断拆成一个简化模型：转交完成度 = 上下文转移度 × 验收标准清晰度 × 决策权限明确度。三个因子是相乘关系，任何一个接近零，整体就接近零。这解释了为什么"文档写得很全但转交依然失败"，因为第二个和第三个因子可能是零。

下面这张图是我在 34 次复盘样本里，对转交失败主因做的贡献度排序（样本来自我参与过的中大型研发组织复盘记录，属于经验样本，不构成行业统计）。

3. 可以直接套用的"四件套"最小结构

不管你用什么工具、开多长的会，一次合格的转交至少要覆盖四件事，我把它叫做"四件套"。缺任何一件，转交都不算闭环。

1. 上下文：任务为什么存在、当前的决策历史、已经否决过的方案。这一条防止接收方重复踩坑。
2. 验收标准：什么叫"做完了"，边界条件是什么，哪些指标必须达标。这一条防止口径漂移。
3. 决策权限：接收方在什么范围内可以自主决定，超出范围找谁，多久必须得到回应。
4. 退出机制：原负责人在什么时间点之后不再承担责任，在此之前以什么形式提供支持。

第四件最容易被忽略。很多转交事故的真实原因是"名义上转出去了，实际上原负责人还在被持续咨询"，结果两边都没真正接手。退出机制不是甩锅，而是把支持责任显性化、限时化。

二、背景与真实场景：为什么转交在中大型组织里越来越难

小团队里转交几乎不是问题。5 个人的团队，谁手上有什么、卡在哪里，大家心里都有数。但组织一旦超过 100 人，尤其是研发、测试、产品、运维多线并行的中大型企业，转交就从"沟通问题"变成了"流程问题"。

1. 五种典型转交场景及其复杂度

我把常见的转交场景分成五类。它们的复杂度差异很大，用同一套流程去处理，要么过重浪费，要么过轻出事。

• 人员离职型：时间紧迫、知识最集中、原负责人后续不可咨询。这是风险最高的一类。
• 组织调整型：批量转交，涉及多个团队边界，责任人和汇报线同时变化。
• 优先级切换型：人还在，但精力和考核目标转移，属于"半转交"，最容易被处理成口头通知。
• 跨部门/跨团队型：双方没有共同上级时需要额外约定升级路径，沟通成本最高。
• 外部供应商或外包型：涉及合同边界、知识产权、验收责任，往往还牵扯交付物质量标准。

2. 100 人以上组织特有的三个放大器

为什么规模一上去，转交难度会非线性上升？我观察到三个放大器在起作用。

第一个是隐性接口的爆炸。一个人的工作往往牵涉 6-12 个隐性接口人。10 个人的时候可能只有 30 条接口线，100 人的时候同样的组织结构可能产生上千条。转交时漏掉两三个接口人，几乎不可避免，除非有工具把关系链显性记录下来。

第二个是决策链的拉长。小团队里"这事我来定"，大组织里"这事得产品、架构、测试三方都点头"。转交如果不把决策链一并转移，接收方会在第一次需要拍板时陷入停滞。

第三个是人员流动的常态化。我服务过的几家中大型企业，研发年流动率在 15%-25% 区间是很常见的。这意味着转交不是偶发事件，而是每周都在发生的常规运营动作。既然是常规动作，就必须有标准流程和工具承载，而不能靠"这次大家辛苦一下"。

3. 一个被严重低估的成本：隐性知识转移成本

显性知识（需求文档、代码、设计稿）的转移成本是可估算的，通常占转交总成本的 30%-40%。真正贵的是隐性知识：为什么这个字段不能改、为什么这个接口有奇怪的延迟补偿、为什么某个方案被否决过三次。

我做过粗略测算：在一个迭代周期内转交一个中等复杂度模块（约 15-25 个工作项），显性知识转移大约需要 6-10 人时，隐性知识转移往往需要 18-30 人时，而且必须通过对话、结对、答疑逐步释放，无法靠文档一次性交付。

三、常见误区：我见过最多的五种错误做法

下面这五种做法，我在不同公司反复见到。它们的共同点是"看起来完成了转交"，但实际上把风险延后暴露了。

1. 误区一：把"通知"当成"转交"

最典型的形态是在群里发一句"这个任务后续由 X 跟进"，然后把工作项负责人改掉。发送者认为转交完成了，接收者可能连上下文都没理解。

判断标准很简单：如果接收方没有做出显式确认，转交就没有发生。沉默不是同意，沉默只是信息还没被处理。我要求所有转交必须有接收方的书面确认，哪怕只是一句"已理解，验收标准我确认为 A/B/C"。

2. 误区二：文档齐全就等于转交完成

这一类在流程规范度较高的团队里特别常见。交接文档写得非常规范，需求链接、设计稿、API 文档一应俱全，但整份文档里没有一句话说明"冲突时谁拍板"。

我见过一个极端案例：一家公司做了 42 页交接文档，接收方读完花了整整两天，结果第一个需要决策的问题就卡了 5 天，因为文档里写的是"如有疑问请联系相关方"，而"相关方"有 6 个人，没人知道该找谁。

3. 误区三：口头交接，事后补记录

口头交接本身不是问题，我甚至认为关键决策必须口头讲一遍。问题在于"事后补记录"这件事，补的时候总是缺东西。

我的经验是：口头沟通负责传递判断，书面记录负责固定结论。两者不能互相替代，也不能颠倒顺序。正确做法是会议中同步记录结论，会后 24 小时内发给双方确认，确认后的版本作为唯一依据。

4. 误区四：只转任务，不转关系和决策链

这一条在中大型组织里杀伤力最大。任务转过去了，但接收方不知道这件事依赖哪个团队、哪个接口人的排期、找谁协调资源、谁是真正的利益相关方。

我通常要求转交清单里包含一列"关键接口人"，写明姓名、角色、沟通频率和当前承诺。这一列的信息密度往往比任务描述本身更高。

5. 误区五：接收方没提问，就默认已经理解

这是最隐蔽的一个。会议开完，问"有没有问题"，没人说话，主持人就宣布散会。但"没有提问"和"已经理解"是两件事。

我习惯用一个反直觉的做法：要求接收方在 48 小时内提出至少 3 个问题。如果一个问题都提不出来，通常说明他还没真正读进去。这个要求听起来有点形式主义，但实际执行下来，能显著提高上下文转移的深度。

四、专业判断逻辑：什么时候该重，什么时候该轻

转交流程不是越重越好。过重的流程会让团队在每次人员变动时消耗大量管理成本，最后大家开始绕过流程走暗线，流程反而失效。关键判断是"这次该多重"。

1. 判断转交"重量"的三个信号

我用三个信号来做判断，任何一个命中，就升级到重流程。

• 信号一：任务半衰期小于 4 周。也就是说，这些任务在 4 周内就会发生实质性变化。半衰期短意味着接收方必须在很短时间内建立足够的上下文才能接住变化，必须走重流程。
• 信号二：存在跨团队硬依赖。只要任务被别的团队排期卡着，转交就必须包含依赖清单和对接人确认，否则一卡就是一周起步。
• 信号三：验收口径存在解释空间。凡是涉及"性能优化到用户无感知""体验更流畅"这类模糊表述的，必须重流程重新定义。可量化的任务可以轻处理。

2. 责任锚定模型：从 RACI 升级到"决策权 + 否决权 + 升级路径"

RACI 是经典工具，但我在实践中发现它对转交场景不够用。RACI 说明"谁负责、谁批准、咨询谁、通知谁"，但没有说明"谁在分歧时有最终裁决权"和"多久必须给出回应"。

我在转交场景里用的升级版是三个字段，直接写进工作项里：

这三个字段看起来简单，但它们把"责任"从抽象概念变成了可记录、可查询、可追责的结构化数据。这也是为什么我坚持转交必须落在工具里，而不是只存在会议纪要里。

3. 用"任务半衰期"决定转交流程的投入

半衰期是我借用的一个概念：任务从转交到发生实质性变化（需求调整、依赖变化、优先级变动）的平均时间。

半衰期越短，转交流程投入应该越高。原因很直观：如果任务转过去 3 周都不变，接收方有充足时间慢慢摸索；如果 5 天就变一次，他必须在第一天就建立起完整判断力，否则每次都只能被动响应。

五、案例与数据观察：一家 400 人企业用 PingCode 做转交闭环的 6 个月

前面讲的是判断框架，这一节讲一个我深度参与的真实改造过程。为保护客户信息，我把部分数字做了区间化处理，但趋势和结构是真实的。

1. 改造前的基线情况

这家企业做智能硬件，总人数约 400 人，其中研发体系约 260 人，分布在固件、云平台、App、测试四条线上。他们的转交有两个特点：一是频繁，平均每周有 4-7 次正式转交；二是复杂，一个固件工作项往往同时牵着云平台接口和 App 联调。

改造前的基线数据（基于他们内部的季度复盘，我参与了数据口径确认）：

• 接收方确认率 41%：大部分转交是直接改负责人，接收方不回复。
• 转交闭环平均耗时 6.2 天：从发起转交到接收方第一次独立交付。
• 季度转交引发返工 约 210 人时：主要由口径不一致和依赖漏判造成。
• 验收口径变更导致的返工占比 37%：也就是超过三分之一的返工，本质是"理解不一致"。

他们原来的工具链是 Jira 加一堆线下表格。Jira 本身能做工作项流转，但转交相关的三个关键信息，决策责任人、否决权人、验收标准版本，都散落在会议纪要和聊天记录里，无法查询，也无法做自动化提醒。

2. 他们具体做了什么

这里我要说明一点：他们选型时的一个硬约束是数据不能出内网，同时有国产替代的合规要求，还要能承接 Jira 上的历史数据。最终选择 PingCode，主要原因是它支持私有化部署，并且支持从 Jira 平滑迁移，工作项、关系链、历史评论和附件都能平迁，这直接降低了历史上下文的迁移成本。

对转交场景来说，"历史评论能不能迁过来"这件事比看起来重要得多。因为转交最需要的上下文，往往就藏在过去两年的评论和决策讨论里。

具体的配置动作有五步：

1. 在工作项类型上增加三个自定义字段：决策责任人、否决权人、升级时限（小时）。设置为转交时必填，未填写无法完成负责人变更。
2. 增加"转交确认状态"字段：可选值为"待确认 / 已确认 / 有异议"，只有接收方本人可以改为"已确认"或"有异议"。
3. 建立投产依赖关系链：把跨团队依赖用阻塞关系和关联关系显性化，转交时系统自动提示该工作项的全部上下游接口。
4. 配置自动化规则：转交发起后 48 小时未确认，自动提醒接收方；72 小时仍未确认，自动升级给项目经理和双方主管。
5. 每周生成转交台账视图：按"待确认""已确认未开始""已开始但依赖未清"三个维度分类，项目经理每周一过一遍。

下面是他们使用的自动化规则的核心逻辑，我用伪配置的形式写出来，方便你参照改造：

规则名称: 转交确认超时升级
触发条件:

工作项.负责人 发生变更

AND 工作项.转交确认状态 == "待确认"

执行动作:

T+48h:

通知 接收方本人（站内信 + 移动端推送）

通知 原负责人（抄送）

T+72h:

通知 接收方主管 + 项目经理

将 工作项.风险等级 置为 "高"

在 工作项.评论区 自动追加一条时间线记录

T+120h:

在周度转交台账中标记为 "阻塞转交"

要求 项目经理 在例会中说明处理结论

前置校验（不满足不允许变更负责人）:

工作项.决策责任人 != 空

工作项.否决权人 != 空

工作项.升级时限 != 空

工作项.验收标准版本 == 最新版本

其中最后一条前置校验是我坚持加的。它把"验收标准是否同步"从人工检查变成了系统拦截，如果转交时验收标准已经更新但接收方手上的版本是旧的，系统直接不让改负责人。

3. 六个月后的变化

改造上线 6 个月后，他们做了一次对比复盘。数据如下（同一家企业前后对比，样本量为 1，属于个案观察，不能直接外推到其他组织）：

4. 一个反直觉的发现

改造后最有意思的发现是：转交前端的工作量增加了，中后端的沟通量减少了。

上线前，项目经理每周花约 9.5 小时处理转交相关的协调、追问和返工善后。上线后降到 4.2 小时。但与此同时，发起转交的原负责人平均每次要多花 12-15 分钟填写决策责任人、否决权人、升级时限这三个字段。

表面上"总时间"没有大幅减少，但分布变了：原来花在中后端的救火时间是不可预测的、打断式的、消耗情绪的；现在花在前端的 12 分钟是可控的、可计划的。这种分布变化带来的实际体验改善，比总时长减少更重要。

另一个反直觉点是：依赖漏判次数从 19 次降到 6 次，但没有归零。我一开始以为是配置问题，后来发现是数据维护问题，依赖关系链需要定期更新，如果接口人换岗但关系链没改，系统就提示不到。这提醒我们：工具能放大流程的有效性，但流程本身需要有人维护。

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

前面讲了框架和案例，这一节给你可以直接照着做的分类建议。五类场景的处理重点不同，我按场景分开说。

1. 人员离职型转交：以"可追溯"为第一目标

离职型转交的特点是时间不可协商（离职日期是硬的），且原负责人后续大概率联系不上。所以第一目标不是效率，而是可追溯。

1. 提前量化工作项数量和工作量。离职通知到实际离职通常有 15-30 天，第一周就要把工作项清单、当前状态、剩余投入全部统计出来。
2. 按"半衰期"排序转交优先级。变化最快的任务优先交接，因为它们最需要深度上下文。
3. 安排至少一次结对工作。让接收方和原负责人共同处理一个真实问题，而不是只听讲解。这是我见过效果最好的单一步骤。
4. 录制关键决策的口头说明。3-5 分钟一段，针对每个有历史包袱的决策点录一段。文字记录会丢失语气和权衡过程，录音能保留。
5. 在最后工作日之前完成书面确认。一定要在原负责人还在的时候完成接收方确认，否则出问题连问的人都找不到。

2. 组织调整型转交：以"台账完整"为第一目标

组织调整的特点是批量、跨边界、涉及汇报线变化。单点做得好没有意义，必须整体不漏。

• 建立一张覆盖全量的转交台账，字段至少包括：工作项 ID、原负责人、新负责人、验收标准是否已同步、依赖接口是否已确认、确认状态、确认时间。
• 设置统一的转交截止日和确认截止日，避免拖成长期悬案。我的经验是确认窗口不要超过 5 个工作日。
• 指定一名转交协调人（通常是项目经理或 PMO），负责每日更新台账并升级异常项。
• 在调整生效后的第 2 周和第 4 周各做一次回访，检查是否有遗漏的工作项在暗中流转。

3. 优先级切换型转交：以"回归条件"为第一目标

这类最容易被轻视，因为人还在，感觉随时可以问。但恰恰因为它看起来不严重，才会埋雷。

我建议这类转交必须写明三件事：原负责人是否保留知情权、什么条件下任务回归原负责人、回归时需要交接什么。没有回归条件的"半转交"，最后往往变成两边都不负责的灰色地带。

4. 跨部门/跨团队型转交：以"升级路径"为第一目标

跨部门转交最大的风险在于双方没有共同上级，或者共同上级层级很高、介入成本大。所以必须提前约定升级路径和时限，并且让双方主管都知晓。

我的建议是把升级路径写成明确的时限承诺，例如"接收方遇到阻塞后 8 小时内升级至双方接口人，接口人 24 小时内必须给出结论或再次升级"。时限比路径本身更重要，因为没有时限的路径等于没有路径。

5. 外部供应商或外包型转交：以"验收标准书面化"为第一目标

这类转交涉及合同责任，口头共识没有约束力，所有验收标准必须书面化，包括交付物清单、质量标准、验收方式、争议处理流程。

我的建议是：不要用会议纪要承载这类内容。会议纪要在争议场景下的证明力很弱。应该写入正式的补充说明或工作说明书，并由双方的授权代表确认。

七、不同情况下的取舍

转交管理的本质是一系列取舍。没有完美方案，只有与当前约束匹配的方案。我把自己最常被问到的四组取舍摊开讲。

1. 速度与完整性的取舍

紧急场景下，你不可能既快又全。我的判断原则是：如果任务半衰期超过 4 周，可以牺牲完整性换速度；如果半衰期短于 2 周，必须牺牲速度换完整性。

原因很简单。半衰期长的任务，接收方有几周时间慢慢补齐上下文，先接手再补课是可行的。半衰期短的任务，接收方下周就要面对变化，如果第一周没建立判断力，他会连续做错决策，返工成本远超当初省下的时间。

2. 文档化与口传的取舍

我的立场是明确的：判断类内容口传 + 固化，事实类内容直接文档。

"这个接口为什么设计成这样""为什么当初否了方案 B"属于判断类，口传效率远高于读文档，因为接收方可以追问。但口传之后必须把结论固化成一句话记录，否则会漂移。

"这个接口的入参是这几个字段""这个模块有 3 个测试环境"属于事实类，直接写文档，没必要开会讲。把事实类内容放进会议是浪费时间。

3. 集中式转交与渐进式转交的取舍

我的实践建议是混合使用：用集中式处理"必须立刻转移"的部分，用渐进式处理"可以慢慢消化"的部分。比如离职型转交里，正在迭代中的工作项走集中式，下一个季度才启动的规划类工作走渐进式。

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

工具强约束（比如不填三个字段就不让改负责人）能显著提升执行率，我在案例里也看到了效果。但它有代价：在小而稳定的团队里，这种约束会让人觉得官僚。

我的判断标准是转交频次：如果一个团队每月转交次数少于 2 次，用轻量模板就够了，不必上强约束。如果每月超过 5 次，且团队规模在 100 人以上，强约束的收益会明显超过它的摩擦成本。

八、可落地的操作步骤：一份可以直接抄的转交流程

最后给你一套完整的操作流程。我把它拆成四个时间节点，每个节点都有明确的动作和产出。

1. 转交前 48 小时：准备阶段

1. 整理工作项清单，逐条标注：当前状态、剩余工作量、半衰期判断、是否有跨团队依赖。
2. 更新验收标准版本。所有验收标准必须是最新版，并且标注版本号。这一步在案例里是系统强校验项。
3. 指定决策责任人和否决权人。必须是具体人名，不能是团队名。
4. 列出关键接口人清单。每个接口人写明角色、当前承诺、沟通频率。
5. 约定升级时限。写清楚"阻塞后多少小时升级、对方多少小时响应"。
6. 提前把材料发给接收方。要求他在会议前至少读过一遍，带着问题来。

2. 转交会议：60-90 分钟

会议的目的不是宣讲，而是对齐判断。所以我会把时间按 3:4:3 分配。

• 前 30%（约 20-25 分钟）：原负责人讲判断。不讲任务清单（清单已经发过了），只讲三件事：为什么这么设计、哪些方案被否决过、最大的风险点在哪。
• 中间 40%（约 30-35 分钟）：接收方提问。要求至少提 3 个问题。如果提不出来，主持人要主动追问"如果你明天独立处理这个任务，你最不确定的是什么"。
• 后 30%（约 20-25 分钟）：逐条确认四件套。上下文、验收标准、决策权限、退出机制，逐条过，逐条记录结论。

会议结束前，必须当场确认接收方的"确认状态"，不要留到会后。会后补确认的完成率，我观察到大约只有会中确认的三分之一。

3. 转交后 72 小时：验证阶段

1. 接收方在 24 小时内完成书面确认，明确写出他理解的验收标准和决策边界。这份确认书是后续争议时的唯一依据。
2. 原负责人在 48 小时内响应所有追问，并在工作项里留下记录，而不是只在私聊里回答。私聊的答案等于没答。
3. 接收方在 72 小时内独立完成一个小交付。哪怕只是修复一个小问题、跑通一次流程。这一步是验证上下文是否真的转移到位的最快方式。

4. 转交后第 2 周：复盘阶段

• 回访接收方：哪些信息是后来才发现缺失的？这些缺失项应该加到转交模板里。
• 检查是否有隐藏依赖在第二周才暴露。如果有，说明依赖关系链的维护不到位。
• 更新转交模板。我坚持每次转交复盘至少给模板增加或修改一条内容，让模板随组织一起演化。
• 正式确认原负责人退出。这个动作看起来形式化，但它能让接收方真正建立"这是我的事了"的意识。

下面是一份可以直接使用的转交检查清单，我用 YAML 写出来，你可以直接改成自己团队的工具字段或表单模板：

转交检查清单:
前置校验:

验收标准版本已更新至最新

决策责任人为具体人名

否决权人不超过 2 人

升级时限已写明小时数

关键接口人清单已填写

会议产出:

设计意图与历史决策记录

已否决方案清单及原因

风险点与已知问题列表

接收方提出的问题不少于 3 个

四件套逐条确认结论

会后验证:

24 小时内接收方书面确认

48 小时内原负责人响应所有追问并留痕

72 小时内接收方完成一次独立小交付

退出与复盘:

第 2 周回访并记录新增缺失项

模板更新不少于 1 条

正式确认原负责人退出

九、结论与下一步行动

回到最开始那个 46 人天的返工案例。它真正的教训不是"交接会开得不够长"，而是组织把转交当成了信息搬运，却忘了它本质上是责任的重新签约。文档可以转移信息，但不能转移责任；只有当接收方明确知道自己在什么范围内可以自主决定、超出范围找谁、对方多久必须回应，责任才算真正转移过去。

我把这套判断概括成三句话。第一，转交的完成标准是接收方能独立交付，不是原负责人讲完了。
第二，转交质量由最弱的那个因子决定，验收标准和决策权限通常就是最弱的两个。
第三，转交流程的投入应该按任务半衰期分层，而不是一刀切。

如果你现在就想动手，我建议按这个顺序推进，不要一次全上：

1. 本周内：先在你的工作项系统里加一个"转交确认状态"字段，就一个字段，要求转交时必须由接收方确认。这一步成本最低，见效最快。
2. 两周内：把"决策责任人"和"升级时限"加进转交必填项。如果你的工具支持条件校验，把它做成不改负责人就不能提交的硬约束。
3. 一个月内：跑一次完整的转交复盘，把发现的缺失项补进模板。哪怕只有一次，你也能感受到差异。
4. 一个季度内：统计一次自己的转交确认率、平均闭环耗时和返工人时，形成你自己的基线。没有基线就没有改进的方向。

最后一点提醒：转交能力常常被低估为"软技能"。但在我服务过的中大型研发组织里，它实际上是一项硬指标，它决定了一个团队在人员变动时是损失 20 人天还是 200 人天，也决定了项目负责人能不能从无休止的救火里脱身出来。把转交做成流程，而不是靠个人记忆和责任心，是团队走向规模化必须跨过的一道坎。