本文是《管理复盘》中「资源与容量」这条线的展开。
资源不足时，最常见的补丁是让少数人更努力：多接一些需求、少做一些检查、晚上再处理遗留问题。短期看似守住了交付，长期却把容量问题伪装成了个人表现，直到疲惫、投诉和事故一起出现。
我自己就曾把"再坚持一下"当过解法，直到一次深夜的发布事故让我意识到：透支的不是某个人的意志，是容量系统的缺口。下面写的是原则，不针对任何团队。
定容先帮助三方达成共识
资源受限其实是常态，不是例外：人力有限、预算和服务器有限、能用的工具也有限。几乎所有团队本质上都在解决同一个问题——如何在资源受限的情况下达成核心目标。真正容易被跳过的第一步，不是直接谈目标，而是先让所有合作方对"资源确实有限"这个事实达成共识，而不是各自默认资源可以无限供给。有了这层共识，才谈得清要做成什么、为什么值得做，也才能拿这个理由去争取更多资源。
举个我自己遇到的场景：某一年搜索业务的指标要求，是把搜索转化率从入口到结果这条链路做到 50%，但团队只有三四个人，各种需求和 AI 相关的新功能却层出不穷。这时候真正要做的工作，不是让这三四个人硬扛下去，而是先把所有相关方拉回同一个事实平台——资源就是这么多，不是谁许愿就能变多——大家才会开始认真协调优先级，而不是各自按自己的期待去要进度。
"这个团队需要几个人"看似是人数问题，实质是效能与交付预期的问题。没有人能仅凭一个比例回答它：同样十个人，项目占用、技能结构、依赖复杂度和现有风险不同，真实能力就完全不同。
定容的目的，是帮助三方达成共识：团队此刻能稳定交付什么；为了新增一项承诺必须放下什么；在什么条件下风险会超过可接受范围。它不是为现有人数辩护，也不是把不合理目标包装成资源申请。
判断该不该为一件事申请或投入资源，可以先按紧急、重要两个维度拆分：紧急且资源有限，有充分理由申请更多资源；重要但不紧急，可以投入少量人力去推进，但同样需要争取到授权和认同，而不是默默加班垫上；不重要的事，给不给资源其实无所谓。缺了"资源事实"和"信任"这两层共识，团队就容易陷入冲突和投诉，也容易让人误以为只要战术上更勤奋就能补上结构性的缺口。
先画出真实容量
容量不是人数乘以工作日，还要扣除维护、支持、沟通、学习、突发问题与必要缓冲。盘点时至少列出人力、可用资源和项目占用：多少能力被运行维护、线上支持、长期项目、协作与招聘消耗；关键工作是否被单点人员掌握；哪些依赖无法由团队自己控制。
每个周期列出三类承诺：必须守住的运行与风险事项、已确认的交付、可随资源调整的探索。若第三类被挤掉，不应假装它仍会发生；若前两类已经超出能力，应尽早升级。
把投诉拆回具体事件
"合作方不满意"并不是一个可行动的结论。先问：发生在哪个项目、哪次交接、什么预期没有被满足？是事实上的延误、质量缺陷，还是一次沟通方式造成的不信任？问题指向事情，还是被扩大成对人的判断？
和前面搜索转化率那个例子类似：如果只停留在"合作方觉得进度慢"这类笼统印象上，团队很容易被拖入无休止的解释和自证；只有把它拆回具体的项目、具体的交接节点，才谈得上是流程或资源配置的问题，还是沟通方式的问题。投诉常常是系统报警，而不是人不够努力。
公开能力边界，让选择向上对齐
团队应能说清：现有能力能保证什么，不能保证什么；如果新增一项承诺，必须暂停或延后什么；哪些风险正在被暂时接受。这个过程不舒适，却比默默透支更诚实。
优先级不是把所有任务标成高优，而是让每个"是"都对应一个明确的"不"。当资源不够、多个方向冲突时，一线团队不应私自承诺，需要整体上升对齐：让拥有更多资源与更高决策权限的人，在同一组事实下选择加资源、减范围、延时间或改目标。定容真正创造的价值，是让这些选择不再由最靠近压力的人默默承担。
让风险有名字。不要只说"可能延期"，而应说明依赖接口未定、关键知识只有一人、测试窗口不足或方案无法快速回退，并配上责任人、触发信号和应对选择。风险被命名后，合作方才能参与取舍。
不把人当作缓冲垫
短期冲刺可以存在，但必须有明确的终点、补偿和复盘。若团队常态化依赖加班、英雄救火和临时协调，真正需要修复的通常是承诺机制、流程入口或资源配置。
管理者的责任不是保证没人失望，而是在资源有限时让代价看得见、选择说得清，并保护团队不把不可持续误认为敬业。
投诉既可能是情绪表达，也可能是系统报警。前者应被尊重地听见，后者应被具体修复；两者都不该变成对人的标签。公开回看承诺、结果和下次更早暴露的环节，容量问题才不会继续被个人化。