研发工作日历是把团队在某个时间段内真正可投入研发的日期、工时和人员可用性整理成的一份基准表，用来把“有多少人”换算成“有多少可用工时”。它服务于可用人力供需这一范围，为需求预测、容量核算和缺口判断提供输入，不负责决定接哪些项目，也不负责给具体人员排期。
要点总览（TL;DR）
- 研发工作日历是在给定统计时段内，按人员或团队记录可工作日期、每日可投入工时和人员可用比例，并扣除请假、培训等占用后形成的可用工时基准表，回答“某段时间内有多少研发工时可用”。
- 它由四部分组成：日历基准（工作日、节假日、调休与特殊安排）、人员维度（在岗人数、投入比例、角色分组）、占用项（请假、培训、支持性事务）、时段口径（按周、按月或按迭代）。
- 可用工时的计算链是：日历工作日×每日工时×投入比例，再扣除请假与占用；先按人算再按团队汇总，两种粒度应基于同一份明细。
- 研发工作日历、资源容量规划、人员排期依次回答“有多少可用工时”“需求与可用是否匹配、缺口多大”“谁在什么时候做哪件事”，流程上先有日历基准，再做容量对比，最后排期。
- 最常见的三类误解是：把日历当排期表、忽略投入比例与占用直接用人数乘天数、各部门口径不一致导致汇总失真；口径统一是日历数字可用的前提。
研发工作日历是什么：一句话定义与核心口径
研发工作日历可以定义为：在给定统计时段内，按人员或团队记录可工作日期、每日可投入工时和人员可用比例，并扣除请假、培训等占用后形成的一份可用工时基准表。它回答的核心问题只有一个——某段时间内，这个团队到底有多少研发工时可以用。
这个口径把管理注意力从“人头数”转向“工时数”。十个人和十个人并不等价：有人半投入，有人月中入职，有人整周在客户现场支持，有人跨两个项目分摊。研发工作日历要求把这些差异提前写进基准，让后续的需求评估、容量核算建立在同一套数字上。
需要区分两个相邻对象。人员数量是编制或花名册信息，说明组织里有哪些人；排期表说明谁在什么时候做哪件事。研发工作日历处在两者之间，它把人员信息加工成时间维度上的可用工时，供容量核算使用，本身不承载任务分派。
“工作日历”中的“日历”指时间基准，包括哪些日期算工作日、每天按多少小时计、统计从哪天到哪天；“工作”指研发投入，需要按投入比例折算。两个词合起来，强调的是可投入研发的时间资源，而非一般意义上的考勤日历。
它包含什么、不包含什么：范围与边界
研发工作日历的范围可以用一句话概括：凡是影响“某时段内可用研发工时”的因素，都属于它；凡是涉及“做不做、谁来做、做得怎么样”的决策，都不属于它。把这条线划清，可以避免日历被当成排期表或项目决策表使用。
| 类别 | 具体内容 | 说明 |
|---|---|---|
| 属于 | 工作日、节假日、调休与特殊工作安排 | 决定统计时段内有多少个可工作日 |
| 属于 | 在岗人数、投入比例、角色或技能分组 | 决定每个可工作日折算多少研发工时 |
| 属于 | 请假、培训、支持性事务等占用 | 从理论工时中扣减实际不可用部分 |
| 属于 | 统计时段与口径约定 | 按周、按月或按迭代，全团队保持一致 |
| 不属于 | 项目承接取舍与优先级排序 | 属于项目组合资源容量规划的范畴 |
| 不属于 | 具体人员的任务排期与分派 | 属于研发资源分配与排期的范畴 |
| 不属于 | 工时填报明细与薪酬核算 | 属于工时记录与人事核算的范畴 |
边界清晰带来的直接好处是责任清晰。日历的维护者只需要对“可用工时数字是否准确、口径是否统一”负责；至于这些工时分配给哪个项目、优先级如何调整，由容量规划和排期环节处理。日历数字出错，问题在基准维护；项目排不下，问题在容量匹配或排期决策，两者不应混为一谈。
研发工作日历由哪几部分组成
一份可用的研发工作日历由四个部分组成，每一部分都直接改变最终的可用工时结果。缺任何一块，算出来的数字都会偏离实际。
日历基准：工作日、节假日、调休与特殊工作安排
日历基准确定统计时段内哪些天可以工作。标准双休、法定节假日、调休上班、团队约定的特殊工作安排（如版本发布周的加班日）都应写入基准。影响方式是乘数效应：一个月按22个工作日计与按20个工作日计，可用工时相差约一成，这个差异会直接传导到容量结论。
人员维度：在岗人数、投入比例、角色或技能分组
人员维度把“人”转成“工时”。在岗人数说明基数，投入比例说明每个人有多少时间真正用于研发，角色或技能分组说明这些工时能承担哪类工作。影响方式是折算：一名成员投入比例50%，其可用工时按一半计；按角色分组汇总，则可以看出前端、后端、测试各自的可用工时是否与需求结构匹配。
占用项：请假、培训、支持性事务等非研发占用
占用项是对理论工时的扣减。年假、病假、培训、面试、线上支持、跨部门协作等都会占用研发时间。影响方式是减法：理论工时减去占用工时，得到实际可用工时。占用项如果只在事后统计而不在事前预估，日历就会系统性高估可用工时。
时段口径：按周、按月或按迭代统计
时段口径决定统计粒度和比较基础。按周统计适合短周期迭代，按月统计适合季度规划，按迭代统计适合与需求批次对齐。影响方式在可比性：不同部门用不同口径汇总，数字无法直接相加。口径一致性要求包括起止日期定义一致、每日工时基数一致、投入比例定义一致、占用项范围一致。
可用工时怎么算出来：从日历到容量
计算思路可以写成一条链：日历工作日 × 每日工时 × 投入比例，再扣除请假与占用，得到可用工时。按人算完再按团队汇总，就得到团队层面的容量基准。
下面是一个演示情景，数字仅用于说明计算过程。某研发小组3人，统计时段为某月，该月日历工作日22天，每日按8小时计。成员A投入比例100%，当月请假1天；成员B投入比例50%，无请假；成员C投入比例100%，参加培训2天。
- 成员A：22 × 8 × 100% = 176小时，扣除请假8小时，可用168小时。
- 成员B：22 × 8 × 50% = 88小时，无占用，可用88小时。
- 成员C：22 × 8 × 100% = 176小时，扣除培训16小时，可用160小时。
- 团队合计：168 + 88 + 160 = 416小时。
按人汇总与按团队汇总的差别在于信息粒度。按人汇总保留每个人的可用工时，便于后续排期时判断谁还有余量；按团队汇总只保留总量，适合与需求总量做粗匹配。两种汇总方式应基于同一份明细，先算人再汇总团队，避免团队数字与个人数字对不上。
口径不一致时结果会明显偏离。例如A部门按每日7.5小时计、B部门按8小时计，同样22个工作日，每人每月就差11小时；再如一方把投入比例理解为“占个人时间比例”、另一方理解为“占项目工时比例”，汇总后的团队容量可能相差数成。这类偏差不会在单个部门内部暴露，只会在跨部门汇总和缺口判断时放大。
当团队规模扩大、项目交叉增多时，工时口径统一和人员可用性维护会从一张表变成一项持续的管理动作。ONES 资源管理提供资源规划视图，管理者可以按业务优先级安排团队资源，并通过筛选与分组掌握成员在不同项目中的投入比重；成员每日投入饱和明细可实时查看，便于识别规划风险。这些能力承接的是日历算完之后的管理环节：把可用工时放到具体项目和成员上核对，发现口径或占用与实际不符时及时修正基准。
容易混淆的相邻概念：工作日历、资源容量与人员排期
三个概念常被混用，原因是它们都涉及“人”和“时间”。区分的关键是各自回答的问题不同，产出物也不同，并且在流程上有先后顺序。
| 概念 | 回答的问题 | 主要输入 | 产出 |
|---|---|---|---|
| 研发工作日历 | 某段时间内有多少可用研发工时 | 工作日基准、人员与投入比例、占用项、统计时段 | 按人、按角色、按团队的可用工时基准表 |
| 资源容量规划 | 需求与可用是否匹配、缺口多大 | 可用工时基准、需求工时估算、优先级 | 供需对比结论、缺口或余量、调整建议 |
| 人员排期 | 谁在什么时候做哪件事 | 容量结论、任务清单、人员技能 | 具体人员的任务时间安排 |
三者的先后关系是：先有日历基准，再有容量对比，最后才是人员排期。日历提供分母，容量规划做减法，排期做具体分配。跳过日历直接排期，容易出现“排了但没人有时间做”的情况；跳过容量规划直接排期，则容易在项目之间争抢同一批工时而无人察觉。反过来，只有日历没有容量对比，日历就只是一张数字表，无法支撑决策。
常见误解与一个完整例子
实际使用中，有三类理解最容易出错，它们共同的特点是让日历数字看起来更“好看”，却让后续判断失真。
误解一：把日历等同于排期表。纠正方式是明确日历只到“有多少工时”为止，不写具体任务。一旦在日历里填任务名称，日历就承担了排期职能，后续任务调整会不断回写日历，基准失去稳定性。
误解二：忽略请假与投入比例，直接用人数乘天数。这种算法得到的是理论上限，而非可用工时。纠正方式是先按投入比例折算，再逐项扣减占用，并把占用项的事前预估纳入维护流程。
误解三：各部门口径不同导致汇总失真。纠正方式是在统计前约定统一口径：每日工时基数、投入比例定义、占用项范围、统计起止日期，四项写清楚后再汇总。
下面用一个跨两个月的演示例子把概念串起来。某团队5人，第一个月日历工作日20天，第二个月22天，每日8小时，全员投入比例80%。第一个月有2人各请假2天，第二个月有1人参加培训3天。
- 第一个月理论工时：5 × 20 × 8 × 80% = 640小时；扣除请假 2 × 2 × 8 × 80% = 25.6小时，可用约614小时。
- 第二个月理论工时：5 × 22 × 8 × 80% = 704小时；扣除培训 1 × 3 × 8 × 80% = 19.2小时，可用约685小时。
- 两个月合计可用约1299小时。
假设这两个月排入的需求估算为1400小时，则缺口约101小时，相当于约16个标准人日。这个结论可以直接进入容量规划环节讨论：是压缩需求范围、调整优先级，还是引入外部支持。日历在这里完成的任务，是把“5个人、两个月”翻译成“约1299小时”，并让缺口以工时形式暴露出来。若省略投入比例和占用扣减，直接按5人×42天×8小时计算得到1680小时，缺口会被完全掩盖，排期阶段才会集中爆发。
把日历维护成一项常规动作，还需要在工具层面保持口径一致。ONES 资源和工时管理解决方案支持查看项目和团队的资源利用率及负荷度，并提供工时登记日志明细的查询与导出，项目经理可以据此核对基准工时与实际投入的差异，在下个统计周期修正投入比例或占用预估。日历数字与实际情况的偏差被持续校正后，容量核算的结论才具备参考价值。
常见问题
研发工作日历应该由谁维护，多久更新一次？
维护责任通常落在直接管理研发人力的角色上，例如研发经理、项目管理人员或资源管理岗，由他们按统计周期更新。更新频率与统计口径对齐：按周统计的团队每周更新一次，按月统计的团队每月初更新当月基准。遇到月中入职、转岗、长期请假、投入比例调整等情况，应在变化发生时即时修正，而不是等到下个周期统一补录。日历维护者只需对“可用工时数字是否准确、口径是否统一”负责，项目取舍和任务分派由后续环节处理。
团队里有人同时参与多个项目，投入比例怎么确定才不至于重复计算？
关键是让投入比例在团队层面加总不超过100%。常见做法是先按人确定研发总投入比例（例如某成员50%时间用于研发，其余用于运维支持），再把这50%拆分到各项目。拆分时以同一套定义为准，避免一方按“占个人时间比例”、另一方按“占项目工时比例”理解。跨项目分摊的工时只应在日历中出现一次，容量规划环节再按项目分别对比需求。若成员参与项目较多、比例频繁变动，建议在工具中维护投入比重并定期核对，减少手工汇总的偏差。
节假日和调休每年都在变，日历基准如何保持准确？
做法是把日历基准与人员维度分开维护：先按国家公布的放假安排和团队特殊工作安排（如版本发布周）确定统计时段内的可工作日，再乘以每日工时和投入比例。每年放假安排公布后集中更新一次基准，遇到临时调休或团队约定的加班日单独补录。跨月、跨季度的统计要特别注意起止日期定义一致，否则两个部门按不同工作日数汇总，缺口结论会失真。日历基准的准确性直接影响容量结论，建议在每次容量核算前复核一遍。
请假和培训这类占用项，事前预估和事后统计应该怎么配合？
两者承担不同作用，需要配合使用。事前预估用于容量核算：在统计周期开始前，把已知的年假计划、培训安排、支持性事务写入占用项，从理论工时中扣减，得到可用于需求匹配的工时。事后统计用于校正基准：周期结束后，用实际的工时登记记录与预估对比，偏差较大的部分在下个周期调整投入比例或占用预估。只在事后统计，日历会系统性高估可用工时；只做事前预估而不校正，偏差会逐月累积。两者结合，日历数字才会逐步贴近实际。
小团队也需要单独维护研发工作日历吗？
团队规模小、成员投入比例稳定、项目数量少时，日历可以简化成一张按月的可用工时表，不必建立复杂的多维度结构。判断是否需要正式维护的标准是：是否存在多人跨项目分摊、是否存在明显的投入比例差异、是否需要跨部门汇总工时。只要出现其中一种情况，口头估算就容易出现偏差，值得把工作日基准、投入比例和占用项写下来。团队扩大或项目交叉增多后，再逐步细化到按角色分组、按迭代统计。
