建立研发资源利用率分析机制，难点往往不在报表，而在口径反复、填报负担重、复盘落不了地。本文按“定口径—工时采集—校验归集—复盘闭环”的顺序，给出一条可按周或按迭代重复运行的流程，并说明各环节的角色、交付物与上线前的核对项。分析范围限定在投入端，用于观察资源分布与结构变化。
要点总览（TL;DR）
- 流程按“定口径—工时采集—校验归集—复盘闭环”四段设计，可按周或按迭代重复运行，每段都有可独立核对的交付物。
- 利用率口径需在启动前由研发负责人与资源管理员共同确认，明确可用工时、实际投入工时、统计周期与排除项，并约定复核周期。
- 工时采集以支撑归集为下限，最小字段集为人员、日期、项目、活动类型、工时数、备注，活动类型从固定分类中选择。
- 归集按“项目×活动类型×角色”固定规则汇总，校验覆盖漏填、超时填报、异常值与人员项目映射一致性。
- 复盘会聚焦投入结构变化与异常占比，形成带责任人与期限的调整动作，下期复盘先核对上期动作关闭情况。
先定口径：利用率与投入结构分别算什么
流程设计的第一步是把指标定义写清楚，再谈采集。口径不清时，工时字段会随每次报表需求变化，归集规则也要反复调整。建议在流程启动前产出一页口径说明，由研发负责人与资源管理员共同确认，并约定每季度或每半年复核一次，复核时只做必要修订并记录变更原因。
利用率的分子与分母
利用率通常表达为“实际投入工时 ÷ 可用工时”。可用工时按统计周期内的工作日乘以每日标准工时计算，并扣除法定假期、已批准的休假与培训等非投入时间；实际投入工时取该周期内已确认的工时记录。两个口径都要写进说明文档，包括每日标准工时取值、加班是否计入、跨周期补填如何处理。若团队同时关注负荷度，可另设一个指标，避免把“投入是否饱和”和“投入是否有效”混在同一个数字里。
投入结构的切分维度
投入结构回答的是“工时花到哪里去了”，建议固定三个切分维度：
- 项目维度：区分不同项目、产品线或内部专项，用于观察项目间投入分布。
- 活动类型维度：需求、设计、开发、测试、缺陷修复、技术支持、会议与协作等，用于观察工作形态构成。
- 角色维度：按职能角色而非个人汇总，用于观察不同角色的投入差异。
三个维度交叉后形成“项目×活动类型×角色”的结构表，这是后续所有分析的基础。维度一旦确定，归集规则就按这套维度固定下来，新增项目或活动类型走变更登记，不在每次分析时临时判断。
边界与排除项
口径说明中要写明本流程的用途边界：分析结果用于资源规划、排期调整与投入结构优化，不用于个人绩效排名；产出价值与投入产出的比较属于另一类分析，不在本流程内展开。同时列明排除项，例如未立项的探索性工作、外包人员工时是否纳入、行政事务时间是否单列，避免统计时口径漂移。
工时采集：字段设计与填报规则
采集环节的目标是让数据足以支撑归集，同时把填报负担控制在可接受范围。字段越多、规则越细，漏填和错填的比例通常越高，因此字段设计以“归集必需”为下限。
最小字段集
| 字段 | 说明 | 是否必填 |
|---|---|---|
| 人员 | 填报人工号或账号，用于归属角色与团队 | 必填 |
| 日期 | 工时发生日期，支持按天填报 | 必填 |
| 项目 | 关联到已立项项目或内部专项 | 必填 |
| 活动类型 | 从固定分类中选择，不允许自由填写 | 必填 |
| 工时数 | 以小时为单位，按半天或小时粒度填写 | 必填 |
| 备注 | 说明具体工作内容，便于异常核查 | 选填 |
活动类型分类建议
活动类型应覆盖团队主要工作形态，数量控制在八到十二个，过多会导致归类困难。一个可用的初始分类是：需求分析、方案设计、编码开发、测试验证、缺陷修复、技术支持、会议与协作、文档与培训。分类之间要有明确边界说明，例如“缺陷修复”只包含已提缺陷的处理，需求变更引起的返工归入对应需求活动。分类清单随口径文档一同发布，新增类型需登记并回溯历史数据是否重算。
填报粒度与截止时间
建议按天填报、按周截止：每人每周固定时间前完成上周工时填报，项目经理在截止后一个工作日内完成审核。为降低负担，可允许按半天为最小单位、常用项目与活动类型设为默认选项、支持从任务列表带出项目信息。规则中要写明补填与修改的时限，例如超过两周的补填需说明原因，避免数据在分析前频繁变动。
承载方式与导出要求
工时数据可以承载在项目管理工具或独立表单中，选择时重点看三点：能否按人员、项目、日期维度导出明细；能否与工作项关联，减少重复录入；导出格式是否便于后续汇总。ONES 的资源管理提供多种资源报表，实时反馈项目投入情况，并支持一键导出工时日志，可作为工时明细导出与投入查看的承载方式之一。具体填报字段与截止规则仍需按团队情况在产品中配置并核验。
数据校验与归集：从原始工时到投入结构表
原始工时导出后不能直接用于分析，需要先校验再归集。这一步的产出是一张可重复生成的投入结构汇总表，校验规则和归集规则都应固化为清单或脚本，减少每次分析时的人工判断。
完整性校验
- 漏填检查：按应填报人数与应填报天数计算应填总量，与实际记录比对，列出缺口人员与日期。
- 超时填报检查：标记截止时间之后补填或修改的记录，单独统计比例。
- 异常值检查：单日工时超过设定上限、单条记录工时为零或明显偏离常规值的情况，逐条核实。
一致性校验
- 人员归属：填报人是否仍在当前团队，离职或转岗人员的工时是否已归档。
- 项目状态：工时是否记在已关闭或未立项的项目上，跨项目借用人员是否标注。
- 活动类型映射：是否存在自由填写或旧分类残留，按映射表统一到当前分类。
归集规则与汇总表
归集按统计周期执行：先把每条工时记录补齐人员角色、项目所属产品线、活动类型标准值，再按“项目×活动类型×角色”汇总工时，同时计算各组合占周期总工时的比例。规则固定后，每个周期用同一套映射重复执行，结果才具备可比性。
| 统计周期 | 项目 | 活动类型 | 角色 | 工时合计 | 占比 |
|---|---|---|---|---|---|
| 第 12 周 | A 项目 | 编码开发 | 后端 | 186 小时 | 18.6% |
| 第 12 周 | A 项目 | 缺陷修复 | 后端 | 64 小时 | 6.4% |
| 第 12 周 | B 项目 | 测试验证 | 测试 | 120 小时 | 12.0% |
表中数据为示例，实际数值以团队导出结果为准。汇总表之外建议保留一张明细底表，便于复盘时下钻核查。
角色分工与交付物：谁采集、谁归集、谁复盘
流程能否稳定运行，取决于每个环节是否有明确的责任人和可检查的交付物。建议按执行层、协调层、决策层划分职责，并把时间节点写进流程说明。
| 环节 | 角色 | 主要动作 | 交付物 | 时间节点 |
|---|---|---|---|---|
| 口径确认 | 研发负责人、资源管理员 | 确认指标定义、维度与排除项 | 一页口径说明 | 流程启动前，之后按季度复核 |
| 工时填报 | 研发人员 | 按天记录工时与活动类型 | 工时记录 | 每周固定截止时间前 |
| 审核与校验 | 项目经理或资源管理员 | 审核填报、执行完整性与一致性校验 | 校验问题清单 | 截止后一个工作日内 |
| 归集汇总 | 资源管理员 | 按固定规则生成投入结构表 | 投入结构汇总表 | 校验完成后两个工作日内 |
| 复盘决策 | 研发负责人主持，项目经理参与 | 解读结构差异，确认调整动作 | 复盘纪要与动作跟踪表 | 每周期固定复盘会 |
协调层角色可以由项目经理兼任，但需要明确其只负责数据质量与归集，不承担对个人的评价职责，这样填报配合度更容易维持。决策层的核心动作是确认调整动作与责任人，而不是逐条审阅明细。
复盘机制：从结构差异到调整动作
复盘会的价值在于把结构数据转成具体安排。会议节奏建议与统计周期一致，按周采集的团队可每两周或每月复盘一次，按迭代运行的团队可在迭代结束时复盘。参会角色包括研发负责人、项目经理、资源管理员，必要时邀请测试或运维负责人。
会上看什么
- 投入结构变化：与上期相比，各活动类型占比的增减，重点看缺陷修复、技术支持等非计划性活动是否持续上升。
- 异常活动占比：会议与协作、返工类活动占比是否超出预期，是否需要调整协作方式或需求澄清流程。
- 项目间投入分布：关键项目投入是否与优先级匹配，是否存在多个项目同时占用同一批人员的情况。
- 利用率与负荷：结合成员每日投入饱和明细，识别长期高负荷或长期低负荷的角色。
形成动作并跟踪关闭
每条调整动作要写清三件事：做什么、谁负责、什么时候完成。例如“下个迭代将 B 项目测试支持人力从 0.5 人调整为 1 人，由测试负责人协调，迭代启动前完成”。动作跟踪表在每次复盘会开头先过一遍上期动作，逐条标记完成、延期或取消，未关闭的动作说明原因并重新约定期限。连续两个周期未关闭的动作，提交研发负责人决定是否调整资源安排。
在数据承载上，ONES 资源管理支持筛选与分组，便于掌握成员在不同项目的投入比重；可实时查看成员每日投入饱和明细，识别规划风险；资源和工时管理方案支持查看项目和团队的资源利用率及负荷度，并支持多维度统计资源投入。这些能力可以承接采集后的投入查看与复盘前的数据准备，复盘议程与动作跟踪仍按团队约定执行。
示例：一个迭代周期的完整流程走查
以下为一个演示情景，用于说明各步骤如何衔接，数值为示意。
背景设定：某研发团队共 20 人，分后端、前端、测试三个角色，按两周一个迭代运行，同时推进 A、B 两个项目。团队决定从本迭代开始运行资源利用率分析流程。
采集阶段：迭代开始前，资源管理员在工具中配置好项目与活动类型选项，研发人员按天填报工时，迭代最后一天为填报截止日。截止后发现 3 人共 5 天未填，2 条记录单日工时超过 12 小时。
校验与归集：项目经理联系未填人员补填，核实超时记录为上线支持，备注后保留。归集结果显示：A 项目占总工时 62%，B 项目占 31%，内部专项占 7%；活动类型中缺陷修复占 19%，较上期上升 6 个百分点；测试角色在 B 项目的投入占比明显低于计划。
复盘与动作：复盘会上，团队判断缺陷修复上升与上期需求变更集中有关，决定在下个迭代增加需求评审环节；B 项目测试投入不足，决定从下个迭代起调整一名测试人员投入比例，由测试负责人协调并在迭代启动前确认。两项动作记入跟踪表，下次复盘会首先核对。
完成检查：流程上线前的核对项
在正式按周期运行前，用下面这份清单逐项核对，全部满足即可认为流程具备稳定运行条件；存在未满足项时，先补齐再启动，避免运行两三个周期后推倒重来。
| 核对项 | 判断标准 | 核对结果 |
|---|---|---|
| 口径与字段已确认并发布 | 指标定义、维度清单、统计周期、排除项、字段清单均有文档且已通知到填报人 | 是 / 否 |
| 采集覆盖率达标 | 试运行周期内应填人员覆盖率与应填天数完成率达到团队设定阈值 | 是 / 否 |
| 数据质量可接受 | 漏填、超时填报、异常值均有处理记录，错误率在可接受范围 | 是 / 否 |
| 归集规则可重复执行 | 用同一规则对两个周期数据归集，结果可复现，映射表有版本记录 | 是 / 否 |
| 复盘节奏与责任人落实 | 复盘会已排入固定日程，主持人、参会角色与动作跟踪人明确 | 是 / 否 |
| 异常与动作有闭环记录 | 试运行期间形成的调整动作均有责任人与期限，并在下一周期完成跟踪 | 是 / 否 |
清单核对完成后，把口径说明、字段清单、校验清单、投入结构表模板、责任表与复盘议程归档为流程文档，后续每个周期按同一套文档执行，修订时同步更新版本记录。
常见问题
团队刚开始运行这套流程，第一个周期应该先做哪些事？
建议先完成口径确认和字段发布，再进入试运行。第一个周期可以只做采集与校验，不急于在会上形成大量调整动作，重点观察填报覆盖率、漏填比例和活动类型归类是否顺畅。试运行一到两个周期后，再按检查清单逐项核对，确认归集规则可复现、复盘节奏可维持，然后转入正式周期运行。
工时填报负担太重、配合度下降时，可以从哪里简化？
优先压缩字段与选项，而不是降低校验标准。可把活动类型收敛到八到十二个，常用项目与活动类型设为默认值，支持从任务列表带出项目信息，按半天为最小填报单位。截止规则保持固定，补填时限写清楚，超过时限的补填需说明原因。填报负担下降后，数据完整性通常比增加字段更容易维持。
利用率数字出现明显波动时，怎么判断是数据问题还是真实变化？
先做校验再解读。检查该周期是否存在集中补填、人员转岗未更新归属、项目关闭后工时仍记在原项目、活动类型映射残留旧分类等情况。排除数据问题后，再看投入结构表中各活动类型占比的变化，结合当期需求变更、上线支持等事件判断是否为真实变化。校验问题清单建议随汇总表一并归档，便于回溯。
复盘会上形成的调整动作经常延期，如何保证闭环？
动作要写清做什么、谁负责、什么时候完成，并记入跟踪表。每次复盘会开头先逐条核对上期动作，标记完成、延期或取消，延期需说明原因并重新约定期限。连续两个周期未关闭的动作，提交研发负责人决定是否调整资源安排。动作数量控制在团队能执行的范围内，比一次列很多条更有效。
分析结果能不能直接用于个人考核？
本流程的用途边界是资源规划、排期调整与投入结构优化，分析结果按角色和项目汇总，不用于个人绩效排名。产出价值与投入产出的比较属于另一类分析，不在本流程内展开。把投入数据与个人评价直接挂钩，容易导致填报失真，反而削弱后续分析的可信度。
