AI研发资源分析要建立在四类依据上：可追溯的工作项与工时数据，说明投入去了哪里；人员负载与技能分布数据，说明谁在承担什么；交付节奏与质量数据，说明产出与返工情况；资源安排规则与历史决策记录，说明建议如何落地。这些依据按统一口径整理成可核验的数据集后，再交给AI做汇总、异常识别和方案草拟，由人确认口径与最终决策。ONES可用于承载工作项、工时与交付记录的管理和留痕，为分析提供可追溯的数据基础。
要点总览（TL;DR）
- AI研发资源分析需要四类依据：投入与工时数据、负载与技能分布数据、交付节奏与质量数据、资源安排规则与历史决策记录，四类依据按统一口径整理后才能交给AI分析。
- 采集前先确定分析对象、时间窗口和统计粒度，把投入、负载、产出、瓶颈四类问题各自对应到具体字段和责任人，避免先导数据后找结论。
- 投入数据以工作项、状态流转和工时登记为核心，缺口部分区分补录与估算并单独标注；负载与交付数据通过“人员＋项目＋时间窗口”关联键拼接。
- AI承担汇总、异常识别和方案草拟，人负责口径确认、背景补充和最终决策，每项AI输出都要有复核结论和留痕。
- 分析结论用于资源安排，不直接作为个人绩效评定依据；交付前用六项检查确认依据链条完整。
先定分析问题与数据口径
资源分析常见的失败方式是先导出大量数据，再试图从里面找结论。更稳妥的顺序是先写清楚要回答什么问题，再倒推需要哪些字段。分析问题清单决定了数据采集的范围，口径定义表决定了不同人导出的数据能否放在一起比较。
第一步是确定分析对象。团队、项目、角色、个人是四种不同的聚合层，同一份工时数据在不同层级的解读完全不同。面向资源调配的分析通常以团队和角色为主、个人为辅；如果分析对象是个人，需要提前说明用途限于工作量分布观察，不用于绩效评定结论。
第二步是确定时间窗口与统计粒度。季度分析通常取13周完整数据，月度分析取自然月，粒度到周或到天取决于工时登记的实际情况。时间窗口要覆盖完整的交付周期，避免把跨月需求截断成两段。
第三步是把“资源分析”拆成四类可回答的问题，并为每类问题定义口径：
| 问题类型 | 典型问题 | 口径要点 |
|---|---|---|
| 投入 | 本季度人力主要投向了哪些项目与工作项类型 | 工时按工作项归集，区分需求、缺陷、技术支持、会议等类型 |
| 负载 | 哪些角色长期处于高并行状态 | 并行任务数按同一时点在手工作项统计，排除已关闭项 |
| 产出 | 交付周期与返工率的变化趋势 | 周期从进入开发到验收，返工按退回次数统计 |
| 瓶颈 | 哪些环节积压最明显 | 按状态停留时长和阻塞记录识别，而非凭印象判断 |
第四步是列出数据来源系统与责任人。每个字段标注来自哪个系统、由谁负责导出、更新频率如何。这份清单是后续所有工作的索引，也是出现数据争议时的对照依据。完成标志是：每个分析问题都能对应到具体字段和具体责任人，没有“到时候再说”的空白项。
核心依据一：投入与工时数据怎么取
投入数据回答“人力去了哪里”，是资源分析中最基础也最容易失真的一类依据。采集时要抓住三个要素：工作项本身、状态流转记录、工时登记记录。
工作项字段至少包括：工作项类型（需求、任务、缺陷、技术支持等）、所属项目、所属团队、负责人、创建与关闭时间、当前状态。状态流转记录用于还原工作项在各环节的停留时长，是判断流程瓶颈的原始材料。工时登记字段包括：登记人、所属工作项、工时数、登记日期、工作内容说明。
归集规则要提前写死。项目维度按工作项所属项目归集，团队维度按负责人所属团队归集，跨团队协作的工作项需要约定主责团队，避免同一份工时被重复计入两个团队。如果组织内存在一人多项目的情况，工时按实际登记拆分，不做平均分摊。
常见缺口是工时登记不全。处理方式有两种：一是要求补录，补录数据标注“补录”及补录日期；二是对无法补录的时段做估算，估算值单独标记“估算”，并在分析结论中说明估算占比。两种方式都不能与原始登记数据混在一起直接汇总，否则后续无法区分数据质量。
数据导出与更新频率按分析节奏设定。季度分析在季度结束后三个工作日内完成导出，导出后冻结为分析基线；分析过程中如需补充数据，新增部分单独版本记录。完成标志是：投入数据字段清单齐全，每个字段有来源和责任人，缺口部分有明确标注。
核心依据二：负载、技能与交付节奏数据
投入数据说明人力流向，负载与交付数据说明这些投入是否合理、产出是否顺畅。两类数据必须能通过关联键拼接，否则只能各自成表，无法支撑瓶颈判断。
负载侧的核心字段是并行任务数、在手工作量和排期冲突。并行任务数按分析时点统计每人处于进行中状态的工作项数量；在手工作量按未完成工作项的预估工时或历史平均耗时折算；排期冲突通过比对同一人在同一时间段被分配的多项任务识别。这三个指标要放在同一张表里看，单看并行任务数容易把短任务误判为高负载。
技能侧需要维护技能标签与关键角色覆盖情况。技能标签由团队负责人确认，标注每名成员的主要技能方向和熟练程度；关键角色覆盖指每个关键角色是否有备份人选。这部分数据更新频率低，但每次组织调整后必须同步，否则AI给出的调配建议可能指向不具备相应技能的人。
交付侧字段包括需求交付周期、返工记录和阻塞记录。交付周期从需求进入开发状态起算到验收通过；返工按工作项被退回的次数和退回原因统计；阻塞记录来自工作项上的阻塞标记或阻塞原因说明。这三类数据共同构成“产出质量”的判断基础。
关联键的设计是这一节的关键。推荐以“人员标识＋项目标识＋时间窗口”作为主关联键，工作项编号作为明细关联键。负载表、技能表、交付表都带上这组键，才能在分析时把“谁在什么项目上承担了多少、交付得怎么样”串成一条线。完成标志是：三张表能通过关联键无损拼接，拼接后的记录数与原表一致。
核心依据三：资源安排规则与历史决策记录
前三类依据回答“现状是什么”，规则与历史决策依据回答“建议能不能落地”。AI可以基于数据给出调配方案，但方案是否符合组织的审批权限、优先级原则和例外约定，需要有一份可对照的规则台账。
规则台账应包含：资源调配的审批规则（谁有权批准跨团队借调、谁批准加班安排）、优先级原则（紧急缺陷、战略需求、常规迭代的排序约定）、例外情况的处理约定（关键角色临时缺位时的替代流程）。规则要写成可判断的条件句，例如“跨团队借调超过两周需双方团队负责人及项目负责人共同确认”，而不是“加强沟通协调”这类无法执行的表述。
历史决策台账记录过去若干次重要调配决策：决策背景、备选方案、最终选择、执行结果。这份台账的价值在于让AI的建议有参照系——如果历史上某类调配反复出现人员流失或交付延期，新建议就应避开同类做法。台账不需要覆盖所有日常安排，聚焦影响范围超过一个迭代的决策即可。
规则会变化，需要指定维护责任人。建议由资源管理或项目管理岗担任规则维护人，每次规则调整记录变更日期、变更内容和生效范围。完成标志是：规则台账中每条规则都有明确的判断条件和责任人，历史决策台账覆盖最近四个季度的主要调配事件。
把依据交给AI：分析步骤与人工复核
四类依据准备完毕后，进入AI辅助分析环节。这一步的分工是：AI承担汇总、异常识别和方案草拟，人承担口径确认、背景补充和最终决策。
第一步是数据清洗与脱敏。清洗包括去除重复记录、统一人员与项目命名、处理缺失值；脱敏包括隐去不必要的个人身份信息，用人员编号替代姓名。脱敏后的数据集才适合提交给AI工具处理。
第二步是向AI描述分析任务与约束。描述中要包含：分析对象与时间窗口、四类依据的数据结构说明、需要回答的具体问题、已知的数据缺口和估算占比、不可逾越的规则约束（如审批权限、关键角色不可同时抽调）。约束写得越具体，输出越接近可用草案。
第三步是接收AI输出。典型输出包括：投入分布汇总、负载异常名单及判断依据、交付瓶颈环节、若干资源安排建议草案。每项输出都应附带其依据的数据字段，便于人工回溯。
第四步是人工复核。复核分三层：口径层，检查AI使用的统计口径与口径定义表是否一致；背景层，补充数据中未体现的信息，如某成员即将休长假、某项目已确定缩减范围；决策层，由决策人确认最终方案并说明采纳或调整AI建议的理由。
复核记录要留痕：记录AI输出的原始版本、人工修改内容、修改理由和最终结论。完成标志是：每个AI输出项都有对应的复核结论，采纳与不采纳都有记录。
角色分工与交付物
这套机制要持续运转，需要把数据、口径、分析、决策四件事落到具体角色上。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 数据提供方（各团队负责人或项目管理员） | 按字段清单导出并提交本团队数据，标注缺口 | 投入、负载、交付数据表 | 分析窗口结束后三个工作日内 |
| 口径维护人（资源管理或项目管理岗） | 维护口径定义表与规则台账，处理口径争议 | 口径定义表、规则台账 | 每次分析启动前确认版本 |
| 分析执行人 | 清洗数据、组织AI分析、整理输出 | 分析报告初稿与复核记录 | 数据齐备后五个工作日内 |
| 复核人（相关团队负责人） | 核对口径、补充背景信息 | 复核意见 | 初稿提交后两个工作日内 |
| 决策人（资源或项目决策岗） | 确认最终资源安排方案 | 决策结论与理由 | 复核完成后 |
结果反馈环节容易被忽略。决策执行后，执行情况应回写到历史决策台账，作为下一轮分析的输入。这样每轮分析都在上一轮结果的基础上推进，而不是每次从零开始。
示例：一次季度资源分析怎么跑
以下为演示情景，用于说明依据如何组合，不代表真实组织数据。
某研发团队在季度结束后启动资源分析。输入数据为：本季度13周的工作项与工时记录、季度末时点的人员负载快照、技能标签表、本季度交付与返工记录、现行资源规则台账及前四个季度的决策台账。
AI汇总输出显示：后端组两名成员连续八周并行任务数超过五项，且承担了本季度大部分紧急缺陷处理；需求交付周期中位数较上季度延长，延长主要发生在测试等待环节；返工集中在两个需求范围反复变更的项目上。
人工复核时补充了背景：其中一名高负载成员已确定下季度初休假两周；测试等待延长与测试环境资源紧张有关，属于已知问题。复核后形成的资源安排建议为：下季度初将紧急缺陷处理职责轮换至另一名具备相应技能的成员，测试环境扩容列入下季度基础设施计划，两个范围变更频繁的项目在需求评审环节增加范围冻结确认。
决策人采纳了轮换建议，测试环境扩容转为专项跟进，范围冻结确认纳入下季度流程改进项。三项结论连同理由回写决策台账，下季度分析时作为对比基线。
完成检查：依据是否够用
分析交付前，用以下清单逐项核对，判断本次分析的依据是否充分、结论是否可信。
| 检查项 | 通过标准 |
|---|---|
| 四类依据是否齐全 | 投入、负载与交付、规则与历史决策均有对应数据集，无整类缺失 |
| 口径是否一致 | 各数据表使用同一时间窗口、同一人员与项目标识，关联键拼接后记录数一致 |
| 数据缺口是否标注 | 补录与估算数据单独标记，估算占比在结论中说明 |
| AI建议是否经人工确认 | 每项建议有复核意见，采纳与调整均有理由记录 |
| 决策结果是否回写留痕 | 最终方案及执行情况已记入历史决策台账，可供下轮对比 |
| 用途边界是否明确 | 分析结论用于资源安排，未直接作为个人绩效评定依据 |
六项全部通过，说明本次分析的依据链条完整，结论可以作为资源决策的参考。任何一项未通过，应先补齐对应依据再交付结论，避免把数据缺口带入决策。
常见问题
工时登记长期不全，还能做AI研发资源分析吗？
可以开展，前提是把数据质量说清楚。处理方式有两种：能补录的时段要求补录，并标注补录日期；无法补录的时段做估算，单独标记为估算值。两类数据都不能与原始登记数据混在一起直接汇总。
在向AI描述任务时，应说明估算占比和涉及范围，让AI在输出中区分“基于完整数据的结论”和“基于估算的推断”。如果估算占比过高，建议先缩小分析范围，例如只分析工时登记较完整的团队或项目，再逐步扩大。
分析对象包含个人时，如何避免结论被当成绩效评定？
关键在于提前写明用途边界。以个人为粒度的数据只用于观察工作量分布和负载均衡，不用于绩效结论。具体做法有三点：分析报告中个人数据以人员编号呈现；结论表述聚焦“任务分配是否合理”而非“谁做得多谁做得少”；个人层面的异常先由团队负责人核实背景，再进入资源调配讨论。
如果组织确实需要绩效评估，应使用独立的绩效管理流程和指标，与本分析分开。
AI给出的资源调配建议与团队实际情况冲突，怎么处理？
这属于正常情况，AI看到的是数据，看不到数据之外的信息。复核时应补充背景，例如成员即将休假、项目范围已确定调整、某人有未记录在技能表中的经验。补充后可以要求AI在新增约束下重新生成草案，也可以由人工直接调整方案。
无论采纳还是调整，都要记录理由。这些记录积累下来，会成为下一轮分析的重要参照，也能帮助逐步完善规则台账和技能标签。
第一次做这类分析，应该从多大规模开始？
建议从一个团队或一个项目集开始，时间窗口取一个完整季度。范围小，数据缺口容易暴露，口径争议也容易在少数人之间达成一致。第一轮的重点是跑通“采集—清洗—AI分析—人工复核—决策回写”的完整链条，而不是追求结论的全面性。
跑通一轮后，再逐步扩大分析对象范围，并把口径定义表和规则台账沉淀为固定资产。每扩大一次范围，先检查新增数据能否用现有口径和关联键拼接。
规则台账和历史决策台账需要多细？
规则台账写到可判断的程度即可，每条规则包含触发条件、审批主体和生效范围，例如“跨团队借调超过两周需双方团队负责人及项目负责人共同确认”。历史决策台账聚焦影响范围超过一个迭代的调配事件，记录决策背景、备选方案、最终选择和执行结果，日常小调整不必逐条记录。
两份台账都需要指定维护人，规则调整时记录变更日期和生效范围，避免分析时引用过期规则。
