AI资源负载分析要建立在四类依据上：人员与团队的基础档案、工作项与任务的过程数据、资源分配与排期记录、产出与质量侧的证据。把这些数据按统一口径整理成可追溯的数据集，再交给AI做汇总、异常识别与负载均衡建议，结论才站得住。AI输出用于辅助判断，资源调整与绩效评价仍需由负责人确认。下文按数据清单、分析口径、角色分工、示例和完成检查依次展开，过程中会说明ONES在过程数据持续记录上的承载方式。
要点总览（TL;DR）
- AI资源负载分析需要四类依据：人员与角色基础数据、工作项过程数据、资源分配与排期数据、产出与质量证据，缺一类结论就会偏。
- 分析前先统一工时口径与统计周期，再清洗去重，按“人员—周期—任务”组织数据，提示AI输出负载分布、超载空闲名单和瓶颈清单。
- 角色分工要落到交付物：项目负责人确认归属与优先级，成员维护真实工时与状态，PMO制定口径并汇总，团队负责人对调整建议拍板。
- 判断结果是否可用看五项：数据完整性、口径一致性、可追溯性、建议合理性、边界确认；AI输出仅作辅助，不直接用于绩效决策。
- 过程数据靠日常记录沉淀，ONES可承载工作项、工时与迭代排期，减少每次分析临时补录带来的失真。
AI资源负载分析的核心依据清单
负载分析回答的是“谁在什么时间承担了多少工作、是否超出可用产能”。要得出这个判断，数据必须同时覆盖人的产能、任务的量、任务的分配关系和任务的实际消耗。只准备其中一类，AI给出的结论都会偏。下面按四类依据列出用途与最小字段，字段可以先少后全，但关键字段缺失会直接影响结论可信度。
人员与角色基础数据
这类数据定义“可用产能”，是负载率的分母。最小字段包括：成员标识、所属团队、角色、技能标签、可用工时（按周期折算）、投入比例（如某成员在本项目投入50%）。技能标签用于判断任务能否在成员之间转移，投入比例用于处理一人跨多项目的情况。可用工时需扣除已知的请假、培训与公共事务，否则分母偏大、负载被低估。
工作项过程数据
这类数据定义“工作量”，是负载率的分子。最小字段包括：任务标识、任务类型（需求、开发、测试、缺陷等）、优先级、预估工时、实际工时、状态、状态流转时间、所属项目与迭代。状态流转时间能暴露任务在等待、评审、阻塞环节停留多久，是定位瓶颈的主要线索。预估与实际并存，才能看出估算偏差是否集中在某类任务或某个人身上。
资源分配与排期数据
这类数据把人和任务连起来，回答“谁在什么时间段做哪些事”。最小字段包括：任务归属人、计划起止时间、实际起止时间、跨项目占用记录。跨项目占用是负载分析中最容易被忽略的部分：一个人在两个项目各投入一半，单看任一项目都不超载，合起来可能已经满负荷。排期数据还用于判断负载是集中在某几周还是均匀分布。
产出与质量证据
工时数据只反映投入，不反映结果。需要补充交付节奏（按周期的完成任务数或故事点）、返工记录（缺陷回流、需求变更导致的重复工作）、阻塞与延期记录。返工多的成员，实际有效产出低于工时显示的水平；长期阻塞的任务会虚增在制工作量。这类证据让AI的负载判断从“忙不忙”走向“忙得是否有产出”。
时间范围与颗粒度要求
分析周期决定数据颗粒度。按周分析，工时记录需细到天；按迭代分析，需与迭代起止对齐；按项目阶段分析，需保证阶段边界与任务状态流转一致。时间范围至少覆盖一个完整周期加一个对照周期，才能区分常态负载与偶发高峰。颗粒度低于分析周期（如只有月度汇总却要做周分析）时，结论只能停留在趋势层面。
| 依据类别 | 回答的问题 | 最小字段 |
|---|---|---|
| 人员与角色基础数据 | 有多少可用产能 | 成员、角色、技能、可用工时、投入比例 |
| 工作项过程数据 | 工作量有多大、卡在哪里 | 任务类型、优先级、预估/实际工时、状态与流转时间 |
| 资源分配与排期数据 | 谁在何时做哪些事 | 归属人、计划/实际起止、跨项目占用 |
| 产出与质量证据 | 投入是否转化为结果 | 交付节奏、返工、阻塞、延期记录 |
从数据到结论：分析口径与操作步骤
原始数据直接交给AI，得到的往往是笼统描述。可用的分析需要先统一口径、清洗数据，再设计输入与提示，最后对输出做人工复核。以下步骤按顺序执行，每一步都有明确的输入、动作和完成标志。
第一步：统一工时口径
输入是各来源的工时记录，动作是确定唯一计量单位（建议统一为人天或小时，二选一并全程不换）、明确预估与实际的定义边界、规定加班与请假在负载计算中的处理方式。常见做法是把加班计入实际投入但不计入可用产能，请假从可用产能中扣除。完成标志是所有参与分析的数据使用同一单位与同一套加减规则，且规则写成一句话可复述的说明。
第二步：确定分析周期与统计范围
输入是分析目的（看整体负载、查某项目瓶颈、评估下周期排期可行性），动作是选定周期（周、迭代或项目阶段）和范围（全部团队、某项目组或某角色群体）。范围过大会稀释个体超载信号，范围过小则看不到跨项目占用。完成标志是周期起止日期与纳入的人员、项目清单固定下来，后续不再中途变更。
第三步：数据清洗与去重
输入是汇总后的原始记录，动作包括：合并同一任务在多个来源的重复记录（以工作项主记录为准，工时以明细累加）、剔除测试数据与已取消任务、补齐缺失的归属人或时间字段、标记无法修复的缺失项。完成标志是形成一份字段完整率可统计的数据集，并记录每类缺失的比例，供后续判断结论可信度。
第四步：设计AI分析输入与提示
输入是清洗后的数据集与分析问题，动作是把数据按“人员—周期—任务”组织成结构化表格，提示中明确要求AI输出三类内容：按人按周期的负载分布（投入工时/可用工时）、超载与空闲名单（附判定阈值，如负载率超过100%为超载、低于60%为空闲）、瓶颈定位（阻塞时长最长的任务与环节）。提示中应要求AI对每条结论标注依据的数据行，便于回溯。完成标志是AI输出包含分布、名单、瓶颈三部分且每条结论可对应到数据。
第五步：形成输出与人工复核
输出形式建议为三件套：负载分布表、瓶颈清单、资源调整建议草案。建议草案要写明调整对象、调整方式（转移任务、延后排期、补充人力）和预期效果。人工复核节点至少包括：超载判定是否符合实际（如某人短期加班属计划内）、任务转移是否受技能与依赖限制、建议是否与优先级冲突。完成标志是负责人对每条建议给出采纳、修改或驳回的意见，并记录理由。
角色分工与各环节交付物
负载分析失败最常见的原因不是数据不够，而是没人对数据真实性负责、没人对结论拍板。以下分工按环节划分，每个角色都有明确的交付物和交接时点。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目负责人 | 确认任务归属与优先级，判断排期约束 | 任务归属确认表、优先级清单 | 分析启动前 |
| 团队成员 | 维护工时与状态的日常真实记录 | 工时明细、状态更新记录 | 持续进行，周期结束前补齐 |
| 研发效能或PMO角色 | 制定口径、组织数据汇总与清洗 | 口径说明、清洗后数据集、缺失率报告 | 分析执行阶段 |
| AI分析使用者 | 设计分析问题与提示，复核AI输出 | 分析提示、AI输出初稿、复核记录 | 分析执行与复核阶段 |
| 团队负责人 | 对资源调整建议做最终确认 | 采纳/修改/驳回意见 | 分析结束后 |
分工之外，还需要一个承载过程数据的系统，否则工时、状态、排期分散在表格和聊天记录里，每次分析都要重新收集。ONES在这类场景中的作用是让工作项、工时与迭代排期在同一处持续记录：任务的状态流转、预估与实际工时、归属人与计划时间都随日常执行沉淀下来，分析时按周期导出即可，减少临时补录带来的失真。这里的关键是日常记录习惯先建立，工具才有数据可依。
示例：一次迭代的负载分析怎么做
以下为演示情景，用于说明流程，数据为示意值，不代表任何真实团队。
示例背景与数据范围
某研发小组8人，迭代周期两周，包含需求、开发、测试三类任务共46个。数据来源为工作项记录、工时明细和迭代排期。可用产能按每人每迭代10人天计算，扣除已知请假后合计76人天。
数据整理后的负载分布
清洗后按人汇总实际投入工时，得到负载率分布：3人负载率在85%—95%，2人在100%—115%，1人约70%，1人因跨两个项目合计达到125%，1人因请假实际投入偏低。跨项目的那位成员单看本项目只有65%，合并后才暴露超载。
AI识别出的超载与空闲情况
按超载阈值100%、空闲阈值60%判定，AI输出超载2人（含跨项目成员）、空闲1人，并指出空闲成员的任务多为等待评审状态，属于被动空闲而非产能过剩。这一区分直接影响后续建议方向。
瓶颈定位与调整建议草案
AI进一步定位瓶颈：测试环节的任务平均阻塞时长最长，集中在迭代后半段；两名超载成员的阻塞任务中有多个在等待同一评审人。建议草案包括：将跨项目成员的一个非关键任务转给空闲成员（需确认技能匹配）、把评审集中到固定时段以减少等待、将部分测试任务前置到开发中期。
负责人复核后的调整
负责人复核后采纳了任务转移和评审集中两项，驳回了测试前置，理由是上游依赖尚未就绪。被驳回的建议记录理由后留档，作为下个迭代排期的参考。这次分析的价值不在于AI给出了多少建议，而在于每条建议都能回到具体任务和具体人。
完成检查：分析结果是否可用
分析做完不等于可用。以下检查项建议逐条核对，任一项不通过时，应在结论中标注限制，而不是直接对外发布。
- 数据完整性：关键字段（归属人、工时、起止时间）缺失比例是否在可接受范围，缺失是否集中在某类任务或某个人，缺失部分是否已在结论中说明。
- 口径一致性：工时单位、加班与请假处理、周期边界定义是否全程统一，跨项目占用是否已合并计算。
- 可追溯性：每条超载、空闲、瓶颈结论能否对应到具体数据行或任务记录，抽查若干条验证。
- 建议合理性：资源调整建议是否考虑了任务优先级、技能匹配和上下游依赖，是否说明了预期效果与风险。
- 边界确认：AI输出是否明确标注为辅助判断，资源调整是否经负责人确认，分析结果是否被排除在绩效决策依据之外。
把这五项做成固定检查表，每次分析后填写，既能保证本次结论可用，也能积累口径与数据质量的改进记录。负载分析是周期性动作，检查表本身也应随团队数据成熟度逐步调整字段要求。
常见问题
团队工时记录不完整，还能做AI资源负载分析吗？
可以做，但结论要标注限制。先统计关键字段（归属人、工时、起止时间）的缺失比例，判断缺失是否集中在某类任务或某个人。缺失比例较高时，把分析目标从“精确负载率”调整为“趋势与异常识别”，并在输出中说明哪些结论受数据缺失影响。同时把补齐记录作为下一周期的改进动作，而不是等数据完美再开始分析。
跨项目投入的成员，负载应该怎么算？
按人合并计算，而不是按项目分别看。把该成员在所有项目中的实际投入工时加总，除以扣除请假后的可用产能，得到合并负载率。单看任一项目可能都不超载，合并后才暴露真实负荷。分析时需要在数据中保留跨项目占用记录，否则这类超载会被系统性低估。
AI给出的资源调整建议，负责人一定要采纳吗？
不一定。AI建议基于数据模式生成，负责人需要结合任务优先级、技能匹配、上下游依赖和计划内加班等实际情况逐条判断，给出采纳、修改或驳回的意见并记录理由。被驳回的建议留档后，可以作为下个周期排期和口径调整的参考。AI输出定位是辅助判断，资源调整的决策责任仍在负责人。
分析周期选周、迭代还是项目阶段，有什么区别？
周期决定数据颗粒度和结论用途。按周分析适合发现短期超载和排期冲突，要求工时记录细到天；按迭代分析与研发节奏对齐，适合评估下个迭代的排期可行性；按项目阶段分析适合看整体投入结构，但会掩盖阶段内的波动。范围过大会稀释个体超载信号，范围过小则看不到跨项目占用，建议至少覆盖一个完整周期加一个对照周期。
负载分析结果能直接用于人员绩效评价吗？
不建议。负载率反映的是投入与产能的关系，工时高可能来自任务难度、阻塞等待或估算偏差，不能直接等同于贡献大小。绩效评价需要结合产出质量、交付结果和职责要求综合判断。把负载分析定位为资源安排和瓶颈定位的辅助工具，在分析输出中明确这一边界，可以避免数据被误用。
