可用研发人天是团队在给定时间窗内真正能投入研发工作的人天总量，核心算法为：先按人员在岗工作日和每日可投入研发工时折算，再逐人扣减请假、培训、会议、支持等非研发占用。它回答的是“这段时间团队能承接多少研发工作量”，需要与需求侧人天对比才有意义。本文给出可直接套用的口径、公式和算例，并说明工时与资源数据如何借助ONES的工时记录和资源视图取数。
要点总览（TL;DR）
- 可用研发人天 = Σ（每人计划在岗工作日 × 每日可投入研发工时 ÷ 标准工时）− 非研发占用折算人天，单位统一为人天并保留一位小数。
- 计算前先定人员范围、时间窗和统计粒度：全职按实际在岗天数计入，兼职按约定比例折算，外包单独列示，中途入职按实际在岗天数计算。
- 标准工时是折算分母，每日可投入研发工时是实际可投入研发的上限，两者不能混用；扣减项要逐人逐项登记，并避免与可投入工时重复扣减。
- 可用人天只反映供给能力，需与需求侧人天在相同口径下对比才有意义，不能当作产出或绩效指标使用。
- 分母为零、时间窗过短、口径不一致或估算比例过高时，结果只能作为参考区间，跨团队对比前先对齐口径表。
评估目标：可用研发人天要回答什么问题
可用研发人天服务于一个具体决策：在某个时间窗内，团队可承接的研发工作量是多少，与已排入或待排入的需求人天相比，缺口或余量有多大。它把“有多少人”转换成“有多少可用的研发投入”，让供给和需求在同一单位下比较。
使用这项度量时，建议固定三个动作：先确定时间窗和人员范围，再算出该窗口的可用人天，最后与需求侧人天逐项对照，形成“供给—需求—缺口”的结论。例如季度规划前算出下季度可用人天为120人天，而候选需求合计150人天，缺口30人天就是需要取舍或补充资源的依据。
这项度量反映的是供给能力，适合用于容量判断、排期前的可行性评估和资源申请说明。它不适合作为个人绩效考核依据：可用人天扣减了会议、支持等必要占用，数值高低更多反映岗位分工和投入结构，无法区分产出质量和个人贡献。把团队级结果直接下钻到个人排名，容易诱导少登记非研发工时，反而破坏数据口径。
指标与范围：人员、时间窗与统计边界
计算前先写清三件事：谁计入、按多长周期统计、汇总到什么粒度。范围定义一旦确定，同一团队各期结果才可比较，跨团队对比也才有基础。
| 维度 | 类别 | 纳入规则 | 是否计入 |
|---|---|---|---|
| 人员 | 全职研发人员 | 统计期内正常在岗，按实际在岗天数计入 | 计入 |
| 人员 | 兼职投入人员 | 按约定投入比例折算，如50%投入按0.5人计 | 计入，需标注折算比例 |
| 人员 | 外包人员 | 由团队管理并承担研发任务时计入，单独标注来源 | 计入，单独列示 |
| 人员 | 实习生 | 有明确研发任务且需指导成本时，按约定比例计入 | 可选，需在口径中声明 |
| 时间窗 | 月度 | 适合常规容量跟踪，按当月实际工作日计算 | 推荐默认口径 |
| 时间窗 | 季度 | 适合规划与预算讨论，由三个月度结果汇总 | 计入 |
| 时间窗 | 迭代 | 按迭代起止日期截取，跨月迭代需拆分归属 | 计入，需说明拆分规则 |
| 粒度 | 团队级 | 由个人结果加总，作为对外结论 | 主口径 |
| 粒度 | 个人级 | 作为明细和核对依据，不单独对外发布 | 明细层 |
人员范围的关键是“是否由本团队管理和调度”。同一名兼职人员若同时服务两个团队，应按约定比例拆分，避免在两个团队重复计入。中途入职、离职人员按实际在岗工作日折算，不按整月计。
时间窗不宜过短。按周统计时，一次全天培训就可能让结果大幅波动，建议以月度为主口径，季度用于规划，迭代用于执行前校验。团队级结果是个人明细的加总，两者必须能对上；若对不上，先检查人员范围和扣减登记，再解释差异。组合层面的项目承接取舍和具体人员排期属于相邻主题，本文只解决“有多少可用人天”的计算。
数据口径：每日可投入工时与扣减项怎么定
口径要解决两个字段：分母用什么、分子扣什么。标准工时是折算分母，通常取每日8小时；每日可投入研发工时是每人每天实际能用于研发任务的上限，通常小于标准工时，因为会议、支持等日常占用客观存在。两者混用会让结果系统性偏高。
| 字段 | 定义 | 取数来源 | 处理规则 |
|---|---|---|---|
| 标准工时 | 折算人天用的每日工时基准，如8小时 | 公司制度统一规定 | 全团队统一，不按个人调整 |
| 在岗工作日 | 统计期内实际应出勤的工作日 | 考勤记录、公司日历 | 扣除法定节假日，按人统计 |
| 每日可投入研发工时 | 扣除固定日常占用后可用于研发的工时 | 历史工时记录测算或团队约定 | 按岗位或团队设定，需注明依据 |
| 请假 | 事假、病假、年假等缺勤 | 考勤系统 | 按小时或天登记，折算人天 |
| 培训 | 内外部培训、认证学习 | 培训计划、日历 | 按实际占用小时登记 |
| 会议 | 例会、评审、跨团队协调会 | 日历、会议记录 | 只计未包含在可投入工时内的部分，避免重复扣减 |
| 值班支持 | 线上值班、客户支持、故障处理 | 值班表、工时记录 | 按实际投入小时登记 |
| 管理事务 | 团队管理、招聘面试、行政事务 | 工时记录、约定比例 | 管理者按约定比例扣减 |
扣减项最容易出错的是重复计算。若“每日可投入研发工时”已经按历史数据扣掉了日常会议，那么会议就不应再单独扣一次；只有超出日常水平的专项会议才追加登记。建议在口径文档中写明：可投入工时覆盖哪些固定占用，扣减清单只登记超出部分。
缺失值的处理要事先约定。未登记工时的天数，可按该人近期平均值估算并标注“估算”；完全无记录的人员，按可投入工时上限计入并在结果中说明。估算比例过高时，结果只能作为参考区间使用，不宜直接用于承诺交付。工时记录、请假和日历数据分散在不同系统时，先统一到“人—日—小时”的明细表，再进入汇总。
计算步骤：从在岗天数到可用人天的公式
公式如下，单位统一为人天，结果保留一位小数：
可用研发人天 = Σ（每人计划在岗工作日 × 每日可投入研发工时 ÷ 标准工时）− 非研发占用折算人天
其中，非研发占用折算人天 = 非研发占用小时 ÷ 标准工时。Σ表示对纳入范围的每个人逐人计算后加总，不能先用人数乘平均天数再统一扣减，否则兼职和中途入职人员会被算错。
分步流程：
- 定范围：列出纳入人员名单，标注全职、兼职比例、外包和实习身份，确定时间窗起止日期。
- 取在岗天数：从考勤和公司日历取每人计划在岗工作日，扣除节假日和个人请假天数。
- 取可投入工时：按岗位或团队确定每日可投入研发工时，写明是否已含日常会议。
- 登记扣减：逐人逐项登记培训、专项会议、值班支持、管理事务的小时数，并折算人天。
- 汇总核对：按人计算后加总，与团队总量、上月结果和需求侧人天对照，检查异常值。
示例口径：标准工时8小时，每日可投入研发工时6小时，则每人每个在岗工作日折算为0.75人天。这个系数让“在岗天数”和“可投入工时”两个来源的数据在同一公式中对齐。
算例：一个五人小组的月度可用人天
以下为演示情景，数值用于说明计算过程。假设某五人研发小组统计2026年3月，当月21个工作日，标准工时8小时，团队约定每日可投入研发工时6小时。
| 成员 | 在岗工作日 | 投入比例 | 可投入工时/日 | 折算人天 | 扣减项（小时） | 扣减人天 | 可用人天 |
|---|---|---|---|---|---|---|---|
| A（全职） | 21 | 100% | 6 | 15.8 | 培训8 | 1.0 | 14.8 |
| B（全职） | 19 | 100% | 6 | 14.3 | 请假16、值班8 | 3.0 | 11.3 |
| C（兼职50%） | 21 | 50% | 6 | 7.9 | 专项会议4 | 0.5 | 7.4 |
| D（中途入职，3月10日起） | 16 | 100% | 6 | 12.0 | 无 | 0 | 12.0 |
| E（全职，兼管理） | 21 | 100% | 6 | 15.8 | 管理事务24 | 3.0 | 12.8 |
| 合计 | — | — | — | 65.8 | — | 7.5 | 58.3 |
逐项核对：A的折算为21×6÷8=15.75，保留一位小数为15.8，扣减8÷8=1.0，可用14.8。B在岗19天，19×6÷8=14.25，取14.3；请假16小时加值班8小时共24小时，折算3.0人天，可用11.3。C按50%投入，21×6÷8×0.5=7.875，取7.9，扣减4÷8=0.5，可用7.4。D从3月10日起在岗16天，16×6÷8=12.0。E扣减管理事务24小时，折算3.0人天，可用12.8。
汇总：折算人天合计65.8，扣减合计7.5，可用人天58.3。手工核对时先加总各人可用人天（14.8+11.3+7.4+12.0+12.8=58.3），再与“总折算减总扣减”对照，两者一致说明逐人计算没有遗漏。若该月候选需求合计70人天，则缺口约11.7人天，需要在需求取舍、外部支持或时间窗调整之间做选择。
兼职和中途入职人员的处理要点是“先按实际在岗天数，再乘投入比例”，两个系数不能互相替代。若D的入职日期跨在统计期中，只计实际在岗部分，不按整月折算。
解读与限制：分母为零、数据不可比与常见误用
结果算出来后，先看它能否支撑结论，再看结论的置信度。可用人天是一个供给估计，与需求人天对比时，两侧口径必须一致：需求侧也应按相同时间窗、相同人天定义统计，否则缺口数字没有意义。
- 分母为零或时间窗过短：标准工时缺失或统计期不足一个完整工作周时，折算结果波动大，应改用更长窗口或直接标注“样本不足”，不输出精确到小数的人天结论。
- 口径不一致导致不可比：不同团队对“每日可投入工时”是否含会议、外包是否计入、兼职如何折算的约定不同，结果不能直接横向比较。跨团队对比前先对齐口径表。
- 只反映供给，不等于产出：可用人天高不代表交付多，它没有考虑任务难度、依赖等待和返工。把它当作产能上限使用，产出和绩效评价需要另设指标。
- 估算比例过高：未登记工时占比大时，结果应作为区间而非确定值，与需求对比时给出乐观和保守两档。
- 单期结果直接外推：某月因集中培训或版本发布导致可用人天偏低，不宜直接作为全年基准，应结合多期趋势判断。
当团队把可用人天纳入月度或季度容量评审时，取数环节可以借助ONES承接：工时记录和工时日志用于登记与导出实际投入，资源视图按工作数量和工时规模呈现成员排期，筛选与分组可查看成员在不同项目的投入比重，资源报表和饱和度明细用于识别规划风险。这样“在岗天数、可投入工时、扣减项”三类数据能在同一套记录中核对，算出的可用人天也便于和需求侧在同一视图下对照。需要说明的是，这些能力支撑的是数据记录与资源投入分析，人天口径和扣减规则仍需团队自行约定并写入口径文档。
常见问题
团队里有人同时服务两个项目，可用人天怎么拆分才不重复计入？
按约定投入比例拆分，并在两个团队的口径文档中写明同一比例，避免两边都按全额计入。拆分时先确定该人在统计期内的实际在岗工作日，再乘各自团队的投入比例，最后分别登记扣减项。若投入比例在统计期内发生变化，按时间段分段计算后加总，不取平均值。跨团队汇总时，把这类人员单独标注，便于核对总量是否超过其实际可用上限。
每日可投入研发工时用历史数据测算，还是由团队直接约定？
两种方式都可以，关键是写明依据并保持稳定。有较完整的工时记录时，可按岗位取近几个月的实际研发投入均值作为测算值，并注明样本区间；记录不足时，由团队按岗位约定一个上限值，例如扣除日常会议和支持后取6小时。无论哪种方式，都要在口径文档中说明该值是否已包含日常会议，避免与扣减清单重复计算。测算值建议每半年复核一次，岗位分工明显变化时及时调整。
某个月可用人天明显偏低，能直接用来判断团队产能不足吗？
单期结果不足以支撑这个结论。集中培训、版本发布、故障支持等都会让某个月的可用人天短期下降，属于正常波动。建议结合连续三个月以上的趋势判断，并核对当期扣减项明细，看偏低是结构性占用还是偶发事件。若多期持续偏低，再与需求侧人天对比，判断是人员配置、非研发占用过高还是需求超出容量，分别对应不同的处理方向。
未登记工时的天数怎么处理，估算会不会让结果失真？
先约定规则再计算：未登记工时的天数可按该人近期平均值估算，并在明细中标注“估算”；完全无记录的人员按可投入工时上限计入，并在结果说明中注明。估算比例较低时，结果可直接使用；估算占比明显偏高时，把结果作为区间呈现，与需求对比时给出乐观和保守两档。长期看，减少估算比例的办法是让工时登记成为日常动作，而不是月底集中补录。
算出的可用人天和需求人天对比时，需求侧要注意什么？
两侧必须使用相同的时间窗和人天定义。需求侧也要按标准工时折算，把需求估算中的小时数统一换算成人天，并确认是否包含测试、文档等配套工作。若需求侧按理想工时估算，而供给侧扣除了会议和支持，缺口会被高估。对比时建议同时列出两侧的口径说明和估算置信度，缺口结论再用于需求取舍或资源申请。
