AI资源负载分析要回答的是：研发资源在需求、任务、缺陷上的投入是否过载、分配是否合理，以及下一周期还能承接多少工作。它把工时、工作项状态和交付结果按统一口径量化，再用指标解释分布。本文给出评估目标、指标定义、数据口径、计算步骤和一个可复算的两周迭代算例，并说明解读边界。文中会自然提到ONES作为承载工时与工作项数据、支持负载归集分析的工具方向。
要点总览（TL;DR）
- 先定评估目标：过载识别看负载率与饱和度，分配合理性看投入结构，产能预测看交付产出与历史负载的结合。
- 负载率=已投入工作量÷可用工作量，饱和度把已分配未完成工作量计入分子，两者分母口径必须固定并在报告中写明。
- 数据口径要覆盖工时填报、工作项状态流转、代码与评审记录三类来源，并预设缺失值、跨项目分摊、兼职折算规则。
- 计算按取数清洗、指标计算、分组对比、异常复核四步走，AI适合承担归集、异常初筛和文字解释，公式与口径由人先定义。
- 负载指标反映投入分布与排期松紧，样本量小、口径变更、跨团队比较时可比性有限，结论应回到排期与协作调整并做前后验证。
评估目标：AI资源负载分析要回答什么问题
负载分析的第一步是把“看看大家忙不忙”转成可回答的问题。不同问题对应不同的分析对象、时间窗和指标组合，先定目标能避免算出一堆数字却无法支撑决策。常见目标有三类：识别过载、判断分配合理性、预测产能。
| 目标 | 要回答的问题 | 主要分析对象 | 决策用途 |
|---|---|---|---|
| 过载识别 | 哪些人或团队在某个时间窗内投入超过可承受范围，集中在哪些工作项类型上 | 个人或小组，按周或迭代 | 调整排期、补充人手、削减范围 |
| 分配合理性 | 需求、任务、缺陷、支持类工作的投入比例是否符合当前阶段重点 | 团队，按月或季度 | 调整工作结构、减少非计划性打断 |
| 产能预测 | 按历史负载与交付节奏，下个迭代可承接多少工作量 | 团队，按迭代 | 迭代规划、承诺量校准 |
分析对象要事先写清楚。以个人为单位适合发现局部过载，但样本小、波动大，结论容易受单个大任务影响；以团队为单位更稳定，适合看结构和趋势，但会掩盖个体差异。实际做法通常是团队层面看趋势，个人层面只在异常复核时下钻。
用途边界同样要提前约定。负载指标反映的是投入分布，用于改进排期、协作方式和工作结构；把它直接当作人员绩效裁决依据，会诱导工时填报失真，反而破坏数据质量。目标确定后，指标选择就有了依据：做过载识别需要负载率和饱和度，做分配合理性需要投入结构，做产能预测需要交付产出与历史负载的结合。
指标与范围：负载率、饱和度与投入结构
负载分析常用四类指标。它们各自回答不同问题，单位和分析单位也不同，混用会让结论失真。下表给出定义与适用边界。
| 指标 | 定义 | 单位 | 分析单位 | 建议时间窗 |
|---|---|---|---|---|
| 负载率 | 已投入工作量 ÷ 可用工作量 | 百分比 | 个人、小组 | 周或迭代 |
| 饱和度 | 已分配（含未完成计划）工作量 ÷ 可用工作量 | 百分比 | 个人、小组 | 迭代 |
| 投入结构 | 各类工作项投入占总投入的比例，如需求、缺陷、支持、技术债 | 百分比 | 团队 | 月或季度 |
| 交付产出 | 时间窗内完成的工作项数量或工作量，可附按期完成率 | 个或人时 | 团队、工作项 | 迭代 |
负载率与饱和度的区别在于分子：负载率看已经发生的投入，饱和度把已排入但尚未完成的工作也算进去，因此更适合迭代开始前判断是否排得过满。两者都需要一个“可用工作量”作分母，分母口径在下一节展开。
投入结构适合回答“团队的时间花在哪”。当缺陷和支持类工作占比持续偏高时，说明计划性工作被频繁打断，这时单看负载率高低意义有限。交付产出则用来对照投入：同样的负载率下，完成量和按期率的变化更能说明问题。
哪些指标适合AI辅助批量计算，哪些需要人工判断，可以按规则明确程度区分。负载率、饱和度、投入结构、完成量这类有固定公式和取数规则的指标，适合由系统按统一口径批量归集和计算；异常识别，例如某成员负载率显著偏离同组分布，也适合用规则或模型先筛出候选。判断“这个偏离是合理的项目冲刺还是排期失误”“支持类工作占比上升是否可接受”，需要结合业务背景由人完成。AI在这里的价值是减少取数和初筛的重复劳动，把人的注意力集中到需要解释的少数异常上。
数据口径：工时、工作项与缺失值怎么处理
不同团队算出的负载率能否比较，取决于取数来源和分母是否统一。口径说明应至少覆盖三类数据源、分母选择和缺失值规则。
第一类是工时填报，直接提供投入量，粒度细但依赖填报习惯，容易出现集中补填或按整天粗略填写。第二类是工作项状态流转，通过计划工时、故事点或状态变更时间推算投入，客观性较好，但只覆盖有登记的工作。第三类是代码提交与评审记录，适合佐证实际活跃度，通常作为交叉验证而非主口径。三类数据各有偏差，选定一类作为主口径后，其余用于复核。
分母选择直接影响结果。可用工时通常按“人数 × 时间窗工作日 × 每日标准工时”计算，再扣除已知的休假、会议和公共事务；计划工时是迭代内已排入的工作量总和；自然日口径简单但会把周末计入，适合粗看趋势，不适合精细比较。三种分母算出的负载率可能相差很大，同一份报告内必须固定一种，并在口径说明中写明。
缺失值和特殊情况需要预设规则，否则各团队自行处理会导致结果不可比。可以参考以下规则：
- 工时未填报：该成员该周不计入负载率计算，同时记录缺失率；缺失率超过约定阈值（如30%）时，该组结果标注为参考值，不参与跨组排名。
- 跨项目分摊：按工时比例拆分到各项目，无法拆分时按项目数均分，并在口径中注明分摊方式。
- 兼职与借调人员：按实际投入比例折算可用工时，折算系数写入人员属性，避免每次手工调整。
- 新入职与离职过渡期：单独标记，不纳入同组均值比较。
这些规则应在分析开始前确定并版本化。口径一旦变更，新旧结果不宜直接对比，需要在报告中标注变更时间和影响范围。
计算与评估步骤：从取数到结论
完整的负载分析分四步：取数与清洗、指标计算、分组对比、异常复核。每一步都有明确的产出，便于他人复算。
第一步，取数与清洗。确定时间窗、人员范围和纳入的工作项类型，导出工时或计划工作量数据，剔除测试数据、重复记录和已关闭的无效工作项，补齐人员属性（所属组、可用工时折算系数）。产出是一张按“人员 × 工作项类型 × 时间窗”组织的明细表。
第二步，指标计算。核心公式如下：
- 负载率 = 已投入工作量 ÷ 可用工作量 × 100%。分子为该时间窗内实际投入的工时或折算工作量，分母为按人数、工作日和每日标准工时计算的可用总量并扣除已知缺勤。
- 饱和度 = （已投入工作量 + 已分配未完成工作量）÷ 可用工作量 × 100%。
- 投入结构占比 = 某类工作项投入 ÷ 总投入 × 100%，分母为该团队该时间窗的全部投入。
- 按期完成率 = 按期完成工作项数 ÷ 应完成工作项数 × 100%，分母只计时间窗内计划完成的工作项。
第三步，分组对比。按团队、角色或工作项类型分组，比较负载率分布而非只看均值，同时观察投入结构与交付产出是否匹配。对比时保持分母口径一致，样本量过小的组单独标注。
第四步，异常复核。对偏离同组分布较远的个体或小组，回到具体工作项核对：是否承接了跨组支持任务、是否有大颗粒需求集中在同一人身上、是否存在工时集中补填。复核结论写入分析说明，作为后续调整排期的输入。
AI辅助分析主要落在第一、三、四步：按统一规则归集多来源数据、识别偏离分布的异常候选、把计算结果整理成可读的文字说明。公式本身和口径规则需要人先定义清楚，AI按既定口径执行，避免每次分析各算各的。在ONES中，项目、工作项、迭代和工时投入属于同一套工作上下文，ONES Assistant可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，适合作为负载归集后的初步解读入口；具体指标口径仍建议在分析前书面固定。
算例：一个两周迭代的负载分析
以下为演示情景，数字为便于复算而设定，不代表任何真实团队。某小组5人，迭代周期10个工作日，每日标准工时8小时，迭代内1人有2天休假。组内共投入需求类工作320小时、缺陷类80小时、支持类40小时，迭代结束时仍有60小时已分配任务未完成，计划完成工作项20个，实际按期完成16个。
先算可用工作量：5人 × 10天 × 8小时 = 400小时，扣除休假 1人 × 2天 × 8小时 = 16小时，可用工作量为384小时。
负载率 = （320 + 80 + 40）÷ 384 × 100% = 440 ÷ 384 × 100% ≈ 114.6%。超过100%说明实际投入超出了标准可用工时，可能来自加班或工时填报口径偏宽，需要复核。
饱和度 = （440 + 60）÷ 384 × 100% = 500 ÷ 384 × 100% ≈ 130.2%。迭代内排入的工作明显超过可用容量，属于排期过满。
投入结构：需求 320 ÷ 440 ≈ 72.7%，缺陷 80 ÷ 440 ≈ 18.2%，支持 40 ÷ 440 ≈ 9.1%。按期完成率 = 16 ÷ 20 × 100% = 80%。
解读时把几项放在一起看：饱和度高、按期完成率偏低，说明问题更可能出在承诺量而非执行效率；缺陷占比接近两成，可进一步核对是否集中在迭代后期，若是，则排期时应预留缺陷处理缓冲。
边界情况也要有规则。若某成员整周休假，其可用工作量为零，负载率分母为零，此时不计算该成员的负载率，标记为“无可用工时”，不计入组均值。若某成员工时缺失率达到40%，按前述规则其数据标注为参考值，组均值计算时同时给出含与不含该成员的两种结果，并在说明中注明差异。
解读与限制：指标能说明什么、不能说明什么
负载指标反映的是投入分布和排期松紧，不能直接推出产出质量或能力高低。负载率高可能意味着任务重，也可能意味着估算偏保守或工时填报偏宽；负载率低可能是产能富余，也可能是工作未被登记。把单次结果与个人评价挂钩，会同时损害数据真实性和分析价值。
可比性风险主要来自三处。样本量小：三五人的小组，一个人的休假或一个大任务就能让负载率大幅波动，此时更适合看趋势而非单点。口径变更：分母从计划工时改为可用工时后，前后数据不可直接比较，需要分段呈现。跨团队比较：不同团队的工作项颗粒度、工时填报习惯和支持类工作占比不同，直接排名容易得出误导性结论，比较前应先对齐口径并说明差异。
结论要回到可验证的改进行动。例如针对饱和度偏高，下个迭代把承诺量下调一档，再观察按期完成率和缺陷占比是否改善；针对支持类工作占比上升，指定固定对接人并单独统计支持工时，看计划性工作是否恢复。改进措施实施一到两个迭代后，用同一口径重算指标，对比变化方向，才能判断措施是否有效。指标本身不构成因果证明，验证需要前后对比和业务侧确认。
在工具层面，负载分析依赖工时、工作项和迭代数据在同一处归集。ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，能理解项目、工作项、迭代等真实工作上下文，并基于用户可访问的数据回答问题、执行后续操作；其输出基于ONES权限体系，过程可追踪、结果可审计。把负载分析的口径规则先梳理清楚，再借助这类能力完成数据归集和初步解读，可以减少重复取数，把讨论集中在排期和协作调整上。
常见问题
团队工时填报缺失严重时，负载分析还能做吗？
可以做，但需要先设定缺失处理规则并标注结果可信度。常见做法是：工时未填报的成员该周不计入负载率计算，同时记录缺失率；缺失率超过约定阈值（如30%）时，该组结果标注为参考值，不参与跨组排名。若缺失集中在少数人，可同时给出含与不含该成员的两种组均值，并在说明中注明差异。更根本的改进是减少填报负担，例如按工作项登记投入而非按天逐条填写，让数据在协作过程中自然产生。
负载率和饱和度都超过100%，说明什么？
超过100%通常指向两种可能：一是实际投入确实超出标准可用工时，来自加班或临时支援；二是工时填报口径偏宽，例如把会议、沟通等未单独登记的时间一并计入。饱和度高于负载率，说明迭代内排入的工作量超过可用容量，属于排期过满。判断时把按期完成率放在一起看：饱和度高而按期完成率低，问题更可能出在承诺量；饱和度高但按期完成率正常，则要复核工时口径是否一致。
不同团队的负载率可以直接排名比较吗？
不建议直接排名。不同团队的工作项颗粒度、工时填报习惯、支持类工作占比和人员构成不同，同一公式算出的数字含义并不相同。比较前应先对齐口径：统一分母类型（可用工时或计划工时）、统一时间窗、统一纳入的工作项类型，并说明各团队的差异。样本量小的团队（如三五人）单点波动大，更适合看多个周期的趋势而非单次排名。跨团队比较的结论应定位为发现差异线索，再回到具体团队核实原因。
AI在负载分析中具体能替代哪些人工环节？
适合交给AI的是规则明确、重复度高的环节：按统一口径归集多来源数据、按公式批量计算指标、筛出偏离同组分布的异常候选、把计算结果整理成可读的文字说明。需要人完成的是口径定义和异常解释，例如判断某成员负载偏高是项目冲刺还是排期失误、支持类工作占比上升是否可接受。ONES Assistant可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，适合作为归集后的初步解读入口，具体指标口径仍建议在分析前书面固定。
负载分析结果能直接用于人员绩效考核吗？
不建议。负载指标反映的是投入分布和排期松紧，负载率高可能意味着任务重，也可能意味着估算保守或填报偏宽；负载率低可能是产能富余，也可能是工作未被登记。把单次结果与个人评价挂钩，会诱导工时填报失真，反而破坏后续分析的数据基础。更稳妥的用法是把结果用于排期调整、工作结构优化和协作方式改进，并在措施实施一到两个迭代后用同一口径重算指标，对比变化方向来验证效果。
