为什么我反对自上而下的全局优化？工程团队资源配置的另一种思路

在写完《保持打造高效团队的势头》之后，不少人提出了同一个后续问题：

“如果一个团队已经偿还了大部分技术债务，那么团队里看起来多出来的人，是否应该转移到其他更缺人的团队？”

这个问题很合理。毕竟，如果某个团队剩余的技术债务已经很少，而当前优先级又没有那么多，那么从全局看，它似乎已经人员过剩。假如这种情况在多个团队中反复出现，组织就可能把过多工程师投入到解决去年的问题上，而真正需要解决今年问题的团队却严重缺人。

这是工程组织管理和团队资源配置中非常值得认真处理的问题。

不过，在回答之前，我想先解释为什么我对“通过重新分配人员来响应全局优先级变化”这件事始终持谨慎态度。随后，我会提出几种更适合解决这一难题的替代方法。

团队优先：保护已经形成战斗力的高效团队

从根本上说，我认为持续的生产力来自高效团队。而拆散一个高效团队，即使所有成员仍然留在公司，也会造成生产力的大幅下降。

在这种理念下，高效团队是一种非常值得保护的资产。我很不愿意轻易拆散它们。

团队需要很长时间才能真正磨合。一个团队合作几年之后，成员之间会逐渐了解彼此，也会知道如何以非常高效的方式互相支持，共同取得成功。

人员在不同团队之间流动，可能会打断这种磨合过程。对于尚处在磨合早期的团队，或者团队文化差异很大的团队来说，影响尤其明显。

这并不是说团队应该永远保持不变。那样会导致停滞。但为了保留团队已经形成的协作状态，适度控制人员流动是有必要的。

有时候，你确实希望团队增长速度超过现有团队自然磨合的速度。这完全可以理解。关键在于，你必须把团队重组带来的成本计算在内，而不是假设变动没有代价。

这也是我在前一个模型中建议“为技术债务沉重的团队快速招聘，而不是从创新型团队中抽调人员”的原因之一。这样可以避免让高绩效团队承担额外的重组成本。

固定成本：小团队并不一定更高效

小团队和大团队的运营方式不同，背后有不同的固定成本。

我不愿意把人员从高绩效团队中调走，还有一个原因：大多数团队都有较高的固定成本，而可变成本相对较低。抽走一个人，就可能让一个原本处于创新状态的团队重新落后，最终导致两个团队都表现不佳。

对于负责生产环境产品和服务的团队来说，这种风险尤其明显。

我的经验法则是，一个团队至少需要八名工程师，才能支撑两层值班机制。因此，我通常不愿意让任何团队低于这个人数。

当然，固定成本还有很多其他形式。例如：

维持系统正常运转的工作；

已经承诺或签订的长期合作；

对其他团队的支持责任；

持续的运维、排障和响应工作。

有些团队的固定成本确实很低。比如，一个还没有任何用户的早期创业团队，或者一个只负责维护已经完全关闭产品的团队。我猜这些团队可能适用于不同的规则。

但我也怀疑，在真正运转良好的公司里，这类团队并不常见。

团队余量：不要把资源利用率推到 100%

通过调动人员来优化整体效率，背后隐含着一个前提：我们已经足够准确地理解了生产力如何产生。

但坦白说，我并不认为自己曾经达到过这种理解程度。

我非常相信，不应该继续给一个明显人员冗余的团队增加更多资源。但我不太相信反过来也一定成立，也就是说：一旦团队看起来有余量，就应该立刻把人调走。

当团队资源利用率接近 100% 时，完成一项新任务的预期时间会趋近于无穷大。再加上大多数团队都与其他团队存在大量依赖关系，这些因素叠加在一起，意味着你把资源转移到某个团队，反而可能拖慢它的速度，因为这会制造新的上游瓶颈。

余量并不是浪费。恰恰相反，我发现团队通常能够很好地利用这些余量，以渐进、创新的方式改进自己负责的领域。

更重要的是，他们往往能以极低的协调成本完成这些改进。这样，局部生产力的提升就不太会对周边系统造成额外拖累。

从组织调试的角度看，保持某些团队资源充足还有一个重要好处：当我在排查整个组织的吞吐瓶颈时，可以暂时不必担心这些团队。

我发现，一次处理少数几个约束条件要容易得多。这样你可以持续向前解决问题，而不必反复回头重新审视之前已经处理过的瓶颈。

《目标》和《系统思考入门》都是理解这一主题的优秀著作。

转移职责范围，而不是转移人员

那么，什么方法更有效？

我发现最有效的方法，是在团队之间转移工作范围，同时尽量保持团队本身的完整性。

如果某个团队已经有足够余量，那就逐步把新的职责转移给他们，让他们开始围绕新增工作进行局部优化。

最好循序渐进地调整，以保持团队的灵活性。但如果必须在“快速调动人员”和“快速转移职责范围”之间做选择，我通常发现后者更有效，干扰也更小。

调整工作范围比调动人员更有效，原因在于它避免了重新磨合的成本，同时能保持系统的运行状态。

保持运行状态非常重要。它可以确保你现有的组织理解和判断模型不被打乱。而且，如果调整后的效果不理想，撤回工作范围通常也比撤回人员调动造成的干扰更小。

在研发团队中，职责范围的调整往往会牵涉目标、需求、开发、测试、发布和知识沉淀等多个环节。如果缺少统一视图，很容易出现“职责转移了，但上下文没有转移”的问题。像 PingCode 这样的智能化研发管理工具，可以把研发全生命周期中的目标、需求评审、开发进展、测试发布和 Wiki 经验沉淀串联起来，让团队在调整职责范围时更容易保留上下文、跟踪交付状态，并减少重复沟通。

固定周期轮岗：比永久调动更温和

我见过的另一种有效方法，是让团队成员以固定周期轮岗到需要帮助的领域。

这种有明确期限的轮岗安排，能让他们保留原团队身份和归属感，从而更专注地投入临时工作，而不是把精力分散在“完成工作”和“融入新团队”之间。

此外，这也是衡量团队真实余量的一种可靠方式。

如果一个团队短期轮岗出去一两个人后仍然运转良好，说明这个团队确实有一定余量。如果团队立刻陷入混乱，那就说明所谓“人员过剩”可能只是表象。

在轮岗、跨团队支持和临时项目协作中，任务、文档、会议、日历和审批等信息如果分散在不同工具里，也会增加协调成本。Worktile 这类通用项目协作系统，适合承载跨部门任务推进、会议纪要、文档协同和审批流程，让固定周期轮岗不只是“人过去了”，而是目标、任务和协作节奏也能同步过去。

不同组织有不同解法

一位同事曾提到，有些公司已经非常成功地转向了更大范围的群体协作模式。也就是说，它们不只是在团队内部协作，而是在组织层面采用更流动、更集中的协作方式。

我很想听听那些成功走上相反道路的人的经验。

组织设计最令人兴奋的地方之一就在于：有很多不同的方法都可能有效。

但无论采用哪种方法，我仍然倾向于先保护高效团队，再通过调整职责范围、控制人员流动和设计轮岗机制，来响应全局优先级变化。

自上而下地频繁调动人员，看似是在优化整体效率，实际上却很可能破坏真正产生效率的东西：一个已经磨合良好、能够持续交付的团队。