做AI研发资源分析，先要准备四类依据：资源投入数据、产出与流动数据、质量与风险数据、AI使用数据。分析开始前先固定统计口径和时间窗口，明确每类数据的来源系统与责任人，再按取数、校验、分析、复核、行动的步骤推进。结论用于资源调配和流程改进，不直接作为人员绩效判定。
要点总览（TL;DR）
- AI研发资源分析的依据分四类：资源投入（工时、任务量、迭代容量）、产出与流动（交付周期、在制品、阻塞与返工）、质量与风险（缺陷、线上问题、评审记录）、AI使用（调用记录、采纳与回退、生成内容评审结论）。
- 分析前先固定口径：明确分析对象、时间窗口与对比基线、指标定义和变更记录，口径表由研发管理者书面确认后生效。
- 执行按五步推进：确认问题与口径、取数与校验、计算与分组对比、结合业务解释差异、形成建议并复核，每步设完成标志。
- 角色分工要落到交付物：研发管理者定口径审结论，项目经理提供业务背景，分析角色负责取数与计算，团队代表核对数据真实性。
- 结论用于资源调配与流程改进，不直接作为人员绩效判定；AI使用数据需与交付、返工等业务结果在同一时间窗口内对照解读。
先定分析问题与统计口径
“分析一下AI对研发资源的影响”这类诉求无法直接执行，需要先收敛成可回答的问题。常见的问题有三类：某团队近两个迭代的人力投入是否被非计划工作挤占；某项目的交付周期延长来自资源不足还是流程阻塞；引入AI工具后，哪些任务的耗时结构发生了变化。问题不同，需要的依据和对比方式也不同。
问题确定后，同步固定口径。口径至少要回答四个字段：分析对象是团队、项目还是迭代；时间窗口取多长，对比基线是上一周期、同类团队还是引入AI之前；每类指标如何定义；口径发生变更时如何记录。口径不固定，跨期对比就失去意义。
建议用一张口径定义表承载这些内容，字段包括指标名、定义、数据来源、统计周期、责任人和变更记录。下表是一个可填写的结构示例。
| 指标名 | 定义 | 数据来源 | 统计周期 | 责任人 | 变更记录 |
|---|---|---|---|---|---|
| 人员投入工时 | 按工作项登记的工时合计，含需求、缺陷、技术支持 | 研发管理平台工时记录 | 按迭代 | 项目经理 | 2025-Q1起将技术支持单纳入统计 |
| 需求交付周期 | 需求进入开发到验收通过的自然日 | 需求工作项状态流转记录 | 按迭代 | 效能分析角色 | 无变更 |
| 缺陷密度 | 测试阶段发现缺陷数/需求工作量 | 测试管理与缺陷记录 | 按迭代 | 测试负责人 | 缺陷严重级别口径调整需留痕 |
| AI生成内容采纳率 | 被采纳的AI生成产出/生成总数 | AI工具使用记录与评审结论 | 按周或按迭代 | 团队代表 | 采纳判定标准变更需留痕 |
口径表在分析启动会上确认，由研发管理者签字或书面确认后生效。中途确需调整，在变更记录中写明调整原因和生效时间，避免前后两期数据被误读为趋势变化。
依据清单：四类数据与取数来源
四类依据分别回答不同问题：投入类回答“资源花在哪里”，产出与流动类回答“工作推进得顺不顺”，质量与风险类回答“代价有多大”，AI使用类回答“AI在哪些环节被用、用得怎么样”。四类数据需要组合解读，单独看任何一类都容易得出片面结论。
| 数据类别 | 关键字段 | 来源系统或记录 | 更新频率 | 缺失时的处理 |
|---|---|---|---|---|
| 资源投入 | 人员、工时、任务量、迭代容量、非计划工作占比 | 研发管理平台的工时登记、工作项分配、迭代计划 | 每日或每周 | 工时缺失超过约定比例时，标注为估算值并说明估算方法 |
| 产出与流动 | 需求交付周期、在制品数量、阻塞时长、返工次数 | 需求与任务的状态流转记录、阻塞标记、评审记录 | 每日 | 状态流转不规范时，先补录关键节点时间，再计算周期 |
| 质量与风险 | 缺陷数、缺陷密度、线上问题数、评审意见数与关闭情况 | 测试管理、缺陷跟踪、线上问题单、代码与文档评审记录 | 按迭代或按周 | 线上问题记录不完整时，以监控告警和值班记录补充 |
| AI使用 | 调用次数、使用场景、采纳与回退记录、生成内容的评审结论 | AI工具使用日志、评审记录、团队使用登记 | 按周 | 无系统日志时，采用抽样登记，并注明抽样范围和比例 |
取数时注意字段对应关系。例如“工时”要区分登记在工作项上的工时与会议、支持类事务的工时；“交付周期”要明确起止节点是需求受理还是开发启动、验收通过还是上线。字段对应不清，后续计算和对比都会失真。
AI使用类数据需要与业务结果结合。调用量高可能说明团队依赖度高，也可能说明反复重试；采纳率高可能说明生成质量好，也可能说明评审标准宽松。把AI使用数据与交付周期、返工记录放在同一时间窗口内对照，才能判断AI在资源结构中实际起了什么作用。
当工作项、迭代、工时与评审记录集中沉淀在研发管理平台时，取数环节可以显著简化。ONES 中的项目、工作项、迭代与 Wiki 页面构成真实工作上下文，ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，供分析人员作为初稿参考，再由人工核对原始记录。相关输出基于 ONES 权限体系执行，过程可追踪、结果可审计，便于复核环节留痕。具体可用范围以实际部署与配置为准。
操作步骤：从取数到形成结论
一次完整的分析按五步推进，每步都有明确的输入、动作、输出和完成标志。完成标志未达成时不进入下一步，避免带着数据问题往下算。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：确认问题与口径 | 分析诉求、上期口径表 | 把诉求写成可回答的问题，逐项确认指标定义、时间窗口与对比基线 | 分析问题清单、口径定义表 | 研发管理者书面确认口径 |
| 第二步：取数与校验 | 口径定义表、各来源系统权限 | 按字段取数；检查记录完整性、重复登记、明显异常值；对缺失项标注处理方式 | 原始数据集、校验记录 | 完整性与异常检查全部有结论，缺失项有说明 |
| 第三步：计算与分组对比 | 校验后的数据集 | 按口径计算指标；按团队、项目或迭代分组；与基线对比 | 指标结果表、对比视图 | 计算结果可复算，分组口径与定义表一致 |
| 第四步：结合业务解释差异 | 指标结果、项目背景信息 | 与项目经理、团队代表核对异常点；区分资源紧张、流程阻塞与AI使用方式差异 | 差异解释说明 | 每个显著差异都有业务原因或标注为待查 |
| 第五步：形成建议并复核 | 差异解释、历史改进记录 | 提出资源调配或流程改进建议，明确责任人与验证方式；提交复核 | 分析报告与行动建议 | 复核通过，建议均有责任人和验证时点 |
第二步的校验最容易被跳过，也最影响结论质量。完整性检查关注工时登记覆盖率、状态流转节点是否齐全；重复检查关注同一工作是否被多次登记；异常值检查关注单条工时畸高、周期为零或负值等记录。发现异常先回查原始记录，无法确认的标注为待查，不在计算中直接剔除。
第四步是分析能否落地的关键。指标差异本身不构成结论，需要业务解释支撑。例如某迭代交付周期上升，若同期在制品数量增加、阻塞时长集中在等待评审环节，则更可能是流程阻塞；若工时投入下降而任务量未减，则更可能是资源紧张。解释过程要与项目经理和团队代表共同完成，避免分析角色单方面推断。
角色分工与各环节交付物
分析结论无人认领，通常是因为分工不清。四类角色各承担一段，交接时点与交付物事先约定。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 研发管理者 | 提出分析问题，确认口径，审定最终结论 | 确认后的分析问题清单与口径表、审定意见 | 分析启动时确认口径；复核环节审定结论 |
| 项目经理或迭代负责人 | 提供业务背景，解释异常数据，确认改进动作可行性 | 异常说明、改进动作承诺 | 计算完成后、解释差异前 |
| 数据或效能分析角色 | 取数、校验、计算、整理对比视图 | 原始数据集、校验记录、指标结果表 | 校验完成后交解释环节；计算完成后交复核 |
| 团队代表 | 核对数据真实性，反馈工时与任务登记偏差 | 数据核对意见 | 取数校验阶段 |
交接时点要与分析节奏对齐。口径确认放在启动会上完成，避免取数后返工；数据核对安排在取数后一周内，趁团队对当期工作记忆清晰；改进动作的确认放在复核前，确保建议具备执行条件。每个交接点留下书面记录，便于下一周期追溯口径与结论的变化。
示例：一个迭代周期的AI研发资源分析
以下为演示情景，用于说明依据如何组合成结论，数据为示例值。
背景：某研发团队在两个连续迭代中引入AI编码辅助工具，管理者希望判断资源投入是否需要调整。分析对象为该团队，时间窗口为两个迭代，对比基线为引入AI之前的两个迭代。
| 数据类别 | 引入AI前两迭代均值 | 引入AI后两迭代均值 | 观察 |
|---|---|---|---|
| 人员投入工时（人时/迭代） | 640 | 610 | 略有下降 |
| 需求交付周期（自然日） | 14 | 15 | 未缩短 |
| 在制品数量（峰值） | 18 | 24 | 明显上升 |
| 阻塞时长占比 | 12% | 21% | 上升，集中在等待评审 |
| 返工次数 | 9 | 14 | 上升 |
| 缺陷密度 | 0.8 | 0.9 | 基本持平 |
| AI生成内容采纳率 | — | 62% | 回退集中在接口与数据层代码 |
解释过程：工时下降但交付周期未缩短，说明瓶颈不在编码投入。在制品上升与阻塞时长集中在评审环节相互印证，更可能是评审容量不足造成的流程阻塞，而非资源紧张。返工上升与AI生成内容在接口、数据层的回退记录对应，说明部分场景下AI产出需要更多返工，评审负担随之增加。
据此形成的建议：一是在评审环节增加轮值评审人，压缩等待时间；二是对接口与数据层代码的AI生成内容增加前置检查项，降低返工；三是保持当前人力配置，观察一个迭代后再评估是否需要补充资源。每条建议明确责任人与验证时点，下一迭代用同一口径复算在制品、阻塞时长与返工次数。
该示例的适用边界：团队规模、技术栈与AI工具使用深度不同，结论不可直接套用；采纳率与回退记录的统计依赖使用登记，登记不完整时结论需降级为参考。
完成检查：结论可用前的核对项
提交结论前逐项核对，全部通过再进入决策环节。
- 口径已书面固定，指标定义、时间窗口与对比基线与上期一致，变更处有记录。
- 四类数据均完成完整性检查，缺失项已标注处理方式，未用估算值替代原始记录而未说明。
- 重复登记与异常值已回查，无法确认的记录标注为待查，未直接剔除。
- 每个显著差异都有业务解释，或明确标注为待查并指定核查人。
- 结论区分了资源问题与流程问题，未把流程阻塞归因为人力不足。
- 报告写明结论用于资源调配与流程改进，不直接作为人员绩效判定依据。
- 每条建议都有责任人和验证方式，验证时点与下一分析周期对齐。
- AI使用类数据与交付、返工等业务结果在同一时间窗口内对照解读，未单独以调用量或采纳率下结论。
核对完成后，将口径表、数据集、校验记录、解释说明与建议一并归档，作为下一周期对比的基线。分析结论进入行动后，按约定时点回看改进动作是否生效，未生效的回到解释环节重新判断原因。
常见问题
团队工时登记不完整，还能做AI研发资源分析吗？
可以，但需要先处理数据缺口再下结论。做法是：先统计工时登记的覆盖率，明确哪些工作项或角色缺失；缺失比例在约定范围内时，可用估算值补充，并在数据集中标注估算方法和影响范围；缺失比例过高时，优先用任务量、迭代容量等替代字段判断资源投入结构，同时把工时登记补录列为改进动作。无论哪种处理，报告中都要写明数据来源与局限，避免把估算结果当作精确值用于调配决策。
AI使用数据没有系统日志，只有团队口头反馈，怎么处理？
采用抽样登记的方式补充，并注明抽样范围和比例。可以按周让团队登记使用场景、大致调用频次、采纳与回退情况，再抽取部分生成内容对照评审记录核实。抽样数据适合判断使用趋势和场景分布，不适合精确计算采纳率。若要把AI使用数据与交付周期、返工次数对照，需保证两者时间窗口一致，并在报告中说明数据精度差异，结论表述相应降级为参考性判断。
分析结论显示某团队工时投入偏低，是否可以直接判定人力富余？
不能直接判定。工时偏低可能来自登记不全、任务被非计划工作挤占、或工作拆分粒度较粗。需要结合产出与流动数据交叉验证：若同期交付周期正常、在制品数量稳定、阻塞时长无明显上升，才更可能说明容量有余；若交付周期延长而在制品堆积，则更可能是流程阻塞或任务分配不均。解释环节要与项目经理和团队代表核对，确认原因后再提出调配建议。
两个迭代之间调整了指标口径，跨期对比还能用吗？
可以对比，但需要分段处理。在口径定义表的变更记录中写明调整内容、原因和生效时间，对比时把调整前后的数据分开呈现，或按新口径回溯重算历史数据后再比较。若无法回溯重算，报告中应说明该指标在口径变更点前后不可直接比较，趋势判断只参考口径一致的区间。口径变更留痕是跨期分析可信的前提，建议每次变更都在启动会上确认。
分析报告提交后，如何确认改进建议是否生效？
在建议形成时就约定验证方式和验证时点，通常与下一分析周期对齐。验证时使用同一口径复算相关指标，例如针对评审阻塞的建议，回看下一迭代的阻塞时长占比和在制品峰值是否下降；针对AI生成内容返工的建议，回看接口与数据层代码的返工次数是否减少。若指标未改善，回到解释环节重新判断原因，而不是直接追加资源或更换工具。验证结果与原始报告一并归档，作为后续对比的基线。
