可用研发人天是团队在给定时间窗内真正能投入研发工作的人天总量，常用口径为：可用研发人天 = Σ（个人日历工作日 × 每日可投入工时占比）− 请假与占用 − 非研发事务占用，再折算成人天。计算前要先固定时间窗、人员范围和工时基准，再逐人扣减请假、培训、值班支持等占用，最后汇总并与需求人天对比，得出缺口或余量。这个结果用于供需判断，不宜直接作为个人绩效依据。
要点总览（TL;DR）
- 可用研发人天 = Σ（个人日历工作日 × 每日可投入工时占比）− 请假与占用 − 非研发事务占用，计算前先固定时间窗、人员范围和工时基准。
- 请假、培训、值班支持按实际占用天数折算人天，半天按0.5天计；缺失数据先标记、保守估计、再复核。
- 五人小组月度算例：基础70.875人天，扣减后约64.1人天，与需求70人天对比缺口约5.9人天。
- 结果用于余量、平衡、缺口的供需判断，不设通用达标线，也不作为个人绩效依据。
- 兼职折算偏差、占用漏记、时间窗错配和工时基准漂移是主要失真来源，需按团队历史数据校准。
评估目标：可用研发人天要回答什么问题
可用研发人天服务于一个具体决策：在某个时间窗内，团队能投入研发的工作量，是否足以承接已排定或待决策的需求。它把“有多少人”转换成“有多少可用的研发投入”，让资源供给和需求排期使用同一单位对话。评估开始前，建议先写清三件事：时间窗、决策用途、结论形式。
常见的决策场景有三类。第一类是承接判断：新需求进入前，比较剩余可用人天与需求人天，判断是否需要调整范围或时间。第二类是排期校验：迭代或季度计划排定后，检查总需求是否超出可用容量。第三类是缺口预警：在时间窗开始前识别供给不足，提前安排外部支持、缩减范围或调整优先级。三类场景对应的时间窗和精度要求不同，月度容量看趋势，迭代容量看排期，计算口径应随之明确。
结论形式建议统一为三种：余量（可用人天大于需求人天）、平衡（两者接近）、缺口（可用人天小于需求人天），并附上缺口的人天数量和涉及的时间段。这样结论可以直接进入排期讨论，而不停留在“人手紧不紧”的模糊判断上。
需要明确的是，这个指标衡量的是团队层面的投入能力，不用于个人绩效排名。个人层面的可用人天受岗位、职级、协作职责影响，差异属于正常现象；把它横向比较会诱导虚报工时或回避支持性工作，反而破坏数据质量。评估目标说明可以按下面的结构填写：时间窗（如2025年3月）、决策用途（如季度需求承接判断）、结论形式（余量/平衡/缺口及数量）。
指标与范围：人员、时间窗与工时基准
计算前先划定边界，否则不同人算出的结果无法比较。范围定义包含四项：人员类别、时间窗、每日可投入工时基准、折算系数。建议把范围定义固化成一张表，每次计算沿用同一张表，只更新数值。
| 范围项 | 取值规则 | 示例 |
|---|---|---|
| 全职研发人员 | 全部纳入，按实际工作日计算 | 后端3人、前端2人 |
| 兼职研发人员 | 按约定投入比例折算，如50%投入按0.5系数 | 兼职测试1人，系数0.5 |
| 外包人员 | 纳入其可承接研发任务的部分，明确是否含管理与验收工时 | 外包开发2人，系数1.0 |
| 时间窗 | 月度、季度或迭代，与决策场景匹配 | 2025年3月自然月 |
| 每日可投入工时基准 | 扣除会议、沟通、行政等固定事务后的研发工时 | 每人每日6小时 |
| 折算系数 | 每日可投入工时 ÷ 标准工作日工时 | 6 ÷ 8 = 0.75 |
人员范围的取舍原则是“是否实际承接研发任务”。全职研发人员全部纳入；兼职人员按约定投入比例折算，并在范围表中注明折算依据；外包人员纳入其承担研发工作的部分，同时明确需求评审、验收等管理工时是否计入，避免同一批工时被重复或遗漏计算。休假中的长期缺岗人员、已确定调离的人员，在时间窗内按实际可投入天数处理。
时间窗的选择与决策节奏对齐。月度窗口适合观察容量趋势和月度缺口；季度窗口适合规划级承接判断；迭代窗口适合排期校验，但迭代长度不一，需在范围表中写明起止日期。不同时间窗的结果不能直接相加或比较，跨窗口汇总时应先统一到同一时间单位。
工时基准决定折算系数。若标准工作日为8小时，团队约定每人每日可投入研发6小时，则折算系数为0.75，一个自然月20个工作日对应15个可用人天。工时基准应来自团队的实际工作节奏，并在多个计算周期内保持稳定；频繁调整基准会让前后结果失去可比性。基准变化时，在结果中注明变更日期和原因。
数据口径与证据：请假、占用和缺失值怎么处理
扣减项决定结果是否可信。每一项扣减都应有明确的记录来源和折算规则，保证任何人拿到同一份记录都能复算出相同结果。建议为每类占用建立口径清单，写明取数来源、折算方式和确认人。
| 扣减项 | 记录来源 | 折算规则 |
|---|---|---|
| 请假 | 考勤或请假审批记录 | 按实际请假天数×当日可投入工时占比折算 |
| 培训 | 培训计划或报名记录 | 按培训占用天数折算，半天按0.5天计 |
| 值班与线上支持 | 值班表或支持工单记录 | 按排班天数折算，跨天支持按实际占用时段折算 |
| 非研发事务 | 会议、评审、行政事务记录 | 超过固定事务基准的部分单独扣减 |
半天和部分占用的折算要统一。半天请假按0.5个工作日计，再乘以当日可投入工时占比；跨天占用按实际覆盖的工作日拆分到每天；一天内多个短时占用可以累加，累计超过半个工作日的按半天计，避免碎片记录导致精度失真。折算规则一旦确定，在同一时间窗内保持一致。
缺失数据的处理原则是“先标记、再保守估计、后复核”。未确认的请假或占用，先按已知信息记录，并在结果中标注为待确认项；对结果影响较大的缺失项，按保守方向估计（即多扣减），并在结论中说明该估计对缺口判断的影响。全员数据缺失或关键扣减项无法取数时，暂停发布结论，先补齐数据。缺失值处理记录应随计算结果一起留存，便于下次复算时对照。
当团队使用工时填报和工作项管理工具记录投入时，请假、培训、支持等占用可以与工作项关联，减少手工汇总。ONES 提供工时管理与资源管理相关能力，可把成员工时、工作项投入和请假记录放在同一套数据中，便于按人、按时间窗导出扣减项。具体字段和报表形式以团队实际配置为准，计算口径仍由本文的规则决定。
计算步骤：从日历工作日到可用人天
公式为：可用研发人天 = Σ（个人日历工作日 × 每日可投入工时占比）− 请假与占用 − 非研发事务占用。其中“个人日历工作日”指时间窗内该成员应出勤的工作日数量，“每日可投入工时占比”即折算系数，“请假与占用”“非研发事务占用”均以人天为单位。公式的分子是可投入的研发工时总量，分母折算为“每人每日标准工时”，最终单位是人天。
计算按以下顺序执行，每一步都保留中间结果，便于复核：
- 确定时间窗内的日历工作日总数，剔除法定节假日和团队统一休息日。
- 逐人计算基础可用人天：日历工作日 × 折算系数。兼职人员先按投入比例调整工作日，再乘折算系数。
- 逐人扣减请假、培训、值班支持等占用，按口径清单的折算规则换算为人天。
- 扣减非研发事务占用中超出固定事务基准的部分。
- 按个人→小组→团队逐级汇总，得到团队可用研发人天。
- 与同时间窗的需求人天对比，输出余量、平衡或缺口结论及数量。
汇总层级要与组织实际一致。个人结果是计算单元，小组结果是管理单元，团队结果是决策单元。跨小组共享的人员（如公共测试、架构支持）只在其主要归属小组计算一次，避免重复计入。汇总时同时保留各扣减项的合计，方便定位缺口来源。
分母为零或全员不可用的情形需要单独处理。若某成员在时间窗内折算系数为零（如全月脱产培训），其可用人天记为零并在备注中说明原因，不参与缺口比例的分母计算。若整个团队在时间窗内可用人天为零，结论直接标记为“无可用容量”，不计算缺口率，避免出现除以零的结果。部分成员不可用时，正常汇总，但在解读时说明可用人天的构成变化。
算例：一个五人小组的月度可用人天
以下为演示情景，数字用于说明计算过程。某研发小组5人，时间窗为2025年3月，当月日历工作日21天，团队约定每人每日可投入研发6小时，标准工作日8小时，折算系数0.75。小组当月需求人天为70人天。
| 成员 | 日历工作日 | 折算系数 | 基础人天 | 请假/培训扣减 | 支持占用扣减 | 可用人天 |
|---|---|---|---|---|---|---|
| 成员A | 21 | 0.75 | 15.75 | 1.5（请假2天） | 0.75（值班1天） | 13.5 |
| 成员B | 21 | 0.75 | 15.75 | 0 | 0 | 15.75 |
| 成员C | 21 | 0.75 | 15.75 | 3.0（培训4天） | 0 | 12.75 |
| 成员D（兼职，投入50%） | 10.5 | 0.75 | 7.875 | 0 | 0.75（支持1天） | 7.125 |
| 成员E | 21 | 0.75 | 15.75 | 0.75（半天请假） | 0 | 15.0 |
| 合计 | — | — | 70.875 | 5.25 | 1.5 | 64.125 |
计算过程：成员A请假2天，按2×0.75=1.5人天扣减，值班1天扣0.75人天，可用人天为15.75−1.5−0.75=13.5。成员C培训4天，扣减3.0人天。成员D为兼职，投入比例50%，日历工作日按10.5天计，基础人天7.875，支持占用1天扣0.75，可用人天7.125。成员E半天请假扣0.375，按0.75计为0.75人天，可用人天15.0。小组可用人天合计约64.1人天。
与需求人天70对比，缺口约5.9人天，约占可用人天的9%。小组可以据此判断：要么压缩约6人天的需求范围，要么通过外部支持或加班补足，要么把部分需求顺延到下一个时间窗。若成员C的培训时间可调整，缺口会缩小到约2.9人天，这为排期讨论提供了具体选项。算例中的每个数字都可以按前文的公式和口径清单复算。
解读与限制：结果怎么用、哪里会失真
可用人天与需求人天对比后，结论应落到具体动作上。余量较大时，可以评估承接新增需求或提前启动低优先级事项；接近平衡时，重点检查需求估算的准确性，预留缓冲应对变更；出现缺口时，明确缺口数量、涉及时间段和可选应对方式（缩减范围、调整时间、补充支持）。对比时使用同一时间窗和同一人天口径，跨窗口比较前先统一单位。
常见失真来源有四类。第一，兼职折算不准：投入比例按约定值计算，实际投入可能偏离，长期偏离时应在下一周期修正系数。第二，占用漏记：值班、线上支持、临时评审等碎片占用容易遗漏，累计后可能显著高估可用人天，建议固定取数来源并定期核对。第三，时间窗错配：用月度可用人天判断迭代排期，或用季度容量判断单周承接，都会放大误差。第四，工时基准漂移：会议和协作负担变化后未更新折算系数，导致基础人天偏离实际。
这个指标不设通用达标线。不同团队的业务节奏、协作密度和支持职责不同，可用人天的合理水平需要按团队自身的历史数据校准。建议连续记录几个周期的可用人天和实际完成人天，观察两者偏差，再调整折算系数和扣减规则。可用人天是供需判断的输入之一，需求估算质量、依赖关系和人员技能匹配同样影响承接结果，单一人天数字不能替代这些判断，也不应作为个人绩效评价的依据。
常见问题
团队里有人月中入职或离职，可用研发人天怎么算？
按时间窗内实际在职的日历工作日计算，不按整月折算。例如某成员3月17日入职，当月剩余工作日为11天，就以11天作为其日历工作日基数，再乘折算系数并扣减占用。离职人员同理，算到最后一个在职工作日。这类人员在汇总时单独标注，便于解读时区分“编制变化”和“占用变化”带来的容量差异。
加班时间要不要计入可用研发人天？
建议不计入基础可用人天。可用研发人天衡量的是常规工作节奏下的可投入能力，加班属于临时调节手段，计入后会让容量看起来比实际稳定供给更大，掩盖缺口。若团队确实计划在某个时间窗内安排加班，可以单独列一行“计划加班人天”，与基础可用人天分开展示，在缺口讨论时作为可选应对方式之一，而不是直接并入供给。
多个小组共用一名测试或架构人员，怎么避免重复计算？
按主要归属原则处理：该成员只在其主要归属小组计算一次，共享服务通过内部结算或分摊比例在需求侧体现，不在供给侧重复计入。如果确实需要按比例分摊，就在范围定义表中写明分摊比例和依据，并保证各小组分摊之和不超过该成员的可用人天总量。汇总到团队层级时再核对一次总量，防止重复。
可用研发人天和实际完成人天偏差很大，先查什么？
先查扣减项是否漏记，尤其是值班、线上支持、临时评审这类碎片占用，它们累计后容易高估可用人天。其次查折算系数是否与实际工作节奏一致，会议和协作负担变化后未更新基准会造成系统性偏差。最后查需求侧的人天估算口径是否与供给侧一致。建议连续记录几个周期，观察偏差方向：持续高估供给，优先修扣减规则；偏差忽高忽低，优先统一估算口径。
迭代周期不固定，还能用这套方法算吗？
可以，把时间窗换成迭代的实际起止日期即可，公式和扣减规则不变。需要注意两点：一是迭代内的工作日要按实际日期逐日核对，剔除节假日和团队休息日；二是不同长度的迭代结果不能直接比较，跨迭代汇总时先折算到同一时间单位（如每人每日人天），再讨论趋势。迭代窗口适合排期校验，容量趋势判断仍建议用月度或季度窗口。
