资源负载Capacity教程：产品经理效率提升，避坑指南

资源负载 Capacity 看起来像一道除法题：把一个人的可用工时分给项目，算出利用率。但产品经理真正容易踩的坑，恰恰是把它当成一道除法题。团队计划表显示每个人只排了 80% 的时间，迭代却仍然延期；新需求进入时，所有人都说“能做”，直到测试和上线前才发现关键岗位早已超载。本文把 Capacity 拆成可计算、可校准、可用于决策的工作方法，并用一组明确标注为情景模拟的数据说明：容量规划的价值不是把每个人排满，而是尽早识别承诺与现实之间的缺口。

一、先讲核心结论：Capacity 不是排满工时，而是管理承诺

1. 先把四个容易混淆的概念分开

Capacity 通常指一个团队或成员在指定时间段内，能够投入工作的可用容量。它回答的是“最多能承接多少工作”，不是“应该把多少工作塞进计划”。Availability 是扣除休假、会议、支持轮值等因素后的可用时间；Demand 是需求预计消耗的工作量；Load 则是当前计划或实际工作量相对于可用容量的占用程度。

我建议产品经理在讨论容量前，先问清楚团队正在谈哪一种口径。有人把 Capacity 当作标准工时，有人把它当作可承诺工作量，还有人把排进迭代的任务总估时直接称为负载。口径不统一，表格即使计算正确，也只会让错误看起来更精确。

2. 负载率是预警信号，不是绩效分数

常见公式是：负载率 = 已计划工作量 ÷ 可用容量 × 100%。它适合用来发现明显超载和资源冲突，却不适合直接评价个人效率。一个成员负载率达到 110%，可能代表计划超出容量；也可能是估时口径偏差、跨项目重复记账，或临时支持工作没有进入计划。

我的判断是：负载率应该触发一次核查，而不是触发一次责备。当数字超过 100%，先追问工作是否可拆分、是否有依赖阻塞、是否存在未登记支持任务，再讨论调整承诺。若把高负载率当作“投入度高”，团队会倾向于隐藏风险；若把低负载率当作“效率低”，成员会倾向于把每个空隙都填满。

3. 计划容量要为不确定性留位置

产品工作不是流水线上的稳定工序。线上问题、需求澄清、跨团队评审、验收返工都可能改变计划。对高度可预测的维护任务，可以使用较高的计划承诺；对探索性需求或依赖尚未确认的项目，则应保留更多缓冲。容量管理的目标不是消除变化，而是让变化出现时仍有选择。

二、背景和真实场景：为什么产品经理常在迭代中途才发现超载

1. 纸面空闲与真实可用之间存在时差

产品经理经常看到这样的计划：开发成员本周期有 80 小时容量，任务估时合计 64 小时，表面负载率 80%。但这 64 小时只统计了需求开发，没有算上代码评审、线上问题、部署协助和临时技术咨询。计划看起来有余量，团队却没有可用于新需求的整块时间。

更麻烦的是，碎片时间不能简单相加。一天中有六段各 20 分钟的空档，数学上等于两小时；但如果任务需要连续上下文，实际产出可能远低于两小时。对于需要深度思考的产品方案、复杂开发或测试回归，时间是否连续，往往和总时长一样重要。

2. 多项目共享人员会制造隐性重复承诺

一名设计师同时支持三个产品小组，每个小组都把她的半天排进计划，单独看每个项目似乎都合理，合起来却可能超过一周可用时间。若项目计划各自维护，冲突可能直到评审或交付节点才暴露。跨项目资源问题不是某个项目经理“不够协调”，而是缺少统一的容量视图和优先级决策。

如果使用项目管理平台管理中大型组织的工作，产品经理可以把项目、迭代、任务负责人、预估工作量和实际记录放在同一套流程里核对。以 PingCode 为例，可把容量视图作为计划协同的一部分，而不是把表格当成独立系统；但工具能帮助暴露冲突，不能替管理者决定哪个项目应当让路。

3. 100 人以上组织的难点往往是口径，不是表格

在 100 人以上的组织里，容量数据常由多个团队分别维护。研发以故事点估算，测试以人时排期，产品以需求数量汇报，项目管理则以里程碑跟踪。它们可能都正确，却无法直接相加。组织规模越大，越需要统一“计划单位”和“更新责任”，否则集中看板只会汇总出一组不可比较的数据。

我会把容量规划看成三个层次：团队层回答本周期可以承诺多少；角色层回答关键岗位是否形成瓶颈；个人层用于检查具体冲突和过载。优先级应先在团队和项目层决定，个人层主要用于核查执行约束，不应把资源规划退化为个人工时审查。

4. 计划失准常发生在输入信息没有及时更新

成员临时请假、依赖团队延期、范围变化和生产事故，都可能让原来的可用容量失效。如果计划只在迭代开始时填写一次，后续不更新，再精致的仪表盘也会逐渐变成历史陈列。容量信息必须有更新触发条件，例如休假确认、需求增删、支持轮值调整或关键依赖变更。

三、常见误区：看起来精确的数字，为什么反而误导决策

1. 把八小时工作日当作八小时专注产出

八小时是常见的工作日长度，不代表八小时都能用于项目任务。会议、沟通、上下文切换和必要的协作会消耗时间。把标准工作日直接乘以人数，得到的是理论工时，不是团队承诺量。忽略这一层，团队会把“理论满载”当成正常计划，最后只能靠加班补差额。

解决方法不是随意给每个人乘一个固定折扣，而是先记录可观察的固定占用，再用历史迭代数据校准剩余部分。固定会议可以从日历计算；支持轮值可以按排班估算；难以预测的中断，则应通过过去数个周期的偏差来估计。

2. 把故事点换算成人时，再按人头硬分配

故事点是团队对工作复杂度、风险和相对规模的估计，不是天然的小时单位。一个团队把 1 个故事点视为 4 小时，另一个团队可能完全不是这个比例。强行统一换算，会让局部经验被误认为组织通用规律，也可能诱导团队通过调整估点来满足容量目标。

如果团队长期使用故事点，应优先用本团队的历史交付速度规划迭代，不要为了制造表面统一而把点数翻译成精确工时。如果工作必须按工时排程，例如值班、外包合同或严格的交付窗口，则要明确这是另一种计划口径，并避免把故事点和人时直接混加。

3. 把百分之百利用率当作效率最优

当每个人都被排到满载，任何新增需求、缺陷修复或依赖等待都会导致计划被挤压。满载不是稳态，而是没有缓冲的脆弱状态。团队可能短期看起来产出更多，长期却因返工、疲劳和切换成本增加而降低可靠性。

我不会给所有团队规定一个统一“最佳利用率”。稳定维护团队、探索型产品团队和强依赖项目团队的波动完全不同。更有效的问题是：在当前需求不确定性下，团队承诺多少工作量，才能保持较稳定的交付节奏？答案应从实际偏差、延期原因和未完成工作中得到，而不是从一个固定百分比抄来。

4. 把人均负载当成团队负载

五个人的总容量充足，不代表关键角色也有容量。团队可能总共剩下 40 小时，但这 40 小时都属于产品、而真正缺的是测试；也可能开发空闲，唯一熟悉某个系统的工程师却已经超载。平均数会把瓶颈抹平。

容量核算至少要按关键角色检查一次。对每个里程碑，确认需求分析、设计、开发、测试、发布和运维支持是否都有人承接。只看团队总工时，等于假设所有角色可以互相替代；在真实项目中，这个假设通常不成立。

5. 把估时差异解释为个人能力差异

估时是对未来工作的判断，不是对个人价值的测量。偏差可能来自需求边界不清、外部依赖、任务粒度过大、环境不稳定，或者估算时把验证工作遗漏了。若团队把估时误差直接归责于个人，成员很快会学会报大数、报安全数，数据反而更难用于计划。

处理偏差时，我会比较同类工作和共同条件，而不是简单比较不同成员的估时。一个任务从 8 小时变成 20 小时，先检查新增工作是什么、何时发现、为何未进入原计划；这比追问“为什么没做完”更容易得到可行动的改进措施。

6. 只看本迭代，不看队列和未来约束

某个迭代当前没有超载，不代表整个季度的资源安排合理。大项目可能在开发阶段容量充足，却在验收、迁移或上线窗口集中挤压测试和运维。若只看短周期负载，组织会把延期风险向后推，直到关键阶段无处调整。

对跨季度项目，建议至少观察未来两个至三个交付窗口。越远期的数字越不应伪装成精确承诺，应使用区间、假设和置信度表达。例如“预计需要 3 至 5 个测试人日，前提是接口在本周冻结”，比“需要 4 天”更诚实也更有决策价值。

四、专业判断逻辑：从容量数字走到可执行决策

1. 先确定规划对象和时间范围

开始计算前，先明确是在规划个人、一支团队、一个项目，还是跨项目的共享角色；再明确时间范围是一天、一周、迭代、月份还是季度。个人日容量适合处理排班和冲突，迭代容量适合做交付承诺，季度容量适合讨论路线图与投资组合。不同范围不能直接混为一谈。

时间越短，已知日历信息越可靠；时间越长，需求和依赖的不确定性越大。因此，短周期可以讨论具体人日，长周期更适合用范围与情景推演。不要在季度计划中制造精确到小时的假象，也不要在下周排班时只用模糊故事点。

2. 区分固定损耗、可变损耗和不确定风险

固定损耗包括休假、固定会议和已排定轮值，可以在计划前扣除。可变损耗包括临时支持、跨团队协调和需求澄清，需要参考历史数据估算。不确定风险则包括接口变更、线上事故和新技术探索，未必能准确预测，应通过缓冲、备选方案或范围控制来管理。

这三类损耗不能都塞进一个“效率折扣”。如果某团队每周都有固定支持轮值，就应直接计入容量；若团队偶发高严重度事故，则应记录发生频率和影响范围，采用风险预留或应急机制。把原因拆开，才能知道改善空间在哪里。

3. 用历史偏差校准，不用单次表现定规矩

计划误差可以按工作量比较：偏差率 =（实际消耗 − 计划消耗）÷ 计划消耗。若计划 100 小时，实际消耗 120 小时，偏差率是 20%。但只有把偏差进一步分类，这个数字才有用：需求新增、估时低估、等待依赖、返工、支持插入，可能需要完全不同的行动。

我倾向于观察连续数个周期，而不是用一次异常迭代改写所有规则。一次重大事故足以让实际工时大幅上升，却不代表未来每个迭代都应按事故规模预留。如果偏差连续出现，再检查容量折减、任务粒度或计划流程是否系统性失准。

4. 以关键角色和依赖链校验，而非只看总量

团队总量看似足够时，还要检查关键路径上的角色是否有容量。假设一个需求需要产品澄清、设计确认、开发、测试和发布协作，任何一个环节不可用，都可能阻断整体交付。对于共享测试、数据或安全评审资源的项目，尤其要把等待时间和排队风险纳入计划。

实际决策可以按如下顺序进行：

1. 确认需求范围、验收条件和计划周期，避免为尚未定义的工作精算工时。
2. 按成员日历计算可用容量，并扣除已知休假、固定会议和轮值工作。
3. 依据历史记录估算可变损耗，标记数据覆盖范围和置信度。
4. 按角色核查关键任务和依赖，不以团队平均容量替代岗位容量。
5. 对比需求负载和承诺容量，优先处理超过容量的部分。
6. 明确超载时的选择：减范围、延时间、增资源或降低服务承诺，并记录决策人。
7. 周期结束后对比计划与实际，把误差原因回写到下一周期，而不是只更新一个利用率数字。

5. 设定阈值时，把阈值当作触发器

可以设置容量预警，例如达到可用容量的 85% 时提醒核查，超过 100% 时要求明确处理方案。但阈值不是自然定律，也不是所有团队统一的绩效线。新团队、探索项目和高频运维团队的波动程度不同，阈值需要结合历史完成情况校准。

我更关心的是阈值之后发生什么。预警后若没有范围调整、依赖确认或优先级选择，阈值只是颜色变化；若每次预警都能引发责任明确的决策，它才成为管理机制。建议把“超载后的处理动作”与阈值同时设计，而不是先追求漂亮的仪表盘。

五、案例与数据观察：一支五人团队如何避免迭代承诺失真

1. 先声明案例口径，避免把模拟数据包装成调研结论

下面是一组情景模拟，用于演示核算过程，并非真实企业调研，也不是任何工具的效果承诺。假设某产品团队由 1 名产品经理、2 名开发、1 名测试和 1 名设计组成，规划一个两周迭代，每人 10 个工作日，每日按 8 小时计算。理论工时为 400 小时，但五个角色的可用时间并不相同。

团队的固定会议、休假和支持安排共占 100 小时，剩余 300 小时。考虑临时支持和估时偏差后，团队将 15% 作为计划缓冲，得到约 255 小时的可承诺容量。这里的 15% 只是案例假设，不应直接复制到其他团队；实际比例应通过连续周期数据校准。

2. 总量够，不代表每个角色都够

假设计划需求共计 240 小时，低于 255 小时承诺容量，看起来可以接。但拆到角色后发现：开发需要 116 小时，可用承诺容量为 120 小时；测试需要 62 小时，可用承诺容量只有 48 小时；产品需要 38 小时，可用容量为 42 小时；设计需要 24 小时，可用容量为 30 小时。

如果只看 240 小时小于 255 小时，项目经理可能会直接批准。角色拆解却显示测试缺口为 14 小时。此时再多安排一名非测试成员，并不能自动补上缺口；需要选择减少验收范围、提前安排测试支持、拆分发布批次，或把交付时间后移。

3. 识别瓶颈后，比较四种处理方案

方案一是减少范围：把低优先级验收项移到下一批次，降低测试工作量。它不增加成本，但需要产品负责人确认业务影响。方案二是增加测试支持：可以保留范围，却会产生调度成本，还要确保新加入人员了解环境和用例。

方案三是延长交付时间：适用于范围必须完整、测试质量不可妥协的场景，但可能影响市场窗口或上下游排期。方案四是分批发布：先交付低风险部分，再通过后续批次完成剩余功能。它能降低单次压力，却要求架构、数据和用户体验允许分阶段上线。

这个案例的关键判断不是“团队还差 14 小时”，而是“测试容量是交付链条的约束，增加其他角色工时不会消除约束”。容量分析应帮助团队找到最小代价的约束缓解方式，而不是证明所有人都很忙。

4. 用计划偏差解释下一周期怎么调整

假设迭代结束后，团队计划工作量为 240 小时，实际记录为 278 小时，表面偏差是 15.8%。进一步拆分发现，需求澄清增加 12 小时，线上支持增加 16 小时，测试返工增加 10 小时，而两项原计划任务减少了 8 小时工作量。若只说“估时不准”，就会错过不同问题的处理路径。

需求澄清增加，可能需要更早完成验收标准和依赖确认；线上支持增加，可以考虑调整轮值容量或设立应急预留；测试返工增加，则应检查需求质量、测试数据和环境稳定性。下周期是否提高缓冲，要看这些因素是否具有重复性，而不是把一次性异常永远固化成折扣。

六、落地方法：让容量规划进入产品经理的日常工作

1. 第一次建立容量基线，不要一上来追求全面

第一次做容量规划，建议先覆盖一个团队、一个短周期和几类关键角色。不要同时推广到全组织，也不要要求每个成员记录每一分钟。先把最影响承诺判断的信息补齐：计划周期、休假、固定会议、支持轮值、工作量估算、负责人、依赖和实际结果。

如果团队目前连计划工时都没有，先用任务数量、需求规模或故事点建立相对基线也可以，但要明确它只能用于同团队、同口径比较。等团队积累了足够的交付记录，再逐步加入可用工时和角色容量。过早引入复杂模型，只会增加维护成本。

2. 迭代开始前，先完成三项核对

• 日历核对：确认休假、节假日、固定会议、培训、值班和发布窗口，不要等迭代中途才发现成员缺席。
• 需求核对：检查优先级、验收条件、依赖团队和需求成熟度。尚未明确的工作应标注区间和假设。
• 角色核对：逐一确认产品、设计、开发、测试、数据、安全或运维等关键角色是否有可用容量。

这三项核对的顺序有实际意义：先知道人何时可用，再知道工作是什么，最后确认工作能否由对应角色完成。反过来先把需求装进迭代，再临时找人接手，往往会把缺口留到交付末端。

3. 迭代中途只在重要变化时重新评估

容量规划不需要每天全量重算，但出现关键变化时必须更新。适合触发重新评估的事件包括：高优先级需求插入、关键成员缺席、重大线上事故、外部依赖延期、需求范围明显变化，以及测试或发布窗口调整。

每次重新评估时，不要只修改计划数字。记录变化发生的日期、影响角色、被挤出的工作和决策责任人。这样复盘时才能判断计划偏差来自估算、执行还是优先级变化，也能避免团队把新增工作误算成原计划未完成。

4. 迭代结束后复盘系统误差，而不是排名个人

复盘建议围绕三个问题展开：哪些工作按计划完成？哪些工作偏离预估，主要原因是什么？下一周期需要改变哪个机制？如果重复发生的原因是需求进入过晚，就改进需求准备；如果支持工作经常打断计划，就调整轮值和容量；如果测试总在末尾积压，就提前安排测试活动。

复盘不必追求每个小时都精准。对于产品决策，更重要的是辨认误差方向、风险类型和可干预环节。容量数据的精度应该服务于决策需要：判断项目是否可做，可能只需 10% 的区间；排班或合同核算，才可能要求更细的时间记录。

5. 用工具时，先设计数据责任，再配置页面

无论使用电子表格还是项目管理平台，都需要明确谁更新什么数据、多久更新一次、哪些变化必须留痕。任务负责人更新工作量，项目负责人确认优先级，资源协调者检查跨项目冲突，产品负责人决定范围取舍。没有责任分工，系统中的“实时数据”很快会变成过期数据。

对于中大型团队，可以在 PingCode 这类项目管理平台中关联项目、迭代、任务和负责人，再结合资源视图识别冲突。部署时应先确认系统字段与团队现有估算口径兼容，并通过一个团队试运行。不要把工具里的默认报表直接当成组织管理标准，更不要在数据质量未经验证时用来做绩效评价。

6. 让容量看板回答决策问题

一个实用看板不需要堆满图表，至少要让产品经理快速回答：当前周期承诺是否超过可用容量？哪个角色是瓶颈？新增需求会挤掉什么？关键依赖是否已确认？实际偏差主要由什么造成？如果页面只能显示“某某负载 103%”，却不能解释工作来源和调整选项，它还不够支持决策。

建议将看板拆成三类信息：容量输入包括日历、角色和固定占用；执行过程包括任务、依赖、变更和支持工作；结果反馈包括完成量、偏差、延期原因和返工情况。这样既能看当前风险，也能通过历史记录校准下一周期。

七、不同情况下的行动建议：不要用同一种容量模型解决所有问题

1. 小团队或单一产品线：先用轻量方法建立共同语言

团队规模较小、项目数量少时，可以用共享表格或看板记录周期、成员、可用天数、固定占用、任务工作量和风险备注。重点不是上线复杂系统，而是让所有人按同一口径讨论：什么算可用容量，支持任务是否计入，需求变化如何调整。

当成员主要负责单一产品、跨项目冲突不多，团队速度和任务完成情况可能比逐人精确工时更有价值。不要为了“专业化”把每项工作拆到过细，否则维护表格的时间可能超过它节省的协调成本。

2. 多项目共享关键岗位：建立统一的资源冲突入口

当设计、测试、数据或安全等岗位同时服务多个项目时，项目内部排期不足以解决问题。需要有一处统一查看各项目需求、截止时间、负责人和工作量的入口，并明确冲突由谁裁决。最重要的不是让每个项目都拥有完整资源，而是让优先级冲突在承诺之前被看见。

如果一个关键岗位经常被多个项目同时争抢，可进一步设置服务等级或预约规则。例如紧急线上修复优先于计划需求，法规截止任务高于一般体验优化。规则必须由有权决定优先级的人认可，否则资源负责人会被迫在不同项目之间承担隐性取舍。

3. 高不确定性探索项目：用范围区间和阶段门

探索性项目早期通常缺少稳定需求，逐项估时的误差很大。此时更适合用人周、预算区间或阶段性资源上限来规划，例如先投入有限容量验证关键假设，再决定是否扩展范围。容量管理的重点是控制试错成本，不是提前预测完整产品的每个任务。

阶段门应规定何时继续、何时调整、何时停止。若用户验证结果未达到预设标准，不应因为“资源已经排了”就继续投入。已投入资源是沉没成本，未来容量应根据新增证据分配。

4. 运维和支持占比高：把服务工作纳入容量，不要藏起来

对于线上支持、客户问题和维护工作频繁的团队，应把值班和支持工作显式纳入计划。可以设置轮值容量、服务队列和应急缓冲，并定期观察支持工作占总容量的比例。如果支持工作长期挤压产品迭代，问题可能不在计划能力，而在产品稳定性、自动化或运营流程。

需要注意，不能把所有未计划工作都归为“突发”。如果某类问题反复出现，它已经是可预测的需求，应进入容量模型或专项改进计划。把重复发生的问题一直称为突发，会让组织永远低估真实成本。

5. 组织规模大、团队口径多：先统一最小数据标准

中大型组织不必要求所有团队采用同一套估算技术，但至少要统一周期定义、工作状态、角色名称、实际工作记录口径和偏差原因分类。比如一个团队的“完成”指代码合并，另一个团队指正式发布，汇总交付数据时就会产生口径偏差。

可以保留团队内部的故事点或相对估算，同时在组织层使用更稳定的共同字段，例如角色容量区间、已承诺事项、风险等级和交付窗口。对外汇报时说明数据来源、假设和更新时间，不要把团队局部速度拿来直接做跨团队排名。

6. 管理者要求“资源利用率更高”：先问提升的是哪一种效率

如果组织希望提高利用率，先确认目标究竟是减少闲置、提高按期交付、缩短需求等待，还是降低成本。这些目标不总是一致。把所有人排满可能提高账面利用率，却增加等待、切换和返工；若交付可靠性下降，整体效率反而变差。

可先对比三类结果：承诺完成率、需求从开始到交付的周期、返工与线上问题占用。若利用率提高但交付周期变长、返工增加，就不应继续加码排满。优秀的容量机制优化的是系统吞吐与可预测性，而不是单个成员的忙碌程度。

八、不同情况下的取舍：容量管理没有一个永远正确的答案

1. 精确记录与低维护成本之间的取舍

记录越细，越容易发现时间流向，但维护负担也越高。高风险交付、合同计费或监管场景可能值得细记；常规产品团队则未必需要记录每次短暂沟通。判断标准是：更细的数据是否会改变决策？如果不会，增加记录只是在增加流程成本。

可以从较粗粒度开始：按任务或半天记录，观察一个月后是否仍无法解释偏差，再决定是否细化。先确认数据可以被稳定使用，再提高精度。虚假的精确比诚实的区间更危险，因为它会让管理者误以为结果有确定性。

2. 资源利用率与交付稳定性之间的取舍

利用率偏高，短期可以承接更多计划；代价是吸收变化的余地变小。利用率适度偏低，可能看起来不够饱和，却能让团队更快处理紧急问题和依赖变化。选择哪一种，取决于工作可预测性、服务承诺和延误代价。

对于高可预测、低紧急度工作，可提高计划负载；对于线上故障、探索项目或强外部依赖工作，应保留更大缓冲。不要用一个统一负载目标覆盖所有团队，也不要把缓冲当成可随时塞入新需求的空白地带。

3. 标准化与团队自治之间的取舍

标准化有助于组织汇总和资源协调，但过度统一会削弱团队对工作特征的表达。故事点适合团队内部相对估算，人时适合明确排班和服务工作，阶段预算适合探索性项目。组织可以统一字段和治理要求，同时允许不同工作类型采用适合的估算方法。

我建议把统一范围放在“决策接口”，而不是所有团队内部的计算细节。跨团队汇报需要说明容量区间、承诺范围、关键风险和口径；团队内部则可以保留最能帮助执行的估算方式。

4. 增加资源与减少范围之间的取舍

增加资源并不总能立即增加产能。新成员需要熟悉系统、环境和业务，团队还要花时间分配任务和协作。对于高度耦合的工作，增加人数可能增加沟通成本，短期交付甚至会变慢。

减少范围也不是免费选择，它可能影响用户价值、商业目标或上线完整性。产品经理应把取舍说清楚：新增资源的到位时间和上手成本是多少；减少范围会影响哪些用户或指标；延迟交付会错过什么窗口。把代价摆在桌面上，团队才能做真实决策。

5. 统一团队速度与尊重工作差异之间的取舍

组织常希望获得统一产能口径，但不同团队的技术栈、产品成熟度、依赖数量和质量门槛不同。强行比较团队速度，会鼓励团队优化数字而非交付。可以比较过程指标，例如计划变更频率、依赖等待时间和偏差原因；对于绝对产能，应避免脱离工作背景做排名。

在确实需要组合投资决策时，可用成本、风险、预期价值和交付区间作综合比较，而不是只比较人均故事点。资源分配是经营判断，不是数学模型自动给出的答案。

九、常见问题 FAQ：把 Capacity 用对的几个边界

1. Capacity 和 Velocity 有什么区别？

Capacity 描述未来周期可用的资源和工作承接空间；Velocity 描述团队过去完成工作的节奏，常用故事点或其他团队内部单位表达。Capacity 更偏向计划输入，Velocity 是历史观察。它们可以共同辅助规划，但不同团队的 Velocity 通常不能直接横向比较。

2. 负载率超过百分之百时，是否一定要延期？

不一定，但必须有明确处理动作。团队可以减少范围、延长时间、增加合适资源、调整服务承诺，或接受更高风险。若既不减范围、不增资源、不延时间，却仍维持原承诺，那么超载数字只是在记录一个不可执行的计划。

3. 没有历史数据时，缓冲比例怎么定？

先根据任务类型和已知风险做区间估算，并标记为初始假设。每个周期结束后记录计划与实际差异，连续观察数个周期再调整。不要把首次采用的比例包装成最佳实践，也不要因为一次偏差就大幅修改所有计划。

4. 个人容量数据可以用于绩效考核吗？

不建议直接使用负载率或估时偏差做个人绩效结论。它们受到任务难度、依赖、角色职责、支持工作和需求变化影响。若用于管理对话，应先检查工作分配和系统条件；个人绩效需要结合交付质量、协作贡献、职责范围和持续表现综合判断。

5. 产品经理该用人时、故事点还是任务数量？

看决策目的。需要排班、支持轮值和合同核算时，人时更直接；团队稳定、采用敏捷估算时，可用故事点和历史速度；工作高度相似且节奏固定时，任务数量可能足够。关键是口径一致，并且不要把不同单位强行相加。

6. 是否应该把所有会议都计入容量？

固定且占用明显的会议应纳入可用时间核算。短暂沟通不必逐条记录，但如果沟通频繁到持续打断工作，可以通过日历抽样或团队观察估计其影响。重点是确保容量计划没有系统性忽略真实工作，而不是追求每分钟留痕。

十、结尾：先让团队看见约束，再谈效率提升

Capacity 最有价值的地方，不是证明每个人有多忙，而是把“我们能不能接”变成有证据、有前提、有选项的讨论。一个靠谱的计划会说明可用时间从哪里来、风险缓冲为什么这样设、哪个角色构成瓶颈，以及超载时由谁决定减少范围、延后交付或增加资源。

我建议下一步只做一件具体的事：挑选一个即将开始的迭代，按角色列出可用容量、已知占用和计划工作量；在迭代结束后，把偏差分成需求变化、支持工作、依赖等待、估算误差和返工几类。连续观察数个周期，再调整缓冲和承诺规则。

真正成熟的容量管理，不是把资源表填满，而是让组织在承诺之前看见代价。产品经理效率的提升，也不是多做一张表，而是更早识别约束、更快推动取舍，并减少团队把不可执行计划误当成目标的次数。