资源不足时，怎样不让团队靠透支运转

本文是《管理复盘》中「资源与容量」这条线的展开。

资源不足时，最常见的补丁是让少数人更努力：多接一些需求、少做一些检查、晚上再处理遗留问题。短期看似守住了交付，长期却把容量问题伪装成了个人表现，直到疲惫、投诉和事故一起出现。

我自己就曾把”再坚持一下”当过解法，直到一次深夜的发布事故让我意识到：透支的不是某个人的意志，是容量系统的缺口。下面写的是原则，不针对任何团队。

定容先帮助三方达成共识

“这个团队需要几个人”看似是人数问题，实质是效能与交付预期的问题。没有人能仅凭一个比例回答它：同样十个人，项目占用、技能结构、依赖复杂度和现有风险不同，真实能力就完全不同。

定容的目的，是帮助三方达成共识：团队此刻能稳定交付什么；为了新增一项承诺必须放下什么；在什么条件下风险会超过可接受范围。它不是为现有人数辩护，也不是把不合理目标包装成资源申请。

容量不是人数乘以工作日，还要扣除维护、支持、沟通、学习、突发问题与必要缓冲。盘点时至少列出人力、可用资源和项目占用：多少能力被运行维护、线上支持、长期项目、协作与招聘消耗；关键工作是否被单点人员掌握；哪些依赖无法由团队自己控制。

每个周期列出三类承诺：必须守住的运行与风险事项、已确认的交付、可随资源调整的探索。若第三类被挤掉，不应假装它仍会发生；若前两类已经超出能力，应尽早升级。

“合作方不满意”并不是一个可行动的结论。先问：发生在哪个项目、哪次交接、什么预期没有被满足？是事实上的延误、质量缺陷，还是一次沟通方式造成的不信任？问题指向事情，还是被扩大成对人的判断？

例如，某个支持团队总被说”响应慢”。记录一周后发现，大部分请求并非处理慢，而是提交时缺少必要信息，来回澄清占去了一半时间。此时应改变入口和分级规则，而不是要求值班的人更快回复。投诉常常是系统报警，而不是人不够努力。

团队应能说清：现有能力能保证什么，不能保证什么；如果新增一项承诺，必须暂停或延后什么；哪些风险正在被暂时接受。这个过程不舒适，却比默默透支更诚实。

优先级不是把所有任务标成高优，而是让每个”是”都对应一个明确的”不”。当资源不够、多个方向冲突时，一线团队不应私自承诺，需要整体上升对齐：让拥有更多资源与更高决策权限的人，在同一组事实下选择加资源、减范围、延时间或改目标。定容真正创造的价值，是让这些选择不再由最靠近压力的人默默承担。

让风险有名字。不要只说”可能延期”，而应说明依赖接口未定、关键知识只有一人、测试窗口不足或方案无法快速回退，并配上责任人、触发信号和应对选择。风险被命名后，合作方才能参与取舍。

短期冲刺可以存在，但必须有明确的终点、补偿和复盘。若团队常态化依赖加班、英雄救火和临时协调，真正需要修复的通常是承诺机制、流程入口或资源配置。

管理者的责任不是保证没人失望，而是在资源有限时让代价看得见、选择说得清，并保护团队不把不可持续误认为敬业。

投诉既可能是情绪表达，也可能是系统报警。前者应被尊重地听见，后者应被具体修复；两者都不该变成对人的标签。公开回看承诺、结果和下次更早暴露的环节，容量问题才不会继续被个人化。