Capacity怎么做？研发团队数据分析：资源负载从0到1

研发团队做 Capacity 分析，最容易犯的错不是算错工时，而是把“每个人看起来有多少空闲”误当成“团队还能接多少工作”。一个团队账面上有 12 名工程师，每人每周可工作 40 小时，似乎拥有 480 小时产能；但扣掉会议、值班、支持、休假和跨项目切换后，真正能投入计划工作的时间可能不到 300 小时。Capacity 要做的不是把人头乘以工时，而是把可用时间、工作类型、技能约束和承诺风险放进同一套决策框架。

我建议从一个可验证的小范围开始：先统一“可用产能”和“已承诺工作”的定义，再选一个团队、一个迭代周期，连续记录 4 至 6 周。不要一开始追求全公司实时大屏，也不要把容量表做成员工利用率排名。Capacity 的价值在于让团队更早发现承诺过量、关键技能单点和支持工作挤占计划的情况，最终帮助管理者回答三个问题：我们能接多少、为什么不能再多接、需要改变什么条件才可以接。

一、先讲核心结论：Capacity 不是工时总和，而是可兑现承诺

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

在研发资源分析中，我会先区分产能、负载和利用率。产能是某个时间窗口内，在既定人员、日历、职责和约束下可用于工作的时间或相对能力；负载是已经计划或正在发生的工作所占用的资源；利用率则是实际投入与某个可用基数的比值。三者有关联，但不能互相替代。

如果团队把“每周 40 小时”直接当作每个人的产能，就会把所有未登记的工作都误判为空闲。会议、代码评审、线上故障、技术支持、招聘面试和临时协调往往不是不存在，而是没有进入计划系统。模型因此看起来精确，结果却持续偏乐观。

我更愿意把 Capacity 定义为：在明确的时间范围、团队边界和工作规则下，团队可以较有把握地兑现的工作承诺。这里的“较有把握”很重要。容量估算不是物理定律，而是有误差、有条件、有置信程度的决策依据。

2. 容量要回答决策问题，不是制造一个漂亮数字

一张资源负载报表如果只能告诉管理者“某人本周占用 92%”，却不能解释其中多少来自产品迭代、线上支持、代码评审或会议，就很难支持行动。真正有用的分析，至少要能回答：超载从哪里来、哪些工作可以调整、调整后风险会转移到哪里。

举例来说，某团队下个迭代看起来有 30 人天可用，但其中 8 人天来自一位唯一熟悉支付对账模块的工程师。如果两项高风险任务都依赖他，团队的总容量并没有变，真正可承诺的容量却可能显著下降。瓶颈不是总工时，而是技能供给和任务依赖。

因此，我通常把 Capacity 分析拆成四层：日历可用时间、工作类别占用、技能与角色约束、承诺结果校准。前两层告诉我们“时间在哪里”，第三层解释“为什么总量不能随意互换”，第四层验证模型是否能支持更可靠的计划。

3. “满载”通常不是最优状态

把每个人安排到 100% 并不意味着资源效率高。研发工作包含不确定性：需求澄清可能反复，线上问题可能插入，评审等待可能延长，跨团队依赖也可能改变。如果计划把全部时间占满，任何小波动都会变成延期、加班或质量折损。

我会把容量看成一个带缓冲的计划区间，而不是必须填满的槽位。缓冲不是浪费，而是对波动的承认。团队越依赖外部输入、线上支持越不稳定、任务越新颖，计划就越需要保留余量。相反，对于流程稳定、工作项较小、历史预测误差较低的团队，可以逐步提高计划占用，但仍不应把满载当成目标。

二、背景和真实场景：为什么资源负载会失真

1. 计划工作只是研发工作的一部分

研发团队的时间通常分散在多种工作之间。产品需求开发只是其中一类，此外还包括缺陷修复、技术债治理、代码评审、发布保障、线上支持、客户问题定位、内部工具建设和必要的知识传递。不同团队的工作组合差异很大，因此单一的“研发人天”并不能天然代表相同的交付能力。

我见过不少容量表只登记产品迭代任务，结果团队每个迭代都显得计划合理，实际交付却总被支持工作打断。复盘时，大家再把偏差归结为“估时不准”。但如果线上支持本来就占据稳定比例，这不是估时问题，而是容量模型遗漏了工作类别。

解决方法不是把每一分钟都记录下来。对大多数团队而言，先把时间归入少数几类就足够：计划交付、运行保障、协作与治理、不可预期工作。分类的目标是发现结构性占用，不是建立微观监控。

2. 人员数量相同，不代表可替换能力相同

总工时模型隐含一个假设：团队成员之间可以任意替换。现实往往相反。某个服务只有一位成员熟悉，某类测试环境只有少数人能维护，某项架构决策必须由特定角色审核。团队总容量即使充足，关键技能所在的局部容量也可能已经超载。

我会把技能约束视为“容量的形状”，而不仅是容量的总量。团队可能有 300 小时可用，但其中后端开发 140 小时、测试验证 70 小时、数据迁移 24 小时。若承诺的工作需要 40 小时数据迁移能力，总工时尚有余量也没有意义。

3. 资源分析既是数据问题，也是信任问题

如果员工认为容量数据将被用于比较谁更忙、谁效率更高，就会倾向于高报工作量、低报空闲，或者把任务拆分成更难解释的记录。数据表面上变得完整，决策质量反而下降。容量模型要获得真实输入，必须明确使用边界：它用于团队级计划和系统性瓶颈分析，不用于把个人工时直接换算成绩效排名。

对于 100 人以上的组织，这个问题会更明显。跨团队依赖、不同项目节奏和角色定义不一致，会让统一仪表盘看起来整齐，却把各团队的实际差异抹平。以 PingCode 这类面向中大型企业和 100 人以上组织的平台为例，工具可以帮助汇总项目、迭代、任务和人员信息，但字段能否统一、数据是否按同一口径填写，仍决定了分析是否可靠。

我不会因为平台可以汇总数据，就默认汇总结果可以直接比较。平台解决的是采集、关联和展示效率；团队需要负责定义容量口径、工作分类、责任边界和决策规则。

4. 建模前先确定“看谁、看多久、看什么工作”

Capacity 的边界至少包含三个维度：组织范围、时间窗口、工作范围。组织范围可以是一个稳定团队，而不是跨越多个汇报线的临时集合；时间窗口可以是迭代、月度或季度；工作范围则要明确是否包含支持、治理、培训和休假等内容。

边界不清时，同一份数据会出现不同解释。例如，某项目负责人只统计需求开发，工程经理却把线上支持也算进去；某团队按自然周估算，另一个团队按迭代周期估算。两边数字都可能正确，却不适合直接对比。

三、常见误区：数字看起来越精细，结论未必越可靠

1. 误区一：用人数乘以标准工时推导产能

“10 个人乘每周 40 小时等于 400 小时”只适合作为名义工时起点，不是交付容量结论。它没有扣除休假、法定假日、固定会议、值班、必要协作，也没有考虑成员实际承担的职责差异。

如果团队希望从名义工时开始，至少应逐项扣除可确定的日历时间，再为波动工作建立单独的预算。对于稳定的支持工作，可以用近期实际占用的中位数或分位区间估算；对于故障等低频高影响事件，则应结合事件记录和风险承受能力，而不能只看单月平均。

不要把所有扣减项都合并成一个未经解释的“效率系数”。一个固定的 80% 系数可能在某团队过于保守，在另一个团队又过于乐观。系数可以用作临时起点，但应尽快拆解成可观察的工作类别。

2. 误区二：把计划容量当作员工工作时长指标

Capacity 用来改善团队承诺和资源配置，不是测量个人价值。一个人某周任务较少，可能是因为他在处理架构风险、辅导新人、排查线上问题，或者等待跨团队输入。若只盯着任务填充率，团队就会受到“尽量让每个人看起来很忙”的激励。

这会带来两种典型后果。第一，团队过度拆分工作，增加同步和切换成本；第二，员工为了避免空闲印象而提前承诺任务，使计划变得更加脆弱。容量分析应观察系统负载和瓶颈，不应把个人空档自动认定为低效。

我更关注团队是否持续兑现合理承诺，而不是每个人是否持续满载。如果团队有适当空闲，却能减少延期、降低线上风险并改善响应速度，这种容量安排可能比表面满载更有效。

3. 误区三：把所有工作换算成同一种工时

工时有助于观察占用，但并不意味着不同工作可以无损互换。8 小时需求开发和 8 小时事故响应，在日历上都是 8 小时，在上下文切换、不可预期性和对计划的破坏程度上却完全不同。

如果团队只看总工时，就会忽略切换造成的碎片化。一位工程师上午处理客户问题、下午参加评审、傍晚继续开发，即使登记为 8 小时有效工作，也未必产生 8 小时连续开发的效果。对需要深度专注的工作，时间块和连续性可能比总量更关键。

4. 误区四：把故事点、工时和容量直接混成一个数

故事点是团队用于相对估算的尺度，工时是日历时间，容量是特定窗口内可承担工作的能力。三者可能有关联，但不存在适用于所有团队的固定换算。把 1 个故事点直接定义为若干小时，通常会让相对估算退化成隐性工时承诺。

如果团队使用故事点，可以用已完成工作项的历史分布辅助计划，不要为了方便汇报而强行转成精确人时。若管理者必须知道资源投入，应单独记录投入类别与时间范围，并明确它与工作项估算的用途不同。

5. 误区五：把预测误差都归咎于个人估时

计划偏差可能来自估算，也可能来自需求变更、依赖等待、环境故障、支持插入、人员缺席或工作范围变化。没有原因分类，就无法知道应该改进估算、压缩批量、处理依赖，还是重新配置支持责任。

我建议把未按计划完成的工作分成至少四类：工作量估算偏差、范围变化、外部等待、意外插入。分类不用追求复杂，但要能区分“原来没想到要做”和“已经承诺却没能完成”。否则团队会通过不断提高估算来掩盖系统性阻塞。

6. 误区六：用月度平均数掩盖峰值和局部瓶颈

平均支持负载每周 20 小时，并不意味着每周都可以稳定留出 20 小时。真实情况可能是大多数周只占 8 小时，少数周突然占到 50 小时。只看平均值会低估峰值风险，只按最高值规划又可能长期压低计划容量。

对波动较大的工作，我会同时查看中位数和高分位数，并把两者用于不同决策。中位数适合描述典型周，高分位数适合评估保障能力或准备缓冲。具体取哪个分位，取决于故障后果、响应承诺和团队可承受的延期风险。

四、专业判断逻辑：从可用时间到可兑现承诺

1. 第一步：明确分析单位和周期

开始建模前，我会先写下一句可被团队共同确认的话，例如：“本分析覆盖支付研发小组，观察未来两个迭代，以团队可完成的计划交付工作为目标，包含值班支持和固定治理工作，不用于个人绩效比较。”这句话看似简单，却能提前暴露边界争议。

分析单位不一定越小越好。若团队角色稳定、依赖较少，可以在小组层面测量；若多人频繁跨项目，则需要同时看项目占用和团队共享工作。对矩阵组织而言，个人作为容量单位可能很直观，却容易让计划变成资源争抢；以稳定团队作为单位通常更适合交付预测。

时间窗口也应与决策节奏匹配。迭代计划适合看未来一至数周的可执行性，季度规划适合看岗位、技能和团队配置，不适合承诺具体任务细节。把短期波动直接外推到季度，或者用季度平均数安排下周工作，都会产生误用。

2. 第二步：计算日历可用容量

对每个成员，可以先从计划窗口内的工作日和标准工作时间开始，再扣除已知的休假、培训、法定假日及其他固定缺席。团队层面的日历容量可以简单表示为：

日历可用容量 = 观察窗口内名义工作时间 − 已知非工作时间

如果团队成员工时制度不同，应按个人日历计算后汇总，不要假定每个人的可用时间相同。兼职、轮班、值班和跨时区安排也要纳入边界。计算结果是“人在日历上可工作的时间”，尚未扣除工作本身的结构性占用。

3. 第三步：扣除稳定的非交付占用

接下来统计会议、代码评审、值班、发布保障和固定支持等工作。这里的关键不是让每个人精确记录到分钟，而是建立团队可接受的分类，并让记录粒度足以区分主要成本来源。

对于固定会议，优先使用日历和会议周期推算；对于支持工作，使用工单、值班记录或事件记录；对于代码评审等协作活动，可以先抽样观察 2 至 4 周，判断它是否构成稳定负担。长期稳定的活动应该纳入容量模型，而不是每次计划时都假装它不存在。

团队初期若没有可靠记录，可以先用成员共同认可的估算区间，例如每人每周约 4 至 7 小时用于评审和协作。此时必须标注这是初始假设，而不是事实。接下来用实际记录逐步校准，并保留假设变更历史。

4. 第四步：识别技能、角色和依赖约束

时间总量扣减完毕后，还要检查工作是否落在正确的角色和技能上。我通常用轻量技能矩阵，而不是追求复杂的能力评分。矩阵只需要标记关键领域的熟悉程度、可独立承担人数、审核或交接限制。

例如，某项数据迁移工作需要两名熟悉数据库迁移流程的成员，其中一人还要承担值班。如果未来两周只有一人能独立完成迁移，那么团队总工时再充足，也不能简单接受需要双人并行的计划。可选动作可能是调整批次、安排结对、引入其他团队协助或推迟承诺。

技能矩阵应服务于风险识别和能力建设，不应变成员工贴标签。能力会随项目经验和知识传递变化，矩阵应定期更新，并记录“目前依赖单点”而不是将单点固化为个人身份。

5. 第五步：为不确定工作设置不同置信度

并非所有任务都适合同一种容量折扣。成熟的常规功能、首次探索的技术方案、需要外部审批的集成和高风险数据迁移，其不确定性来源不同。与其统一把所有任务增加 20% 缓冲，不如按任务类型和历史结果校准。

对稳定工作，我会用近期实际完成量估计常态能力；对未知工作，我会采用短周期验证、技术探针或分阶段承诺；对外部依赖，我会把等待和交付责任单独列出，而不是把整个风险都加进开发工时。这样管理者能够看见风险究竟来自哪里。

Capacity 输出最好是区间和条件，而不是只有一个小数点后两位的数字。例如：“在无重大线上事件、测试环境按期就绪的情况下，团队可承诺 8 至 10 个中等规模工作项；若支持负载高于每周 24 小时，应优先下调一个工作项。”这样的结论比“容量为 86.4%”更便于决策。

6. 第六步：用承诺结果反向校准容量

计划不是模型的终点，兑现结果才是。每个周期结束后，比较计划工作与完成工作，同时查看未完成原因、临时插入、缺陷返工和范围变化。不要只问“完成了多少”，还要问“为何这部分没有完成”以及“是否通过加班才完成”。

如果团队连续多个周期承诺过量，就要检查容量假设是否过高、工作项是否过大、外部依赖是否不稳定，或者是否存在持续插入的未计划工作。如果团队经常完成计划且仍有大量未使用时间，再逐步增加承诺，并观察质量和支持响应是否恶化。

校准时不要被单个周期牵着走。一次线上事故可以显著改变结果，但不一定说明团队的常态容量已经永久下降。至少观察数个周期，结合分布和事件背景再调整。

五、具体案例：一个 12 人团队如何从“总工时充足”发现局部超载

1. 先说明案例数据的性质

下面的案例是基于常见研发计划场景构造的样本推演，不代表某家企业的真实项目数据，也不是行业基准。它的目的，是展示如何从团队名义工时逐步推导可承诺容量，并说明数字之间的因果关系。

设一个 12 人的产品研发团队，计划窗口为两周，每周按 40 小时名义工作时间计算。名义工时为 960 小时。团队成员中包含后端、前端、测试和平台角色；两周内有成员休假，且需要承担线上支持、评审、发布保障和跨团队协作。

2. 从总工时逐项扣减

先扣除已知休假和非工作日影响，共计 48 小时；再扣除固定会议和团队协作 96 小时；根据近期支持记录为线上支持和缺陷处理预留 120 小时；代码评审、发布保障和技术治理合计占用 88 小时。剩余的 608 小时，是可以进入计划评估的时间，不等同于可以无条件承诺的产能。

团队随后检查角色分布，发现 608 小时中，后端相关可计划时间约 250 小时，前端约 150 小时，测试约 118 小时，平台和数据迁移约 90 小时。某个关键数据迁移工作需要 60 小时，而团队只有一位成员能独立处理，且他还要承担 16 小时值班。于是，平台相关工作可用时间不能只按总量 90 小时理解。

这一步改变了原计划。产品负责人原本依据 608 小时，提出 20 个中等规模工作项；团队结合角色容量和依赖关系，判断其中 4 个工作项集中依赖数据迁移能力。经过拆分和排序后，团队承诺 16 个工作项，另将 2 个作为条件承诺，剩余 2 个暂不进入本周期。

3. 为什么不直接把 608 小时塞满

如果把 608 小时全部换成计划任务，模型仍遗漏了两种风险：临时支持超过预留，以及角色之间不能自由替换。团队因此设置了一个可调整的风险缓冲，并把条件承诺与支持负载挂钩：若第一周支持占用超过 24 小时，第二周先不启动一项低优先级迁移工作。

这里的重点不是“16 个任务”一定比“20 个任务”正确，而是团队明确了接受 16 个任务的依据、另外 2 个任务启动的条件，以及发生高支持负载时的取舍顺序。Capacity 让模糊的“感觉有点忙”转成可讨论的资源约束。

4. 周期结束后怎样读结果

在样本推演中，团队最终完成了 15 个已承诺工作项，另有 1 项因外部接口环境延迟而未完成。两项条件承诺中，第一周支持负载达到预警线，因此团队没有启动低优先级迁移工作。实际支持占用为 136 小时，比预留多 16 小时。

如果只看完成率，可能会得出“计划不够准确”的结论。但原因分析显示，团队主要问题不是开发估时，而是支持负载高于预留且外部环境延迟。下一周期可考虑提高支持预留、改善接口环境准备条件，并继续保留迁移单点风险的缓冲。

5. 案例的专业判断：总量正常，不代表局部健康

从总量上看，团队计划了 608 小时，似乎有明显余量；从技能结构看，数据迁移能力却接近饱和。若管理者只看总工时，会继续向团队追加任务；若只看个人负载，又可能要求关键成员“再多接一点”。真正的判断必须同时看工作总量、角色容量、依赖风险和支持波动。

这个案例还有一个容易忽略的信号：当团队把未计划工作记录下来后，支持负载从“总是有突发情况”变成可观察的时间分布。即使记录仍不完美，讨论也从责任归因转向流程选择，例如是否轮换值班、是否建立常见问题自助处理、是否安排专项偿还技术债。

六、从 0 到 1 的落地方法：先让数据能被讨论，再让系统自动化

1. 第一阶段：用一页规则建立共同口径

启动时不需要先买复杂工具或做全公司数据模型。先用一页规则说明团队边界、计划周期、工作分类、数据来源、更新频率和数据使用边界。负责人应与团队共同确认规则，而不是单方面把字段发下去。

我建议工作分类控制在 4 至 7 类，避免类别太粗而失去解释力，也避免类别太细导致没人愿意维护。一个常见起点是：产品交付、缺陷与运行支持、技术治理、协作与评审、培训与知识传递、临时插入工作。

如果实际工作经常落在“其他”类别，先观察“其他”的具体内容，再决定是否拆分；不要为了报表看起来整齐，提前设计几十个分类。

2. 第二阶段：先收集 4 至 6 周基线

基线期的目标是了解工作结构，而不是立刻调整每个人的排期。团队可以记录实际投入的大类、支持工单或事件、计划外工作以及工作项完成情况。数据采集应尽量复用现有任务、工单和日历，不建议让成员每天额外填写一份重复表格。

基线期要允许数据不完整，并明确哪些结论暂时不能下。比如只记录了部分线上支持，就不能断言支持只占 8%；只观察一个迭代，也不能据此判断团队效率趋势。数据质量说明本身就是分析结果的一部分。

3. 第三阶段：选一个计划问题试点

试点应从一个具体决策问题开始，例如“下个迭代是否能接入这项需求”“值班安排是否导致关键功能延期”“某个关键技能是否形成单点”。问题足够具体，团队才知道哪些数据值得采集。

不要第一步就扩展到所有部门、所有项目和所有管理层级。范围太大时，字段定义和组织边界会先消耗大量精力，最后得到一张看起来全面却无法指导具体行动的仪表盘。

4. 第四阶段：建立每周期的计划与复盘动作

计划前，团队核对日历可用时间、支持预留、技能约束和跨团队依赖；计划中，输出容量区间、承诺工作和条件承诺；周期结束后，复盘实际占用、完成情况与偏差原因。

复盘结果要能改变下一次计划。若每次都发现支持超预留，却不调整支持排班或容量假设，记录只是文档负担。若某项工作总因外部依赖延期，应改善依赖管理，而不是不断增加开发估算。

5. 第五阶段：有稳定流程后再自动化

当团队已经稳定使用工作分类和计划口径，再考虑自动汇总任务状态、迭代周期、人员日历、工单和支持记录。自动化能降低重复操作，但不能替团队决定某项工作属于哪一类，也不能自动判断两个人是否具备可替换技能。

对于 100 人以上的组织，平台化通常能提升跨项目汇总、权限管理和流程一致性。使用 PingCode 等项目管理平台时，我会先核查数据源是否真正能代表团队工作、字段是否被不同团队以相同方式解释、人员和项目关系是否及时更新。若这些基础不稳，自动化只会更快地产生错误结论。

实施时可从团队级视图开始，再逐步扩展到部门层。管理层视图应突出容量区间、关键技能风险、支持负载和承诺变更，而不是把个人利用率做成排行榜。跨团队汇总时，要保留团队口径说明，避免不同工作模式被压缩成一个不可解释的“产能分”。

6. 衡量试点是否成功，关注行为改变而非报表数量

一个容量试点是否成功，不应以创建了多少图表或录入了多少条工时记录来判断。我更愿意检查：计划前是否更早发现超载；临时插入是否有明确取舍；管理者是否开始按风险条件调整承诺；周期复盘是否改变下一轮容量假设。

可以选择少量指标进行观察，例如计划完成率、未计划支持工时占比、工作项延期原因分布、关键技能单点数量和容量估算偏差。每个指标都要写明定义和用途，避免一个数字在不同团队被解释成不同意思。

七、不同情况下的行动建议：容量模型要随工作形态调整

1. 团队工作稳定、任务相似度较高

这类团队可以先按固定周期统计可用时间和已完成工作，使用近 4 至 8 个周期的结果校准计划承诺。若工作项规模稳定、依赖较少，历史完成量会比逐人估时更适合用作计划参照。

仍要保留休假、支持和治理工作分类。即使产品开发相对稳定，团队也可能因发布、评审或技术债活动出现周期性负载变化。稳定不是不需要容量分析，而是更适合用历史数据提高预测一致性。

2. 团队承担大量线上支持或客户问题

支持型团队应优先记录事件到达量、处理时长、严重程度和中断影响，而不仅是总工时。若支持请求持续打断计划开发，可以考虑轮值、分层响应、问题自助化或固定支持窗口，让多数成员获得更连续的工作时间。

容量规划可使用常态和高峰两套情景：常态情景支持负载较低，可以安排常规改进；高峰情景则只承诺必要交付，并优先保障稳定性。不要把低谷周的表现直接外推到整个季度。

3. 团队频繁跨项目、成员共享严重

此类团队容易出现“每个项目都只占一点点，但没人能连续完成”的情况。此时需要记录并发项目数、上下文切换和关键角色分配，必要时限制同时启动的项目数量。单纯把每个人的时间切成 10% 或 20% 分配，并不能消除切换成本。

若项目优先级冲突，应让业务负责人明确排序，而不是要求团队自行在多个承诺之间挤时间。容量分析的一个重要作用，就是把资源冲突呈现出来，让取舍回到有决策权的人手中。

4. 团队刚组建、历史数据很少

新团队不应伪装成拥有精确预测能力。可以先从日历可用时间和必要支持工作开始，采用较宽的容量区间，并把关键假设写出来。前几个周期的主要价值是建立基线和发现工作结构，而不是证明最初估算正确。

同时要明确哪些工作是试验性的。新技术、新业务流程或首次集成，适合拆成短周期验证任务，不宜直接按成熟项目的完成速度承诺大批工作。随着数据积累，再逐步缩小预测区间。

5. 管理层要求跨团队比较资源效率

先确认比较的问题是什么。如果想知道哪些团队存在结构性支持负担，应比较工作类别和支持占用；如果想知道交付是否稳定，应比较承诺兑现情况和变更背景；如果想做人员编制判断，则要看业务需求、技能缺口和风险，而不是只看当前利用率。

在没有统一口径、相似工作结构和可解释上下文前，不建议给团队做单一容量排名。数字排名会把“工作不同”误读为“效率不同”，也会诱发团队改变记录方式来适应排名。

6. 工具数据不完整或多个系统并存

先建立权威数据源清单：哪些系统记录计划任务，哪些记录支持工单，哪些记录人员日历，哪些只是参考。对同一类工作，不要让多个系统都成为彼此不一致的“唯一真实来源”。

数据汇总时保留更新时间和缺失说明。若某团队的支持工单没有完整记录，就把结论标注为低置信度，并安排补齐流程；不要用其他团队的平均值替代该团队实际数据。

八、不同情况下的取舍：准确性、维护成本与管理风险

1. 选粗粒度还是细粒度

粗粒度分类维护成本低，适合刚起步的团队，但难以解释具体负载来源；细粒度分类更有诊断价值，却需要更多填写和治理。我的建议是先用少量大类跑通计划闭环，再根据真实决策需要拆分类别。

判断是否应该拆分一类，可以问：这个拆分会改变管理动作吗？如果“会议”进一步拆为例会、评审和跨团队协调后，确实能帮助减少某类会议或优化评审安排，那么值得拆；如果只是让报表更细，却没有对应行动，就不必增加维护成本。

2. 选工时还是相对工作量

工时适合分析日历占用、支持负载和人力安排；相对工作量适合团队内部比较工作项大小、观察完成趋势。两者服务于不同问题，不必强行统一成一个数字。

如果管理者既需要知道资源投入，也需要预测工作完成量，可以保留两种视角，并明确转换关系没有普适常数。团队之间的相对估算尺度不同，拿故事点横向比较通常不如比较实际工作结构和承诺稳定性可靠。

3. 选个人容量还是团队容量

个人容量有助于发现休假、职责冲突和关键技能单点；团队容量更适合承诺和交付规划。只看个人会强化资源分配思维，只看团队又可能掩盖局部瓶颈。比较稳妥的方式是：以团队作承诺单位，用个人层面的信息诊断限制，但不把个人负载直接当成绩效结论。

对于成员长期跨团队的组织，应明确其主要归属和可用边界。不能让同一份容量在多个项目计划里被重复承诺，也不能在汇总时把跨项目投入重复计算。

4. 选固定缓冲还是动态缓冲

固定缓冲易于执行，适合工作类型和支持波动相对稳定的团队；动态缓冲能响应近期负载变化，但需要更好的记录和解释能力。初期可以采用保守固定值，同时每个周期检查它是否长期偏高或偏低。

当团队数据足够稳定后，可以根据支持负载分位数、任务不确定性和外部依赖情况调整缓冲。不要为了提高计划数字而削减缓冲；缓冲是否合理，应由实际延期、加班、质量和支持响应共同验证。

5. 选统一口径还是团队自治

大型组织需要统一最低口径，例如计划周期、工作分类大类、数据定义和隐私边界，否则汇总后无法解释。团队也需要保留自治空间，因为平台团队、产品团队、保障团队的工作方式不同，统一到同一种容量公式会失真。

可采用“共同核心加团队扩展”的办法：组织统一少量基础字段，团队自行补充有助于决策的细分类别。管理层汇总时保留口径说明，并把比较范围限制在工作形态相近的团队。

6. 选自动化还是人工校验

自动化适合重复、规则清楚的数据汇总，例如从日历读取假期、从任务系统计算计划工作项数量。人工判断适合复杂归类、依赖风险和技能约束。把所有判断都交给自动化，可能得到快速但无法解释的结果；所有工作都手工维护，则容易让模型过时。

建议先自动化低争议数据，再保留关键假设的人工确认。每次计划前让团队检查数据异常，例如重复占用、人员跨项目冲突、未更新的休假和长期未归类工作。自动化负责减少机械劳动，团队负责解释数据。

九、结尾：先让团队能做出更好的取舍，再追求更精细的容量数字

1. Capacity 从 0 到 1，关键不是表格，而是决策闭环

研发团队的 Capacity 分析，不应从“每个人有多少小时”开始，而应从“我们要做什么承诺、承诺依赖什么条件”开始。先统一团队边界和工作定义，再从日历可用时间扣减固定占用，识别支持波动与技能瓶颈，最后用实际兑现结果校准下一周期。

我最看重的不是容量数字有多精确，而是它是否帮助团队更早说清楚：什么能做、什么暂时不能做、需要调整什么条件才能做。能够支持这类讨论的容量模型，即使初期只有粗略区间，也比一张精确到小数点后两位、却无人据此改变计划的报表更有价值。

2. 下一步可以从一个小实验开始

选择一个稳定团队和一个计划周期，写下一页容量口径；回看最近 4 至 6 周的工作，粗分交付、支持、协作和治理；在下一次计划中标出已知缺席、支持预留和关键技能约束；周期结束后只复盘最主要的三类偏差。

如果团队发现数据不足，就把不足本身记录下来，先补足最影响决策的部分。若团队发现总量足够但关键技能不足，就优先处理单点和交接；若支持工作持续挤占计划，就改变支持机制；若容量长期准确但承诺仍不稳定，就进一步检查范围变更和外部依赖。

从 0 到 1 的标准，不是完成一套复杂模型，而是让下一次资源承诺比上一次更有依据、更透明，也更容易在条件变化时及时调整。

常见问题解答（FAQ）