可用研发人天是把团队在给定时间窗内真正能投入研发工作的人力折算成天数的指标，口径由时间窗、人员范围、扣减项三个要素共同决定。推荐公式为：可用研发人天 = Σ（每位计入人员在该时间窗内的可工作天数 × 研发投入系数）。本文按“先定用途、再定范围、后定扣减与系数”的顺序给出可复算的口径方案，并说明验证与误用边界。
要点总览（TL;DR）
- 可用研发人天的口径由时间窗、人员范围、扣减项三个要素共同决定，先固定这三项，系数与汇总才有稳定的分母。
- 推荐公式为：可用研发人天 = Σ（每位计入人员的可工作天数 × 研发投入系数），单位统一为人天。
- 可工作天数按“日历工作日 − 法定节假日 − 个人请假与不可用日”折算；零散占用通过研发投入系数整体折算，两类处理不重复计算。
- 口径写成文档并固定分母、单位、缺失值处理和系数依据，口径变更保留版本记录，跨周期数据才可比较。
- 可用研发人天反映供给上限，不等于实际产出，适合排期前的承接判断，不宜单独作为团队绩效评价依据。
评估目标：可用研发人天要回答什么问题
可用研发人天回答的是一个供给侧问题：在某个时间窗内，团队理论上能承接多少研发工作量。它用于排期前的容量判断、跨团队人力对比、以及需求与供给的匹配测算。口径设计应围绕这三类决策场景展开，让同一指标在不同团队、不同周期之间可以放在一起比较。
这个指标衡量的是供给能力上限，与实际产出属于不同层面。完成人天、交付速率、需求吞吐量等产出类指标记录的是已经发生的工作结果，受需求变更、返工、协作效率等因素影响；可用研发人天则在排期之前给出“最多能做多少”的边界。两者可以配合使用：用可用研发人天做承接判断，用产出类指标回看实际消耗与交付情况，但不宜互相替代。
明确用途还能约束口径的精细度。若只用于团队内部的月度排期，人员范围和扣减项可以相对简化；若要支撑跨团队横向对比或季度容量规划，就需要统一时间窗、统一角色分类、统一扣减项清单，否则数字之间不具备可比性。
指标与范围：哪些人、哪段时间计入
人员范围和时间窗是口径的两个基础维度，先固定这两项，后续的扣减与系数才有稳定的分母。建议在口径文档中直接写明“计入”与“不计入”的名单规则，而不是每次统计时临时判断。
人员范围的选择
常见做法是以“直接参与研发交付的角色”为计入范围，全职研发、测试、设计通常计入；兼职人员按其实际投入比例折算；外包人员是否计入取决于统计目的——用于团队自身容量判断时可不计入，用于项目整体交付能力测算时应计入并单独标注。产品经理、项目经理等角色是否计入，取决于他们是否有明确的研发工作量，建议在口径中按角色列明，避免同一团队不同周期口径漂移。
时间窗的选择
| 时间窗 | 适用场景 | 注意事项 |
|---|---|---|
| 周 | 短期排期、迭代内人力核对 | 受单日请假影响大，波动明显 |
| 月 | 常规容量规划、跨团队对比 | 需统一按自然月还是工作月统计 |
| 迭代 | 敏捷团队的承接判断 | 迭代长度不一致时不可直接横向比较 |
人员变动在时间窗内的处理
入离职、借调、转岗应按“在时间窗内的实际可工作天数”折算，而不是整月计入或整月剔除。例如某成员在月中入职，只计入入职日之后的工作日；借调到其他团队的人员，若借调期覆盖整个时间窗则不计入本团队，部分覆盖则按剩余天数折算。转岗人员按转岗生效日切分，前后分别归属对应团队。这些规则写清楚后，跨周期数据才不会因人员流动出现无法解释的跳变。
数据口径：可工作天数与扣减项怎么定
可工作天数的基本算法是：可工作天数 = 日历工作日 − 法定节假日 − 个人请假与不可用日。日历工作日先按国家法定工作日确定，再逐人扣减个人层面的不可用时间。扣减项需要逐项列出，并明确数据来源和记录责任角色，否则统计时容易出现“有人扣、有人不扣”的不一致。
扣减项清单与取数来源
| 扣减项 | 是否扣减 | 数据来源 | 记录责任角色 |
|---|---|---|---|
| 法定节假日 | 扣减 | 国家法定工作日历 | 口径维护人统一维护 |
| 年假、调休 | 扣减 | 考勤或请假审批记录 | 成员本人提交，主管确认 |
| 病假、事假 | 扣减 | 考勤或请假审批记录 | 成员本人提交，主管确认 |
| 培训、外部会议 | 扣减或计入系数 | 培训计划、会议安排 | 团队负责人登记 |
| 例会、站会 | 计入研发投入系数 | 团队例行安排 | 团队负责人设定 |
| 运维支持、线上问题处理 | 计入研发投入系数 | 值班表、工单记录 | 团队负责人估算 |
| 招聘面试 | 计入研发投入系数 | 面试安排记录 | 团队负责人估算 |
表中“扣减”与“计入系数”是两种处理方式：整天的、可精确记录的不可用时间直接从可工作天数中扣除；零散的、难以逐日记录的占用则通过研发投入系数整体折算。两者不要重复计算，同一类占用只选一种处理方式。
缺失值的处理
没有请假记录时，默认按全勤处理，并在统计结果中标注“按默认值估算”；对于关键角色或大额扣减项，若记录缺失则标记为待补，不直接按零处理。口径文档中应写明默认值和待补标记的使用条件，保证不同人统计同一时间窗时得到一致结果。
计算步骤：从原始数据到可用研发人天
完整公式为：可用研发人天 = Σ（每位计入人员的可工作天数 × 研发投入系数）。单位统一为人天，分母为时间窗内的计入人数乘以该时间窗的工作日数，用于计算人均可用人天等衍生指标时保持口径一致。
研发投入系数的设定
研发投入系数反映被非研发事务占用的比例，取值在0到1之间。设定依据可以是历史工时记录中研发工作占比，也可以是团队负责人的结构化估算。示例区间：专注核心开发的成员可取0.8–0.9；承担较多运维支持和面试的成员可取0.6–0.75；兼有管理职责的技术负责人可取0.5–0.7。系数应按角色或团队分别设定并保留取值依据，每季度或每半年复核一次，避免长期沿用导致偏差累积。
汇总层级与计算顺序
- 按人计算可工作天数：日历工作日减去法定节假日和个人不可用日。
- 按人乘以研发投入系数，得到个人可用研发人天。
- 按小组汇总，再汇总到团队；汇总时只做加总，不重新调整系数。
- 记录时间窗、计入人数、扣减明细和系数取值，形成可复算的底稿。
当团队使用项目管理系统承载排期与工时记录时，成员排期、投入比重和工时日志可以作为系数设定与扣减核对的输入。例如ONES资源管理支持通过工作数量和工时规模了解成员排期，并按筛选与分组查看成员在不同项目的投入比重；ONES资源和工时管理方案支持多维度统计项目和成员的资源投入，并可查询、导出工时登记日志明细。这些记录能帮助口径维护人核对系数取值是否与实际投入相符，具体取数方式仍需按团队现有流程确定。
算例：一个五人小组的月度可用研发人天
演示情景：某五人研发小组统计某自然月（该月22个工作日）的可用研发人天。人员构成为3名开发、1名测试、1名兼管运维的开发。以下数字为演示用，不代表任何团队的实际水平。
| 成员 | 角色 | 日历工作日 | 个人不可用日 | 可工作天数 | 研发投入系数 | 可用研发人天 |
|---|---|---|---|---|---|---|
| 成员A | 开发 | 22 | 2（年假） | 20 | 0.9 | 18.0 |
| 成员B | 开发 | 22 | 1（病假） | 21 | 0.85 | 17.85 |
| 成员C | 开发 | 22 | 0 | 22 | 0.8 | 17.6 |
| 成员D | 测试 | 22 | 2（培训） | 20 | 0.8 | 16.0 |
| 成员E | 开发兼运维 | 22 | 1（调休） | 21 | 0.65 | 13.65 |
合计可用研发人天 = 18.0 + 17.85 + 17.6 + 16.0 + 13.65 = 83.1人天。手工核对方式：先核对日历工作日是否为22天、法定节假日是否已统一扣除；再逐人核对请假记录与可工作天数是否一致；最后核对系数取值与口径文档中的角色设定是否相符。三项核对通过后，结果即可作为该月容量判断的输入。
从这个算例可以看到，扣减项和系数对结果的影响都很直接：成员E因承担运维支持，系数取0.65，比同工作天数的开发成员少约4人天；两名成员的请假和培训合计扣减5个可工作天数。口径文档中把这些取值依据写清楚，跨月比较时才能解释差异来源。
解读与限制：口径的适用边界与常见误用
可用研发人天反映的是供给上限，不等于实际产出。实际交付受需求清晰度、依赖等待、返工和协作成本影响，可用人天充足也可能出现交付延迟。因此它适合用于排期前的承接判断和供需缺口测算，不适合单独作为团队绩效评价依据，也不宜与完成人天直接相减得出“效率”结论。
异常情况需要预先约定处理方式。当时间窗内计入人数为零，或人员全部不可用时，分母为零，此时应输出“不适用”并说明原因，而不是填0或留空，避免在汇总时被误当作零容量。人员部分不可用时按实际可工作天数折算，不整月剔除。
口径变更要有版本记录。调整人员范围、扣减项或系数取值时，记录变更日期、变更内容和影响范围，历史数据保留原口径结果并标注版本。跨周期比较时使用同一版本口径，或在新旧口径之间给出换算说明，否则趋势变化可能来自口径调整而非实际容量变化。
最后，把口径写成文档并固定分母、单位、缺失值处理和系数依据，是让这个指标可复算、可审计的前提。团队规模、业务类型不同，系数取值和扣减项清单会有差异，按自身历史数据校准比套用外部数值更可靠。
常见问题
团队第一次建立可用研发人天口径，应该从哪一步开始？
建议先明确这个指标服务哪类决策，再定范围。若只用于团队内部月度排期，人员范围和扣减项可以简化；若要支撑跨团队对比或季度容量规划，就需要统一时间窗、角色分类和扣减项清单。范围确定后再设定研发投入系数，并同步写好口径文档，避免先算数、后补规则导致历史数据无法解释。
兼职、外包和借调人员在时间窗内怎么折算？
按人员在时间窗内的实际可工作天数折算，不整月计入或整月剔除。兼职人员按实际投入比例折算；外包人员是否计入取决于统计目的，用于团队自身容量判断时可不计入，用于项目整体交付能力测算时应计入并单独标注；借调期覆盖整个时间窗则不计入本团队，部分覆盖按剩余天数折算。这些规则写入口径文档后，跨周期数据才不会因人员流动出现无法解释的跳变。
研发投入系数取多少合适，需要多久复核一次？
系数取值在0到1之间，依据可以是历史工时记录中研发工作占比，也可以是团队负责人的结构化估算。参考区间：专注核心开发的成员0.8–0.9，承担较多运维支持和面试的成员0.6–0.75，兼有管理职责的技术负责人0.5–0.7。建议按角色或团队分别设定并保留取值依据，每季度或每半年复核一次，避免长期沿用导致偏差累积。团队规模与业务类型不同，按自身历史数据校准比套用外部数值更可靠。
某个月计入人数为零或人员全部不可用，指标该怎么输出？
此时分母为零，应输出“不适用”并说明原因，不填0也不留空，避免在汇总时被误当作零容量。人员部分不可用时按实际可工作天数折算，不整月剔除。这类异常处理规则建议提前写入口径文档，与缺失值的默认值处理一并约定，保证不同人统计同一时间窗时得到一致结果。
口径调整后，历史数据还能直接和本期比较吗？
调整人员范围、扣减项或系数取值时，记录变更日期、变更内容和影响范围，历史数据保留原口径结果并标注版本。跨周期比较使用同一版本口径，或在新旧口径之间给出换算说明，否则趋势变化可能来自口径调整而非实际容量变化。若团队用项目管理系统承载排期与工时记录，成员投入比重和工时日志可作为系数复核的输入，例如ONES资源管理支持按筛选与分组查看成员在不同项目的投入比重，ONES资源和工时管理方案支持多维度统计项目和成员的资源投入并查询、导出工时登记日志明细，具体取数方式仍需按团队现有流程确定。
