团队容量规划

研发团队谈“空闲资源”，最容易犯的错误，是把工时表上没有排满的人直接视为可用产能。一个工程师本周看起来空出两天，可能正在等待外部接口、处理线上值守、补写测试，或被拆成多个项目的零碎…

研发团队做 Capacity 管理，最容易犯的错不是“算得不够精确”，而是把每个人的工时填满后，误以为项目因此更可控。实际运行中，排期表看起来达到 100% 利用率，需求变更、线上…

资源负载工作负载教程的关键，不是把每个人每天填满八小时，而是看清团队在某段时间内承诺了多少工作、实际能交付多少，以及关键岗位是否已经成为瓶颈。研发团队最常见的误判是：项目计划看起来…

Capacity 做不起来，通常不是因为团队不会算工时，而是因为大家把“有多少人”误当成“有多少可交付能力”。一个 8 人团队看上去有 40 人日周容量，扣掉会议、支持、休假、跨项…

资源负载超负荷，通常不是“大家不够努力”，而是承诺的工作量超过了团队在目标时间内真实可用的能力。最危险的信号也不一定是任务逾期：更常见的是计划表看起来满满当当，关键岗位却被临时需求…

产品经理说“这个月还能接两个需求”，研发负责人却判断团队已经超载，项目会上两边都拿着自己的表格，最后只能靠谁声音大来决定优先级，这不是产能不足的唯一表现，往往是 Capacity …

资源平衡管理最容易失控的时刻，往往不是团队“没事做”，而是每个人看起来都很忙，关键项目却仍然延期。产品经理把需求排进路线图之后，如果没有进一步核对人员技能、可用时间、依赖关系和风险…

资源负载表上每个人都没有超载，项目却连续两个月延期，这是我在梳理一类中大型产品团队资源问题时反复看到的反常现象。问题通常不在于团队缺少一张排期表，而在于“谁能承诺什么、冲突由谁裁决…

不少产品团队的容量表看起来很精确：每个人每周可用 40 小时，任务也都填了工时，表格还能自动算出负载率。但到了迭代中段，需求延期、线上故障和临时评审一叠加，原本低于 80% 的团队…

负荷管理指南的关键，不是把每个人的日程填满，而是让团队在不透支关键岗位的前提下，持续交付最重要的结果。产品经理常遇到这样的局面：路线图上同时有增长需求、客户承诺、线上问题和技术改造…