可用研发人天预测值与实际值偏差大，通常先分两类原因：预测和实际统计的口径不一致，或者工时填报、请假占用、人员变动等数据环节失真。排查时先量化偏差范围，再用同一口径重算历史数据，然后逐环节核对原始记录，定位到具体项目或人员后修正，并用连续两三个统计周期验证偏差是否收敛。
要点总览（TL;DR）
- 先把“偏差大”量化：按项目、团队、月份列出预测值、实际值、差值和偏差率，并区分系统性偏差与局部偏差，优先处理贡献最大的对象。
- 第一类原因假设是口径不一致，逐项对照人天定义、扣减项、统计对象和时间窗，用同一口径重算历史一个月，看偏差是否显著缩小。
- 口径对齐后仍有偏差，按工时填报、请假与占用、人员变动、跨项目分摊、计划变更的顺序核对原始记录，每项结论标注假设成立或已排除。
- 修正时区分一次性原因与结构性原因，涉及历史数据先备份、明确审批人和停止点；修正后用同一时间窗重算，并连续观察两到三个统计周期。
- 把口径规则文档化、固定填报与审批回写节点、月度偏差复盘并设置阈值告警，防止同类偏差反复出现。
偏差有多大、出现在哪些范围
“偏差大”本身无法直接排查，第一步是把它转成可比较的数字，并确定偏差集中在哪些项目、团队或月份。建议同时使用三个度量：绝对人天差（预测值减实际值）、偏差率（绝对差除以预测值）、以及按项目、团队、月度三个维度拆分后的分布。只看总量容易掩盖局部问题，例如整体偏差率10%，可能由三个项目严重高估和两个项目严重低估相互抵消。
拆分后要判断偏差属于系统性还是局部性。系统性偏差表现为多数项目、多数月份朝同一方向偏离，通常指向口径规则或统计范围问题；局部偏差表现为少数对象明显偏离、其余基本正常，通常指向具体项目的计划变更、集中请假或个别人员填报异常。两类偏差的排查路径不同，先做这个判断可以减少无效核对。
同时确认预测值与实际值是否覆盖同一时间窗和同一人员范围。常见情况是预测按自然月统计、实际按迭代统计，或预测包含借调人员而实际只统计本团队，这类范围错位会直接表现为“偏差大”，但原因不在预测方法本身。
可以用一张偏差分布表承载上述信息，按项目、团队、月份逐行列出预测值、实际值、差值、偏差率，并增加一列标注该行属于系统性还是局部偏差。表格的作用是让后续排查有明确的优先对象，贡献偏差最大的几行应排在最前面处理。
| 项目/团队 | 统计月份 | 预测可用人天 | 实际人天 | 差值 | 偏差率 | 偏差类型 |
|---|---|---|---|---|---|---|
| A项目 | 3月 | 120 | 96 | -24 | -20% | 局部 |
| B项目 | 3月 | 80 | 78 | -2 | -2.5% | 正常 |
| 全团队 | 3月 | 400 | 352 | -48 | -12% | 系统性 |
本文讨论的范围限于可用人力供需口径下的预测与实际对比，项目组合层面的承接取舍、具体人员排期不在排查范围内，遇到这类问题应转到相应的规划流程处理。
先对齐口径：预测和实际算的是不是同一件事
口径差异是偏差最常见也最容易修复的原因。排查时把预测侧和实际侧的取值规则逐项对照，重点检查四类规则：人天定义、扣减项、统计对象、时间窗。每一项都问同一个问题——预测和实际是否按同一规则计算，如果不同，差异有多大。
人天定义方面，确认一个标准人天对应多少小时，自然日如何折算为工作日，加班工时是否计入实际人天。预测按标准工时估算、实际却包含加班，实际值会系统性偏高；反之预测按满负荷估算、实际按有效工时统计，实际值会系统性偏低。
扣减项方面，逐项确认请假、会议、支持性事务、培训、值班是否在预测的可用人天中扣除，实际统计时是否也扣除了同样的项目。常见问题是预测扣了请假但没扣会议和支持事务，实际工时却把这些都算进了投入，导致实际值高于预测。
统计对象方面，确认按人统计还是按角色统计，兼职人员和跨项目人员如何归属。一人参与两个项目时，预测可能按50%投入折算，实际工时却全部记在主项目上，两个项目会同时出现偏差。
时间窗方面，确认按周、按迭代还是按自然月统计，跨月任务如何切分。预测按迭代、实际按自然月，跨月迭代的工时会被切到不同月份，单月对比必然失真。
验证口径假设的方法是：选取历史一个月，按统一后的口径重新计算预测值和实际值，观察偏差率是否显著缩小。如果重算后偏差从20%降到5%以内，说明口径不一致是主因；如果重算后偏差依然很大，说明问题更多出在数据记录环节，需要进入下一步核查。
| 口径项 | 预测侧规则 | 实际侧规则 | 是否一致 | 差异影响 |
|---|---|---|---|---|
| 标准人天 | 8小时 | 按填报工时累计 | 需确认加班是否计入 | 实际偏高 |
| 请假扣减 | 已扣除 | 未从可用人天扣除 | 否 | 实际偏低 |
| 统计对象 | 按人 | 按人 | 是 | 无 |
| 时间窗 | 自然月 | 迭代 | 否 | 跨月失真 |
再查数据环节：原始记录在哪一步失真
口径对齐后仍有偏差，就要按数据从产生到汇总的顺序逐环节核对。每个环节先提出失真假设，再找可核对的原始证据，结论标注为“假设成立”或“已排除”，避免把猜测直接当成原因。
工时填报环节，检查是否按日填报、是否存在周末或月末集中补填、填报颗粒度是否到任务。集中补填会让工时在日期上分布失真，颗粒度只到项目不到任务时，跨项目分摊缺少依据。可核对的证据是填报时间戳与工时日期的对比、单日填报条数异常记录。
请假与占用环节，检查审批通过的请假是否回写到容量数据，会议、支持性事务是否占用了可用人天却没有体现在预测中。证据是请假审批单与同期容量数据的比对，找出审批已通过但容量未扣减的时段。
人员变动环节，检查入职、离职、转岗、借调是否及时更新到人员台账和容量数据。新人入职当月按整月预测、实际只工作半个月，或离职人员仍留在预测名单中，都会造成偏差。证据是人员台账的变动日期与容量数据的生效日期是否一致。
跨项目分摊环节，检查一人多项目时人天如何拆分，是否存在同一工时重复计入两个项目，或某个项目漏计。证据是同一人员同一日期的工时记录汇总，与总可用人天比对，看是否超过上限或明显低于实际投入。
计划变更环节，检查需求插入、优先级调整后预测是否同步更新。预测停留在月初版本、实际执行已按新需求调整，偏差会集中在变更发生的项目上。证据是需求变更记录与预测更新记录的时间对照。
| 环节 | 可能失真表现 | 验证证据 | 初步结论 |
|---|---|---|---|
| 工时填报 | 月末集中补填 | 填报时间戳与工时日期对比 | 待核对 |
| 请假与占用 | 审批通过未扣减容量 | 请假审批单与容量数据比对 | 待核对 |
| 人员变动 | 离职人员仍在预测名单 | 人员台账变动日期 | 待核对 |
| 跨项目分摊 | 工时重复计入 | 同一人员单日工时汇总 | 待核对 |
| 计划变更 | 预测未随需求更新 | 变更记录与预测版本对照 | 待核对 |
这些核查动作依赖工时记录、审批结果和人员信息的可追溯性。ONES 资源管理提供资源报表反馈项目投入情况，并支持一键导出工时日志，资源和工时管理方案支持查询和导出工时登记日志明细，便于把填报记录与容量数据放在一起比对；资源规划视图可按业务优先级安排团队资源，用于检查预测侧是否随计划变更同步更新。审批结果与人员变动是否自动回写容量数据，需要按实际配置确认，不能默认已经打通。
定位到具体对象并修正
完成口径对照和数据环节核查后，用偏差分布表锁定贡献最大的项目或人员，优先处理影响最大的几项。判断原因类型时区分一次性原因和结构性原因：集中请假、突发支持属于一次性原因，处理方式是修正当期数据并在下期预测中体现；口径长期不一致、分摊规则缺失属于结构性原因，需要修改规则本身，否则下个周期会再次出现同类偏差。
处置动作按原因对应展开。口径问题统一预测侧和实际侧的规则，形成书面约定；工时问题补录或修正错误记录，并明确填报时限要求；人员变动问题建立台账更新与容量数据同步的节点；分摊问题明确一人多项目时的拆分规则和归属原则。每项动作指定负责人和完成时间，避免核查结论停留在文档里。
涉及修改历史工时或容量数据时，先备份原始记录，明确修改范围和审批人，设定停止点——例如只修正最近一个统计周期内的数据，更早的数据保留原样并在报表中备注。修正过程保留变更前后的对照，防止覆盖原始记录后无法回溯。
| 问题对象 | 原因类型 | 修正动作 | 负责人 | 风险与回退 |
|---|---|---|---|---|
| A项目3月 | 一次性：集中请假未扣减 | 补录请假扣减，重算当月可用人天 | 项目经理 | 修改前备份工时记录，可回退 |
| 全团队 | 结构性：时间窗口径不一致 | 统一按自然月统计，修订预测模板 | 资源管理员 | 保留旧模板一个周期对照 |
验证恢复并防止复发
修正完成后，用修正后的口径重算同一时间窗，观察偏差率是否降到团队可接受的区间。可接受区间由团队根据业务波动自行设定，例如稳定交付团队可设在10%以内，需求波动大的团队可适当放宽。重算结果与修正前对比，记录偏差缩小的幅度和剩余偏差的来源。
单次重算通过不代表问题解决，需要连续观察两到三个统计周期，确认偏差稳定在阈值内。观察期内如果偏差再次扩大，按本文顺序重新排查，重点检查是否出现新的口径分歧或数据环节断点。
复发预防落在四个固定动作上：把口径规则写成文档，预测和实际两侧共同引用；固定工时填报与审批回写的节点，例如每周五完成当周填报、请假审批通过后当周内更新容量；每月做一次偏差复盘，记录偏差率最高的项目和原因；设置偏差阈值告警，超过阈值时触发排查流程。ONES 资源管理可实时查看成员每日投入饱和明细，识别规划风险，配合资源报表和工时日志导出，为月度复盘提供数据基础。
- 重算结果：修正后同一时间窗偏差率，与修正前对比
- 观察周期：连续两到三个统计周期，偏差稳定在阈值内
- 规则文档：人天定义、扣减项、统计对象、时间窗四项规则书面化
- 复盘机制：月度偏差复盘，记录高偏差对象与原因
- 告警设置：偏差率超过阈值时按本文顺序重新排查
常见问题
预测按迭代统计、实际按自然月统计，这种时间窗错位怎么处理？
先确定一个统一的时间窗作为对比基准，再决定另一侧如何折算。常见做法是以自然月为基准，把跨月迭代的工时按实际发生日期切分到各月；如果团队以迭代节奏管理，也可以把自然月数据按迭代起止日期重新归集。关键是预测和实际使用同一套切分规则，并在规则文档中写明跨月任务的处理方式。重算历史一个月验证，如果偏差明显缩小，说明时间窗错位是主因之一。
一人参与多个项目时，工时重复计入导致偏差，排查时看什么？
取同一人员同一日期的全部工时记录汇总，与该人员的可用人天上限比对。汇总超过上限，说明存在重复计入；明显低于实际投入，说明有项目漏计。再对照预测侧的分摊比例，确认预测按50%折算而实际工时全部记在主项目的情况。修正时明确一人多项目的拆分规则和归属原则，并指定由谁在什么时点完成分摊，避免下个周期重复出现。
修正历史工时数据有哪些风险，边界怎么定？
主要风险是覆盖原始记录后无法回溯，以及修正范围过大影响已发布的报表结论。建议先备份原始记录，明确修改范围和审批人，设定停止点，例如只修正最近一个统计周期内的数据，更早的数据保留原样并在报表中备注。修正过程保留变更前后对照，便于后续核对。涉及跨团队共享的数据，修改前与相关方确认口径，避免单方面调整造成新的不一致。
偏差率降到多少算恢复正常？
可接受区间由团队根据业务波动自行设定，没有统一标准。稳定交付、需求变化小的团队可以设得紧一些，例如10%以内；需求插入频繁、支持性事务多的团队可适当放宽。设定后连续观察两到三个统计周期，确认偏差稳定在阈值内，而不是只看单月重算结果。阈值同时作为告警线，超过时按先对齐口径、再查数据环节的顺序重新排查。
ONES 资源管理在排查偏差时能提供哪些数据？
ONES 资源管理提供多种资源报表，实时反馈项目投入情况，并支持一键导出工时日志；资源和工时管理方案支持查询和导出工时登记日志明细，便于把填报记录与容量数据放在一起比对。资源管理还可实时查看成员每日投入饱和明细，识别规划风险，资源规划视图可按业务优先级安排团队资源，用于检查预测侧是否随计划变更同步更新。审批结果与人员变动是否自动回写容量数据，需要按实际配置确认。
